trying to get SCADAPack to interface with existing serial radio system

I do know that with qModMaster, I was able to query all the sites just fine with my laptop, so it *has* to be something with the SCADAPack and how it is interacting with the radios.

I'd suggest building an RS-232 sniffer with one RS-232 port rx line connected to the tx of the ScADApack and the second connected to the rx line. Open up both ports in hyperterm or putty and try a send from the server. See what you get back on your sniffer
 
I did this quite a few years ago. We set up the system using one of the AutomationDirect.com PLCs as the master, and let it do all of the polling to the remote PLCs and SCADAPak RTUs. The HMI software, WonderWare in our case, only polled the master PLC.
 
OK, got an update here.

After some back and forth with Digi, I was able to determine how to get into the existing "base" radio and query all of its settings to see if there was anything there that could be modified for getting serial port comms properly adjusted. I have also set up one of the spare radios as a "base" replacement, so I can modify settings to my heart's content and can go back to the old radio with no risk of messing up the existing system.

Firejo mentioned some issues with spread spectrum radios and "end of message", plus the idea of the radios transmitting faster than the serial port baud rate. I have found a few settings that deal with these exactly:

1. RF Baud Rate - 125 kb/s (the only other option is 10 kb/s)

2. Packetization Timeout (shorthand is RO, value is 3) - This one is interesting. The description says "RF transmission begins when data is in the DI buffer and either of the following criteria are met:
1. RO value characters of silence (so 3) on the UART receive lines after receiving at least 1 byte
2. Packetization threshold number of characters have been received (in this case, 0x800 bytes)

Not sure if RO has anything to do with "end of message" characters, but it looks like it could.

The other thing I did was use all the diagnostics that are built into the SCADAPack, and what I found was every time any of the remote sites has a comm fail, it was invariably a checksum error.

At this point I'm doing research to see what exactly a checksum error would indicate.
 
2. Packetization Timeout (shorthand is RO, value is 3) - This one is interesting. The description says "RF transmission begins when data is in the DI buffer and either of the following criteria are met:
1. RO value characters of silence (so 3) on the UART receive lines after receiving at least 1 byte
2. Packetization threshold number of characters have been received (in this case, 0x800 bytes)

Not sure if RO has anything to do with "end of message" characters, but it looks like it could.

The other thing I did was use all the diagnostics that are built into the SCADAPack, and what I found was every time any of the remote sites has a comm fail, it was invariably a checksum error.

At this point I'm doing research to see what exactly a checksum error would indicate.

Any idea how many bytes of data you're requesting? Even how many words would tell if you're under the 800 byte threshold. Having the radio break up the messages if over 800 bytes could cause this issue. I would doubt you'd have messages that big though.

I would try increasing RO to a bigger value and see what happens. It's possible that the radio is starting to transmit too early and your packet is getting split in two. The SCADApack will see this as a checksum error, as it'll only get half a message.

What is your serial baud rate compared to the rf baud? You could try setting a serial baud higher than the rf baud which will ensure the radio receives the whole packet into its serial buffer without the risk of any break in transmission because the buffer is empty.
 
I found this explanation on the web. I think what you are seeing is a framing error that screws up the message and generates a checksum error.

In RTU mode, messages start with a silent interval of at least 3.5 character times. This is most easily implemented as a multiple of character times at the baud rate that is being used on the network (shown as T1-T2-T3-T4 in the figure below). The first field then transmitted is the device address.
The allowable characters transmitted for all fields are hexadecimal 0 ... 9, A ... F. Networked devices monitor the network bus continuously, including during the silent intervals. When the first field (the address field) is received, each device decodes it to find out if it is the addressed device.
Following the last transmitted character, a similar interval of at least 3.5 character times marks the end of the message. A new message can begin after this interval.
The entire message frame must be transmitted as a continuous stream. If a silent interval of more than 1.5 character times occurs before completion of the frame, the receiving device flushes the incomplete message and assumes that the next byte will be the address field of a new message.
Similarly, if a new message begins earlier than 3.5 character times following a previous message, the receiving device will consider it a continuation of the previous message. This will set an error, as the value in the final CRC field will not be valid for the combined messages.
 
I found this explanation on the web. I think what you are seeing is a framing error that screws up the message and generates a checksum error.

