A client is currently using an overhead track of MagneMover Lite (MML) motors and vehicles to store and transport their product. When the product is ready for operations at the ground level, the MagneMotion vehicles carrying the product are sent to elevators that bring them in groups of three to the factory floor, where operators can unload from two racks: an upper and a lower rack.

Since the elevator needs to interface with both the ground racks and the overhead track, we must split the elevator and each ground rack into separate paths with their path beginnings defined by terminus nodes. A Terminus node defines the start or end of a path where vehicles move to or from their current path. When a vehicle is moving from the elevator to a ground rack, it must exit from the elevator terminus node and enter the ground rack terminus node, which accepts the vehicle onto the path. This process is repeated for all three vehicles in either direction, both boarding and departing the elevator.

While the elevator is lowering to the ground racks, a stack light flashes and emits an audible warning to alert operators that vehicles are arriving. Still, the client requested adding two photoeye (PE) sensors and a stop to prevent vehicles from colliding with any operators who are in the way of the arriving vehicles. We worked on a similar MagneMover Lite solution with an elevator system during the pandemic, helping Ginkgo Bioworks optimize their manufacturing process for developing RNA.

Ginkgo Bioworks is working on optimizing the manufacturing process for RNA – the key ingredient in vaccines produced by Pfizer/BioNtech and Moderna. RNA instructs cells to produce proteins that trigger the body to fight the coronavirus. https://t.co/w7tcvlUjpz pic.twitter.com/ZKpIY8Bwb8

— 60 Minutes (@60Minutes) March 1, 2021

Path Suspension

To help our client with this specific motion control request, we initially implemented logic to issue a path suspend command when the PE sensors were tripped. A suspend command causes any vehicle in motion on the path to decelerate and stop based on its current velocity and commanded acceleration.

It is not recommended to issue a stop command to a path while a vehicle is either entering or exiting terminus nodes. Due to this, if a PE sensor was tripped after the first vehicle had departed the elevator and while the second vehicle was in the process of exiting the elevator, there would be a delay before a suspension command could be issued to the ground rack path, causing the first vehicle to continue moving even after the PE was tripped.

Implementing the Stop Command

MML does not contain an explicit “stop” command; instead, you can issue a move command with a velocity of zero, keeping all other parameters (acceleration, path number, position, move direction, PID set) the same. Once you are ready for the vehicle to move again, you issue another move command with a nonzero velocity.

To implement the stop command, we cached the velocity, targeted position, and MoverID (unique ID assigned to MM vehicle) of each vehicle that was on a ground rack when the PE sensor was triggered. The cached velocity was used to ensure that any vehicle with a non-zero velocity was issued the “stop” command when a PE sensor was triggered. The targeted position was then used to reissue the same move before the vehicle was ordered to stop. The MoverID of each vehicle was cached after it was commanded to stop, allowing us to confirm all carriers on the path have been commanded to stop if the PE sensor has been triggered.

This solution was implemented across four elevators, each with two ground racks, and our Automation team has received only positive feedback from the client about the vehicles’ improved stopping times.

The post How to Issue a Stop Command in MagneMotion MagneMover Lite appeared first on DMC, Inc..

In this blog, we’ll discuss in detail how to manage traffic in your MagneMotion systems to prevent traffic jams and optimize your track’s efficiency.

MagneMotion Guide Series

• MagneMotion Guide Part 1: Creating Configuration Files
• MagneMotion Guide Part 2: Starting up and Commissioning a Track
• MagneMotion Guide Part 3: Controlling a System with a PLC
• MagneMotion Guide Part 4: Using Path and Station AOI’s
• MagneMotion Guide Part 5: Alternative Routing Controls
• MagneMotion Guide Part 6: Track Recovery Considerations
• MagneMotion Guide Part 7: Traffic Lights
• MagneMotion Guide Part 8: Simulation
• MagneMotion Guide Part 10: Moving Track

Typical Traffic Issues

There are a few typical sources of traffic jams in a MagneMotion track:

Source 1

The first, and often most frequent traffic jam, occurs when too many vehicles are sent to a branch of track. This causes the branch to overflow with vehicles and blocks off the rest of the track.

