Send to Port By Expression problem/bug?

Question

question

Kevin-Hsiang asked Aug 16, '23 Jason Lightfoot commented Aug 23, '23

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.

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

Software Version:

FlexSim 23.1.0

output port byexpression

1692184633613.png (152.3 KiB)

sendtoport-problem.fsm (27.7 KiB)

· 1

Joerg Vogel commented · Aug 16, 2023 at 11:59 AM

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

0 ·

Answer 1 · 2023-08-16T12:11:06Z

Jason Lightfoot answered Aug 16, '23 Jason Lightfoot commented Aug 23, '23

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

Joerg Vogel commented · Aug 16, 2023 at 02:44 PM

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

Jason Lightfoot ♦ Joerg Vogel commented · Aug 16, 2023 at 03:00 PM

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:

1 ·

1692198103816.png (12.6 KiB)

Joerg Vogel Jason Lightfoot ♦ commented · Aug 16, 2023 at 03:07 PM

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

0 ·

Show more comments

Joerg Vogel Joerg Vogel commented · Aug 16, 2023 at 02:52 PM

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

question