A quick reminder: NC host is used to monitor the status of MagneMotion controllers, motors, and movers. The NC host IP address should be the node controller.

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 9: Traffic Jam Prevention
• MagneMotion Guide Part 10: Moving Track
• MagneMotion Blog Part 11: Tuning

Track Graphic Files

Track graphics are files with the .mmtrk extension that are used to help visualize a MagneMotion system when using NC Host. For general information, see MagneMotion Guide Part 2: Starting up and Commissioning a Track.

Typically for MagneMotion Lite systems, track graphics are generated in the Magnemotion Configurator tool by going to File -> Export -> Create MMTRK File From Config 

Below is an example of a track layout file. 

Here is that same track’s corresponding .mmtrk file visualized in NC Host.

When monitoring the track graphic in NC Host, you can easily see where each vehicle is on the track. By hovering over track segments, you can also see which path of the track you are hovering over. 

These .mmtrk files are simple text files which can be opened in the text editor of your choice. If needed, you can also modify the track file to better fit your system. 

The track file components are simple. Each section starts with a comment describing the path that the section of the text file is defining. If you are making changes to a track file, it is advisable to include additional comments on whatever change is being made.  

Next, the track file defines the path connection. The path_start #a #b line indicates that you are defining path #a that has a previous path of path #b. Note that some paths have multiple previous paths defined in the configuration file, but only one previous path needs to be defined in the track file. This is because the track file is only concerned with the physical location of the path, not how it links to the rest of the system. 

Following the path definition, the file will contain information on each motor in the path. Starting from the first motor, there will be a line that contains the motor type and the motor’s direction. This direction corresponds to the orientation of the motor in the track graphic file. Everywhere the track turns, this direction should change for the next motor. 

In the examples below, note that the direction changes from “left” to “right” after the “motor_r_curve” entry to ensure that the track graphic follows the actual track layout from the configuration file. 

In track layout files, there are no separate definitions for switches. Instead of having a single entry for a switch on the track, there will be an entry for each path that the switch is on for both the straight and curved section of the switch. 

For example, for a right switch that merges paths 3 and 4, one path will have a “motor_q_meter” entry for the straight section of the switch, and the other path will have a “motor_r_curve” entry for the curved portion of the switch. 

In addition to defining the track, you can also modify the track graphic to change how vehicles are displayed in NC host. Adding a line setting the vehicle_size will change the size of the vehicle graphic displayed in NC Host to better match your system. 

Note that NC Host doesn’t do any verification that the track graphic you are using lines up with the configuration file of your system. If you end up using the wrong .mmtrk file, NC Host will still display the graphic and attempt to display where vehicles would be on the track even if path lengths and orientations do not match up. 

Disjointed Tracks

There are unfortunately some limits in the track graphics that can be created by the MagneMotion configurator tool. If any track is “disjointed” (i.e. completely separated from the rest of the track), then the configurator tool will be unable to generate the track file for that system. However, you are still able to create the track file for that system manually. 

Let’s say we have a MagneMotion Lite track where the majority of the track is in a loop on the ground. A part of this loop is a section of track that can be raised to connect to a stretch of track that is suspended by the ceiling. So, we have one track system that is split into different sections. 

You can’t get this track file directly from the configurator, but you can start by making the paths of just the ground track and creating a .mmtrk file from that partial section of track. 

Now, to add additional track segments to this file, we need to create a disjointed track section. We do this by adding another line that starts with “track_start” followed by parameters that determine where in your graphic the disjointed track will appear. For each new disjointed track added, you need to input the distance and angle from the very start of the track file to the start of your disjointed track. Then you simply need to add paths/motors to the file to match your system. 

If you’re having trouble calculating the position your added track can be in, you can always just display the track graphic to check the position and adjust as needed. 

Now, it’s a simple matter of repeating that same process to add the ceiling track. 

Note that there are other ways you can arrange your track. If you wanted to have your elevator track show up in line with the ground track loop you can tell the track graphic file to consider path 2 to immediately follow path 1 by just manually adding path 2 as a following path for path 1. 

Quickstick Track Graphics 

You can also manually create track graphics for Quickstick systems similar to how you’d create them for a disjointed track. The formatting of Quickstick .mmtrk files is a little different from MMLite track. 

Instead of being given a cardinal direction with each motor, Quickstick motors are each assigned an angle. This allows a track graphic to properly display the curved motors sections that Quickstick can allow. After each Quickstick motor entry, you can also enter a gap distance and angle to display the larger motor gaps allowed between Quickstick motors. 

Below is a straightforward example with a linear track. 

If the Quickstick angles are adjusted, you can also display a nice track curve. 

You can even combine methods to create disjointed tracks with Quickstick graphics to create complicated layouts involving things like rotary tables and moving path nodes. 