Source 2

Another less frequent but problematic jam can occur when too many vehicles are trying to circulate through a central loop of track in the system. This can create a situation where no vehicles can pass through.

Source 3

The final common case occurs when vehicles need to be sent backwards on your track. When not done carefully, this can result in deadlocked vehicles that get in each other’s way.

Below, we’ll go through a way to organize your PLC program to prevent any such traffic jams from occurring.

Step 1: Monitoring Stations

The first step is to organize how the PLC program handles calls of the Station AOI.

First, create a data type that will contain the station AOI instance along with the following information:

• A Boolean tag to enable the station
• A Boolean command to send vehicles from the station
• A dint to store the next station vehicles will be sent to
• A dint to store the number of vehicles headed to the station
• A dint to define the number of vehicles allowed to go to the station at a time

Now, create an arrayed tag that will store all of this information for each station on your track.

Keeping all of the station information in a single centralized location will make it much easier to handle any complex routing logic.

Next, you need to create some structured text logic to monitor each station for incoming vehicles.

By looping through the mover array in the MagneMotion device handler, you can check how many vehicles are headed to any given station. This will give you valuable insight into which sections of your track might be in danger of developing traffic jams without having to deal with the tricky logic of manually keeping track of all of the vehicles sent to a station.

Step 2: Monitoring Paths

The second step in this setup is to create a similar udt to the one you made for stations. This path udt will contain the following information:

• A variable for the contents of a path
• The size of the path
• A Boolean for whether or not the path is full

Next, you’ll create another structured text code for monitoring the contents of each path.

The above code will determine how many vehicles are currently on each path, allowing you to determine which sections of your track are already filled with vehicles.

For efficiency’s sake, you can combine the path monitoring and station monitoring code into a single for loop.

Step 3: Check if a Station is Full

So now that your PLC code is monitoring the status of all your stations and paths, how do you use that information to robustly manage your MagneMotion track?

If you populate iPathSize and iNumAllowedIncoming values for your paths and stations, you can use some fairly simple logic to determine when a station is able to accept any new material.

First, create a simple for loop to determine whether any paths are filled with vehicles.

Next, create some complimentary logic for determining whether any stations have too many vehicles being sent to them.

Note that, to check if a station is full, we must also check to see whether the path it’s on is full. This way, we will account for cases when a station is being backed up by vehicles that are going to another station.

Also note that, if a path’s size or a station’s number of allowed incoming vehicles is 0, we will assume that the station/path is not full. This allows us to ignore paths and stations that will never cause traffic issues and reduce some of the overhead in setting up your track’s program.

Step 4: Sending Vehicles

Since you have information on each station, you can use this information to check a station’s availability before you send another vehicle to it. You can do this piecemeal by just checking the bStationIsFull bit before directing vehicles to particularly problematic stations, but I find it’s usually better to integrate this check into your station logic for a more robust solution.

Compare the above logic to the station logic in MagneMotion Guide Part 4: Using Path and Station AOIs. Here, we will check whether the target destination is full before we send the current vehicle at this station to any destination. This way we can be confident that we won’t cause any traffic jams with the vehicles that are leaving this station.

Also note how we latch the bit for checking if the destination station is full as we send a vehicle to it. This ensures that a station will only be sent one vehicle in a single PLC scan so that we don’t send multiple vehicles to one station before it’s capacity can be re-evaluated. If the station has room for multiple vehicles the bStationIsFull bit will be reset in the next scan, allowing another station to send its vehicle.

Step 5: Preventing Loop Blockage

The issue of too many vehicles stopping up a loop of track was also brought up in MagneMotion Guide Part 7: Traffic Lights. Here we will go into more detail about how to actually develop the logic to trigger traffic lights.

Using the path information compiled in Step 2, we can easily determine how many vehicles are in the loop of track.

From here, it is fairly straightforward to set up a basic system where when the number of vehicles in the loop exceeds a set value, we turn on traffic lights at each entrance to the loop. At this point, no more vehicles will be able to enter the loop while vehicles will still be able to exit the loop freely.

