开云体育

Hi all,
I have a few sketches for my arduino to manage turnouts and sensors (each "sensor" can also be an output to control something). I would like to be able to hook that up to JMRI.
The address scheme I use is one node address (0->254) plus a subaddress (1->127) ; the arduinos are on a bus like network (rs485 probably). Each subaddress represents a turnout or a sensor; the whole setup (address+subaddres<->turnout/sensor correspondance) is saved in eeprom.
For now I am using messages that look like DCC++'s as that was my inspiration. This can be rearranged if needed.
What I need: address/subaddress to identify the turnout/sensor, a way to send commands (read sensor, write to sensor, throw turnout) and be able to receive async answer (mostly for turnouts as they are moved using servos moving slowly). Also all input sensors are checked periodically and in case some have changed, it is signalled.
I hope this is enough information to guide me to a suitable jmri supported protocol.
TIA
Emmanuel

I’d suggest the C/MRI protocol. See





There’s Arduino code available on the web in several places:





and even a Yahoo group that can help:



Bob

On Jun 16, 2017, at 4:51 PM, eallaud@... [jmriusers] <jmriusers@...> wrote:

Hi all,
I have a few sketches for my arduino to manage turnouts and sensors (each "sensor" can also be an output to control something). I would like to be able to hook that up to JMRI.
The address scheme I use is one node address (0->254) plus a subaddress (1->127) ; the arduinos are on a bus like network (rs485 probably). Each subaddress represents a turnout or a sensor; the whole setup (address+subaddres<->turnout/sensor correspondance) is saved in eeprom.
For now I am using messages that look like DCC++'s as that was my inspiration. This can be rearranged if needed.
What I need: address/subaddress to identify the turnout/sensor, a way to send commands (read sensor, write to sensor, throw turnout) and be able to receive async answer (mostly for turnouts as they are moved using servos moving slowly). Also all input sensors are checked periodically and in case some have changed, it is signalled.
I hope this is enough information to guide me to a suitable jmri supported protocol.
TIA
Emmanuel

--
Bob Jacobsen
rgj1927@...

OK thanks I'll look into it.
Emmanuel

Another option is OpenLCB, which according to its proponents is "the future".

It is an event message based approach. What this means is that it is not necessary to poll a sensor. It will send a message when a change happens.

I'm trying to implement the basic protocols on arduino nanos with an ESP8266 wifi gateway to JMRI. It's not yet complete, but what I have so far seems to be working.

If I read your post correctly, you haven't built the transport layer yet. OpenLCB uses a CAN bus rather than RJ45. MCP2515 SPI-CAN adapters are available cheaply from China. I got mine from Tx-Hang's ebay store.

Regards
Otto

Hi Otto,
this seems more promising as after reading about CMRI it is too basic for my needs: I want to be able to throw turnout asynchronously (they take time to be thrown and then signal that they reached the desired position) and I would like to have a "master" node (probably a mega) and then several slaves (uno/leonardo whatever...) over the mega's serial buses or over rs485.
I already have sketches for the slaves: turnout positioning, sensors polling,config saved in eeprom, everything (addresses, subaddresses, pins for servo and relays for each turnout, pins for sensor (I/O)) can be set up using messages from the master.
The Master sketch still needs more work, an everything needs debugging in general ;-)

Can you point me to documentation/code for openLCB to get me started?
TIA,
Emmanuel

Hi,
A key advantage of the Peer-Peer network is that any device can talk directly to any other device. No computer is required to support even the most basic of communications like a polled protocol requires. You may even have enough horse power in your nodes to do ABS signaling. JMRI is still an important tool during configuration, but if you are writing specific code for each node anyway, you might even be able to skip over the configuration step.

Dick :)

OK, but I want to avoid the one node-one sketch thing ;-)
My idea is more along these lines: you plug your equipments on a generic node, you do the setup through JMRI (this I dont know how to do) and that's it.
This would enable people with no knowledge of programming to use these nodes in different config.
Bye
Manu

Hi Manu,

An overview to NMRA LCC ( = OpenLCB) can be found at , and a video (1h15) at .

The specifications for OpenLCB can be found at . These are hard to digest and IMHO an awful specification to program from.

There's a youtube video posted by Balacz Racz (3h25) ( ) which helped me understand what was going on.

So far I have developed a fake OpenLCB Node, although it is not yet complete. It is fake because due to the limitations of the Arduino nano (1K EEPROM and 2K RAM) I won't be able to implement the configuration elements. I have an external programmer which will write to the EEPROM, but will also require some intelligence in front of the screen.

I'll package and post my code on github in the next couple of days.

What works:
Identification of the node to the LCB network, including JMRI: Assignment of an alias and SNI.
Passing messages to/from JMRI and the node.
Writing configuration to EEPROM and reading it back.


Coded but not yet tested (and open to change)
Processing event messages
Writing configuration to EEPROM and reading it back.


The node is generic as it will set arduino pins depending on the messages received or conversely sending messages on the change of pin status. My experience shows the node will be able to handle up to 20 messages and use 10 pins on the nano. What the messages "mean" is up to the configurer.
For example, to operate a point/turnout/switch (or whatever you call it) will take two messages: one to throw the point, the second to close it. The node will turn a selected pin on the nano on or off. For a point, I'll have an ATTiny85 which will actually control the movement to avoid having the OpenLCB node do this.

Regards
Otto

I've put my code on github:

Hope it helps
Regards
Otto