The post MagneMotion Guide Part 12: Track Graphics and .mmtrk Files 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 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 9: Traffic Jam Prevention
• MagneMotion Guide Part 10: Moving Track

What is Tuning?

Tuning is the process of adjusting the parameters of your system that control the motion profiles used to turn motion commands (i.e., move this vehicle to this position) into mechanical movement. In the case of MagneMotion, tuning usually involves adjusting the Control Loop Parameters in the configuration file along with other advanced parameters that handle the system response to vehicles being out of position. 

While some systems have automatic tuning processes, MagneMotion tuning is a very iterative process. Typically, you’ll adjust tuning parameters before running your track, make observations about the current track behavior, and then iterate on the parameters again until system performance meets application requirements. 

Benefits of Tuning

There can be several different reasons why you would want to tune your system. The first is to ensure that vehicle motion is smooth. A properly tuned system will reduce vibrations and jerky movements from vehicle motion. 

Tuning can also be useful in increasing the overall throughput of your system. Mistuned vehicles can take longer to get up to speed or might slightly overshoot their targets, causing delays as they need to correct their positions. 

Similarly, tuning can also considerably reduce the current draw and thermal load on your MagneMotion motors. When a vehicle is moving smoothly and precisely, there is less need for the motors to draw an excessive amount of current to correct the vehicle’s positioning. 

Before you begin tuning your system, it is important to consider what your priorities are in tuning. A system tuned to optimize speed and responsiveness may look different from a system tuned to reduce thermal load. 

Configuration File Adjustments

See MagneMotion Guide Part 1: Creating Configuration Files for additional details.

The relevant parameters for MagneMotion tuning are found in the motor defaults section of the track. While you can adjust these parameters on a per motor basis, it’s usually a good idea to adjust them on a per path basis to keep vehicle motion consistent across your track. 

Here you can set up different sets of control parameters. To make use of a new set simply fill out the parameters and click the Enable check box. When commanding a vehicle to move (through NC Host or a controller) you can set the command to run at one of the PID sets configured here. Typically, it is a good idea to have a PID set for unloaded vehicles and another for vehicles that are loaded. Additional PID sets can be added, either to account for different load types or different types of moves along the track. 

Below is a quick description of each parameter used in a control set: 

Tuning Process

Using Virtual Scope

To properly tune a system, you will need to run a vehicle around your track while assessing whether the vehicle’s behavior is improved after each adjustment to the system’s control parameters 

While you can certainly do this by just monitoring the system, MagneMotion has created a tool to help gather more specific motion data called Virtual Scope.

The Virtual Scope tool gathers data about a vehicle’s position error, velocity, and current use as it moves along a motor of your track. 

To use Virtual Scope in your tuning process simply hit the setup button and input the IP address of your HLC controller along with the vehicle ID you are planning on tracking and the path and motor you are running your tuning tests over. 

Note that for a running system it can be tricky to line up a scope of a specific vehicle crossing a specific motor. Make use of NC Host’s ability to track vehicle positions to setup a trace before the vehicle approaches the motor you are monitoring. 

When a profile is captured, you can select which parameters you wish to display. You can also choose to set up a data capture to record the data from the scope into a .csv file for additional analysis. 

Data Streams

The Virtual Scope tools make use of data stream files to determine which data it is capturing from the MagneMotion motor. By default, virtual scope uses a data set that includes information on the vehicle position, error, and velocity.  

The virtual scope tool can gather additional information on things like motor temperature, power specifics or other details if the scope tool is loaded with different data streams by going to “Advanced” -> “Load Data Stream.” Rockwell does not publish these data stream files, but you can reach Rockwell ICT’s support team for alternative data streams if needed. 

Using NC Host

While you can certainly run your tuning by setting up a PLC program to run tests, it is often easier to use NC Host to control a singular mover instead of spinning up a whole PLC program or modifying your production code. 

For more details on NC Host see MagneMotion Guide Part 2: Starting up and Commissioning a Track.

NC Host also has a tool that allows you to use a temporary set of PID parameters to reduce the number of times you’ll need to change the configuration file of your system. This means you can try out PID values without needing to restart your system. (Note that any parameters changed through NC Host will be reset the next time the system restarts or the relevant path is reset). 

Other Tuning Considerations

On top of the typical PID-based configuration adjustments, there are also several additional configuration modifications that can be made to improve your system’s behavior. 

Disable Control Thrust

 If a vehicle is having trouble settling into position, the configuration file can be adjusted to disable the control thrust on a vehicle when it is within a certain tolerance of its target. This comes at a cost to how closely the vehicle will hold to its destination but removes any oscillation or additional thrust from a vehicle that is within tolerance of its position. 

Motion Limits

If you are having trouble ensuring smooth motion on your vehicles, configuring a stricter velocity limit or acceleration limit can prevent the vehicle motion from overshooting its target too aggressively at the cost of overall system speed. Importantly, this also is the easiest way to reduce temperature issues on a motor. 