Step 6: Backup Permissions

If you find you need to send a vehicle in reverse direction down your track, you can also safely do this by monitoring path contents.

For example, say you have a vehicle on a branch of your track that needs to back up back onto your main loop of track before continuing along.

If you set up a traffic light on the main section of track and turn it red while there are no vehicles on the path you need to back up onto, you can be confident that you can back up your vehicle without causing a deadlock with a vehicle headed the other way.

Overview

Now that your PLC program is set up to monitor paths and stations, you are ready to further develop your MagneMotion track for maximum efficiency. These station and path checks are not meant to compose an entire routing system, but they are valuable building blocks for defining your own routing system.

While only a few use cases for station and path monitoring have been shown here, the general tools these tactics provide can be used in a variety of ways and different systems to help guarantee that your track runs smoothly.

The post MagneMotion Guide Part 9: Traffic Jam Prevention appeared first on DMC, Inc..

Simulation can be a powerful tool for testing things out on your system, especially if you’re waiting on long lead time hardware to actually commission your system. Fortunately, MagneMotion has a very simple Simulation setup that works very reliably.

MagneMotion Guide Series

• MagneMotion Guide Part 1: Creating Configuration Files
• MagneMotion Guide Part 2: Starting up and Commissioning a Track
• MagneMotion Guide Part 3: Controlling a System with a PLC
• MagneMotion Guide Part 4: Using Path and Station AOI’s
• MagneMotion Guide Part 5: Alternative Routing Controls
• MagneMotion Guide Part 6: Track Recovery Considerations
• MagneMotion Guide Part 7: Traffic Lights
• MagneMotion Guide Part 9: Traffic Jam Prevention
• MagneMotion Guide Part 10: Moving Track

Requirements

To simulate a MagneMotion track, you will need a physical Node Controller that will run the actual simulation. Even if your system will need multiple Node Controllers, you typically only need a single Node Controller to run that track in simulation mode as long as your entire track can fit on a single High Level Control group.

While you can get some value out of a simulation of just a Node Controller and an NC Host, you will also likely want to have a physical PLC to run your controls software on so that you can more fully test out your routing logic.

For the purposes of this blog, we’ll assume you already have a configuration file for your Node Controller (MagneMotion Guide Part 1: Creating Configuration Files) and a PLC project to use for simulation (MagneMotion Guide Part 3: Controlling a System with a PLC).

Updating the Configuration Files

The first step in simulating your track is to update your configuration file to include simulated vehicles.

If you cannot see the simulated vehicles under the Paths of your system, go to Options > Show Simulated Vehicles to display them.

Now, open whichever path you want to place your simulated vehicles on, right click on Simulated Vehicles, and select “Add To End.” This will create a simulated vehicle that will appear on that path on startup in the specified location.

Repeat the above steps to create as many vehicles as you want for your simulation. Make sure to separate the vehicle locations so that they are not all in the same spot, and do not add more vehicles than what can fit on the path.

Simulate the Node Controller

Now that you have an updated configuration file, go to the Node Controller web page and upload the new configuration file.

Once that is done, go to the IP Settings page of the Node Controller and check the box that says “This box is a High Level Controller Simulator” under Configured Functions. Make sure that the other two boxes are unchecked.

Next, hit the Apply Changes button and reboot the Node Controller. When that is done, you should be all set to run your simulation.

To verify that it worked, openNC Host (MagneMotion Guide Part 2: Starting up and Commissioning a Track), attempt to reset, and then startup the paths on your simulated Node Controller. If everything is working properly, you should be able to see the simulated vehicles you added to the configuration file.

PLC Simulation

There should not be a need for PLC code changes to get your PLC to work with a simulated Node Controller. As far as the PLC is concerned, a simulated Node Controller and a Node Controller running an actual line of MagneMotion track are the same thing. The logic for connecting to the controller, sending commands to it, and interpreting messages from it should all be the same in a simulated environment.

This does not mean it is impossible for new issues to arise once the PLC program is moved to work with a non-simulated Node Controller, however. The time it takes the Controller to run various instructions will be different in a simulated Controller, so watch out for race conditions.

