Return 0;

Hello,
I have got this simple model where a separator splits an item into 8. items are sent to 8 queues (of capacity 2) with the help of a transporter (capacity 2). I just would like to have my transporter to unload two items in the same destination in order of the output ports. [The destinations are simply 8 queues of capacity 2.]

Now, each queue receives only one whereas I would like the first available queues receive their full capacity which is 2. Do you have any suggestion that maneuvers on "SendtoPort" code of separator! Well, I welcome more suggestions based on "SendtoPort" code.

return trunc(getrank(item)/2)+fmod(getrank(item),2);

This will force round robin delivery to the first ports in 2's (Separator splitting only). However it is not a "first available" style logic, so if one of the queues is still full from the last round, then deliveries will stop until it is clear to receive.

In order to avoid some coding work in the SendToPort, I would suggest having the separator split an item into 4 (each representing 2), then have the transporter carry only 1 item at a time to separators (splitting to 2) that replace your existing queues. This way you could keep the default "First Available" SendToPort.

Another approach, is choosing the "Do Not Release Item" option in the SendToPort (return -1). Then sending a message from the ProcessFinish trigger to the separator itself where you can assess the downstream situation and release each of the items to the ports of choice using releaseitem(). This is a bit easier than trying to do it all from the SendToPort because you don't have to know as much about the sequence that the SendToPort and the RequestTransportFrom are executed for each of the 8 items. I suggest putting some pt()s in each of these fields to interpret what is going on behind the scenes.

another way is to write a logic in the >>break to<< function of the taskexecuter: a combination of same loadstation and same destination until the capacity of the TE is depleted.

Originally Posted by Kris Geisberger

return trunc(getrank(item)/2)+fmod(getrank(item),2);

This will force round robin delivery to the first ports in 2's (Separator splitting only). However it is not a "first available" style logic, so if one of the queues is still full from the last round, then deliveries will stop until it is clear to receive.

In order to avoid some coding work in the SendToPort, I would suggest having the separator split an item into 4 (each representing 2), then have the transporter carry only 1 item at a time to separators (splitting to 2) that replace your existing queues. This way you could keep the default "First Available" SendToPort.

Another approach, is choosing the "Do Not Release Item" option in the SendToPort (return -1). Then sending a message from the ProcessFinish trigger to the separator itself where you can assess the downstream situation and release each of the items to the ports of choice using releaseitem(). This is a bit easier than trying to do it all from the SendToPort because you don't have to know as much about the sequence that the SendToPort and the RequestTransportFrom are executed for each of the 8 items. I suggest putting some pt()s in each of these fields to interpret what is going on behind the scenes.

There is no way that I can ignore the first available requirement. The idea of having an item for two items is not what I could use in my model considering my specifications (actually this is the challenge of this modeling in hand). your third idea is not feasible because at processfinish of separator you only have access only to the ORIGINAL item and sending a message like
senddelayedmessage(current, 1, current, tonum(item));
is only giving access to the first rank object contained in separator! and even if I use getrank(), how come I could check if downstream is OK to send my items there because you never know with what condition to check the availability of downstream; they might always be reserved for items to be sent to but not full (thus , you cannot simply write getcontent(queues)==2 and solve the issue). so defining a condition that would allow you to determine queues being free in the sense that no previous item has been assigned would be the challenge

If there was a way to memorize the first available port and then assign the next coming item as the same port, it would have been the perfect solution.
How come could you manage to save the port in return 0; just before any other functions are run?

@Jorg
The problem if you take a closer look is not to manage the operator to take two and deliver at the same destination; as you might know the OnRequestTrigger happens (with a probable delay) after the Assignment of port. so, if you don't have the right port on your item, it doesn't help if you go for BreakTO requirement because the port is not the right chosen.

I have used a GlobalTable that saves the first available port and uses it for the second released item as well!

Originally Posted by shafizad

The idea of having an item for two items is not what I could use in my model considering my specifications (actually this is the challenge of this modeling in hand).

What specifications are preventing you from the single item approach? Even if you split them each into 2 after the transport?

Originally Posted by shafizad

your third idea is not feasible because at processfinish of separator you only have access only to the ORIGINAL item and sending a message like
senddelayedmessage(current, 1, current, tonum(item));
is only giving access to the first rank object contained in separator! and even if I use getrank(), how come I could check if downstream is OK to send my items there because you never know with what condition to check the availability of downstream; they might always be reserved for items to be sent to but not full (thus , you cannot simply write getcontent(queues)==2 and solve the issue). so defining a condition that would allow you to determine queues being free in the sense that no previous item has been assigned would be the challenge

Of course you can, you just don't know how yet. You should be more willing to learn when you ask for help. You have great potential. Attached is a model that uses the OnMessage trigger as a job dispenser. Basically when there are newly split items (ProcessFinish) or when the operator does not have any work (OnResourceAvailable) a message will be sent to tell the separator to release the next 2 items accordingly. This might not be the exact behavior you are searching, but the OnMessage contains plenty of commands to get you into trouble now. I'm still promoting the single item approach.

Your latest model with the global table will fail if there is a single item remaining in one of the queues. Connect a conveyor on the exit of one of the queues with capacity 2 to see that when the conveyor is full with 17 items (the 18th in the queue), the operator will deliver a single 19th item and the 20th will be stuck at the separator.

thank you for your feedback and excuse my impatience on commenting. I am sorry if it has carried a somehow negative impression.

I cannot unfortunately open your attached model to understand better your response.
Gives me this on console (as well as a message declaring a Syntax Error asking to open VisualC to verify syntax)
exception: Exception Caught in ObjectFunction002__project_exec_globals_nodefuncti ons_updatemodelversion object: MAIN:/project/exec/globals/nodefunctions/updatemodelversion class: MAIN:/project/exec/globals/nodefunctions/updatemodelversion

Error: GL_ARB_occlusion_query extension not available
exception: int stringsadd(char *s1, char *s2)
ex: stringsadd
exception: int stringsadd(char *s1, char *s2)
ex: stringsadd
exception: int stringsadd(char *s1, char *s2)
ex: stringsadd
Error: GL_ARB_occlusion_query extension not available

His model is in 5.1. You can't open it properly in a previous version.

We changed the file format for tree saving in 5.1 to pave the way for file encryption and password protecting models and libraries. Flexsim 5.1 is backward compatible with 5.0 tree files, but Flexsim 5.0 is not forward compatible with 5.1 files. This is the norm. You can't open a version 5 model in version 4. We've never kept forwards compatibility to make sure new stuff works in old versions. We try hard to keep backward compatibility to make sure old stuff works in new versions.

It doesn't give the "this model was built in a newer version" error because it doesn't open the model enough to know what version the model was built in. This is a draw-back of the old way of saving models, which we have tried to fix in the new file format by adding header information that contains the version number.

Opening a 5.1 model in a previous version is kind of like renaming a Word document to MyDocument.fsm and trying to open it with Flexsim. The effects are bad because we weren't able to see into the future in developing Flexsim 1.0 to know that we would need to change the file format for 5.1. The new system tries to take this issue into account though for future versions.

Originally Posted by shafizad

@Jorg
... so, if you don't have the right port on your item, it doesn't help if you go for BreakTO requirement because the port is not the right chosen...

You are absolutely right, I see my mistake now. I attached a small model which uses similar to the lastest models in this thread a table.

The Taskexecuter is able to deliver more Items than to only one unloadstation and and uses lifo- or fifo-stacking on delivering.



Jörg