Arrival Tolerance 

Similarly, if a station has too large of a settling time where vehicles are adjusting themselves to get into a station position, you can adjust the arrival position and velocity targets. This way, if on that particular path vehicle tolerance is not too strict, you can reduce the delay between when a vehicle arrives at its destination and when MagneMotion indicates that the vehicle is in position. 

This parameter only affects when MagneMotion considers a vehicle ‘in position’ and does not change the motion profile of a vehicle. 

Host Controller Communication 

You can also potentially reduce settling time by adjusting the system’s communication with its host controller. For high throughput systems, changing the Send Vehicle Status Period or the Vehicle Records/Status Period values can reduce the delay caused while waiting for the Node Controller to tell the host controller that the vehicle has arrived. Care should be taken when adjusting these values to ensure that you are not overloading the communication resources of the Node Controller or the Host Controller. 

On a host controller, this update frequency also depends on the cycle time of the MagneMotion device handler. 

Also note that these settings are specifically for systems that make use of Rockwell’s ICT library, see MagneMotion Guide Part 3: Controlling a System with a PLC. 

The post MagneMotion Guide Part 11: Tuning appeared first on DMC, Inc..

Typically, a MagneMotion track is designed to fit a 2D profile, the track might turn left or right but not up or down. While this is sufficient for most MagneMotion applications, sometimes systems are designed to lift or move MagneMotion track out of its typical 2D plane.  

Whether this is to move MagneMotion closer to tooling or to transport MagneMotion vehicles from one level of track to another, configuring this type of track involves careful modifications to the typical MagneMotion system. In this blog we’ll review general guidelines on how to handle these situations. 

Note: This blog is for MagneMover Lite systems only. QuickStick systems have a built-in feature of linking and unlinking paths which is a preferred way to handle this issue.

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 9: Traffic Jam Prevention

Step 1: Creating the Track Layout 

When laying out track, any moving segments of track should be carefully considered. You will need to account for any moving track in your system configuration, but different tracks have different considerations. 

Terminus Nodes vs. Relay Nodes 

Regardless of how the track is set up it is often a good idea to define any moving track as its own specific path. This allows the host controller to suspend or start that track section independently and makes it much easier to follow if there are any vehicles on the track. 

If the track is simple, you can usually add relay nodes to your system to break out your lifting path. In the below example, a single meter of track would be used to raise carriers from a ground section of track to a raised section of track. 

Here, you can maintain a simple track setup. Vehicles can still be sent from the ground track to the lift track or from the lift track to the ceiling track using the same typical motion commands that you’d use in other parts of your MagneMotion System. 

However, some tracks are more complicated to set up. Since MagneMotion is constrained to 2D systems any track that requires having multiple motors in the same two-dimensional position will require more a complicated track configuration to set up. 

In the example below, the track has been set up with a lift that can move vehicles to any one of three different levels of track. 

In this example, the track must be configured so that the different levels of track are considered separate from the rest. While regular vehicle commands can still be used to pass vehicles from the left ground track to the lift track, any vehicles sent from the lift track to one of the right-side tracks will need to be done with a terminus node handoff. 

Terminus Node Considerations 

In general, this terminus node-based configuration should be reserved for tracks where alternate configurations are not possible. While these terminus nodes will function, they come with some additional caveats. 

While terminus nodes can be properly simulated, you will need to add additional simulation logic to your PLC to properly run a simulation test of your system. Since MagneMotion will not know that the track on either side of the terminus node spot is next to each other when a vehicle exits through one terminus node it will not automatically appear on the other track section. Spoofing logic will be required to create an additional vehicle to receive it on the other track. 

Also, while MagneMotion supports disjointed tracks, many of the MagneMotion tools used in generating files will not work for non-contiguous tracks. For example, the “walk the paths” action will only create a configuration file with the paths of one disjointed section, any additional paths and nodes will need to be added manually. Similarly, the configurator tool cannot generate an .mmrtk file from the configuration of a disjointed track (though you can manually create an .mmtk file on your own using any text editor). 

Terminus nodes also require more programming overhead to control and manage. Moving vehicles across a terminus node is more complicated than regular MagneMotion motion commands. 

Step 2: Controlling Motion Across Your Lift 

Once you have your track laid out, you need to consider how to best control the movement of vehicles across your track.  

Having moving track in your system adds another considerable risk to your project. If a vehicle is commanded off the lift track at the wrong time it can fly off the lift into empty air and hurt anyone nearby. While you could theoretically control your lift track the same exact way you control all your other track, it is always a good idea to add some extra precautions when dealing with moving track.  

It is also worth noting that MagneMover Lite is not a safety-rated system so including reasonable mechanical constraints in your system is also a good idea. Ideally, any system would be set up so that no matter what, a vehicle wouldn’t fall off the track. 