It is also entirely possible that the Node Controller will pass back slightly different messages to the PLC while it is being simulated, and there are numerous errors and fault conditions that can only appear when using actual MagneMotion track that a simulation will not catch.

Simulation Tips

While you are simulating your system, there are several important things to keep in mind.

First, always remember that — while the MagneMotion simulation does a great job simulating routing vehicles along a representation of your track — there will always be additional considerations with a physical system. Any physical considerations like vehicle nest collisions, unbalanced vehicles, or devices interacting with the MagneMotion track will not be accounted for in the Simulation.

Second, it is also important to attempt to simulate a variety of conditions in your system. Typically, the easiest way to do this is to regularly modify your configuration file to have different amounts of vehicles and change where vehicles are positioned on the track, but additional variety should be added by manually redirecting vehicles around the track to ensure that all the routing edge conditions are checked.

A physical environment is much less predictable than a simulated environment, so it is important to make sure that the routing software is not only tested for a single, ideal set of conditions.

Positive Things to Verify Through Simulation

1. Station Layout

Having your track simulated is a good opportunity to verify your overall track layout. While you cannot fully verify that your track layout is ok in simulation, you can make sure that the Node Controller is able to send vehicles from point A to point B without issue. This will allow you to catch various errors that can stem from configuration file issues

2. General PLC and Node Controller communication

Since the Node Controller communicates to the PLC in the same way, regardless of whether it is a simulated controller, simulation offers a great chance to test PLC communications. The configured connection to the Node Controller, along with all of the array lengths used in the MMI tags passed between the Controller and the PLC, can all be verified in simulation

3. Routing Logic

The main thing to test in any track simulation is whether the PLC logic works. All logic surrounding whether the PLC is telling which vehicles to move, the location to which they should move, and at what time, can typically be very robustly simulated.

This is a great chance to test if vehicles are being told to go to the right stations and to verify that the PLC is appropriately tracking any information associated with each vehicle. Keep in mind that there will potentially be some differences with the various reactions the Node Controller has to PLC commands that could affect the functionality of the PLC logic.

4. Traffic Light Operation

Traffic lights can be fairly reliably simulated; however, keep in mind that, since the timing of Node Controller actions will vary between a simulated controller and running actual track, any time sensitive traffic light operations cannot be tested (ex. if you want to set a traffic light red before a vehicle gets to the end of a path, you would not be able to properly test the timing of the traffic light in simulation.)

Also, keep in mind that the ICT library blocks for handling traffic lights are relatively new, so they are liable to have fault messages pop up when running on an actual track that might not show up during simulation.

5. System Throughput Estimations

While simulation is not suited for calculating exact throughput calculations, it can be a very useful way to get a rough benchmark of your system’s throughput. It is fairly easy to modify your PLC code to use a variety of timers to test how quickly your system can run and to see how long it will take vehicles to cross your track.

6. Traffic Jam Analysis

Simulation can also be a valuable tool for testing whether your system has any concerning traffic jams that might need to be addressed. Simulation is a great time to answer questions like: Does sending too many vehicles to Station A block off Station B? If vehicles leave Stations C and D at similar times, do they get in each other’s way?

By varying the number of simulated vehicles on your track and the starting locations of those vehicles, you can robustly test routing vehicles across your system to get an early diagnosis of any lingering traffic considerations.

Negative Things to Verify Through Simulation

1. Vehicle spacing and collision avoidance

Theoretically, the vehicle length set in the MagneMotion configuration file will prevent any vehicle collisions, but, in practice, it is always a good idea to thoroughly verify that vehicles placed close to each other will not collide when going through switches or when going around hairpin turns. Take special care if your vehicles are notably wider than the MagneMotion pucks.

It is likely you will also need to fine-tune the positions of many of the stations and traffic lights of your system; while a first pass of this can be done in simulation, the final values for these positions should be set during the commissioning of the physical track.

2. Track Startup

