article

Paul Toone avatar image
1 Like"
Paul Toone posted Phil BoBo edited

Item and Current   

The terms item and current are two access variables that refer to objects in FlexSim. When you edit the code of a given trigger or picklist, you will always see at the top of the code one or more "header" statements. These statements set up your access variables for you, and usually will look something like the following:

treenode item = parnode(1);  treenode current = ownerobject(c);  int port = parval(2);

For more information on port, see the Ports page.

Example

In this example, the first statement is what we call a variable declaration. For example, the second line declares a variable called current. The variable type of current is a treenode. This is a variable type that holds a reference to an object in FlexSim's tree structure. I don't want to go into too much detail on this, so in a nutshell, all data in FlexSim, including objects and flowitems, is stored as nodes in a tree structure, and the treenode variable type is simply a reference to a node (or object) in that tree structure. For more information on the tree structure, refer to the topic on FlexSim's tree structure.

The first statement's declaration also sets the value of this variable named current to: ownerobject(c). Now, I also don't want to go into too much detail on what the meaning of ownerobject(c) is because that can be a complicated side-track. The essential thing here is that you have a treenode variable (or object reference) called current, and you'll just have to trust me when I tell you that current will always point to the "current" object that you are editing the field for. If you go into a Source's parameters window and edit the Source's exit trigger, then in that field, current is a reference to that Source object. If, on the other hand, you go into a Processor object's parameters window, and open the code for the Processor's process time field, then within that field, current is a reference to that Processor object.

The example code also has a second statement. The statement is another declaration of a treenode variable, called item this time, that is given the value: parnode(1). Again, in order not to get side-tracked, I'm not going to explain the parnode command but will just say that item will always refer to the flowitem that is associated with a specific execution of that field or trigger. For example, if you are implementing the exit trigger of a Source, then each time the exit trigger is fired, item will refer to the flowitem that is exiting the Source at that specific time. Note that the item reference will change each time the exit trigger is executed because a new flowitem is exiting, whereas the current reference will be the same each time because the Source object does not change.

So these header statements set up the access variables that can be used within the code of the field. This is why in the previous examples I was able to use the word item in writing the commands:

setitemtype(item, bernoulli(60,1,2));

or:

if(getitemtype(item)==2)...

because I have a reference to the flowitem and the reference is named item.

Often the header statements mentioned above will vary depending on the type of field you are writing code for. For example, the header statements of an exit trigger should look like this:

treenode current = ownerobject(c);  treenode item = parnode(1);  int port = parval(2);

Here there is an additional variable declaration of an integer called port. In this case port is the output port number through which the item is exiting. A reset trigger's header statements, on the other hand, will look like this:

treenode current = ownerobject(c);

Here there is only one variable declaration, namely current. There is no item declaration. The reason for this is because the reset trigger, which is executed when you press the model reset button, has no specific flowitem associated with its execution.

This user manual documents each field and its access variables in the topics and sub-topics of the picklist section.

Review

So to review, within FlexSim's code fields you will often have access to variables called current and item. Current will always reference the object whose code you are editing. Item will always reference a flowitem that is associated with a specific execution of the field (e.g. the item that is exiting the Source). The access variables will vary based on the type of field, but you can always find which variables are available just by looking at the header statements at the top of your code, or by referring to the user manual.

Note on specifying the correct object when accessing labels or itemtype: It is important to understand which object is holding a label or itemtype. For example, in the example above we use the command getlabel(item, "numOfCopies"). We do not use getlabel(current, "numOfCopies"). The reason we use item and not current is because the label is stored on the flowitem itself, and not on the FlexSim object. If you add a label to a flowitem in the flowitem bin, then item should be the reference for the getlabel command. On the other hand, if you are using a label on the object (you have added the label to the object through its properties window), then current should be the reference in the getlabel command.



flexsim users manual
· 2
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Michael avatar image Michael commented ·

When calling a user command from an object's trigger's custom code, does the "current" in the user command scope still reference the original object that was triggered? Or should we pass in a reference to the object as an argument to the user command?

0 Likes 0 ·
Phil BoBo avatar image Phil BoBo ♦♦ Michael commented ·

From an object's trigger's custom code, current is a local variable. You need to pass it as an argument to the user command if you want to access it within the user command.

1 Like 1 ·

Article

Contributors

paul.t contributed to this article

Navigation

FlexSim 2016.1