Hemiptera Bugtracker at bugs.linux-forks.de

I made a setup of a LuaATC track to have a train to departure every 10 minutes (/ph).

Some LCDs should also display the information

The first try to do it was that I had setup a operation panel as information hub to preprocess the data including the actual time for sending them to the LCD. That worked well - as long as the area was loaded. When the area was unloaded and loaded again the interrupt for keeping the displayed time current seemed to be lost.

My suspicions: the interrupt itself is lost or the 'digiline_send()' kills the Lua processing while the operation panel is unloaded.

The next try moved the 'digiline_send()' to another operation panel and keeping the time display currrent was also moved to it.

The test was the same desaster like before - the display was not refreshing and the information was old.

It seems to me that the internal interrupts in operation panels are lost when unloading and the 'digiline_send()' also kills any Lua processing in unloaded areas.

I would exprect that the internal interrupts are continue to work and the the 'digiline_send()' becomes a no-op in unloaded areas, so that the other commands are executed without problems.

If the interrupts can't be kept running in unloaded areas then I expect at least a "wakeup" event when the operation panel is loaded again to at least be able to clean up the mess from the missing processing.

I suspect that digiline_send executed in unloaded areas fails silently, so that the interrupt() call is never executed.

please try what happens when moving the interrupt() call before the digiline_send() call.

Independent of this, I need to investigate.

Am 27. August 2018 15:20:01 MESZ schrieb 58@bugs.linux-forks.de:

>I made a setup of a LuaATC track to have a train to departure every 10

>minutes (/ph).

>Some LCDs should also display the information

>The first try to do it was that I had setup a operation panel as

>information hub to preprocess the data including the actual time for

>sending them to the LCD. That worked well - as long as the area was

>loaded. When the area was unloaded and loaded again the interrupt for

>keeping the displayed time current seemed to be lost.

>

>My suspicions: the interrupt itself is lost or the 'digiline_send()'

>kills the Lua processing while the operation panel is unloaded.

>

>The next try moved the 'digiline_send()' to another operation panel and

>keeping the time display currrent was also moved to it.

>The test was the same desaster like before - the display was not

>refreshing and the information was old.

>

>It seems to me that the internal interrupts in operation panels are

>lost when unloading and the 'digiline_send()' also kills any Lua

>processing in unloaded areas.

>

>I would exprect that the internal interrupts are continue to work and

>the the 'digiline_send()' becomes a no-op in unloaded areas, so that

>the other commands are executed without problems.

>If the interrupts can't be kept running in unloaded areas then I expect

>at least a "wakeup" event when the operation panel is loaded again to

>at least be able to clean up the mess from the missing processing.

--

Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

> please try what happens when moving the interrupt() call before the

> digiline_send() call.

I have reworked the LuaATC code, it had still (unneeded) digiline_send().

So I will see if that was causing it.

In all other parts of the setup are the digiline_send() moved in operation panels with only the digiline_send() to separate them from the interrupt()-calls

I found the probable cause of this bug:

The definition of the operation panel set the groups:

groups = {

        cracky = 1,

        save_in_nodedb=1,

    },

However, that group was renamed to "save_in_at_nodedb". This caused that

operation panels were not saved in the node db at all.

What failed silently was not the call to digiline_send, but the

interrupt to the operation panel itself.

I fixed the group and included a warning when a node that receives an

interrupt is not found.