Modbus - removed from the Systems Manufacturing List #12991
Labels
Pending closure
This issue or PR has not been updated for a while
Comments
|
As near as I can tell from reading the code, the Modbus implementation was never completed. There was some work in 2014/2105 but it only got as far as documentation. There doesn't seem to have ever been working code there. But I may have gotten this wrong. Did you have it working at some point? |
|
In case anybody looks into this again, the commit that removed the documentation-only packages was: This is credited to #4665 |
|
BobActually was looking at using this implementation with some servo devices I wished to build and PanelPro. I developed PLC Masters in Modbus based actuators some years back and due to that knowledge thought that one of the simplest, cheapest methods to implement track control on NTRAK modules was via Modbus. My idea, while there was no Modbus master in JMRI, was to build up a small RTU based “Network Master” that spoke as a Master to JMRI and then pushed commands via another Master port to some cheap servo controller on the layout, that is until JMRI had Master capability. Guess it was wishful thinking.Suggest that if you mean to pull Modbus, then you may wish to pull documentation too. I can look for a non-JMRI method of control, but the GUI on a PI is difficult to come by cheaply now a days.If I can assist with Modbus (RTU / TCP) development please let me know. Might date me a bit, but my previous work was done using “C” on multiple platforms in the day.I’m not familiar with CMRI, as mention in the documentation. Is that a Modbus RTU like control protocol?MikeSent from my PhoneOn Mar 30, 2024, at 07:50, Bob Jacobsen ***@***.***> wrote:
As near as I can tell from reading the code, the Modbus implementation was never completed. There was some work in 2014/2105 but it only got as far as documentation. There doesn't seem to have ever been working code there.
But I may have gotten this wrong. Did you have it working at some point?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
C/MRI is very similar, though much simpler, than ModBus. JMRI acts as a master, polling each node in turn over an RS485 bus. (I think the hardware for the connection is essentially identical). You can read and write individual bits, which in turn are connected to sensors and turnouts, etc. There are Arduino libraries that implement it, if that's helpful. For more information on the protocol: It might be possible to add ModBus to JMRI, I think. But the person who started on it is no longer with us, and I'm not sure who might be motivated to do it. I'll ask around. |
|
Bob,
There is an outside chance I might be up enough on Modbus sometime
this summer. Since topics like Industrial Automation have been added
to my job description, I may be learning enough about that to support
what we need here. Then there is still this issue of interest or time,
neither of which I have clues at this time.
|
|
OK. Happy to help with what I can, but I don't have much ModBus knowledge nor anything to test against. |
|
Bob / Ken;
I have reviewed C/MRI in a rudimentary fashion this afternoon and hopefully without anyone flaming me, these are my thoughts of using these two protocols; C/MRI vs. Modbus:
Modbus Positives:
There is a 16 bit CRC (RTU mode) transmitted within the message. Any corrupted message only has about a .05% chance of being accepted.
For some odd number of years Modbus has been used in the industrial arena, even encapsulation into TCP/IP.
With the use of a repeater, the addressing can be up to 255 slaves, no need to be concerned with adding a hex 65 to the address.
Can be implemented with readily available applications such as inexpensive GUIs.
There are plenty of applications, some free, to diagnosis, decode and develop the protocol
There are many code examples of the protocol on the Internet.
Supports bit, 8 bit, 16bit or even floating point (32bit) data.
Modbus Negatives:
Isn’t readily used in the hobby
It may be slightly more complex to implement. As example, there are two modes, RTU and ASCII, as well as several parity checking methos and the modes require two different types of frame checking (CRC and LRC). Of course that does not mean that they should all require initial implementation.
It would need to be implemented into JMRI, tested and supported.
C/MRI Positives:
Seems that C/MRI has been used for years in the hobby.
Seems to have a lower overhead for the transfer of data.
C/MRI Negatives:
No method of secure data communication (of course I may have missed something here and that may not be a big deal in the hobby)
Maximum of 127 addresses, but then who’s counting?
Doesn’t really allow communication to devices that can be found readily available. Inexpensive devices, including controllers can be found on Amazon, Ebay or AliExpress.
Corruption security?
Both use RS-485, but I do suggest that Modbus can be used in multiple physical layers, including Ethernet encapsulation RS-232, RS-422, and possibly (though I haven’t tried it), one wire as few others.
As a Modbus Master, one can use a subset of the commands (Function Codes) to communicate with slaves.
I also know that one can use Modbus data to “configure” the slave, for instance to set a bit to say blink a LED and a set a register that controls the timing of the blink. Not sure but, by looking in to C/MRI “control” during my afternoon research, I don’t see that mechanism is possible with C/MRI.
Obviously, the biggest point is whether implementing Modbus into JMRI is worth the time and effort. If there is a decision to press forward, then I would be happy to volunteer where it makes sense.
From: Ken Cameron ***@***.***>
Sent: Sunday, March 31, 2024 11:28 AM
To: JMRI/JMRI ***@***.***>
Cc: truittm ***@***.***>; Author ***@***.***>
Subject: Re: [JMRI/JMRI] Modbus - removed from the Systems Manufacturing List (Issue #12991)
Bob,
There is an outside chance I might be up enough on Modbus sometime
this summer. Since topics like Industrial Automation have been added
to my job description, I may be learning enough about that to support
what we need here. Then there is still this issue of interest or time,
neither of which I have clues at this time.
—
Reply to this email directly, view it on GitHub <#12991 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6OHL3CWKR2W2FE3ZKCAXLY3A2RPAVCNFSM6AAAAABFPDCVXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYHAYTINZQGA> .
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
This issue is stale because it has been open for 45 days with no activity. |
github-actions
bot
added
the
Pending closure
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Release 5.6 does not have a listing for the Modbus protocol. I don't know when this removed or why, but I was hoping that this protocol would be progressed, especially the Master mode, which would allow easier use of easily developed low cost slave devices that can be multidropped (up to 35 devices) on a single RS 485 half duplex. At the moment I hoped that I could build a "network master" that uses two Master communicators to poll the JMRI Modbus slave system and then retransmit that send commands to a series of multidropped slaves.
This of course is based on the ability of Modbus communication via JMRI and the reinsertion of that capability into the releases and possibly that addition of a Master mode.
The text was updated successfully, but these errors were encountered: