开云体育

Hi!

I'm playing around with CMRI and trying to get it working over the network interface.

Version 5.3.5 and using, primarily, the Michael K. Adams ArduinoCMRI library on an Arduino mega with a W5500 ethernet board.

When creating a CMRI connection in the JMRI preferences, all nodes default to 'enable polling on startup' being unticked. I can understand why but I think this causes problems.

Firstly, there seems to be a bug in the node interface where changes to that tick box are not permanently saved. This is under any connection type, serial or network. Go in, tick or untick the box, done, save preferences. The change persists while JMRI is running but does not persist when JMRI restarts.

I tried to work around the polling thing in the Arduino code by just sending a response to a poll anyway every 250 ms even though it didn't actually receive one. There is a discussion here, obviously, around only sending responses when sensor values actually change, but I'm just trying to work through the simple stuff to start with and see if I can get it working in a basic fashion without issues.

This approach works, the CMRI monitor logs the receive and data, and sensor states are updated accordingly.

However, an error appears in the CMRI log, every time the receive arrives
2023-04-25 11:21:55,919 jmrix.AbstractMRTrafficController???? ERROR - reply complete in unexpected state: 10 was 42 52 01 00 00 in class serial.SerialTrafficController [serial.SerialTrafficController Receive thread]

From a quick search, it appears that this error is related to poll responses not being received within a certain timeframe and wonder if the error is being triggered falsely, because a reponse is being received without a poll being sent.

So I was wondering if anybody could have a quick look - either make changes to 'enable polling at startup' in CMRI node preferences persist, or see if that error message can be stopped when a receive occurs without a poll being sent. The whole approach does appear to work, it's just that error message filling up the console window that doesn't feel right.

This 'false response to an imaginary poll' approach uses the 'GET' command, as I believe 'SET' is specific to a node and requires a destination node address, which CMRI on JMRI does not have, as far as I know. A 'GET' seems to be known by CMRI as s response from a node (with the sending node's address included) which is intended for the controlling CMRI itself, allowing it to locate the correct sensor on the correct connection on the correct node at the correct address and update it.

I did try moving back from a Network connection to a Serial connection, using the same approach as above - turn off polling and send responses anyway - and the error messages were still there, so I don't think the error is specific to the Network configuration, it's just triggered by it due to the change in polling defaults.

Thanks for reading if you got this far!

Chris

Chris -

Unfortunately, people run into this problem every now and then (see?/g/jmriusers/topic/86916126#196196).?
I worked with one of the developers on this a while back but we didn’t make too much progress. ?Perhaps your new information will help.

For my own layout, I shifted to using MQTT over wifi as a much more capable (and also user-friendly) protocol for monitoring and controlling turnouts, sensors, and accessories. ?There is also an active user group MQTT4MR.

Jerry
___________________________________
jerryg2003@...

Thanks Jerry!

It may well have been you who recommended MQTT to me a week or two ago - thank you! I've looked into it extensively and am well towards getting it implemented. I'd say, though, it's in some ways not as simple and accessible as CMRI.

For example, with CMRI, management of shift registers and most inputs is much more simple - I can just get a byte from a shift register, shove it into CMRI and everyone is happy because CMRI communicates in bytes.

With MQTT it dela only with single values for single accessories, so blending that into and out of bytes for shift registers takes a little more thinking about.

I think CMRI serves as a very accessible entry point to accessory control buses, and it seems to me that CMRI over TCP/IP can and does work perfectly well - and that the error message that's generated in the logs is being triggered incorrectly. If that could be suppressed, CMRI would work very well over TCP/IP.

Totally agree on MQTT though, it's very efficient and very well implemented in JMRI too.

Chris

There are three things here, I think:

1) The ERROR message probably shouldn’t be emitted when an unsolicited input message is received, particularly when JMRI isn’t polling on a network link. I’ll check on that.

Note that “Send when you have data” or “Send periodically” instead of “send in response to poll” is very problematic on an RS485 connection. If you have more than one node present, that will almost certainly not work right. The RS485 link can only have one node sending at a time, and there’s no way to sort out who can send and who can’t except for the polling mechanism.

2) “enable polling on start up” not being remembered from run to run. When I looked at this last, I wasn’t able to recreate it. I agree that, to the extent it’s happening, it’s a bug. But it’s hard to fix a bug that I can’t recreate. Could you send me your profile.xml file? It’s found in the profile directory for your current profile, under the JMRI preferences directory.