In RTU mode, messages start with a silent interval of at least 3.5 character times. This is most easily implemented as a multiple of character times at the baud rate that is being used on the network (shown as T1-T2-T3-T4 in the figure below). The first field then transmitted is the device address.
The allowable characters transmitted for all fields are hexadecimal 0 ... 9, A ... F. Networked devices monitor the network bus continuously, including during the silent intervals. When the first field (the address field) is received, each device decodes it to find out if it is the addressed device.
Following the last transmitted character, a similar interval of at least 3.5 character times marks the end of the message. A new message can begin after this interval.
The entire message frame must be transmitted as a continuous stream. If a silent interval of more than 1.5 character times occurs before completion of the frame, the receiving device flushes the incomplete message and assumes that the next byte will be the address field of a new message.
Similarly, if a new message begins earlier than 3.5 character times following a previous message, the receiving device will consider it a continuation of the previous message. This will set an error, as the value in the final CRC field will not be valid for the combined messages.

I was thinking this may be exactly what I needed to work with. I'm still confused as to why the existing system works flawlessly, but I've been told that one thing about Lookout is that the Modbus driver was written extraordinarily well so maybe that, along with the latency of the RS232 to USB converter, keeps issues from happening.

As for the quote you provided, can you provide a link for where you found it?

Would it make sense to increase the RO to something above 3.5, like 4, and see how that affects things?
 
Any idea how many bytes of data you're requesting? Even how many words would tell if you're under the 800 byte threshold. Having the radio break up the messages if over 800 bytes could cause this issue. I would doubt you'd have messages that big though.

Yeah I actually know exactly how much data I'm requesting. Basically all the RTUs are identical, the code just packs/unpacks bits and leaves all the data processing/scaling and programming to the Lookout software. So each request reads three holding registers. The resultant data reply would correspondingly be 11 bytes including the CRC. So yeah, well under 800 byte.



I would try increasing RO to a bigger value and see what happens. It's possible that the radio is starting to transmit too early and your packet is getting split in two. The SCADApack will see this as a checksum error, as it'll only get half a message.

I was thinking exactly this, and Firejo suggested the same. That'll definitely be the next experiment I try, and there is a remote site that's literally within walking distance from the control room (which I've never been able to successfully communicate with) so that'll be a great place to start.

What is your serial baud rate compared to the rf baud?

Serial baud is 9.6k while RF baud is 125k.

You could try setting a serial baud higher than the rf baud which will ensure the radio receives the whole packet into its serial buffer without the risk of any break in transmission because the buffer is empty.

That's a really interesting thought, I could definitely try speeding up the serial baud and see what happens (though technically I couldn't make the serial baud faster, as the upper limit for the SCADAPack is 115k so it would be close, but not greater than). If that happened to fix the issue then I wouldn't have to adjust the RO setting in all the remote sites, which would be nice.

Thanks for the suggestions!
 
It's finally working! The solution turned out to be speeding up the serial interface baud rate. At 9.6k, the system was intermittent as I described but at 19.2k or above, the radios work flawlessly. Amazing how such a simple setting will completely change system behavior.

Big (HUGE!) thanks to everyone who provided insight on Modbus, checksums/CRC and spread spectrum radio behavior. As I learned more and more about these issues, I was able to drill down to root cause and then fix it.
 
Nice one, glad you found a solution that didn't require new radios!

Thanks, and I am too! We literally were discussing the potential possibility of replacing all radios which of course would have been a hardware/labor cost nightmare...and I didn't mention the ridiculous difficulty of actually getting into the radios (firmware issues, long story short). I literally couldn't be more relieved that things worked out the way they did.
 

Similar Topics

I can't seem to get the Panel View Plus 7 standard edition to downgrade to V_11, when I check the AB downloads and compatibility websites for this...
Replies
1
Views
97
Hi I used to be able to launch PLCsim without any problem. Now it tells me " STEP 7 Professional Licence is required to simulate this PLC"...
Replies
15
Views
454
Hello! When trying to load the hardware configuration I get error 0050-133 2 2458, check the diagnostic buffer. When checking the buffer, it says...
Replies
4
Views
128
We have a keg check weigher that that lost a fight to a forklift. The scale was previously a Systec IT3000, which was the only PROFIBUS slave...
Replies
5
Views
646
Back
Top Bottom