MicroLogix 1100 Modbus RTU radio link

You are going to need to come up with a way to figure out the pinout of the null adaptor. If the handshaking lines aren't being passed then it simply won't work and it sounds like that is a possibility.

Alright, I’ll see if I can grab it and do a pinout on it myself. There’s no part number on it unfortunately, just a beige adapter with a female RS232 port on each end. I did test a couple pins against a pinout and it lined up, it wasn’t just a straight through connector (gender changer). Thanks again for the advice.

EDIT: Sorry, it’s a male RS232 on each end, not female. It appears to be this adapter: https://www.bhphotovideo.com/c/product/1001053-REG/startech_nm9mm_male_to_male_db9.html when I’m back at the office I’ll look for a pinout on the StarTech website.

If you have another location that is working I'd take the cable with null adaptor that you are trying to get to work now to that site and see if it works there. If so then you know the cable is correct. If not (which I suspect you will find) then you know that's a problem that needs to be corrected. At that point (assuming it does not work) then use a multimeter and document the pinout of the working cable and duplicate it.

Firejo said:

If you have another location that is working I'd take the cable with null adaptor that you are trying to get to work now to that site and see if it works there. If so then you know the cable is correct. If not (which I suspect you will find) then you know that's a problem that needs to be corrected. At that point (assuming it does not work) then use a multimeter and document the pinout of the working cable and duplicate it.

Click to expand...

I'll see if that's an option, it's a good idea if I can do so. I did check the StarTech website and there's no real technical information on the adapter. Thanks again, I really appreciate it!

Attached a CAD sketch of the pinout of the existing cable that I grabbed from a decommissioned panel with the same setup (ML1100 and Bell 202). Note that pins 4, 6 and 9 are physically removed on the 1761-CBL-PM02 side, and pin 9 is physically removed on the modem side, while 4 and 6 are jumpered together. I tried using this cable at our lift station with no luck unfortunately.

Hey everyone, finally figured it out. No issues on the PLC end, it appears to be both the new radio and the new modem. I went and pulled the radio and modem out of the old panel where I got the null modem cable from and swapped them in and everything came to life no problem. I tried every combination of old radio/new modem, new radio/old modem etc. but the only combination that worked was old radio/old modem. Not sure what the issue was on the radio, the old radio is a Motorola CMD750 (discontinued) and the new one is a Motorola CM200d, the panel shop was told by their Motorola distributor that it was a 1:1 replacement. It could just be a configuration issue in the new radio, not sure. The new modem is slightly different from the typical Bell 202, it's a Schneider TBUX297195, which is a 5902 (SAF), whereas the original was a Control Microsystems 297194, which is a 5902 (SA). I believe the SAF model has frequency shift keying turned on by default (or something like that), either way, it's not operating as a normal 202 out of the box.

Long story short, we were lucky enough to have an old decommissioned system to scavenge parts from, and swapping out the radio and modem did the trick.

Thanks to everyone who chimed in, it was a bit of a head scratcher.

A couple of things worth noting just as an FYI.
First, I should have asked what model the modems were earlier. Knowing what they are makes it a lot clearer as does knowing that the two radios are different.

As to the modems, SCADAPack modems are made to be compatible with each other but there are some differences that will change how they are setup. Because they are Bell202 compatible and they are both FSK. The difference is the SAF has the ability to operate without handshaking lines. They call it "Full Duplex to Half Duplex convert" but the reality is it's an autosensing carrier control system that senses data coming into the port, delays it and turns the carrier on. Data-Linc Group was the first modem manufacture to offer that on a Bell 202 and several companies copied it afterwards. That said, with some of the other features available on the newer version, the setups are different so you can't easily swap units out without needing to change something.

The radio actually have a significant difference that is more than likely the culprit (on the radio side). The old version was sold before the FCC mandated Narrowbanding. Basically the old version operated with either a 12.5kHz or a 25kHz channel spacing with 25kHz being the default and/or the most commonly used. January 1st of 2013 25kHz was no longer allowed in some frequency bands. My guess is that the old radios are operating using 25kHz which the new one won't do. That could give you a scenario where the radio appears to be working but some or most of the data is being removed and/or corrupted.

Good to hear you're up and running.

Firejo said:

A couple of things worth noting just as an FYI.
First, I should have asked what model the modems were earlier. Knowing what they are makes it a lot clearer as does knowing that the two radios are different.

As to the modems, SCADAPack modems are made to be compatible with each other but there are some differences that will change how they are setup. Because they are Bell202 compatible and they are both FSK. The difference is the SAF has the ability to operate without handshaking lines. They call it "Full Duplex to Half Duplex convert" but the reality is it's an autosensing carrier control system that senses data coming into the port, delays it and turns the carrier on. Data-Linc Group was the first modem manufacture to offer that on a Bell 202 and several companies copied it afterwards. That said, with some of the other features available on the newer version, the setups are different so you can't easily swap units out without needing to change something.

