Hi Everyone,
I have recently seen a post from Ben Orchard that in a real world application of serial devices, we may have to consider timing.
I currently have a project wherein i will be using 500 units of RS 485(Modbus Protocol) devices. I am using Opto22 R2 controller and SCM 485 I/O.
Any more suggestions on the things that i must expect and should consider during testing and commisioning?
Thank you in advance.
KNH
That’s a lot of devices - I have some questions that may help get you some guidance/answers:
Are you using multiple R2 racks? How many 485 networks will you have? How frequent do you need fresh data? What is the maximum Modbus address the devices you are using support? What is the max baud rate the devices support? Any other analog or serial modules on the R2 rack(s)?
As far as timing, you need to look out for devices that are not communicating as they will slow down your polling as the R2 waits for the “timeout” period. The trick is to get the timeout period as short as possible without getting false timeouts and then setting up your strategy to retry devices that timed out on a less frequent basis (an orphan list) than the functioning devices. You can also setup flags in your strategy to turn off communications to devices that are defective/missing/unused/unwanted.
Also, be aware that the modbus sdk subroutines are synchronous - so you will want a separate chart for each 485 network.
HI philip,
Are you using multiple R2 racks?
Single R2 Controller for the 500 Devices
How many 485 networks will you have? 8
How frequent do you need fresh data?
I plan to do it 1 sec refresh rate. To be adjusted when needed.
What is the maximum Modbus address the devices you are using support?
On this question, since RS 485 only supports 32 devices. I took advantage of the “Grouping Logic”. Given SCM 1 CH A, 32 devices will be accommodated. SCM 1 CH B, 32 devices will be accommodated. 8 SCM will accommodate 512 devices
What is the max baud rate the devices support?
I set it up on 9600bps which is also the MAX
Any other analog or serial modules on the R2 rack(s)?
3 units of 8 channel Analog Module, 2 units of 4 channel Digital Input.
You can also setup flags in your strategy to turn off communications to devices that are defective/missing/unused/unwanted.
Thank you for this, Will consider this on my development.
Also, be aware that the modbus sdk subroutines are synchronous - so you will want a separate chart for each 485 network.
What do you mean by this?
Thanks
KNH
You can have more than 32 devices on a 485 network. 485 allows 32 “units load” on a bus - most transceivers these days are 1/4 load devices (or less) and then you can add repeaters to connect two 485 buses. The Modbus specification allows 247 slaves on one serial Modbus network. The limitation is if the devices allow you to address them up that high - some devices only allow you to address to 32 or 64 or 128, etc.
You will probably not meet your 1 second poll time requirement at 9600bps, even with 16 separate networks. This of course depends on how much data you are requesting from each slave. If you are reading a small number of consecutive coils, then you could probably do it, but if you are reading a handful of registers, then you will be too slow.
Here is some math for you on reading a single register using Modbus RTU:
Total 243 bits “wire time” minimum to read one register. So to read a single register from every device @ 9600bps with a one second poll time you can read from 39 devices max (9600/243). You probably want to read from more than one register too, each additional consecutive register will add 22 bits to the response. If they are not consecutive, then you have to make an entire new request again.
Are your slaves able to communicate faster than 9600bps? How many registers/coils are you reading/writing? Are you needing to read from all slaves all the time?
What I mean here is if you have one chart calling the modbus subroutines, then you can only be communicating on one serial bus at a time. The subroutines will wait for the slave to respond (or timeout) before they return to you. During this time, your chart is doing nothing, just waiting. You will need separate charts for each serial network if you want to communicate simultaneously. If you are running 16 serial networks, you will need 16 charts running - which I believe is the max on an R2, so that is a concern.
This is why they have ethernet. If there is anyway you can switch to ethernet slaves, then that would be the correct sollution, however, you can speed this all up simply by getting more brains and racks and an S1, or more R2’s and more racks. The speed is attainable but not at your current budget. The S1 can run 32 charts and you could also get more serial modules as well to reduce the load at each network.
This would be a great app for SoftPac but it doesn’t do serial. If your devices did TCP/Modbus, then you could use SoftPac and you would only need 1 brain/rack for the IO, in this scenario SoftPac will have no problem dishing out the comms running 64 charts. The problem then is how do you adapt the existing serial cables for Ethernet? If your existing serial cables are 3 wire plus shield ad they are twisted pairs using fairly small gauge wires (<20ga), you can put RJ45 connectors on these and plug them into 48 port switches. As long as you’re not going very far from the switch, this will actually work. On the other hand with 500 of these that might be cost prohibitive. The switches will cost at least $2500-3500. In that case you’re probably better off getting more brains and an S1.
Thanks for the great suggestions, Barrett. We do have some folks using SoftPAC with Ethernet to Serial converters, and since serial modules + our Ethernet brains can act as Ethernet to Serial converters, I’d imagine that SoftPAC + the hardware Kevin already has could do the trick (assuming there’s no problem with having a Windows PC in the mix). Thoughts?
The problem with the hardware that he listed is that he won’t be able to get the refresh rate he wants unless you can run faster than 9600bps. Until we know how many coils/registers he needs to read, we won’t be able to determine what speed he should be running at or if different hardware will be needed.
I have some ideas to get around the number of running chart limitations, but it would require modifying the Modbus subroutines to separate the transmit from the receive and maintaining state in a chart. Anyone want to send me some 485 serial modules to test this out?? 
That’s a good point Mary, in this case one of the real problems here is like Phillip pointed out, his slaves are way too sloooooow. If these all talked at 115.2k then it would probably work with one R2 and a SoftPac. That’s a factor of 12 times faster. If he were to use the SoftPac like this, then at 9.6k he would have to add a number of more modules to decrease the number of slaves per network. All of this also is dependent on the cabling and how all this stuff is physically grouped.
Another point is people often times see is the cheap cost of buying a slave device like this and then don’t consider the cost of implementation and then realize after it’s too late, they should have just bought racks and brains and did all the sensing and or control with Opto22 instead of Brand X. So depending on what he is doing with these Modbus slaves, he might consider doing with Opto. Don’t forget, you can control 512 points of discrete with one rack, or up to (not sure about this since there are some 32 point analog available) 512 analog? Or if you need speed, 128 points of analog with one rack.
Do the numbers first…
Excellent point! Time is money. I also like your “running flawless for X years” comments… how much is that worth? I’d say “priceless” like that credit card commercial.
HI philip,
Thank you for clearing things out.
Here is a sample 16Byte(Hex) recieve on my slave device, done on a single request command.
010420435A999A00000000000000003E7EF9DB000000000000000041D80000000000002EEA=2368 bits
All the requests(512 devices) are within a single chart and only using one subroutine. I used this method since subroutine in Opto22 can only be accessed at one instance.
All the requests are done one at a time, not simultaneously.
Communication Modules/Channels are opened when used and closed when done.
MODBUS TCP, Adding Additional Hardware for Serial to Ethernet are not an option.
Thank you.
Refresh rate 1s? This is a challenge.
I’m not clear on your 2368 bits, how did you come up with that?
Polling 16 bytes of input registers from each slave sequentially as you have stated, your best case poll time will be over 46 seconds, probably closer to a minute. This is at 9600 baud without parity (8n1), so 10 bits/word.
Is this acceptable for your application?
Also, you can call the same subroutine from other charts. This will allow simultaneous communications - run two charts, you cut your poll time in half, run 8 charts, you can get your poll time down to around 5 seconds, etc. However, getting to 1 second poll interval is not possible without changing the hardware design or communication settings.
I agree with Philip. That is the entire problem, 9600 baud. Could you explain what each of the Modbus devices are doing?
Hi Philip,
Apologies for not getting back to you on this.
Request(Hex Format)=010400000015EB15
Response(Hex Format)=010420435A999A00000000000000003E7EF9DB000000000000000041D80000000000002EEA
I got the 2368 bits by converting the HEX String to total bits.
I considered your suggestion by separating the each of the SCM 485 I/O per chart. It may indeed speed up the process.
Also on this postPost by OptoMary,that subroutine can be called at the same time by different chart.
Thank you everyone for your input on this query.
KNH
I still don’t understand how you came up with 2368 bits - you might want to double check your math. You also are not receiving 16 bytes in your example, you are receiving 16 registers, which is 32 bytes of data. The response you posted is 74 hex characters, which correspond to 37 binary bytes which equals 370 bits using 8n1 (10 bits/byte).
Are you changing your requirements/expectations to work with the equipment you have or are you considering a different approach?
In my limited experimenting on the bench with serial modules and a highly modified modbus subroutine, I would be happy to see a 10 second refresh time for 512 devices on 16 networks reading 16 registers at 9600bps. Add in slow or malfunctioning slaves, and things will get much worse.