A number of questions on the forum involve racks being service by a combination of shuttles and elevators. There are solutions involving network, Astar and AGV navigators, but for this example we’re just going to use TaskExecuter FlowItems and conveyors. The elevator system in particular, as described to me, seemed it would benefit from the flexibility conveyors offer – particularly spacing options, and the possibility of having dog/power-and-free based travel. For the pick face we can just use the slot and item locations to give the task executers travel command, and we can use kinematics for loading and unloading tasks. This removes the need for network nodes or control points at each location and allows fine positioning of a ‘two spot’ shuttle in front of the slot. The system has been put into a container to represent the cell/aisle and it is this object that is the instance member of the ShuttleSystemProcess process flow. The cell is designed to be duplicated with each cell becoming a new member instance of the single process flow. It comprises two racks, two elevators (conveyor loops), and a shuttle return queue (also a conveyor but with no roller visual). The system assumes that by the time an inbound item arrives at the pickup position it has been assigned a slot in one of the racks in the cell – so you should assign a slot in the normal way before it reaches a shuttle. You can additionally request items for picking out of the racks by pushing the item to the global list ItemsToPick. Currently each shuttle will store and/or pick one item in one trip with a dedicated position for each. When doing both in a single trip, the order in which this happens will depend where along the level the slots are located. In the event that there are no remaining tasks but items still need to exit the cell, the shuttles at the front of the queue will be asked to circulate empty through the system, thereby allowing the outbound items to advance to the exit position. The number of shuttles in the system is a process flow variable. In the example system there are elevators at each end of the rack(s) with a number of carriers to transport shuttles to the levels. Both elevators have a process flow variable for the number of carriers to be generated. Shuttles are not allowed to pick from the same level at the same time but in order to keep the up-elevator moving the carriers can unload the shuttle to the level even if another is active on that level. The shuttles only travel along the face of the rack in one direction towards the down-elevator and once are collected by a carrier the next shuttle on that level can start its operations. It is possible to run the system with only one rack should you wish to view the operations without the second rack obscuring your view. Since different applications will use different rack dimensions the cell has a label method called “configureToRack” which will align the conveyors and decision points to Rack1 based on the level heights and size of the racks that the user has set for Rack1. There may be some limits to very small sizes when the conveyor decision points overlap. The second rack will be configured during this method call to mirror Rack1. Here’s an example invocation of this method for an instance of the cell: Model.find("RackShuttleSystem").as(Object).configureToRack The shuttles need levels to be the same height along the length of the rack. Some effort was made to configure the system based on the shuttle and carrier sizes, so you can try adjusting those to suit your needs and hopefully the alignment will work as needed. The elevator conveyor and shuttle speeds are not set by the alignment method so you can edit those in the usual way. This is an example for both learning and perhaps as a starting point for any project should you find the approach suits your application, modelling style and skills. ShuttleLiftAndRack.fsm Time taken: 1 day to build the working model - plus another to work around holes api for auto-alignment code. 17Nov Updated: to initalize shuttles at the load point (via fast entry) added shuttleQheight label for use to set the returnQ height in the cell (used by the alignment method) added a process flow variable 'shuttleLoadTime' for the time to un/load items. aligned shuttle kinematics to the speed and acceleration of the TE FlowItem.