The radio actually have a significant difference that is more than likely the culprit (on the radio side). The old version was sold before the FCC mandated Narrowbanding. Basically the old version operated with either a 12.5kHz or a 25kHz channel spacing with 25kHz being the default and/or the most commonly used. January 1st of 2013 25kHz was no longer allowed in some frequency bands. My guess is that the old radios are operating using 25kHz which the new one won't do. That could give you a scenario where the radio appears to be working but some or most of the data is being removed and/or corrupted.

Good to hear you're up and running.

Click to expand...

Thanks for the insight, that's all great info. We did figure out the issue with the modem yesterday and have noted that for future installations, we're just going to go with the base 202 instead of the SAF version. I believe the radio is UHF, my understanding was that they're in the 900 MHz range. I'll take another look at the specs between the two radios anyways, the radio guy seemed to think that they should be interchangeable as long as the configuration was correct.


Thanks again!


EDIT: Looking at the spec sheets, they're both in the 403-470 MHz range apparently. I think the configuration might just be off.


EDIT #2: I also misunderstood your statement about 12.5/25 kHz channel spacing, I thought you were referring to the actual receiver and transmitter frequencies.

The radios are basically voice radios which are being used to pass the Bell202 frequency (Bell202 operates within the voice band).

glad you got everything working!

some years back, i wrote an application note detailing the steps required to connect a micrologix 1400 to a device that we manufacture, using bell-202 radio modems. the protocol in my app note was df1-radiomodem, but most of the material in this app note should cross over to modbus/rtu.

https://www.scadametrics.com/PDF/App_Note_023.pdf

the app note also references an allen-bradley scada document that is filled with good info applicable to bell-202 applications.

i also illustrated the bell-202 / micrologix operation in an informal youtube video:

https://youtu.be/SGlX0B-JgQw

the bell-202 modem in both the app note and the youtube video was our model b202, which is our (very) "dumb" bell-202 oem modem module, and it requires the plc/rtu to smartly handle all the rts (push-to-talk) timings.

with the schneider/scadapack 5902 modems having been recently discontinued (may 2020?), we fielded many requests this past summer for a "smarter" bell-202 modem that could be used as a drop-in 5902 replacement, so we have since introduced a newer model that serves that purpose. our new "smarter" bell-202 modem supports rts-cts flow control, but it also supports 3-wire rs-232 with no flow control (txd,rxd,gnd). we call this new modem the model "sb.202".

hopefully this additional info will be helpful to anyone else who comes across this interesting thread.

Hey everyone,

Ran into a similar issue on the same network at a different lift station. This one is using a MicroLogix 1400 with a different station address, but otherwise pretty much everything else is the same. The only real difference I can peg is that Schneider Electric has discontinued their model 5902 Bell 202 modem, and recommended the Scadametrics SB202 smart 202 modem as a replacement - their engineer posted the previous reply from the "scadametrics" account, and has been extremely patient and helpful trying to help me get the link working. Unfortunately, we can't seem to get it working, and there seems to be a mismatch in the timing between the poll request coming from the master/base radio and the transmission of data from the PLC/modem. This issue even persists if we swap out the Scadametrics modem for the modem I used at the station that this thread was originally about.

Attached is a comms block diagram with all of the relevant configuration/settings that I had access to.

On the previous lift station from the original thread, I would hear the radio make a particular sequence of squawks, and then I could see the TD/RD LEDs and several of the other LEDs on the Schneider 202 modem light up, and also see the COMM0 indicator on the ML1100 fill in to indicate activity on the port. However, on this station, I can hear the same poll request come in (this station is later in the poll sequence), but I don't see the activity on either COMM0 or COMM2 indicator - originally connected to COMM2 with a straight-through serial cable from the smart modem, and then connected to COMM0 both with a straight-through connection and also a null modem adapter with the Schneider 202 modem from the working lift station. After 5 retries (set in VTScada), the poll sequence moves on after not establishing any communications with the station. Some time later, I can see the RTS/CTS modem lines on the Channel Status in Logix500 go ON, as well as the TD/RD LEDs (when using the old/dumb 202 modem), indicating that the PLC is transmitting data, but the master radio isn't polling or listening for it, so it seems to go unregistered. Not sure what's causing this mismatch in timing, and I didn't think to check if the time difference between the poll request/retries and the attempt to transmit the data is always consistent, or if it's random and they're independent of each other. We have also tried swapping the new radio back to the old (adjusting the pinout wiring as required) to no effect as well. Just for reference, for some reason the only way I could get the original lift station from this thread communicating was to swap the new radio and 202 modem for the old radio and modem from the nearby station that was decommissioned and replaced with the new station. Not sure why the radio needed to be swapped, but the 202 modem supplied by the panel shop was an enhanced 202 modem that isn't configured like a "dumb" modem out of the box.

I have confirmed dozens of times now that the settings for the Modbus RTU Slave channel matches existing stations on the network, only differing on the station/PLC address, and have even tried "No handshaking" in the protocol control, with no luck. Anyone have any ideas as to what could be causing the poll request and response to be asynchronous like I'm experiencing?

Thanks in advance!