3) JMRI on network connections defaults to not sending polls. Personally, I think this isn’t the right default, but the person who wrote this code strongly disagreed. But that won’t matter if I can fix the problem with remembering the polling status, see (2) above. So I’ll focus on that.

Might be a few days before I can get to all this.

Bob

On Apr 25, 2023, at 6:35 AM, Chris Holden <chrisholdenyork@...> wrote:

Hi!

I'm playing around with CMRI and trying to get it working over the network interface.

Version 5.3.5 and using, primarily, the Michael K. Adams ArduinoCMRI library on an Arduino mega with a W5500 ethernet board.

When creating a CMRI connection in the JMRI preferences, all nodes default to 'enable polling on startup' being unticked. I can understand why but I think this causes problems.

Firstly, there seems to be a bug in the node interface where changes to that tick box are not permanently saved. This is under any connection type, serial or network. Go in, tick or untick the box, done, save preferences. The change persists while JMRI is running but does not persist when JMRI restarts.

I tried to work around the polling thing in the Arduino code by just sending a response to a poll anyway every 250 ms even though it didn't actually receive one. There is a discussion here, obviously, around only sending responses when sensor values actually change, but I'm just trying to work through the simple stuff to start with and see if I can get it working in a basic fashion without issues.

This approach works, the CMRI monitor logs the receive and data, and sensor states are updated accordingly.

However, an error appears in the CMRI log, every time the receive arrives
2023-04-25 11:21:55,919 jmrix.AbstractMRTrafficController ERROR - reply complete in unexpected state: 10 was 42 52 01 00 00 in class serial.SerialTrafficController [serial.SerialTrafficController Receive thread]

From a quick search, it appears that this error is related to poll responses not being received within a certain timeframe and wonder if the error is being triggered falsely, because a reponse is being received without a poll being sent.

So I was wondering if anybody could have a quick look - either make changes to 'enable polling at startup' in CMRI node preferences persist, or see if that error message can be stopped when a receive occurs without a poll being sent. The whole approach does appear to work, it's just that error message filling up the console window that doesn't feel right.

