User Event firing - precision problems

Has anyone experienced the strange phenonmenon of userevent set to fire every 3600 (1 hr) timeunit firing at a slightly shifted sim time other than even increments of 3600?

For example, I have a userevent set to 3600, it behaves well for first few hours then it decides to go crazy and shifts by five mintues or four mintues in a random fashion , in either direction, after the hour. This pretty much defeats the purpose of the event set to fire precisely on the hour.

Any and all help is appreciated.

How do you check, if it is working correct or not?
Do you just have a look onto the simulation clock?
I am pretty sure, that you do not have a “screen refresh” in your User Event. Please put e.g. a repaintall(); in your code and it should work.
You can also put a print out in the Output Console every time you fire the User Event and it should give the right values.

pr();pt("Event: ");pf(time());
repaintall();
stop();


I hope I am on the right track.

Tom

I do have repaintall(); in the userevent. The way I detect this condition is simply by a debug msg that stops the sim, when you check the simtime - it is sometimes not an even increment of 3600. Hope this makes it a bit clear.

I am not sure if I understand it right.
If I put my above code in the user event, it seems to work.
What do you mean by a debug msg?
Maybe the problem is that you use a condition like if(time() >= 3600). Then the problem is that you might not have an event at this exact time. A discrete event simulator jumps from event to event. So if you have an event at time 3000 and the next event is at time 6000 than the above condition is true at 6000.
What speaks against my theory is that you said you have an User Event at 3.600, which means that you take care to have an event at the right time. If this is the case then it might be possible that the User Event is fired first and then the condition is checked.

So I am a little bit confused now. Is there a chance to explain it more precise what you are doing? Or is it possible that you post a little model where happens what you describe?

I think sometimes msg boxes are processed asynchronously.Try using this:

 
pr();pt("Event: ");pf(time());
repaintall();
if(msg("user event","fired",2)){
 stop();
}

Jason

I think your assessment might be on the right track - since my debug msgbox at times fires multiple times within the same hour (I guess this is bad considering the userevent is set to fire at fixed intervals).

Tom:

Here is what was going on in the model - I have an userevent set to 3600. Within this event I have to prepare and induct the workload for THAT hour from a list of workloads by hour provided in a global table. Thus you can see the reasoning behind my use of Userevent to control this. The problem I was running into was that when I convert the simtime to SimHour it sometimes gives me unexpected values (say 7AM first time (correct since it fired at 7:00:00AM) and 7AM next time (also correct but userevent fires at 7:59:58AM, instead of precisely at 8:00:00AM). This is the reason I started this post.

After much trial & error - I found out that, any conversion math based on simtime done on the userevent is best done within the userevent.

My problem was - I was trying to be nice and do all the time conversion (simtime-->hour etc) in a common place on the visualtool that shows a running clock (a bit ironic, I know). In the visual tool - I was simply updating the global variable for the sim hour (yes, I do use quite a bit of repaintall , in fact to the point my model has more repaintall than any other useful simulation logic )

After losing sleep over this problem, I finally caved in and moved the sim hour logic inside of the userevent firing every hour. Now it is well behaved since all math is local to the userevent.

Thanks to all those who generously wasted their precious time on this silly problem.