Identical Models Break Between 17.0.0 and 17.1.4

Question

question

Noah Z asked Aug 07 2017 at 1:23 PM Phil BoBo edited Aug 10 2017 at 7:43 PM

Identical Models Break Between 17.0.0 and 17.1.4

I recently upgraded from 17.0.0 to 17.1.4. The switch between versions broke the flow logic of a portion of the model I was building. I can’t attach my real model where this behavior was exhibited so I’ve created two dummy models which replicate the issue.

Basically, when I have the “Reevaluate Sendto on Downstream Availability” checked I expect the “Send To Port” to be rerun for flowitems in a queue when the downstream object becomes available at some point later in the model run(assuming it was busy at the first check).

This seems to work fine in 17.0.0 but in 17.1.4 it doesn’t appear to be working properly. To illustrate this point, I’ve attached two identical models that have been saved under each version. The Flow code in the queue assigns an output port of 500 to an item if the downstream processor is busy (effectively freezing the flowitem in the queue). However, when it gets re-evaluated once the downstream processor is complete with it’s work it should re-run the SendTo code and end up with a return value of 1 (sending the part to the processor). This works in 17.0.0 but not 17.1.4

One thing to note is that in my real model I can’t simply utilize “return 0” (first available) because depending on various conditions (time of day, type of item, etc) I need to send the part to various ports. I need the ability to “freeze” the flowitem at the queue if specific downstream processors are busy and then when they are available, re-execute the SendTo code.return-port-500-problem-in-1700.fsm return-port-500-problem-in-1714.fsm

Software Version:

FlexSim 17.1.4

flow version sendtoport 17.0.0

return-port-500-problem-in-1700.fsm (15.1 KiB)

return-port-500-problem-in-1714.fsm (15.1 KiB)

· 3

Sam Stubbs ♦ commented · Aug 07 2017 at 3:31 PM

This could be a bug. Especially since it's behaving differently between versions. Although it didn't seem to work on either version for me. I'll let the dev team take a look at it, they can look in the back end code, and see what's changed between versions.

In the meantime, as to your issue, as a work around, instead of using ports and port logic, have you considered using a List? You could create a List that has fields on it, with the constraints that you mentions. (Time of Day, time created etc etc.) And essentially have item enter a queue, and be pushed to an item list. Then they will sit at the queue until another object (for example a Processor) pulls them from the list. These pulls could be triggered as you say, by time of day etc. Especially if you're pairing the List with a Process Flow, then you'd have a great deal of control to "gate" your items based on certain constraints.

1 ·

Sam Stubbs ♦ commented · Aug 07 2017 at 4:06 PM

So I just spoke with one of the Developers. Unfortunately, we couldn't get the sample model you sent to work in any version. They all equally simply got stuck. He said that it would be difficult to verify, without seeing your main model. But there could be a change with the reevaluation code that may have affected your model. Instead of using 500 as the means to stop the item, he said to try a -1 instead. That's the number that normally should be returned to stop the item.

IF that still doesn't work with your main model, then again, I'd consider looking into Lists. I think you'll find that you have more direct control over your methods of control.

0 ·

Noah Z Sam Stubbs ♦ commented · Aug 07 2017 at 4:31 PM

Hmm..That's interesting that it wasn't working for you with the 17.0.0 version. I just recorded a short video with it working to show you what happens on my side. sendtoport-working-on-1700mp4.zip

I believe setting the port to "-1" will make the flowitem stay in that queue until I specifically call it using a "moveobject()" command. I just tested this by replacing the 500 with -1 and it looks like the "re-evaluate on downstream availability" does NOT trigger a re-running of the sendtoport code when I used the "-1" for the second flowitem.

I'll look more into using lists but I'm still confused/concerned as to why my actual model (and the example one created) seem to work fine with the logic in the older version.

0 ·

sendtoport-working-on-1700mp4.zip (273.3 KiB)

______

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 · 2017-08-09T23:17:12Z

Phil BoBo answered Aug 09 2017 at 11:17 PM Phil BoBo edited Aug 10 2017 at 7:43 PM

This is a bug introduced with 17.0.2.

The bug fix "Fixed an issue with setting item state incorrectly when using lists in Send To Port" inadvertently introduced this bug.

We'll see if we can get this fixed for the next bug fix release.

Thanks for pointing this out. Sorry for the trouble.

If this bug is critical for you, then you may want to roll back to 17.0.1 until we get this fixed for 17.0.8 and 17.1.5.

· 2

Noah Z commented · Aug 10 2017 at 4:35 PM

Thanks for the further clarification Phil.

Regarding the suggestion to roll back to a previous version until the bug is fixed is there a way to get an older version of FlexSim to open a model that has been saved in the newest version? I've had trouble where I try to use an old version of FS with a newly saved model (on 17.1.4) and the old version opens up a blank model. Is there a workaround for this?

0 ·

Phil BoBo ♦♦ Noah Z commented · Aug 10 2017 at 7:41 PM

Older versions of FlexSim can't open models saved in newer versions of FlexSim.

That's why the update message box suggests that you save your model "under a different name in case the updating process was not successful."

1 ·

question