I’ve been using a script I copied and modified from script examples a couple of decades ago (attached) which “for turnouts in turnouts.getNamedBeanSet() :” sets all but a few of my turnouts to CLOSED. I have a very large basement size layout.? An iMac is connected via a LocoBuffer-NG to a Digitrax DCS 240+ which controls 4 DB150 and DB100 boosters. I have confirmed all are working correctly.

?

Recently, this script is causing the connection between my computer and the layout to freeze, for example, I can no longer turn the layout on or off from the computer.? Looking at the LocoNet Monitor (attached) I can see some turnouts being set to CLOSED but then the connections begin to fail. As the system keeps trying to set new turnouts and re-trying to set previously failed connections, it stops.

?

This problem has been getting worse over many months, so I can no longer says what I did that might have caused it. And it has taken me several months to narrow down the symptoms this far and figure out how to recover the connection.

?

To recover, I have to quit PanelPro, disconnect the LocoBuffer USB from the computer, reconnect it, and restart PanelPro.

?

My railroads XML file looks OK. All the turnouts that failed to set are included in the XML file and are in the PanelPro turnout table. I don’t know how to access “NamedBeanSet()” to further troubleshoot the problem. Something has probably become disconnected but I can’t find the problem. Any help you can give would be appreciated.

?

Thanks,

Nick Brownsberger

Attached files are here.

Thanks. Looking at that now, but I made need help with it.

Thank you very much. I was able to solve my problem by using a "wait(350)" command in my script to slow down the turnout commands.

?

Nick

Nick and anyone else who happens to read this thread looking for help with high volume message traffic issues,?

?

You should be aware of the fact that each iteration the wait() function inserted in the "intialize.py" script as earlier posted in this thread will cause the main JMRI program thread of the entire PanelPro program to pause for the specified duration.? In other words, Everything Stops!??

?

If your script is only run as one of the startup options, the cumulative delays might not be of much concern, at least right now.? Since you described a personal layout in the OP, you have control over all the future ramifications.

?

Other group members reading this may not have such freedom of control.??

?

In our club situation, it is not clear who will make what changes in the future or who will decide to run a script during a messed up Ops session or who will complain when something goes wrong due to some unexpected change or even if they will be aware of the implications of multithread execution.? It is also not clear that I will still be able to dig for answers to any such questions.??

?

The distributed example scripts named "InitAllTurnoutsSensors.py" and "InitLocoNetSensors.py" wrap their advertised decision process in classes derived from jmri.jmrit.automat.AbstractAutomaton as do several other examples, for a good reason.??

?

The big advantage for this discussion, is that the AbstractAutomation class runs on a thread that is not the main program thread.??

?

See for a lot of details, but of interest here is a very long list of functions with names that start with "wait..." that give us some slack to allow a hardware item to respond when or even if there is some external action.??

?

In particular a line of code copied directly from one of the aforementioned scripts that was inserted precisely because we have no control or even much insight into the workings of LocoNet internals:

?

? ?self.waitMsec(125) ?# stall for Command Station action

?

That and similar instructions were added because our club had the same problem you described more than 12 years ago, random incomplete initialization errors. If one searches this group's messages or the /g/LocoNet-Hackers/topics list or perhaps any network related website for message storm or related terminology, there is way too much sad information to share.??

?

The delays do not provide a fix, merely a workaround and are subject to periodic revision as additional LocoNet hardware keeps making new puzzles to deal with.

?

BillyBob provided instructive and useful information back then that helped me, and I am still grateful.

?

The JMRI document he pointed you to has evolved a lot since then.

?

Other DCC Command Stations have similar message traffic limitations for large layouts, but of the few that I have had experience with, better information has been available to the users.??

?

Cliff in Baja SoCal

?