The general function of any startup logic can be tested in simulation (configuring MM communication, resetting paths, creating traffic lights, etc.); however, since one of the main purposes of startup logic is to recover from faults, it is very difficult to verify that it recovers from issues. This is because simulated tracks will always start from an ideal clean slate.

Feel free to run some tests on startup logic for simulation, but do not assume a startup sequence that works in simulation will also work with a physical track.

3. Station Positions

Since station positions are generally affected by physical factors like robot arms, device positions, or Operator preference, it is generally best to hold off on fine-tuning station positions until you are working on the physical tracks.

4. Node Controller Load

In the General Status page of the Node Controller webpage, there is a value for the load average of the Node Controller. These values should always be less than 1 (ideally less than 0.8). If the values for this get too high, it is an indication that your Node Controller is overloaded. Simulation will typically have very low Load Averages, but this is not an indication that the actual implementation of the track will have similarly low load averages.

5. Networking

Since a simulated Node Controller will not be networked to the various MagneMotion motors, do not assume that the PLC and the Node Controller networking is fully functional from simulated tests alone.

6. MICS File

Simulation testing will not verify whether the MICs file has the correct MAC addresses or the correct orientations for motors.

7. Terminus Node Handling

There have been issues simulating Terminus Nodes and having vehicles enter and leave through them. While there have been some recent MagneMotion firmware updates that should improve this issue, you should still be extra careful when testing Terminus Node behavior after simulation.

Topics to look forward to in this series: 

• MagneMotion Guide Part 9: Traffic Jam Prevention

Learn more about DMC's MagneMotion expertise and contact us to get started on your next project. 

The post MagneMotion Guide Part 8: Simulation appeared first on DMC, Inc..

In this blog we are going to cover alternative methods for controlling how vehicles move along your MagneMotion track using utilities found in the ICT library.

MagneMotion Guide Series

• MagneMotion Guide Part 1: Creating Configuration Files
• MagneMotion Guide Part 2: Starting up and Commissioning a Track
• MagneMotion Guide Part 3: Controlling a System with a PLC
• MagneMotion Guide Part 4: Using Path and Station AOI’s
• MagneMotion Guide Part 6: Track Recovery Considerations
• MagneMotion Guide Part 7: Traffic Lights
• MagneMotion Guide Part 8: Simulation
• MagneMotion Guide Part 9: Traffic Jam Prevention
• MagneMotion Guide Part 10: Moving Track

Step 1: Using the MPM AOI

While the Station AOI is typically how you should route vehicles, the MPM AOI is actually the simplest way to have a PLC move a MagneMotion vehicle. 

A call of the MPM AOI sends a position command to the Node Controllers to move a particular vehicle to a specified position on the track. Conversely, the Station AOI sends position commands to move particular vehicles to specified positions with some additional handling logic to facilitate moving vehicles between several commonly used positions, along with some additional checking to determine when a vehicle reaches a station.
 
Like the Station and Path AOIs from the previous blog, the MPM AOI requires inputs from the \raM_Dvc_DH_MM program that was imported from the ICT Library.

The MPM AOI also needs the following information along with the Handler and Mover tags:
•    Cfg_MoverID: The ID of the vehicle you wish to move.
•    Cfg_MoveType: The direction vehicles take when leaving the station to go to their next destination: 0 = Shortest Direction, 1 = Positive Direction, 2 = Negative Direction (It is usually a good idea to use Positive or Negative direction to make your station more predictable and avoid traffic issues.)
•    Cfg_Path: The ID of the path you want to move the vehicle to.
•    Cfg_Position: The distance in mm from the start of the path that you want to move the vehicle to.
•    Cfg_Velocity: The speed in mm/s that you want to move the vehicle.
•    Cfg_AccelDecel: The acceleration in mm/s^2 for the vehicle.
•    Cfg_PID: This will determine which PID settings the vehicle uses to move if you defined separate PID controls in the configuration file.

Once the MPM AOI is called, it will trigger the vehicle to move to the desired position and the output status Sts_IP will go high for the duration of the move. When the move completes, Sts_IP will go low and be replaced with Sts_PC to indicate that the move has finished.