Mechanical Restrictions 

Implementing simple solutions like mechanical guarding around your track can help prevent incidents. Alternatively, adding cylinders to the end of a track that actuate to restrict vehicle motion can help ensure system reliability even if power is lost to the MagneMotion track. 

There are countless ways to design a system to prevent issues with moving track. It is important to consider the possible failure modes of the system and ensure that they are accounted for in the design. 

Traffic Lights 

Traffic lights are used in MagneMotion systems to stop vehicles in certain spots of the track. For more information see MagneMotion Blog Part 7: Traffic Lights. 

Where moving track is used, it can be useful to keep traffic lights on either side of the track. 

To help ensure that no vehicles are commanded off the end of the track, the lights will be set to turn red when it is not safe for a vehicle to cross. 

It is important to note that the traffic light setting is not instantaneous. Not only is there a slight delay in a command for a traffic light being sent from the host controller, but any incoming vehicle will need time to decelerate before the traffic light. This means that when using traffic lights, they should be set to red before the moving track starts to get out of position to ensure there are no issues with incoming vehicles as the track is moving. 

Another consideration is that while traffic lights are defined as a single point on a track, they can take up a fair amount of space. When a vehicle is approaching a traffic light it will maintain a distance between itself and the traffic light based on its configured vehicle length. 

This means that track lifts can run into situations where there is insufficient space to have traffic lights and move vehicles onto the lift track. 

Keepout Areas 

Another tool MagneMotion has for controlling vehicle flow is the creation of keepout areas.  

Keepout areas are configured spots on the track that are set up to make it less likely for vehicles to come to a stop in those spots. When a vehicle approaches a keepout area it will only continue into the area if it has permission to move through the entire area. 

This means that vehicles will not get stuck in a keepout area when they’re backed up, but they will still be able to move through them if the track is clear. Similarly, any vehicles in the keepout area when the track suspends will continue moving until they are outside of the area. 

Unlike traffic lights, keepout areas cannot simply be turned on and off. They are defined in the MagneMotion configuration file and require updating that file and rebooting the system to change. 

Defining Keepout Areas 

Keepout areas are defined in the configuration file on a per motor basis. Each keepout area only applies to upstream or downstream motion. If vehicles will be moving across the keepout area from either direction make sure that both are configured correctly.  

For setting up a keepout area for moving downstream, the “No Move Permission After” parameters need to be set for each motor in the keepout area. The value should correspond to the distance between the start of the motor and the beginning of the keepout area (a value of 5 meters means this parameter is ignored). 

In a keepout area that extends several motors, the first motor in the chain may have a positive value for where the keepout area begins but each motor after it needs to indicate that the keepout area began upstream of it. This means that each downstream keepout area needs to end on the endpoint of a motor. 

Similarly, for defining keepout areas moving upstream simply reverse this process using the “No Move Permission Before” parameter. Here the value means the distance from the start of the motor to the end of the keepout area (a value of -1m means that the motor is not in a keepout area). 

Using Keepout Areas 

For the use case of a lift or other moving track, a keepout area can be used to ensure that a vehicle does not stop halfway on the moving track during normal track operation. 

This will reduce the chance of a mechanical failure where the lift tries to move while a vehicle is in the way. 

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

The post MagneMotion Guide Part 10: Moving Track 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..

In this blog, we will walk through the basics of configuring a SuperTrak system.

Step 1: TrakMaster and SuperTrak Simulation

To begin working with SuperTrak, you will need to get the TrakMaster and SuperTrak Simulation tools from SuperTrak support.

To run the SuperTrak Simulation, simply run the program after installing. The simulation will start running, and you should see this window.

After installing and running the TrakMaster software, you should see an option to connect to a system with the IP address used by the simulator (127.0.0.1). Click on the system and hit “Connect” to get to TrakMaster’s main window.

TrakMaster will ask you if you want to get started with a tutorial. For now, click “close” to continue to TrakMaster. 

Note: if you want more information on SuperTrak configuration after reading this blog, you can return to the default tutorial the next time you connect to the simulator with TrakMaster.

From TrakMaster, go to “Setup” > “Quick Start” to initialize your system to a common default loop. 

To provide a more thorough understanding of the process, we’re going to start our track from scratch.

Step 2: Define the Track Layout

In TrakMaster, expand the “Advanced” tab and go to system layout. Here you can define the layout of your track. 

For this example, we are using a 3-meter-long loop with wide curves, but you can add/remove additional tracks to fit your system using the Append/Insert/Remove buttons at the bottom of the screen. You can also select* if your track is a loop or not and determine the standard flow of direction. 

Note: For loop tracks, the direction “Right” means that pallets will move to the right on the bottom half of the loop, a counterclockwise movement if you are looking at the track from above.

