Replacing old analog panels (and all the associated relay wiring) with virtual panels at the East and West end of 60' yards.
The thought was to use Pi's and touch screens talking to a 'larger' computer running the layout with PanelPro.? The testing was at home using
the RPi 3 (a Locobuffer sim since it is not really connected to anything) as the main system talking across wireless to Pi zeros.??
The problem with the zero's is that the browser uses 100% of the cpu, and response time is poor for updates just talking to the JMRI Web server for our size layout (5k square with about 100 Loconet devices).? Older iPads etc. need to use frames rather than panels, another poor response time option.
So I loaded JMRI on to the zero's, which consumed only roughly 30-50% of the cpu.? Then the decision is which client/server protocol to use to get a JMRI yard panel 'subset', a single panel 'screen' to work on the zeros for the yard operators.? Those yard screens are actually iconified on the main computer that is running primarily for dispatching functions.??
I was not able to get a test using SImple Server, or Loconet only to work...though Bob's thought that the Loconet sim is not robust seemed to be the issue.
At the club I was able to get Loconet over TCP working with good response, i.e. real time updates of the same panels located on both machines.? I guess what I was looking for was the ability to 'allocate' sub panels to different devices that do not necessarily need to share all the table data, i.e. the yard switches (and associated panel and tables) do not have to be known/controlled by the dispatcher's instance of JMRI who is concerned about the mainline.
Might be asking for too much,
Thanks for your assistance,
Martin Booker