Hey everyone, just a little update.

The problematic lift station is still not communicating, but there are three other lift stations that communicate over VHF (as opposed to UHF like the lift station that isn't communicating) to another water treatment plant (WTP), and then is transferred to the main wastewater treatment plant (WWTP) over the internet using a VPN. I was able to get these working this morning without issue, but that's a whole different setup where the polling is controlled by a MicroLogix 1100 configured as the Modbus RTU Master. The radio and new 202 modems are apparently working for those three lift stations, so I'm still left scratching my head as to what could be causing the issue with the lift station that isn't communicating.

I downloaded CASModbusScanner on my computer and bench tested it on a ML1100 in my office, and it worked perfectly with the setup I typically use (Modbus RTU Slave, Half Duplex RTS/CRS handshaking protocol control etc), which is also the setup used on the problematic lift station (different node address), as well as every other lift station on this radio network. I then went out to the lift station and tried the same thing with CASModbusScanner on the PLC, but it wouldn't work. I finally got it to connect when I changed the protocol control to No Handshaking (485 Network). I have no idea what the cause of that is, but it will not work with Half Duplex protocol control.

We've also tried null modem and straight through cables, and it appears that the RTS line on the PLC is going ON, but the CTS line stays OFF. At this point I'm not sure if it's a radio or modem issue, something wrong with the PLC, or a combination of the three.

One last update for this thread, we finally managed to get the problematic lift station communicating on the network. We brought a known working comms setup (from the original station I made this thread about, call it Station 1) to the non-communicating station (Station 2), which consisted of the radio, modem and PLC (ML1100) from Station 1. We dropped it into the panel at Station 2, while leaving it addressed as Station 1. We confirmed with the wastewater utility that Station 1 in their SCADA system came back online when we hooked it up at Station 2.

I then unplugged the serial cable from the Station 1 ML1100 and plugged it into the ML1400 for Station 2, and the utility confirmed that Station 2 was now communicating. This confirmed that both the radio path/antenna and the PLC were not the issue, so we started swapping components from the Station 2 panel back into the setup, and found that both the new radio and new modem (Scadametrics SB202) would not work in the system. The radio tech eventually decided to try moving the audio transmit pin from the "Flat Audio Transmit" pin to the "Mic Audio Transmit" pin on the new radio, and that started to work with the Station 1 modem.

Luckily, we had the original Station 2 Scadapack 202 modem, but it required a small daughterboard (from the previously mentioned "enhanced" 202 modem from the original station for this thread) that would allow it to be powered by a DC barrel connector/wall plug instead of requiring a ribbon cable from a Scadapack PLC. So we managed to get the station up and running with the new radio but an old 202 modem, and the unfortunate part is that we are now out of these old 202 modems for any future projects. As I mentioned in my last post, the Scadametrics 202 modems worked flawlessly on the VHF network, but not on this UHF network. I assume there has to be a way to configure them to work on this network, but I can't figure it out.

Glad you got it sorted eventually. This is the main reason I absolutely hate these old analog radio systems - so many cludges required to get them working, and keeping them working.

How many stations in total do they have? Do they still have the VHF channel license as well as a new UHF one?

I've migrated over 100 sites for one client over the last 3 years from proprietary analog modems with voice radios, to Schneider Trio Q series and J series radios. They are bloody good - we could keep the legacy serial links working for the old RTUs, as well as provide full layer 3 ethernet across the entire network of 4 access points (obviously at limited bandwidth on a 12.5kHz channel).

If they only had a few sites its not an expensive exercise really... if there are 10+, then it's worth getting another licensed channel and migrating incrementally as budget allows. At least if a new station needs to come online, you're not needing to keep rummaging in the scrap bin for parts!

Saffa said:

Glad you got it sorted eventually. This is the main reason I absolutely hate these old analog radio systems - so many cludges required to get them working, and keeping them working.

How many stations in total do they have? Do they still have the VHF channel license as well as a new UHF one?

I've migrated over 100 sites for one client over the last 3 years from proprietary analog modems with voice radios, to Schneider Trio Q series and J series radios. They are bloody good - we could keep the legacy serial links working for the old RTUs, as well as provide full layer 3 ethernet across the entire network of 4 access points (obviously at limited bandwidth on a 12.5kHz channel).

If they only had a few sites its not an expensive exercise really... if there are 10+, then it's worth getting another licensed channel and migrating incrementally as budget allows. At least if a new station needs to come online, you're not needing to keep rummaging in the scrap bin for parts!

Click to expand...

There's about 32 sites reporting directly back to the SCADA system on that UHF network, the VHF stations are polled by a different station/plant and report the tags over internet (TCP/IP) connection to the main station. My boss and I have been kicking around the idea of proposing an incremental upgrade of all the stations to Ethernet radio links, as the current UHF network takes over a minute to poll all of the stations, so the data is essentially snapshots and not overly "live," so having them swapped over to Ethernet would be a huge upgrade for them. I'll have to take a look at those Schneider radios you mentioned, sound like an ideal candidate for that kind of thing.