Next, hit the “Save” button at the top of the screen. You will get a prompt about what you want to save. Make sure at minimum “System Layout” is checked, but also feel free to select all and then hit ok. 

Next, you’ll be asked if you want to reset the system. Feel free to hit “Yes”.

Now if you go back to the “System Dashboard” window you should be able to see your track layout.

Step 3: Configure Track Parameters

Now that your track layout is configured, it is time to define the details of your track motion. 

Navigate to the “Global Parameters” section and look through the various details listed.

These parameters affect all sorts of things about the track, but most importantly, set the basic motion parameters for how pallets will move.

Note: We won’t go into every parameter listed, but make sure you adjust the maximum velocity and acceleration for your system to an appropriate level. Also, set the pallet length and pallet shelf offset to match the tooling you are going to install on your pallets.

It is often a good idea to lower maximum velocity and acceleration during commissioning while the status of the track/system is still in flux.

Step 4: Define Regions

One of the most versatile tools that SuperTrak has is its regions. 

Regions are defined sections of track where the parameters of the track are changed.

To begin making regions, go to the “Global Parameters” section and navigate to the “Regions” tab. Here, double-click on an empty region ID to begin configuring. 

In the above example, I created a region with a larger pallet gap than the rest of the track. 

Regions like this can be useful if you are loading large objects onto your pallets that would collide if the pallet gap distance was not increased.

Take some time to think about what regions your system might need. A common region type requires you to define an area where pallets must move more slowly to allow something to interact with the pallet. Such as a burst of air that might clean the pallet of any lingering dust.

Once you have created your regions, you can go back to the “System Dashboard” to see them laid out on the track. 

From the “Regions” tab on the right, you can also adjust the positions of any regions to ensure they match up with the desired region locations for your system.

Note: Regions cannot overlap, if you need to create overlapping region effects, you will need to divide your regions into pieces and set them all up independently of each other. 

Step 5: Set up Targets

Targets are the primary way SuperTrak controls which pallets go where. Typically, when a pallet needs to move from one location to another, the target it is located at is told to forward its pallet to the next target.

A target should be placed at each location where a pallet will need to stop. To create targets, go to the“Targets” tab under the “Global Parameters” section. Here, you can enter the section and position you want each target to be in.

Here I’ve created a few targets around my track and given them some basic descriptions to make it clear which target is which.

Notice that when you go back to the System dashboard, you will see your targets represented on the screen. 

Step 6: Simulate Your Track

Now that we have our track set up, we can start simulating the track. Simulation will not only allow us to verify that we’ve set up the system correctly, but will also allow us to begin running tests on our system to determine roughly how long it will take for pallets to cross our track.

Step 6-a: Change Track Settings for Simulation

There are a few settings we’ll need to adjust to get your track running in Simulation properly.
First, go to the “System Layout” page under the “Advanced” section. From there, set the “Enable Control” option to “TrakMaster”

Next, go to the “Sections” tab and set the “Load Target” for each section. 

The “Load Target” is the target ID that pallets on each section will head to on system startup. You can select “Copy to all Sections” to give all sections the same load target, or you can set it individually for each section.

Now go back to “Global Parameters” and set “Assign ID to new pallets” to true. This will cause SuperTrak to assign a number to each pallet to help you keep track of them as they move around the system. 

If your system uses an IR reader to assign pallet IDs you will want to change this later, but for simulation, you will want this feature. Also make sure the “Enabled Simulation” box is set to true.

Finally, in the “Advanced” section, go to “Simulation Configuration” and define the positions you will want vehicles to start in for Simulation. 

Here, I’ve just created two pallets in random spots of the track.

Step 6-b: Run your Simulation

To begin running your Simulation, press the “Save” button at the top and confirm the parameters you want to save. 

Then, when prompted, specify that you do want to restart the system. If you go to the systems dashboard, you should see the pallets you defined earlier appear on the track.

Now, when you press the “Enable System” button at the top of the screen, the pallets should be directed to whatever you set as your load target.

Now, you can select a pallet in the “Pallets” tab on the right and direct it to a target by giving it a target ID and pressing “Go”.

Note: Make sure you watch the pallets as they cross targets to ensure that they’re reacting appropriately.

Step 6-c: Auto Release Pallets

Now that you have your simulation moving pallets around the track, you can take advantage of another SuperTrak feature. This feature allows to have your pallets move around the track using simple automation.

Simply go to the “Targets” section in the left-hand tab and expand the “Auto-release” section. 

Note: Here you can set a target to auto-release a pallet by selecting “After a minimum” and inputting a time in milliseconds that the target will wait before sending the pallet. 

On its own, though, that won’t do anything; you still need to tell the target where to send the pallet. 

Further down in the auto release tab, set the “Use move configuration” option to “Local” and set the ID to 1.