This 'false response to an imaginary poll' approach uses the 'GET' command, as I believe 'SET' is specific to a node and requires a destination node address, which CMRI on JMRI does not have, as far as I know. A 'GET' seems to be known by CMRI as s response from a node (with the sending node's address included) which is intended for the controlling CMRI itself, allowing it to locate the correct sensor on the correct connection on the correct node at the correct address and update it.

I did try moving back from a Network connection to a Serial connection, using the same approach as above - turn off polling and send responses anyway - and the error messages were still there, so I don't think the error is specific to the Network configuration, it's just triggered by it due to the change in polling defaults.

Thanks for reading if you got this far!

Chris

—
Bob Jacobsen
rgj1927@...

Thanks Bob! First things first - some steps to recreate.

Run PanelPro, Windows, profile prompt - Create new profile
Called it USBTestProfile, clicked OK.
Preferences window appears. Select C?MRI
System connection = Network Interface
Enter IP address - 192.168.100.110
Additional ticked = port 9006
Configure nodes
Add node
Node address 1 (note that at this point 'Enable Polling at Startup' is ticked)
Done, OK, Done, Save.
Yes to restart
Select newly created profile
When PanelPro loads - Edit - Preferences
Connections - CMRI - Configure Nodes
Select, edit node created eariler
'Enable polling at startup' is not ticked
It's possible here to tick it, save, done etc. and polling will start, but it doesn't persist across restarts of JMRI.

I had a root around in the profile.xmls and did spot that this line, when a node is created in a profile using Serial, is present

<parameter name="cmrinetoptions">1000000000000000</parameter>

However, when a node is created on a network interface connection, this line is not placed in the profile.xml.

Even a manual edit of the profile.xml, pasting that line in, doesn't cause the polling box to be triggered ticked on next load.

I did a little searching and digging in the JMRI repo, hope you don't mind - and found this.

JMRI-master\java\src\jmri\jmrix\cmri\serial\serialdriver\configurexml\ConnectionConfigXml.java

This file seems to manage the general IO of the connection and node settings. It has several references to, and handling for, cmrinetoptions.

JMRI-master\java\src\jmri\jmrix\cmri\serial\networkdriver\configurexml\ConnectionConfigXml.java

This file seems to do the same for the network options - but this has not one mention of cmrinetoptions in it.

Since the 'Enable debugging at startup' tickbox is sat in a box labelled 'CMRINet Options' in the UI - this could well explain it - the polling option is being neither saved nor loaded at save / startup.

Again I totally get why - (and yes, I'd always leave polling on when using RS485 comms - I'd only look at reactive sending of data over network) - the aforementioned dev would feel that polling was not needed - but maybe including the option to have polling on by default, and suppressing the error message when receiving a response to a poll that was never sent (only on the network interface) would put it to bed once and for all!

Example profile.xmls here

/g/jmriusers/files/ProblemsBeingWorkedOn/Chris%20Holden%20Blocks/CMRI

Regards,
Chris

Bob and all-

i ran into this problem a while back as well. In addition to the start-up poll state not being remembered/ saved I recall that the Node Name field would also not be saved to the profile.

I think these data have the cmriNet data type.. maybe that is helpful??

Mark

Thanks for the detail.

There are installers with proposed fixes here:



This (should) preserve the “poll enabled on startup” bit, and not log the wrong-state message if using a network connection.

Thanks in advance for any testing you can do.

Bob

Thank you Bob!

Tests
Network interface CMRI profile - add node, note that 'enable polling at startup' is ticked.
Added node, done, done, save preferences.
Reoped preferences, connections, CMRI, configure nodes, edit node - 'Enable polling at startup' still ticked, as expected.

Quit PanelPro, reopened, same profile. Edit - preferences - connections, CMRI, configure nodesedit node - 'Enable polling at startup' still ticked - as expected.
Loaded settings file containing sensors - polling started - as expected.

However - some unexpected behaviour - if I go back into node settings, untick 'Enable polling at startup', done, done, save preferences and exit - when I restart and go back in, 'Enable polling at startup' is ticked again - disabling polling has not persisted across save and reopen. Examining the profile.xml file after disabling the polling box, saving and exiting - I can see the line <parameter name="cmrinetoptions">1000000000000000</parameter> is still there - but would expect it to have been removed or changed.

Even manually removing that line from profile,xnl, saving then opening PanelPro - the 'enable polling at startup' is ticked, and polling begins when loading in a profile containing a sensor - so it looks like maybe on startup JMRI is not taking the absence of that line as an indicator that Polling should not start by default. Editing that line to be <parameter name="cmrinetoptions">0000000000000000</parameter> DOES have the desired effect - polling is not enabled at startup, as intended, with this line in the profile.xml.

Confirmed - when sending unsolicited 'GET' messages, with polling disabled, to CMRI from a network node, messages are accepted, logged in the CMRI monitor (as 'Receive) and sensor states changed accordingly in the sensor tables. No warnings or errors are logged in the system console, as expected.

Thanks for looking at this so quickly!

Chris

Thank you for the detailed testing!

There’s another set of installers at



that will hopefully resolve the problem with being unable to turn off polling without breaking anything else. Sorry for delay in getting this out, the “without breaking” part was a little complicated.

Bob

On Apr 26, 2023, at 11:07 AM, Chris Holden <chrisholdenyork@...> wrote:

Thank you Bob!

Tests
Network interface CMRI profile - add node, note that 'enable polling at startup' is ticked.
Added node, done, done, save preferences.
Reoped preferences, connections, CMRI, configure nodes, edit node - 'Enable polling at startup' still ticked, as expected.

Quit PanelPro, reopened, same profile. Edit - preferences - connections, CMRI, configure nodesedit node - 'Enable polling at startup' still ticked - as expected.
Loaded settings file containing sensors - polling started - as expected.

However - some unexpected behaviour - if I go back into node settings, untick 'Enable polling at startup', done, done, save preferences and exit - when I restart and go back in, 'Enable polling at startup' is ticked again - disabling polling has not persisted across save and reopen. Examining the profile.xml file after disabling the polling box, saving and exiting - I can see the line <parameter name="cmrinetoptions">1000000000000000</parameter> is still there - but would expect it to have been removed or changed.

Even manually removing that line from profile,xnl, saving then opening PanelPro - the 'enable polling at startup' is ticked, and polling begins when loading in a profile containing a sensor - so it looks like maybe on startup JMRI is not taking the absence of that line as an indicator that Polling should not start by default. Editing that line to be <parameter name="cmrinetoptions">0000000000000000</parameter> DOES have the desired effect - polling is not enabled at startup, as intended, with this line in the profile.xml.

Confirmed - when sending unsolicited 'GET' messages, with polling disabled, to CMRI from a network node, messages are accepted, logged in the CMRI monitor (as 'Receive) and sensor states changed accordingly in the sensor tables. No warnings or errors are logged in the system console, as expected.

Thanks for looking at this so quickly!

Chris

—
Bob Jacobsen
rgj1927@...

Thanks Bob, that's great - all confirmed working as expected.

Change node polling behaviour in node - done, done, save - return to node edit - settings as saved.
Same with exit JMRI and relaunch - polling settings as expected.

Polling occurs when expected (ie when enabled and a sensor exists on the node address) and doesn't occur when not.

Still no errors in the console log when unsolicited responses arrive.

Thanks so much for this Bob!

Regards,
Chris

Thanks for the testing. This will be in the next test release.

Bob

On Apr 28, 2023, at 9:18 AM, Chris Holden <chrisholdenyork@...> wrote:

Thanks Bob, that's great - all confirmed working as expected.

Change node polling behaviour in node - done, done, save - return to node edit - settings as saved.
Same with exit JMRI and relaunch - polling settings as expected.

Polling occurs when expected (ie when enabled and a sensor exists on the node address) and doesn't occur when not.

Still no errors in the console log when unsolicited responses arrive.

Thanks so much for this Bob!

Regards,
Chris

—
Bob Jacobsen
rgj1927@...

Chris

On a related note, a question about your "unsolicited messages". How are you protecting against those unsolicited messages colliding with JMRI polling for other nodes?? I'm askin in this thread because it would seem to me that it could cause problems with the JMRI polling sequence in general.

Thanks

Blair

With Ethernet or direct USB connection, this is not a problem. Both of those are communicating with one node per connection.

With an RS485 connection, you have to use polling to avoid collisions if you have more than one node on the RS485 link.

Bob

On Apr 28, 2023, at 9:33 AM, Blair <smithbr@...> wrote:

Chris

On a related note, a question about your "unsolicited messages". How are you protecting against those unsolicited messages colliding with JMRI polling for other nodes? I'm askin in this thread because it would seem to me that it could cause problems with the JMRI polling sequence in general.

Thanks

Blair

On 2023-04-28 9:19, Bob Jacobsen wrote:

Thanks for the testing. This will be in the next test release.

Bob

On Apr 28, 2023, at 9:18 AM, Chris Holden <chrisholdenyork@...> wrote:

Thanks Bob, that's great - all confirmed working as expected.

Change node polling behaviour in node - done, done, save - return to node edit - settings as saved.
Same with exit JMRI and relaunch - polling settings as expected.

Polling occurs when expected (ie when enabled and a sensor exists on the node address) and doesn't occur when not.

Still no errors in the console log when unsolicited responses arrive.

Thanks so much for this Bob!

Regards,
Chris

—
Bob Jacobsen
rgj1927@...

—
Bob Jacobsen
rgj1927@...

Thanks, Bob, I'd missed that somehow.

Blair

Bob-

I also just downloaded your fix and verified it works with my networked CMRI nodes.? I have been using a workaround for a while.? Appreciate the change.

-Eric
--
Eric Sitiko