Send to Port By Expression problem/bug?

Question

question

Kevin-Hsiang asked Aug 16 2023 at 11:43 AM Jason Lightfoot commented Aug 23 2023 at 5:01 PM

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

______

Cookie preferences

Your privacy is important to us and so is an optimal experience. To help us customize information and build applications, we collect data about your use of this site.

May we collect and use your data?

Learn more about the Third Party Services we use and our Privacy Statement.

Strictly necessary – required for our site to work and to provide services to you

These cookies allow us to record your preferences or login information, respond to your requests or fulfill items in your shopping cart.

YES

Improve your experience – allows us to show you what is relevant to you

These cookies enable us to provide enhanced functionality and personalization. They may be set by us or by third party providers whose services we use to deliver information and experiences tailored to you. If you do not allow these cookies, some or all of these services may not be available for you.

YES

NO

Customize your advertising – permits us to offer targeted advertising to you

These cookies collect data about you based on your activities and interests in order to show you relevant ads and to track effectiveness. By collecting this data, the ads you see will be more tailored to your interests. If you do not allow these cookies, you will experience less targeted advertising.

YES

NO

Are you sure you want a less customized experience?

We can access your data only if you select "yes" for the categories on the previous screen. This lets us tailor our marketing so that it's more relevant for you. You can change your settings at any time by visiting our privacy statement

Your experience. Your choice.

We care about your privacy. The data we collect helps us understand how you use our products, what information you might be interested in, and what we can improve to make your engagement with Autodesk more rewarding.

May we collect and use your data to tailor your experience?

Explore the benefits of a customized experience by managing your privacy settings for this site or visit our Privacy Statement to learn more about your options.

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

Jason Lightfoot answered Aug 16 2023 at 12:11 PM Jason Lightfoot commented Aug 23 2023 at 5:01 PM

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 2: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 3: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 3: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 2: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