Now go back to the “Global Parameters” section and under the “Move Configurations” tab, scroll down to the bottom where you should see options to create “Move Configurations” for each target. 

Create a configuration in Target 1 to move to Target 2. 

Now when your track is running, Target 1 will wait 400ms and then automatically forward its pallet to Target 2.

Redo this process so that each Target in your system forwards pallets to the next target and press the “Save” button. Now you should be able to go back to the “System Dashboard” and monitor your pallets as they continuously circle around the track.

This automatic releasing of pallets can be a useful tool for estimating the throughput of your system if you know roughly how long each process on your track will take. 

If you go to the “Statistics” page, you can even see useful information about the time spent heading to each target.

Step 7: Setup your System for PLC Control

While controlling your track through TrakMaster is useful for setting up and testing your configuration, typically, systems will ultimately want their SuperTrak system controlled by a PLC. 

SuperTrak has built-in functions for communicating with a variety of PLCs. For this blog we’re going to go through configuring the system to talk to a Rockwell PLC over Ethernet/IP, but much of the process for connecting to other PLCs is similar.

First, go to the “System Layout” page under “Advanced” and from “Enable Control” select either “Section Control” or “System Control”. These are both for controlling from an external system. The difference is whether you enable sections individually or all at once.

Now go to the “Control Interfaces” section. Here you can configure an EtherNet/IP interface. 

Modify one of the configurations by entering its IP settings. Note that these settings are not the IP address of your PLC, they are for the network card in the SuperTrak system that the PLC communicates with. This is also a different IP address than the one you connect to via TrakMaster.

Next, go to the “Data Layout” tab. Here you can set up what data gets sent to/from the PLC. 

Feel free to select “Defaults” > “Ethernet/IP” to use the recommended default values. But if your system uses a lot of targets or network IO, you can increase/decrease the amount of space used by each type of message.

Now select “Save”, restart your system, and you should be all set to start setting up your PLC to control the SuperTrak system!

Learn more about our Manufacturing Automation and Intelligence expertise and our open positions!

The post How to Configure a SuperTrak System 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..

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 8: Simulation
• MagneMotion Guide Part 9: Traffic Jam Prevention
• MagneMotion Guide Part 10: Moving Track

What are Traffic Lights?

In a MagneMotion track, traffic lights are simply defined points on your track that can either be set to Green to allow vehicles to pass through or set to Red to prevent any vehicle from passing that point (there is no yellow light in a MagneMotion traffic light).

As you can imagine, as MagneMotion systems get increasingly large and complex, traffic lights are an important tool in directing the flow of vehicles throughout your system to make sure they arrive in a timely fashion.

Traffic Light Uses

1. Completely Blocking off a Section of Track

Traffic lights can be used to block off a section of track where it wouldn’t be safe or smart to move a vehicle. For example, if there is a segment of your track that lifts out of position, traffic lights can be positioned on either end of the track to make sure no vehicles can move from it while it is not in position

2. Controlling Traffic Flow

If your track has any branches off sections of track that experience high throughput of vehicles, any vehicles trying to leave that branch might get stuck waiting for an opportunity to move. A traffic light placed right before that branch can be used to create a break in a line of vehicles

3.Traffic Jam Prevention

You might find that your track has one or more places where having too many vehicles can cause a full-on traffic jam — causing your whole line to get backed up and stuck. Adding traffic lights before any of these choke points can ensure that your line never gets into unrecoverable situations.

Note how none of these vehicles will be able to leave this loop of track.

NC Host Control

A good tool to familiarize yourself with traffic light operation is MagneMotion’s NC Host tool.

To create a traffic light In NC Host, go to the Traffic Light tab under Host Commands. Then, enter a path and position for the traffic light and hit Create

Once the light has been created, you can change its state between red and green by entering the traffic light’s ID by the TL ID entry and press the nearby green and red button to change the color.

If you press the Traffic Lights button in the Launch Status Windows section, you can pull up an image showing the status of the traffic lights in your system.

System Configuration

If you are planning on using a PLC to control your traffic lights, the first thing to do is to make sure that the MagneMotion device handler was properly configured within Application Code Manager (for information on how to set up a project through Application Code Manager see MagneMotion Guide Part 3: Controlling a System with a PLC).

Since traffic light controls are not a part of the default AOIs that are included in the ICT library, first in Application Code Manager, right click the MagneMotion device handler and select Add New.

In the wizard that pops up, type “raM_Opr_MM” in the filter box. You should see the Asynchronous Motion category that contains three AOIs for managing traffic lights. One by one, add the three traffic light AOIs to your project.

Once this is done, you can generate the new controller to create a MagneMotion device handler that is capable of controlling traffic lights.

