Changes in operator behaviour from v3.01 to 3.32

Hi All,

The attached simple model (basically just an operator running back and forth) takes 35s to run in the old version of flexsim and 25s in the new version. Wondering if anyone could explain to me why this is the case?

Thanks
Paul

Paul,

I tried downloading your model but I can't open it (I have tried many programs). Can you try zipping it with another program and posting it again?

Brandon

Hmm don't know why that happened. Here's one zipped in windows zip...

Have also attached 2 small videos showing the different versions. It appears to me that:
- The old version (4.01) drops straight from full speed to v = 0 on arriving at the load/ unload location, and accellerates back up at a given rate
- The new version (4.32) drops to 0 and then immediately goes back up to full speed (infinite acceleration and deceleration). To back this up, when i give the model a ridiculously large acceleration in the old version, it performs the task in 25s.

Paul,
Thank you for bringing this to our attention. This is a bug that was introduced with the 4.3 release. We added some features to the task executer, and in doing so, apparently this bug crept in. If the operator does not need to travel any distance to get back to the last node that he was at (this happens when the task executer is set to not travel offsets), then he will start traveling at his full speed, instead of accelerating up to full speed. We will fix this in the next release. For now, if you would like it to work like it did in 4.01, you can add the following code to the OnArrival trigger of any network nodes that the object will travel to. Also, this is not an issue if you've set the operator to travel offsets.

if(fromedge == 0)
    setvarnum(traveler, "lastupdatedspeed", 0);

Sorry for the inconvenience.

Hi Anthony,

first of all thanks for your quick statement. I saw your answer to Pauls email and I want to add on another question (he is my colleague and we had a chat about the acceleration/deceleration discussion) .
If the task executer is set in the old Flexsim version to not travel offset the acceleration happens on the path, you are right! But what is with the deceleration?
The deceleration just happens in that moment you travel offset. It starts in the moment you leave the path, which I found already funny in the old version. Is it possible to start the deceleration already on the path and not just in the offset modus?

Thanks in advance
Jens

Jens,
Yes, it is possible to allow deceleration on the network. By default the task executer will have his full speed be the end speed of the travel task because there isn't any "lookahead" mechanism to see what the next task after the travel task will be, so he can't really tell whether he should slow down at the end of the travel task. So since the default is for him to travel offsets, we decided to have the default end speed of a travel task be his full speed. To change that, you can go to the Flow tab of the object generating the task sequence (in the example it's the upstream queue), and in the "Request Transport From" field, choose the option Task Sequence Example 1. Then go into the code and for each of the travel tasks, add a parameter onto the end of -1:

inserttask(ts,TASKTYPE_TRAVEL,current,NULL,-1);
inserttask(ts,TASKTYPE_FRLOAD,item,current,port);
inserttask(ts,TASKTYPE_BREAK,NULL,NULL);
inserttask(ts,TASKTYPE_TRAVEL,outobject(current,port),NULL,-1);
inserttask(ts,TASKTYPE_FRUNLOAD,item,outobject(current,port),opipno(current,port));

This will cause the end speed of the travel task to be 0 (passing a value of 0, or the default value, means full speed). If you specify a positive value for that parameter (>0), then that will be the positive end speed of the travel task, meaning you can slow him down to slower-but-not-stopped speed by the end of the travel task. As far as having it be a completely smooth deceleration continuing from the travel task to the offset, that is much more complex because you'd need to calculate the distance he's going to travel for his offsets, then back-calculate the end speed from that, so that's possible, but much harder.

Good Luck,

Hi Anthony,

Thanks for this advice (on behalf of Jens + myself). This provides a very good solution that behaves exactly as we would like it to.

So i guess the only situation not covered (by one solution or another) is the case when you're travelling offsets and there isn't time to decelerate to 0 over the course of the offset. Your choice is to either decelerate to 0 at the node and speed back up again for the offset, or to reach the final destination at a speed greater than 0. I realise this is very nitpicky, I say this not as a criticism (it doesn't affect me at all as i generally don't allow offsets for operators) but as a warning for other young players like myself...

Regards

Paul