One important thing to note is that if a vehicle is re-routed before it reaches its destination (ex. You redirect the mover to a station after it has begun its move) the MPM AOI will throw an error. However, this doesn’t indicate a problem in your code, it’s just an indication that the vehicle was not able to complete the move that the MPM AOI commanded it to do.

While most of your system’s routing should be handled by the Station AOIs, the MPM AOI is valuable for filling in any gaps in routing that the Station AOI doesn’t cover.

Step 2: Changing Vehicle Destination on the Fly

When designing your system, it’s entirely possible that you will want to redirect a vehicle that is already headed to a particular position or station. Maybe you want a button that will send all vehicles to some sort of home position no matter what. Or maybe you want to be able to divert incoming vehicles to a different route if your code detects a potential traffic jam. Or maybe you just think it would look cool if vehicles didn’t have to stop at certain stations before going to their next destinations.

On the surface, changing vehicle destinations mid-move is pretty simple, you can change the TargetID of the vehicle in the Mover array in the ICT library raM_Dvc_DH_MM program. 
 

You can update the TargetID of Mover 3 to Station 4 from Station 3 and the Mover will update its destination and redirect itself to Station 4. Similarly, you could trigger an MPM AOI call to redirect Mover 3 to an entirely different position. However, redirecting vehicles like this comes with some additional risks and considerations. 

The first thing to note is that the Node Controllers will not allow for changing the speed or acceleration of a vehicle while it is already moving. Sending an MPM command to a moving vehicle that has a different acceleration than the vehicle’s current acceleration will often result in the vehicle being labeled “Suspect” and unable to move.

Another important thing to consider is that when you command a vehicle to go from Station A to Station B ,the vehicle’s acceleration, velocity, and move type come from Station A’s parameters. This means that if you want to change these parameters for a vehicle you should do so while the vehicle is stopped at a station. 

The final thing to consider before redirecting a vehicle mid-move is that it can increase the likelihood that you will command a vehicle to perform a move that is impossible for it to finish, or one that will result in a traffic jam.

For example, if you try to redirect a vehicle that is going to Station 2 to Station 3, it’s possible that the vehicle will have already passed the point of no return and will have no valid path to reach Station 3 when it is redirected. This will cause the vehicle to stop at Station 2 without Station 2 registering that there is a vehicle there, which will cause Station 3 to fault out. 

Similarly, if you command a vehicle to go from Station 1 to Station 2 in the positive direction, when you try to move that same vehicle back to Station 1 it will be unable to complete the move since it will be going in the wrong direction.

Step 3: Controlling Vehicles Through Nodes

Since it is fairly easy to cause problems when redirecting moving vehicles, the question that arises is: what is a good way to tell when it is ok to redirect a vehicle to a different station? Of course, there is no single answer to this question, each system has its own quirks and needs. While it is possible to monitor the path and position status of every vehicle and make decisions based on that, those calculations can get intensive in terms of how long they take to program and the amount of PLC resources they take up. One method that is often useful in determining what to do with a moving vehicle is monitoring the status of a node.

In the MMI_node_status tag you can find a status returned from the Node Controller of which vehicle is currently passing through that node. 

This Vehicle_ID value will be 0 when there is no vehicle in the node and will match the ID of the vehicle passing through the node until that vehicle has fully passed through.

Say for example you wanted to redirect any vehicles that were about to reach Station 1 to Station 2 (maybe because Station 1 already had several vehicles queue up at it, or it was temporarily disabled). By monitoring Node 2’s status, we can see which vehicles are on the way and modify their target station when they are in a controlled position to make sure we can redirect any incoming movers without causing any issues with our system.

The above snippet of code will monitor any vehicles passing through Node 2. If it sees a vehicle heading to Station 1, it will verify that it has the correct move type to go to Station 2 and then update its target ID to redirect it. This is a fairly simple robust way to redirect vehicles in a way that we know will not fault out Station 2 or lead to a vehicle being stuck on the track.

Topics to look forward to in this series: 

• MagneMotion Guide Part 6: Track Recovery Considerations
• MagneMotion Blog Part 7: Traffic Lights
• MagneMotion Blog Part 8: Simulation