If you want to update the MagneMotion device handler in an existing program, you can export the MagneMotion program (raM_Dvc_DH_MM) in from your newly generated project and re-import it in to your existing program along with the traffic light AOIs that you want to use. Note that it is not enough to just import the traffic light AOIs since Application Code Manager also has to modify the MagneMotion device handler to support traffic lights

Now that the PLC program is set up, the next step is to update the Node Controller to allow PLC controlled traffic lights.

In the MagneMotion Configurator tool pull up your Node Controller configuration file. Under PLC EthernNet/IP, click the box for Enable Traffic Lights and fill out the Maximum Traffic Light ID value.

Once the new configuration file is uploaded to the Node Controller in the PLC tags, make sure that the traffic light arrays are the right size. Once that’s done you should be all set to use your PLC to control the traffic light

Creating Traffic Lights

To create a traffic light from the PLC, you have to make use of the Create Traffic Light AOI.

Setting this AOI up is simple. First, create an instance of the AOI raM_Opr_MM_CreateTrafficLight in your program and put the Hndl tag from the device handler into the Ref_Handle input. Next, populate the Cfg_PathID and Cfg_Position tags for your traffic light (the position value should be the distance in mm from the start of your path to the traffic light position).

Toggling bCreateTrafficLight in the above code will command the PLC to send a message to the Node Controller to create a traffic light. Note that you do not define what the ID of the new traffic light will be; the Node Controller simply assigns it the next available ID. It is usually a good idea to store the Sts_TrafficLightId returned by the AOI so that you can use the traffic light later.

Setting Traffic Lights

The Set Traffic Light AOI is used to send messages to the Node Controller to change the color of a traffic light.

To use this AOI, create an instance of it and add the Device Handler Hndl tag. Then, just set the ID of the traffic light you wish to set, the color you want to set the traffic light (0 is Green, 1 is Red), and run the AOI.

Toggling bSetTrafficLightGreen in the above code will command the PLC to send a message to the traffic light created earlier to change it green.

Deleting Traffic Lights

Traffic lights will be deleted whenever the path they are on is reset. This means that it is important to include logic to recreate your traffic lights in your track startup logic.

You can do this by triggering a command to create traffic lights into whatever sequence you use to reset paths. However, a useful tactic can also be to check the status of the path the traffic light is on and triggering a creation command whenever the path becomes Operational

If you are planning on using traffic lights to restrict movement of vehicles to areas where machinery might collide with a vehicle, make sure to verify that the traffic lights have been created before sending any vehicle commands. Information on existing traffic lights can be found in the MMI_traffic_light_status controller tag.

If you want to delete a traffic light, there is an AOI similar to the Set Traffic Light AOI that can be used basically the same way.

 Topics to look forward to in this series: 

Topics to look forward to in this series: 

• MagneMotion Blog Part 8: Simulation
• 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 7: Traffic Lights 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 4: Using Path and Station AOI’s
• MagneMotion Guide Part 5: Alternative Routing Controls
• MagneMotion Guide Part 7: Traffic Lights
• MagneMotion Guide Part 8: Simulation
• MagneMotion Guide Part 9: Traffic Jam Prevention
• MagneMotion Guide Part 10: Moving Track

Track Recovery Overview

One of the difficulties of managing a MagneMotion system is learning how to properly startup the track and get things running. Whether you’re starting up the track for the first time or recovering after a major fault or a power cycle, there is a single sequence you should take your system through to get everything operational again.

Here is a short list of the various reasons you might need to re-startup your MagneMotion track:

•    There was a power cycler of motors or node controllers
•    A communication/network issue between the node controllers and the motors
•    A communication fault between the node controllers and the PLC
•    Motor faults that stop movement on the track
•    Vehicles have been pushed out of position and are now “suspect”
•    Configuration file changes

While all these issues have potentially different resolutions, it is generally preferred to take care of all of these issues in a single startup sequence to make sure that all edge cases are handled on recovery and to make the operator interaction of the line as easy as possible.

In this article, we’ll look into each of the steps this sequence has to take to fully recover the track and what each step does for the overall MagneMotion system.

Step 1:  Reinitialization

Among the list of useful ICT library AOIs is the Device Status AOI. This AOI is mainly used to check on the current status of the MagneMotion system and its connection to the PLC.

When you’re recovering your MagneMotion track, the first thing that should be done is triggering the Inp_Reinitialize bit of the Device Status AOI. This will cause the PLC to get rid of the current connection to the High Level Node Controller (HLC) ensuring that whatever you do next will be happening from a clean slae.

After triggering the reinitialize bit you should check the connection statuses from the Device Status AOI. Once the AOI is back to being Connected and Idle the reinitialization process is complete.

Step 2: Configuration

The next step in our sequence is to use the Configuration AOI to re-configure the PLC to HLC communication. (Learn more about the Configuration AOI in MagneMotion Guide Part 3: Controlling a System with a PLC)

