Save/Retrive ProcessTime, SetupTime to bundle table

Save/Retrive ProcessTime, SetupTime to bundle table

guiroehe
Collaborator Collaborator
770 Views
6 Replies
Message 1 of 7

Save/Retrive ProcessTime, SetupTime to bundle table

guiroehe
Collaborator
Collaborator

Hello,

What is the proper way of saving/retrieve code properties to a bundle table?

For instance, for a processor, the "ProcessTime" and "SetupTime" properties can be of type "Unit" or "Code"

I was able to save the content of such properties to string columns using

myTable[row]["SetupTime"] = myProcessor.getProperty("SetupTime");

for instance.

However, when I use object.setProperty... to retrive the value, the property field of the object appears "empty" and the processor does not respect the originally saved value/code.

guiroehe_0-1750030012118.png

Thank you for any clarification.

0 Likes
Accepted solutions (2)
771 Views
6 Replies
Replies (6)
Message 2 of 7

joerg_vogel_HsH
Mentor
Mentor

A property table is much more than just a place to store values. It has got an ability to store complete functional code. 
Setup Time, Process Time, Use Transport, Send to Port and many more are functions returning a value instead of being a readable value of a node. If you want to store a return value of such functions you have to implement a mechanism in source code to achieve this. 
In FlexSim’s past you would have computed the return value outside the involved function, write it in a label and read this label being then returned in the function. Today you write this value into a parameter. In functions you read it to return this value.

My hint is, look into the tree to explore what character a property value is before you implement a mechanism that handles a property on an assumption that it is just a static value.

0 Likes
Message 3 of 7

FelixMoehlmann
Collaborator
Collaborator
Accepted solution

The the field appears empty is normal if the code does not contain any markup that denotes what should be displayed in the GUI. It should still return the correct time though. In an example model it works fine for me. Could you attach yours so we can look for differences?

Message 4 of 7

guiroehe
Collaborator
Collaborator

Hi, @FelixMoehlmann ,

thank you. By inspecting the treenodes as you did I could find that the execution time is being respected. Apologies for the misguided observation. It is strange, though, that the "setProperty" does not take care of markdowns to the benefit of the user. Anyway, thank you for the explanation.

0 Likes
Message 5 of 7

guiroehe
Collaborator
Collaborator

Hello, @FelixMoehlmann,

I have a follow up question on this topic, please:
Context:
1. I have a process flow with an OnEntry triggered activity that detects several aspects when an item enters a processor. Based on such aspects, a process time is defined. The process time is a distribution read from a bundle table stored in the object.
2. As per the conversation above, if there are no markdown tokens, the set content does not appear in the properties window.

3. In the same flow, after the item entered, I set the time based on the recovered item aspects.

Scenarios:

A. Using

current.setProperty("ProcessTime", 
	"Object current = ownerobject(c);\n" +
	"Object item    = param(1);\n" +
	"return " + tblProcessTimes[1]["time"] + ";"
);

B. Using

current.setProperty("ProcessTime", 
	"Object current = ownerobject(c);\n" +
	"Object item    = param(1);\n" +
	"return /**/" + tblProcessTimes[1]["time"] + "/**direct*/;"
);

Question for clarification:
Why, when I implement scenario "A" I get correct results, but when I implement scenario "B" I to not get correct results?
The portion

tblProcessTimes[1]["time"]

translates exactly the same in both cases; it could be a constant or a distribution.
Follow-up question:
What needs to be set so implementation "B" could work?

Thank you for your clarification and support!

0 Likes
Message 6 of 7

FelixMoehlmann
Collaborator
Collaborator
Accepted solution

I don't know to be honest. Neither of those options works correctly for me when I use them during the model run. Possibly because the code does not get re-compiled when it is changed. After a reset or "applying" the changes in the code editor they take effect.

Though I think if the objective is to change the process time dynamically during the model run there are better options than editing the code in the process time field.

- Just put the code that determines what to insert into the code into the process time field directly and make it return the value. Yes, that way you don't see which value was returned but you could also write it to a label before returning it to rectify that.

- Use an Event-Triggered Source that reacts to the "ProcessTime" event and override its return value. This is useful to have the logic in one central place if it is used for multiple processors.

 

Message 7 of 7

guiroehe
Collaborator
Collaborator

Hi, @FelixMoehlmann ,

thank you very much. As always, your insights are very helpful!

0 Likes