Learn more about DMC’s MagneMotion expertise and contact us to get started on your next project.

The post MagneMotion Guide Part 5: Alternative Routing Controls appeared first on DMC, Inc..

MagneMotion Guide Series

• MagneMotion Guide Part 1: Creating Configuration Files
• MagneMotion Guide Part 2: Starting up and Commissioning a Track
• MagneMotion Guide Part 3: Controlling a System with a PLC
• MagneMotion Guide Part 5: Alternative Routing Controls
• MagneMotion Guide Part 6: Track Recovery Considerations
• MagneMotion Guide Part 7: Traffic Lights
• MagneMotion Guide Part 8: Simulation
• MagneMotion Guide Part 9: Traffic Jam Prevention
• MagneMotion Guide Part 10: Moving Track

Step 1: Using the Path AOI

One of the backbones of the ICT library structure is the Path AOI. This AOI allows you to command paths from the PLC in a similar manner to the way paths can be controlled from NC Host (For details on how to use NC Host see MagneMotion Guide Part 2: Starting up and Commissioning a Track).

To setup the AOI, make sure that the Ref_Handle input is set to \raM_Dvc_DH_MM.Hndl and that Ref_Paths is set to \raM_Dvc_DH_MM.Hndl .\raM_Dvc_DH_MM.Hndl is a reference to the main ICT device handler task we generated in the last blog. If you have re-named your task, be sure to use that name instead.

Set the Cfg_TargetPath input to the path you want to send a command to. If you would like to command every path at once, leave Cfg_TargetPath as 0. 

Cfg_Command will be different depending on which command you want to send to the Path:

In the example below, once bCmdPath is triggered the Path AOI will begin sending a command to the Node Controller. You will see the Sts_IP output of the AOI turn true while the command is being executed by the Node Controller. You can watch the path status change in NC Host to follow along. When the command is done you will either see the Sts_PC bit turn on, indicating that the command is done, or you will see the Sts_ER bit to indicate that there was an issue completing the command.

If the command fails and an Error code is returned, look at the tags Sts_ERR and STS_EXERR of your AOI for the error code and extended error code. Then, look up what they mean in the AOI help file.

Step 2: Understanding MagneMotion Stations

In a MagneMotion system, a Station is a defined position on a path. Since Node Controllers typically control vehicles through a command that includes a vehicle ID, a Path ID, and a position value, Stations are a useful way to handle vehicle commands. You can simply tell a Vehicle to go to Station A without knowing exactly where Station A is positioned, or tell the vehicle at Station A to go to Station B without knowing which vehicle is in that exact position.

Before you start using the ICT Station AOI, it is important to know that Stations used by the PLC and Stations established in the Node Controller Configuration are two different things.

In the Configuration file you can define stations as points on paths with a specified ID. These stations are hard coded and cannot be modified without changing the configuration files. They are also not included in the information that is sent between the Node Controller and the PLC, so they are not a very useful tool for PLC controlled systems.

 
The stations used in the ICT library on the PLC are also defined as a position on a particular path but they are more flexible to use. These stations are defined by using the Station AOI and are only used by the PLC code. The Node Controller will have no knowledge of what these stations are or that they even exist. 

For example, if station 4 is 500 mms down path 5 and the PLC tells vehicle 12 to go to station 4, the MagneMotion device handler on the PLC will send a command to the Node Controller to send vehicle 12 to 0.5 meters down path 5. 

Another important thing to note is that a vehicle is only considered to be at a station when its target ID is that station and the Node Controller has confirmed that the vehicle has reached its destination. The PLC does not run any checks for vehicles near the position of a station. This means that a vehicle can be in the exact position of a station, but the station will think there is nothing there. This can be a very useful way to prevent the station from thinking it has a vehicle in the event a vehicle is routing through where a station is located but not stopping there.

Unfortunately, this also means that the Station AOI does not actually verify that the vehicle it thinks is present is actually at the station. If a vehicle is on its way to a station and you command it to go to another location via NC Host, the Station AOI will think the vehicle has arrived at its station once it has stopped, even if it is in an entirely different location. This is because it will receive a “move finished” acknowledgement from the Node Controller.

