Messages behaving differently when stopping processor and station

Question

question

Axel Kohonen asked Jan 18, '18 Axel Kohonen edited Oct 12, '18

Messages behaving differently when stopping processor and station

Hi,

If I send a message to processor that arrives in 10 seconds and then immediately stop the processor the message is also stopped and arrives 10 seconds after the processor has been resumed. The message also disappears from the event list during the time that the processor is stopped. This is displayed in the attached testmessagebehaviouratstop.fsm model.

If I do the same for a station on a conveyor the message arrives on the original time without regard for the fact that the station is stopped. See the attached testmessagebehaviouratstop-conveyor.fsm model.

This difference is somewhat confusing. Is there some particular reason for the station and the processor to work differently here? And is it possible to somehow choose which behavior one wants to get?

Kind regards,

Axel

Software Version:

FlexSim 17.2.5

message trigger stop object

testmessagebehaviouratstop.fsm (16.2 KiB)

testmessagebehaviouratstop-conveyor.fsm (27.6 KiB)

· 1

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Axel Kohonen commented · Jan 19, 2018 at 01:00 PM

For the stations on the conveyor I solved the problem by

Storing the time when the object is stopped in a label
Catching the message as it arrives during the stop and
1. Calculate the time it went into the stop from the current time and the label value
2. Write all the information in the message and the calculated time into an array and store it in a label on the station
When the station is resumed I recreate all the messages using the information in the array and send them as much delayed as the time I calculated. Then I clear the array.

I still want to know if there is some easier solution though.

0 ·

Answer 1 · 2018-10-12T06:58:07Z

Axel Kohonen answered Oct 12, '18 Axel Kohonen edited Oct 12, '18

The code in Phil's answer works, but delayeventsofobjects somehow messes up the message parameters as explained in this post. The answer to how to do for now is in the other post.

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Answer 2 · 2018-02-08T16:07:42Z

Phil BoBo answered Feb 8, '18 Axel Kohonen edited Oct 11, '18

The station handles stopping and resuming differently than a processor because its events affect the conveyor it is on (and potentially other connected conveyors in the conveyor system in certain situations), not just itself.

The station is overriding the methods of the FlexSimObject that would normally remove and restore the events of the object when it is stopped and resumed. I'll add a case to the dev list to consider whether we should also remove and restore any pending events on the station in addition to the unique things that it is doing.

For now, an easier workaround would be to use delayeventsofobject() to delay the events far into the future when stopped and then bring them back to the present when resumed:

if(msgparam(1) == 1){
	//stop the station
	Object station = current.centerObjects[1];
	station.stop(STATE_BUSY);
	delayeventsofobject(station, GLOBAL_DELAYINDEFINITE);
}
else {
	//resume the station
	Object station = current.centerObjects[1];
	station.resume();
	delayeventsofobject(station, -GLOBAL_DELAYINDEFINITE + time() - getvarnum(station, "timeoflaststop"));
}

· 1

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Axel Kohonen commented · Oct 10, 2018 at 10:07 AM

The code works, but delayeventsofobjects somehow messes up the message parameters as explained in this post. The answer to how to do for now is in the other post.

1 ·

question