Flow items with states

In one of my model that I am developing, we need to add states associated with flow items. For example, for trucks going through terminal gate, you may have these states: traveling, waiting in the queue, waiting at the pedestal, being processed, etc. The time that a truck spending in each state is very important and can be used as inputs into emission models.

Since I am using flow items to represent trucks, i wonder if I can set states directly to flow items. However, a simple experiment tells me that I cannot. Then I think I can use TaskExecuterFlowItem. Yes, you can set states for TaskExecuterFlowItem. But the TaskExecuterFlowItem has way more data than a normal flow item. So if you have hundreds or thousands of flow items, it may slow down your model. Then I think probably I can add stats data into normal flow items, and then I can set states. A simple experiment tells me that I am right. I would like share this experience with users here and hopefully it will help somebody who wants to do the same thing in the future.

Here is how I do it.

In the SourceTriggers of the source, put the following code:

// create stats node in the data portion of the item
treenode teStatsTemp=node("/Tools/FlowItemBin/TaskExecuterFlowItem/TaskExecuterFlowItem>stats",model());
treenode itemStats=node(">stats",item);
// destroy any stats data in case doing flowitem recycling
if(objectexists(itemStats))
    destroyobject(itemStats);
// createcopy(node thenode, node container[, num samename, num inobject, num cached, num replace])
createcopy(teStatsTemp,item,1,1,0,0);

</code>

Then you can use setstate command (For example, setstate(item,STATE_TRAVEL_EMPTY)) to set the item's state. Note the available states can be found under the ">stats/state/state-profile" node of the item. And you can add your own state too.

Alan

Actually I have one question. Does all Flexsim object have the same set of build-in state_profile?

Alan

Firstly, all objects generally have the same set of 50 built-in state_profile subnodes as listed in the State List section of Miscellaneous Concepts of the User Manual help documentation. The exception to this is the MultiProcessor which dynamically adds state nodes to the state_profile tree. The names of the new states it adds are the names of each of the new processes that the user may add to the MultiProcessor. As an end user, you are also free to add your own states to your custom objects you might make with the BasicFR or BasicTE. Just add nodes to the stats/state/state_profile node and give the new nodes the name you want the state refered to by in state charts. For instance, to set the state of the current object to the 51st state in the tree, just type setstate(current,51). The State Pie Chart for the object will automatically display the cumulative time the object spent in the 51st state as well as give the state the same name you gave the node in the tree. In the help we make the comment that we will never overwrite states 101 and above if you want to play it safe, but if you add states in a dynamic way like the MultiProcessor and reference them with macros, then you will be okay using whatever the next available state number is.

Now regarding your first post. Nice idea you have for adding state recording to flowitems. I'm assuming you pull off the flowitem's stat information at the end of the model before terminating the flowitems and loosing your data. You've probably come to realize that there aren't a lot of differences between library objects and flowitem objects. We don't do a good job in the Flexsim documentation (or in our training courses) going over all that is possible with flowitems. We should at least explain what the differences are between the different flowitems you see in the FlowItem Bin by default. The best way to understand the differences at this point, is to just go into the tree view and see what's different in each of their object data trees. One thing that trips people up from time to time is the fact that some of the flowitems do not have the centroid node so they do not travel down the center of a conveyor as expected. The TaskExecuterFlowItem is the only flowitem with inheritance from a class (see the classes and superclasses attributes in its data tree). The Pallet flowitem is unique in that it has custom behavior as defined by the OnReceive attribute node in the behaviour/eventfunctions node. The Pallet flowitems is also the only one (I think) that has the nochildscale attribute. If you've ever tried to put one flowitem inside of another flowitem that wasn't a pallet, you probably noticed it got scaled down to match the container flowitem's size. Another interesting fact is that it is not important to strictly maintain the entire branched tree structure you see in the object data tree of most Flexsim objects. One of the few exceptions is the color attribute node which needs to have the rgb component nodes contained inside of it. One time I made a flowitem that I needed to give some dynamic OnDraw code to for animation purposes, and because I was a little worried of memory constraints with the huge number of the flowitems I would have in my model at any given time, I decided to customize the object data tree so the flowitem only contained the following nodes: color, OnDraw, spatialx, spatialy, spatialz, spatialsx, spatialsy, spatialsz, and itemtype. That's all I needed for my purposes; just 9 nodes. Of course the OnDraw had subnodes due to the auto-generated flexscript tree, but I made sure that was as small as possible by calling a user command rather than write all my draw code in the field itself.