I was recently asked how a user can implement jerk, i.e. a rate of acceleration change, in the AGV module. The AGV module uses FlexSim's kinematics API to define the motion of AGVs along paths. The kinematics API does not natively support jerk. However, the AGV module has included a hook to allow developers, and audacious end users :-), to customize the kinematics that drive AGVs on paths. Using this hook, you can approximate jerk by breaking what would otherwise be a single kinematic, with a single acceleration/deceleration, into multiple smaller kinematics that gradually change the acceleration/deceleration of the object as it progresses. There are two ways to do this. The first option is to simply do it as an end user, confining your changes to your model, by customizing nodes in the tree. The second option is to do it as a module developer, using the module SDK. Adding Jerk as a User The AGV network uses an "AGV Customization Delegate" to allow for hooks to be placed at certain points in the AGV navigation logic. There is a default customization delegate that the AGV network uses, but you can override the logic of this default delegate by adding and configuring a special node at MODEL:/AGVNetwork>variables/customizationDelegate. But before I tell you how to do it, I want to explain a little more about how it works. I've attached three C++ files. The main ones you'll want to look at are AGVCustomizationDelegate.h and AGVCustomizationDelegate.cpp. These show the definition of the customization delegate class. In the header file, you'll see the definition of AGVCustomizationDelegate class. This class includes several methods, but the main method relevant here is addKinematics(). This method takes several parameters defining the context. Its responsibility is to add one or more kinematics, in the positive X direction, that will move the AGV the target distance along a path. The AGVCustomizationDelegate class is the default customization delegate used by the AGV network. The C++ files also define a subclass called UserAGVCustomizationDelegate, which overrides the methods of its parent class by delegating the logic to FlexScript code that the user can write in the model. So, now for actually doing it in the model. We want to instantiate an instance of UserCustomizationDelegate at the node MODEL:/AGVNetwork>variables/customizationDelegate, so that we can write FlexScript code to add the kinematics. Navigate in the tree to MODEL:/AGVNetwork>variables/customizationDelegate Right click on that node, and choose Edit > Designate this Node (so) In a script window execute the script: nodeadddata(so(), DATATYPE_SIMPLE) Add a subnode to that node named sdt::attributetree and give it the text: AGV::UserAGVCustomizationDelegate. Copy the node and then paste it onto itself. This will instantiate the UserAGVCustomizationDelegate. Right-click on the addKinematics subnode and choose Build > Toggle Node as FlexScript. Right-click on the addKinematics node and choose Explore > As Code. This will allow you to edit the code for adding kinematics. The header for field should be as follows (note this is determined by the evaluate() command in AGVCustomizationDelegate.cpp at line 71). treenode kinematics = param(1); // the kinematics node to call addkinematic()/getkinematics() on treenode section = param(2); // the associated travel path section double startAtTravelDist = param(3); // the agv cumulative travel distance at this point double distance = param(4); // the distance to travel on the path section (your addkinematics() calls should add up to this distance) double startTime = param(5); // the start time for the first addkinematic() call double startSpeed = param(6); // the initial speed to start at double endSpeed = param(7); // the target end speed (should be going this speed at the end) int reason = param(8); // reason for adding the kinematic (see AGVCustomizationDelegate.h) treenode endSpeedOut = param(9); // if target end speed cannot be reached, update this node's value with the actual end speed double peakSpeed = param(10); double acc = param(11); double dec = param(12); TaskExecuter agv = ownerobject(tonode(get(kinematics.up))); // the agv At this point you can customize how kinematics are added to the kinematics node in this code. To approximate jerk you would break it up into small addkinematic() commands that each change the acceleration/deceleration. Please refer to the kinematics api for more information on how to manipulate kinematics. Note that you should only use the addkinematic() and getkinematics() commands in this field (not initkinematics() or updatekinematics()), and the addkinematic() command should only tell the AGV to move forward in the X direction. Y and Z directions are ignored by the AGV travel logic. In other words, from a kinematics perspective, the AGV network "flattens" an AGV's path into movement in a straight line along the x axis. When you're finished adding kinematics, you should return the end time of the last added kinematic. This will be the same as the return value of the last called addkinematic() command. Adding Jerk as a Module Developer To implement jerk as a module developer, you would first create a module using the module SDK. Then you would include AGVClasses.h and AGVCustomizationDelegate.h in your project (do not include AGVCustomizationDelegate.cpp as it won't compile properly. I'm including that file just to be informative in this article). Then you would subclass AGVCustomizationDelegate with your own class that overrides the appropriate methods, specifically the addKinematics() method. Once you've done that, you would replace MODEL:/AGVNetwork>variables/customizationDelegate with an instance of your customized class, using the same steps described above, but using your own class name instead of AGV::UserAGVCustomizationDelegate. If you need more header files so you can access more information, i.e. the definition of TravelPathSection, the let us know and we can get them to you. agvheaderfiles.zip