In FlexSim there is a close interaction between the "under-the-hood" behavior of the objects in your model and the logic that you implement on those objects through code fields. Often the very reason that a code field is executed is because the FlexSim object (Processor, Source, etc.) is requesting data from you the modeller as to how it should operate. For example, the process time field of a Processor is executed because the Processor needs to know from you what its process time should be for a given flowitem. The way that you pass the correct information back to the Processor is through the return value of that field, or in other words, by executing a return statement in your code.
Example
Let's refer back to the post office example mentioned previously. In that example we implemented the process time code as:
if (getitemtype(item) == 1) return 3; else return 5 + (getlabel(item, "numOfCopies") * (5.0 / 60.0));The Processor will execute this field each time it receives a flowitem, just before it starts the process time. By executing this process time field, it is essentially asking you what the process time for that item should be. In this code we are using the return statement to pass back to the Processor the appropriate process time for that flowitem. Thus, the return statement is used to give back to an object the appropriate data that it needs to operate as we want it to.
Many fields do not need a returned value. For example, in the post office model the Source's exit trigger does not include a return statement. The reason for this is because with an exit trigger, the Source object is not trying to get information back from you, it is simply providing you with a spot where you can execute functionality when a flowitem exits the Source.
This user manual documents each field's required return value in the sub-topics of the pick lists section.