Thank you very much, Cliff. That is very nice explanation.

So it would be safe to use state 101 and above. And generaly every object has 50 states. However, since the state_num is just the rank in the state_profile node in setstate(object, state_num), does that mean if I want to use a state 101, I have create 51 more nodes under state_profile and use the last node as my state?

It is also good to know the minimum data set for a flowitem is: color, OnDraw, spatialx, spatialy, spatialz, spatialsx, spatialsy, spatialsz, and itemtype (The min set is actually spatialx, y, z, sx, sy, sz and itemtypeas explained in Cliff's next post). This will save some memory space if a lot of flowitem involved. How about put this as a build-in flow item type in Flexsim? Maybe call it something like "MinFlowItem".

Does the minimum set has to include some more data, for example, shapeindex? I tried to use the flow item with only the above data set. The flow item is generated but I won't be able to see it in the model.

Have a happy Thanksgiving!
Alan

Alan,

Yes you would have to create a bunch of useless nodes if you used state 101. I would just start with state 51 and either take a chance it won't get overwritten or write some clever OnReset code to set up a flexible directive to the last node in the list.

Actually the minimum data is just spatialx, y, z, sx, sy, sz and itemtype. You're right you won't see anything unless you either have a shape node or an OnDraw with some draw code defined. The index (i.e. shapeindex) nodes are created automatically if you have their corresponding path node (i.e. shape). Or you can get away with just having the shapeindex node without the shape node (so that you only need one rather than two nodes), but you need to realize that the index you reference needs to reference a valid shape that has been preloaded, and you run the risk of the index not being updated when the order of the loaded media changes.

I agree, we need to reevaluate the usefulness of the current list of objects in the FlowItem Bin and possibly add some new ones and get rid of some old ones (or maybe reorganize them). The nice thing about messing around in the flowitem bin is that it shouldn't affect existing models.

Happy Thanksgiving to you too!

Thanks. Seems we all works late .
I edited my post and your post so that it is easy to see the minimum data set of a flowitem.

Alan

Thanks Alan. I thought this topic deserved its own thread with a comprehensive explanation, so I started a separate thread called Customizing Flowitem Attributes

Returning back to the topic of adding your own states, the following information might be useful (and dangerous) to someone. I find it easier to create the nodes in the object's stats profile tree manually within the flowitem bin, rather than writing code. I made a video using Camtasia to show how this can be accomplished. In the video I also show the use of a #define to represent the new states node rank as I find it reads better when using commands like setstate().

Download video:
Custom states on a flowitem

Hi there,
having a stats node in a flowitem is a nice way to keep track of what the flowitem had been used for. But there is one thing I still wonder how to solve. The flowitem (as the Operator) is transfered through many other objects. So the reference to the stats node is always changing. If you try to display the stats node with a recorder, it will only show the results when the item (or Operator) is on the level of the modeltree.
So I am not shure if it would be better to have those stats nodes elsewhere in the tree.You have to set the states anyhow activ for flowitems.
For the Operators it is different because here the states are set as for any other object. So it would be not so easy to have the stats node somewhere in one fixed place.

Kris,

You made such a great movie! This should be put into Flexsim tutorial. I have used Camtasia before. It is really a nice screen movie maker. Just one suggestion to the movie. You may make the text explanation stay on the screen a little bit longer so that it is easier to read.

Several concepts can be seen in the movie:
1. How to create new nodes in the Flexsim tree.
2. How to insert data into a node.
3. How to copy and paste nodes and data.
4. How to add states to flowitems.
5. How to define macro (An extra line has to be added in the end).

Alan

The difficulty of using recorder to display flowitem states is due to the limited functionalities of the current recorder. Since the recorder is being redesigned, I hope your problem can be solved in the future version of Flexsim.

If you just want to track the state of a specific flowitem, you may use a global variable to refer to that flowitem.

Alan

Kris,

Thanks for this great video. Good Job!

Alan, I agree, the text could stay sometimes a little bit longer on the screen. But you can always stop the video to read the text. And I prefer to have a small and fast video.

I really think it would be nice to have small tutorial videos like this for different subjects. But I am also sure, that it will take some time to make such a video.

Anyway, I also have bought Camtasia a while ago, but did not use it a lot. Maybe if I am bored I will think about to make one. So far I did not dare to do so, because I do not want people to get scared because of my voice and bad English. But I like Kris's idea just to use text for small explanations. Kris, you are the man .

Keep in touch
tom the (A)tom

Originally Posted by Tom David

I really think it would be nice to have small tutorial videos like this for different subjects. But I am also sure, that it will take some time to make such a video.

Yes, making a nice video will take significant efforts. Kris, how about you put this video into the tutorial part of the download area. So far there is just one tutorial. And I see this one deserves a position there. Let me know if you want me to do it.

Originally Posted by Tom David

Anyway, I also have bought Camtasia a while ago, but did not use it a lot. Maybe if I am bored I will think about to make one. So far I did not dare to do so, because I do not want people to get scared because of my voice and bad English. But I like Kris's idea just to use text for small explanations. Kris, you are the man .

Tom, you English is very good. Better than mine. And as you said, you do not have to use voice, texts are just fine and sometimes even better. Camtasia is really easy to use. Try it and I think you will like it. And the best thing is the video size is far more less than the standard avi and the video quality is also very good.

Alan

Originally Posted by AlanZhang

If you just want to track the state of a specific flowitem, you may use a global variable to refer to that flowitem.

Alan

Hi Alan,
1. I can set up a global variable to point to the flowitem, but how do I use this variable to set the reference in the recorder?
2. If the item is moving through different objects, the pointer in the global variable will not dynamicly change...

So could you please explain are littel further how you track the state of a flowitem.. Thanx..

Originally Posted by Nico Zahn

1. I can set up a global variable to point to the flowitem, but how do I use this variable to set the reference in the recorder?

Frankly, I am not sure. The current recorder does not handle user defined data very well. And it is not designed for showing data for flow items. It is possible to set NodePath of the recorder directly in Flexsim tree using some code. But I am not sure if it really works or not. Since Flexsim is going to release new recorder soon, you may want to wait for the new release before doing more.

Originally Posted by Nico Zahn

2. If the item is moving through different objects, the pointer in the global variable will not dynamicly change...

Once you set the global variable pointing to a flowitem, the pointer won't change. That means the global variable will point to the same flowitem and it is what we want.

The problem is just which flowitem you want the global variable point to initially. Guess you may have some rule. For example, maybe we only want to know the state of the 100th flowitem. Then we can let the global variable pointing to the 100th flowitem. But this may not be very useful.
A more useful case of flowitem states would be output the flowitem states when the flowitem exits the model. These saved states can be used for post analysis.

Just some of my opinions.

Nico,

Another approach to this issue would be to use a 'dummy' object in your model to represent the states of the flowitem you wish to record the states of. I have created a small model in which I use a queue object to collect the states of the flowitem moving through the model. Under Tools>GlobalVariables I make a pointer to this queue called "StateObject1" which I use in various model triggers to setstate() of the queue. I could not use a VisualTool object because the recorder does not include them in the object list.

As Alan pointed out, in a model with multiple flowitems you will need to decide on a particular flowitem of interest. Hopefully you would make this decision OnCreation then set a label on the item to flag the rest of the triggers in the model to set the state of the dummy object when the flag is present.

Note that the time before the creation of the flowitem and the time after the flowitem is destroyed (until the model is stopped) will be included in the state profile.

OR... if you are interested in the overall sum of states of all flowitems that have passed through the system:

Flowitem State Collector model
I have created another model that shows how a dummy object can be used to hold the sum of the flowitem state profiles. I called it a FlowitemStateCollector. There is also a screenshot showing where necessary changes were made in this model.

1. the flowitems must have a state profile node
2. the OnExit of the Source ensures the state profiling starts only when the item is introduced in the model
3. triggers along the way change the state of the item
4. the OnEntry of the Sink adds the item's state profile to the FlowitemStateCollector object's profile. Keep in mind that some flowitems are in the model longer than others. Thankfully the recorder presents the states as a percentage of the total of all states... not the current model time.
5. the name of the FlowitemStateCollector's state_current node must be cleared so the collector will not successfully manage it's own states
6. if you create a custom state on the flowitem, you must create it on the collector

I'm not sure if new developments to the recorder will make this redundant, but it is a solution at least for now.

Kris

Hi kris,
thanks for the answer. I will take a look at it when I find some time.
The dummy object is what I was talking about when I said it´s best to keep the stas else where.
In this special case I have some flowitems which never leave the model. (I use them as carts and they get loaded by Operators).
So I read the stats at the load and unload triggers and put them to a table, thats fair enough for a long run.