question

Kevin-Hsiang avatar image
1 Like"
Kevin-Hsiang asked Jason Lightfoot commented

Send to Port By Expression problem/bug?

The model source 3 types of item in the two cases.

The one is sent the item from Queue to Processor1,2. The other one is sent the item from Queue to Queue 2,3 (shown below). The Output Flow I setup that is using By Expression.

You can see that Item Type 3 should be left in the Queue in the Processor case because it only 2 output ports. But after I complete this setting in the Processor case, item Type 3 had been sent to the processor.

In the Queue case, the flow is right.

1692184633613.png

I check my operation in this model, and the setting is right.

Is there any operation wrong in this case, or maybe is a bug in this version?

Attach the model here

SendToPort Problem.fsm


Best regards,

Kevin


FlexSim 23.1.0
output portbyexpression
1692184633613.png (152.3 KiB)
sendtoport-problem.fsm (27.7 KiB)
· 1
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

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

Joerg Vogel avatar image Joerg Vogel commented ·

opened in 23.2 - same problem. Directly written in field didn’t change anything. Direct casting into integer didn’t change anything.

0 Likes 0 ·

1 Answer

Jason Lightfoot avatar image
1 Like"
Jason Lightfoot answered Jason Lightfoot commented

To hold the blue items you should return -1 in the sendtoport, or have the processors only pull the correct type.

Can you point me to he material that says returning the outputport length +1 is the correct way to prevent items from being released through ports, so that we can reference it in a bug report and have it fixed or have the documentation altered?

· 6
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

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

Joerg Vogel avatar image Joerg Vogel commented ·
@Jason Lightfoot, the problem is, that if you send an item to a port by a discrete number of 3 in Send to Port function, none item gets released. If you do it by evaluation of item label value with a range of 1 .. 3, then items get released even if the output port number doesn’t exist.

You find this construct to return an invalid port number for example in Picklist option Pull From Fixed Resource List.

0 Likes 0 ·
Jason Lightfoot avatar image Jason Lightfoot ♦♦ Joerg Vogel commented ·

The item is still FRSTATE_READY if you release through a non-existant port and I expect this is used to say "we don't know where we're going yet but the item is available to be pulled from a list or assigned a port" - and so when the processor becomes available it can, I expect, do the equivalent of pulling it from a list, but just using the port. The item sendTo is set to zero not 3 and so is a valid pick according to the outOpenEvent() call of the fixed resource.


By returning -1 the item is still in FRSTATE_INQUEUE and you're saying it has no port to go to. This could be better clarified through documentation which is why I wanted to know from where this notion of passing the larger port number originates.

Example sendToPort for the requested behavior:

1692198103816.png


1 Like 1 ·
1692198103816.png (12.6 KiB)
Joerg Vogel avatar image Joerg Vogel Jason Lightfoot ♦♦ commented ·
@Jason Lightfoot, as I said such construct is in picklist option pull from fixed resource list.
0 Likes 0 ·
Show more comments
Joerg Vogel avatar image Joerg Vogel Joerg Vogel commented ·
@Jason Lightfoot, there is a difference between an invalid assigned port number and a return value of -1. Negative one is explicitly evaluated to hold item, which results into stay until someone calls releaseitem again. Such items aren’t in the scope of items available for release anymore.
0 Likes 0 ·