Hourly times do not work as expected

[GerardWassink]

I saw and tested the Hourly schedules option.

Using server and client from rocrail-1.3.999-293-snapshot-unicode.exe

When I make the schedule times 00:xx then the loc immediately starts, even when the designated minute has not been reached.

When I make the schedule times 01:xx then the loc never starts. (I waited 'till model-time was 10 model-minutes past the schedule time).

Pls let me know whether you need trace files and stuff, I would think this one has got to be reproducable, since its not hardware related).

Gerard

[Rocrail (r.j.versluis)]

Revision 293 is not the right one to test with.
At least 298 is needed.

[Rocrail (r.j.versluis)]

But on the other hand when starting an hourly schedule at xx:10 or later, with its first entry set to 00:10, it will start immediately with a trace on how many minutes the delay is.

[GerardWassink (gerardwassink)]

Testing with snapshot 305 now. Starting clock at 11:58, scheduele's first time is 12:03, train takes of almost immed. after being started (modeltime is 11:59), only for one block. Waits there, potentially holding all traffic, untill 12:03 and starts to its assigned first destination.

At the next schedule time (12:18) it starts again and follows the schedule to its end (which is the original starting point. It there takes of immediately again and finishes everything at once.

It now repeats the schedules without any stops.

===== ANALYSIS =====
Where first hours and minutes where combined into the schedule and model times, presumably in this version only the minutes are taken into account, which fully explains the above scenario as follows:
- train starts immed. because :59 >= :03
- it reaches the next block at :00, which < :03, so it stops
- at :03 it takes off again to the next scheduled stop
- at :18 it rightly takes of back to its origin
- where it immed. takes of again, because :19 or :20 (wasn't looking at that moment) is >= :03
- thats why its repeating (undoubtedly until model tim reaches :00 again

===== Proposed SOLUTION =====
Make the comparison less wide, so not: sched_time >= model_time (which is obviously true the remainder of the hour), but something like (model_time - 1 minute) < sched_time < (model_time + 1 minute).

Here we have to be carefull when things like :59 and (:00 or :01) are being compared.

We're not quite there yet, almost, but...

Gerard

[GerardWassink (gerardwassink)]

Correction to previous entry:

===== Proposed SOLUTION =====
Make the comparison less wide, so not: *** model_time >= sched_time *** (which is obviously true the remainder of the hour), but something like (model_time - 1 minute) < sched_time < (model_time + 1 minute).

Wrong order of model- and schedule times in first comparison.

Gerard

[GerardWassink (gerardwassink)]

I see I made not clear that the schedule mentioned is its own successor, hence the repetition !!

Gerard

[Rocrail (r.j.versluis)]

Can you attach you plan.xml please.

[GerardWassink (gerardwassink)]

Of course. (I am very curious why this is needed though).

Gerard

[GerardWassink (gerardwassink)]

The afore mentioned schedule would be the one named "wh_hr_03"

[Rocrail (r.j.versluis)]

OK, the problem is clear to me.
I will do some extra testing and code changes to get it working as expected.

[GerardWassink (gerardwassink)]

Can I suggest the following in pseudo code?

int allowed_window = 1; /* allowed time slot for departure (absolute) */

if ( schedule_minutes <= allowed_window ) {
         schedule_minutes += 60;
}

if ( abs (modelclock_minutes - schedule_minutes) <= allowed_window ) {
         go =true;
}

Somthing like that...

[GerardWassink (gerardwassink)]

Oh, and perhaps make the allowed_departure_window default 1 or 2 minutes, but configurable in the Rocrail parms?

Sincerely,

Gerard

[Rocrail (r.j.versluis)]

You can test with the folowing snapshot:

http://rocrail.net/software/rocrail-snapshot/

[GerardWassink (gerardwassink)]

Tested it, and it seems to work better now. Nice job on the parameteriztion btw!

No a new problem occurs, my schedule stops half the way. I enclose a debug level trace file. It goes about its business very well, from wdm_3 to hlt_1 (xx:03) and back (xx:18). When I then set the clock forward to xx:31 (to get closer to the next departure time of xx:33) it takes of, travels ONE block to omd_1 and comes to a full stop.

Could you please investigate?

Gerard

[Rocrail (r.j.versluis)]

A debug trace is not the right one.

Disable debug and enable automatic trace.

[GerardWassink (gerardwassink)]

Ok, same situation, other trace file.

Gerard

[GerardWassink (gerardwassink)]

I think I've found it. I have the train running the same trajectory twice in one model-hour. At line 509 in trace.002 you can find that Rocrail thinks it has to look at what seems to be the second line of the schedule, which is the first iteration (containing xx:03), instead of the right one, the line about half-way, which is the second iteration (containing xx:33).

So now it thinks the schedule says xx:03 and then it stops. Makes sense, if it where the right line.

Gerard

[Rocrail (r.j.versluis)]

Can you attache the schedule too, so I can check the trace with it?
And which index is not correct?

20090403.154934.671 r9999a MAT64 OModel 2305 schedule index[0] found for block wdm_3
20090403.154934.671 r9999a MAT64 OModel 2388 currentBlock "wdm_3"

20090403.154946.750 r9999a MAT64 OModel 2276 schedule index[1] matches block omd_1
20090403.154946.750 r9999a MAT64 OModel 2388 currentBlock "omd_1"
20090403.154946.750 r9999I MAT64 OModel 2430 Try to find a route to block "omd_2".

[GerardWassink (gerardwassink)]

The schedule would be in the plan file from line 482 to line 506, as follows:

    <sc id="wh_hr_03" prev_id="wh_hr_03" relativetime="false" scaction="" timeprocessing="2" timeframe="2">
      <scentry block="wdm_3" hour="0" minute="3" swap="false" location=""/>
      <scentry block="omd_1" hour="0" minute="3" swap="false" location=""/>
      <scentry block="omd_2" hour="0" minute="3" swap="false" location=""/>
      <scentry block="omd_3" hour="0" minute="3" swap="false" location=""/>
      <scentry block="omd_4" hour="0" minute="3" swap="false" location=""/>
      <scentry block="hlt_1" hour="0" minute="3" swap="false" location=""/>
      <scentry block="omd_4" hour="0" minute="18" swap="false" location=""/>
      <scentry block="omd_5" hour="0" minute="18" swap="false" location=""/>
      <scentry block="omd_6" hour="0" minute="18" swap="false"/>
      <scentry block="wdm_2" hour="0" minute="18" swap="false"/>
      <scentry block="bdp_0" hour="0" minute="18" swap="false"/>
      <scentry block="wdm_3" hour="0" minute="18" swap="false"/>
      <scentry block="omd_1" hour="0" minute="33" swap="false"/> *************
      <scentry block="omd_2" hour="0" minute="33" swap="false"/>
      <scentry block="omd_3" hour="0" minute="33" swap="false"/>
      <scentry block="omd_4" hour="0" minute="33" swap="false"/>
      <scentry block="hlt_1" hour="0" minute="33" swap="false"/>
      <scentry block="omd_4" hour="0" minute="48" swap="false"/>
      <scentry block="omd_5" hour="0" minute="48" swap="false"/>
      <scentry block="omd_6" hour="0" minute="48" swap="false"/>
      <scentry block="wdm_2" hour="0" minute="48" swap="false"/>
      <scentry block="bdp_0" hour="0" minute="48" swap="false"/>
      <scentry block="wdm_3" hour="0" minute="48" swap="false"/>
    </sc>

And it's the line with the asterikses behind it where it stops. Somehow, because it gets at omd_1 twice, I suppose that the second time it reads the first schedule line where it finds that block?

[Rocrail (r.j.versluis)]

It is not possible to have schedule entries with the same block at the moment.

[GerardWassink (gerardwassink)]

Could this be made possible, for example to keep track (in the active schedule struct) of the index last handled?

Please?

Gerard

[GerardWassink (gerardwassink)]

Another possibility that would have the same effect, is to have a successor for the second part of the hour, but that (of course) does not work, because succession is exactly what we are trying to avoid in this Hourly business. Tried it and realized that it was not possible when it failed... ;-)

Yet another one would be to have the possibility to have more than one schedule active for one loc.

Gerard

[Rocrail (r.j.versluis)]

In revision 316 the double schedule entry problem is fixed.

> Yet another one would be to have the possibility to have more than one schedule active for one loc.
You can accomplish this with actions.

[GerardWassink (gerardwassink)]

316: nice! I will test it as soon as we can download it and let you know.

Could you explain how to do this with actions? Or point me to a url?

Thanks again,

Gerard

[Rocrail (r.j.versluis)]

> Could you explain how to do this with actions? Or point me to a url?
Read the Wiki or ask the Forum.
I know there are already threads in the forum concerning actions and schedules.

http://wiki.rocrail.net/doku.php?id=schedules-actions-en

[Rocrail (r.j.versluis)]

It seems that the nightly builds are broken.
Just test with the manual created snapshots;

http://rocrail.net/software/rocrail-snapshot/

[GerardWassink (gerardwassink)]

Ok, tried it and it works perfectly now. The same block ran twice within one hour, as a result of a schedule that specifies four trips, one from wdm to hlt, one back from hlt to wdm, and the next model-half-hour this commuter trip repeats itself.

However: now I set the clock forward to the next hour xx:01 and wait for it to reach xx:03. Then the whole cycle of two commuter runs per half hour should repeat itself. It doesnt. I waited for model-time to reach xx:15, it just doesnt move again.

This test-run I did not make a successor, so there is no follow-up schedule. suppose that's why it stopped.Fine so far, just testing.

The whole meaning of the Hourly schedule would be (for me) to be able to run a full day on schedules, specifying only one hour...

So, I did another test-run, now WITH a follow-up schedule, the same one of course. Now it runs the next hour as well, and I would expect the next one, and the next one, untill we pull the plug...

May I ask for one more functional addition?

I would like to be able to specify at what time this repating schedule has to start and at what time it should end. Can we have a starting and an ending time? Perhaps we can even make it a choice, you either specify a successor OR a starting and ending time. In that last way we would make hourly schedules inherently repeat themselves from starting time to ending time.

OR, if the previous is too much for now, at least be able to specify how often the successor schedule must run. Can we take that over in some struct?

Now that I think about it, I suspect that a starting and ending time are 1) more elegant and 2) more easy to implement.

My respect for your speedy solutions again, hope we can implement start and end-times, that would be really cool!

Gerard

[Rocrail (r.j.versluis)]

I consider this bug as fixed.
The mentioned extra functionality should go in the Wishlist.