Send to Port By Expression problem/bug?

[az87416]

[ FlexSim 23.1.0 ]

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.

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

[joerg_vogel_HsH]

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

[jason_lightfoot_adsk · Accepted solution]

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?

[joerg_vogel_HsH]

@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.

[joerg_vogel_HsH]

@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.

[jason_lightfoot_adsk]

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:

[joerg_vogel_HsH]

@Jason Lightfoot, as I said such construct is in picklist option pull from fixed resource list.

[az87416]

Thanks for your answer.

I referenced the FRSTATE_READY & FRSTATE_INQUEUE from the user manual, meaning that if the output port is processor, its default state is FRSTATE_READY, and the state is like picklist option pull from fixed resource list. The item would be pulled , even if its Type value does not have a corresponding output port(when I use By Expression.)

If the output port is Queue, the state of Queue is FRSTATE_INQUEUE.

The above is my understanding of the two states, is this correct?

[jason_lightfoot_adsk]

The description under getitemstate() tells us:

FRSTATE_INQUEUE: The flowitem is in-process; it has not been released yet.
FRSTATE_READY: The flowitem has been release, but has not found a downstream object that is ready to receive it.
FRSTATE_MOVEREQUESTED: The flowitem has been released, and a downstream object is ready to receive it, but the item is waiting to get picked up by a transport.

As such it's not dependent on the type of object.