The good news is that as long as you do not command vehicles through NC host while the PLC is trying to control them through Station AOIs, the PLC device handler is sophisticated enough to keep things neat and tidy. However, be wary of using NC host commands while the PLC is controlling the Node Controller.

Step 3: Using the Station AOI

Much like the Path AOI, the station AOI needs the device handler tag from the \raM_DVC_DH_MM program along with the Mover tag from that same program as inputs.
Other Station AOI Inputs:
•    Cfg_Station ID: The numerical ID of the station (make sure no two stations have the same ID)
•    Cfg_Path ID: The ID of the path that the station is on
•    Cfg_Position: The distance in mm of the station position from the beginning of the path (Make sure you do not put in a position that is longer than the actual path)
•    Set_MoveType: The direction vehicles take when leaving the station to go to their next destination: 0 = Shortest Direction, 1 = Positive Direction, 2 = Negative Direction (It is usually a good idea to use Positive or Negative direction to make your station more predictable and avoid traffic issues)
•    Set_Velocity: The target velocity of vehicles that leave the station in mm/s
•    Set_AccelDecel: The acceleration of vehicles that leave the station in mm/s^2
•    Set_PID: The PID controls for the vehicle leaving the station. PID controls are defined in the configuration file. If is fine to leave this as 0.
•    Set_NextTargetID: The ID of the station the vehicle will go to after this one
•    Cmd_ProccessCompleted: A command to tell the station to forward a mover onto the next station

 
While using the Station AOI the configuration inputs to the AOI can be changed while the system is running, but you should be careful when doing so. Changes to the station will only affect vehicles that leave the station after the change is made.

For example, if Vehicle 10 is told to go to from Station 4 to Station 5 at 500 mm/s but then the Set_Velocity of Station 4 changes to 250 mm/s before it arrives, Vehicle 10 will keep moving at 500 mm/s until it arrives at Station 5.

Additionally, if Vehicle 11 is on its way to Station 4 and the Cfg_Path of Station 4 is changed from Path 6 to Path 7, then Vehicle 11 will still go to Path 6 and Station 4 will still consider Vehicle 11 to be at its station even though they are on different paths.

Step 4: Moving Vehicles to Stations

In order to get vehicles to move between stations, you must get a vehicle to a station first. Fortunately, this is fairly simple.

Expand the Mover tag in the raM_Dvc_DH_MM program. In the tag for TargetID, set the value to the station you want the vehicle to go to and the Device Handler will automatically send a command the Node Controller to move the vehicle to the desired station.

Now that the Station is set up and you can send vehicles there, you can start moving vehicles from one station to the next. As you can see in the snippet of code below, when bSendFromStation is toggled, whichever vehicle is at Station 1 will be sent to Station 2.

 
Note that Station 2 must also be configured and properly set up for this to work. There must also be a valid path that a vehicle can take to get from Station 1 to Station 2.

At this point, you must also call the station that the mover is being sent to. In the code above, if bDisableStation was on a station trying to send a vehicle to Station 1, it would make that vehicle wait in place while the station was disabled.

When moving vehicles to stations, it is very important to make sure that the vehicle has a valid route to the target station. If it does not, the target station will fault out and any other vehicles that get sent to that station will be unable to move there until the fault is clear.

To reset the error of a faulted station, go into the mover array and clear out the target ID of whichever mover caused the fault. Then stop calling the station for at least one scan, after which you can resume calling the station. This re-initializes the station and clears out the fault. In the code snippet above, toggling bDisableStation will effectively reset any path faults.

Topics to look forward to in this series: 

• MagneMotion Guide Part 5: Alternative Routing Controls
• MagneMotion Guide Part 6: Track Recovery Considerations
• MagneMotion Blog Part 7: Traffic Lights
• MagneMotion Blog Part 8: Simulation

Learn more about DMC’s MagneMotion expertise and contact us to get started on your next project. 

The post MagneMotion Guide Part 4: Using Path and Station AOIs appeared first on DMC, Inc..