Identical Models Break Between 17.0.0 and 17.1.4

Question

question

Noah Z asked Aug 7, '17 Phil BoBo edited Aug 10, '17

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 03: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 04: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 04: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)

Answer 1 · 2017-08-09T23:17:12Z

Phil BoBo answered Aug 9, '17 Phil BoBo edited Aug 10, '17

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 04: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 07: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