Using the Configuration AOI will direct the PLC to connect to the right IP address for the System’s High Level Controller. This step help to ensure that the PLC and HLC are communicating properly. If there is an issue with the communication, the Configure AOI should throw a fault to indicate its inability to connect. Once this instruction completes the sequence can proceed to the next step.

Step 3: Disable Stations

Typically, MagneMotion systems controlled by a PLC will have several Stations created to help control where vehicles are sent to. (Learn more about stations in MagneMotion Guide Part 4: Using Path and Station AOI’s)

If at any point a station encounters a problem it will throw an error and stop working until that error is cleared. This means that any vehicles directed to this station will remain stationary on the track and any vehicles at this station will be stuck. Typically, this happens when a vehicle that cannot reach a station is told to move there.
To clear station errors the Station AOI needs to temporarily stop receiving calls, so in this step we disable the station call.

Step 4: Reset Paths

If there have been any sort of errors with MagneMotion motors or with vehicles on the track, the paths of the system will need to be reset using the Path AOI (Learn more about paths in MagneMotion Guide Part 4: Using Path and Station AOI’s)

Resetting the paths will cause the MagneMotion system to lose track of which vehicles are where. If in your system you do any sort of internal tracking of what is on each vehicle, you will want to clear that information out before resetting paths so that your PLC will not have outdated/incorrect information about the contents of each vehicle.
This is generally the most important step in the Startup Sequence. At this point any track issues should be resolved, all that is left is to finish starting the track back up and get vehicles moving again.

Step 5: Enable Stations

Now that paths are reset it is safe to re-enable stations. If stations are re-enabled before the resetting step any ongoing faults in the track could re-trigger the station faults requiring them to be disabled again before they can be operational.
For example, if a station was faulted by a vehicle being improperly directed to it, that station fault will not be able to be cleared until the paths have been reset removing that vehicle from the track.

Step 6: Startup the Track

This step is a complement to the previous one. Here we send a startup command to all the paths in the system which will make the track operational again and assign vehicle IDs to everything on the track.

Every once in a while, the Startup AOI will briefly set the STS_PC output to indicate that it is done before it sets the STS_ER output to indicate that a path has faulted. To make sure everything is properly started up, I usually like to add in a brief delay before proceeding to the next step.

Step 7: Vehicle Homing

Now that the track has been successfully started up, the next step is to tell all of the vehicles on your track where to go. There are several different ways to do this, and each system will have different requirements about what needs to happen to vehicles on a startup. I typically like to go with sending every vehicle to a single startup location that then decides where each vehicle can go as they show up.

Step 8: Data Tracking Recovery

So far, the startup sequence works for a system that doesn’t require tracking the information on vehicles, or a system that would clear vehicle contents out before the track has started up. But what should you do if you want your system to remember what is on each vehicle even after a complete restart of the track?

Since MagneMotion itself loses track of which vehicle is which during startup there is no direct way to correlate old tracked vehicle data to whichever new vehicle IDs MagneMotion produces on startup. 

One way to solve this problem would be to develop a complicated vehicle tracking program to try and determine what vehicle contents belong to which vehicle after a startup based on the positioning of the vehicle before and after a full startup of the track. Putting aside the considerable complexity of this plan, there are several added complications where vehicles can be moved while the system is powered down and can drift after power loss in ways that could quickly make any recovery logic very hairy and unreliable.

Another more robust solution to this problem is to affix a unique barcode to each MagneMotion vehicle. Then once the system is reset you can direct each vehicle to a barcode scanner positioned near the track that will scan each vehicle and report to the PLC what its barcode is. Then with this barcode you can create a more robust system for assigning tracked vehicle contents with MagneMotion vehicle IDs.

Additional Considerations

While the above sequence is generally sufficient in restoring a MagneMotion track, there are some important additional things to take into account when commissioning a MagneMotion system.

1.    Some rare MagneMotion faults might require a full reboot or power cycle of the Node Controllers of the system. This is not done through PLC commands but is typically done manually through the Node Controller web page.
2.    Each MagneMotion AOI has its own error code and extended error code output (STS_ER and STS_EXERR). Documentation for these error codes can be found in the help files for the ICT library or in the help section of the AOI properties. 

3..    Additional Error information can be found in the log files of the node controllers, but these error codes are often fairly difficult to read.
4.    If you are building a system that attempts to recover vehicle information after a restart, it is generally useful to include an alternative startup that will default to assuming that every vehicle is empty.
5.    If your system involves vehicles travelling at different speeds based on their contents, remember to lower the speeds of all vehicles until the system can determine what is on the vehicle.
6.    If your system has traffic lights, they will be deleted every time the paths of your system reset.

Topics to look forward to in this series: 

• MagneMotion Blog Part 7: Traffic Lights
• MagneMotion Blog Part 8: Simulation
• 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 6: Track Recovery Considerations 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..