RS232 Splitting Headaches

I am close to wits end and would appreciate any new perspective.

Cannot go into minutia, but here is a rough rundown of the system and issue we are having.

-The system is a currently operating (and ancient) measurement system that uses a 486 computer for data acquisition and a PowerMac to generate reports about the thing that it is measuring. To get some of the measurement properties, like width and height, it uses a multi-gauge interface(MGI) with RS-232, I imagine to save on serial ports. Effectively, the system sends a command to the MGI at regular intervals, and then the MGI sends back the appropriate data.

-The job is to duplicate all of the data collected by the existing system, but replacing the data aquire-er with a CompactLogix and do the data logging with FactoryTalk View. The catch is that the existing system has to be essentially unaffected, meaning that I cannot change the existing programming, and the PLC has little to no control over the existing process.

-The issue we are having is regarding splitting the serial communications. We have tried to split it using 3 different types of splitter. The first was a non-powered 1 in 2 out splitter, which made the comms between the existing system and the MGI non functional as well as not seeing anything back at the PLC, so that was a bust. We tried a simple splitter that simply electrically connects them with no diodes or anything, We would see the Rx lights flash on both PC and PLC but the system would lose communications immediately after. We thought that possibly the transmission from the MGI was not powerful enough for both receivers, so we moved to a powered booster/splitter. When we did this, with the MGI as the input and the PC and PLC as the outputs, the system did not have communication. We then made the PC the input to the booster splitter, and the MGI and the PLC being the outputs, and the System did work! But the only communications I am seeing back are the prompts from the PC, not the MGI.

-I do not need to write anything to the MGI or the PC, I simply need to see the reply from the MGI. I will worry about what data later, but right now I would take literally anything from the MGI.

Any help or thoughts would be much appreciated. I didn't think that we were reinventing the wheel, but to be frank I am not even sure if I know what "round" means anymore. Also to be frank, my expertise in serial largely comes from breakfast time, so I am no expert by any means.

an rs232 serial multiplexer may work.

As you only need monitor existing system RS232 sniffer cable should be enought.


Depending of how you connect it you see both old PC coms and replys from MGI.


https://www.aggsoft.com/rs232-pinout-cable/serial-port-monitor-cable.htm


First picture should be enought. (Half duplex)


You connect RS232 pins directly from DB9-M to DB9-F (or D25).


Then solder diodes to pins 2 and 3 (3mm green and yellows even works and you see from leds data write/read.


then ground (5) to sniffer cable pin 5.



Diodes isolate your system and old one is not affected by your new equipments RS232 signals.




RS232 is point to point connection and you need diodes to connect more equipment, otherwise RX signal reply from new equigment will mess original communication and vice versa.
Another method (maybe) would be to use RS232 / RS485 conversion and then from RS485 to back to RS232.

AS RS485 is multipoint you can connect at least on thery your new equipment to RS485 between converters.






If you need also send querys from both masters to device then diodes need to be connected differently.

I have to look from old connection diagrams but it was 2 diodes to line 2 or 3 to block signal to go only to device and not to other master.



Functionality of these diode connections is explaiment here


https://www.lammertbies.nl/comm/cable/rs-232-spy-monitor




p.s Multi slaves and multimasters on RS232

http://cool-emerald.blogspot.com/2009/10/multidrop-network-for-rs232.html

Let's clarify: the connection you are trying to "split" or "intercept" is between an old IBM 80486 PC and this "MGI" device that connects to several gauges.

What type of plugs are on both ends ? 25-pin or 9-pin ?

Do you know if just pins 2, 3, and 5 are connected, or if there are other hardware handshaking pins connected or involved ? Do your splitters claim to handle handshaking pins ?

You may need to carefully get a meter and "ring out" the cable to see if there are internal jumpers or cross-over wiring.

The first thing I would install is a good old fashioned RS-232 LED breakout box. That's going to show you which pins are actually active and when.

I can't tell what sort of devices you are calling "splitters"; that's the kind of minutiae that you really do have to sort out when solving this kind of application.

What you probably need to intercept this data is a "passive line tap". You can build your own with diodes and connectors, or buy one prebuilt.

What exact device are you using at the CompactLogix end ?

Ken Roach said:

Let's clarify: the connection you are trying to "split" or "intercept" is between an old IBM 80486 PC and this "MGI" device that connects to several gauges.

What type of plugs are on both ends ? 25-pin or 9-pin ?

Do you know if just pins 2, 3, and 5 are connected, or if there are other hardware handshaking pins connected or involved ? Do your splitters claim to handle handshaking pins ?

You may need to carefully get a meter and "ring out" the cable to see if there are internal jumpers or cross-over wiring.

The first thing I would install is a good old fashioned RS-232 LED breakout box. That's going to show you which pins are actually active and when.

I can't tell what sort of devices you are calling "splitters"; that's the kind of minutiae that you really do have to sort out when solving this kind of application.

What you probably need to intercept this data is a "passive line tap". You can build your own with diodes and connectors, or buy one prebuilt.

What exact device are you using at the CompactLogix end ?

Click to expand...

RS232 led breakout boxes are diappearing and soon hard to find ones.

More and more also them how know how to use them for signal testing.

One thing that’s being overlooked is the communications protocol. Splitting RS232 is not overly difficult and given the three attempts you made, you’ve probably successfully split the signal. However, if the PC is sending commands to the MGI and the MGI is responding, that is a polling routine and that’s going to involve a communications protocol. With as old as it sounds coupled with the fact that it is using RS232, my guess is that whatever the protocol, it’s a full duplex protocol and can’t be split. Even if it’s a half duplex protocol, in order for both the PC and the PLC to be able to get data from the MGI, it (the MGI) would have to be the system master which is not likely. But, even if the MGI is the system master, it would need to be reprogrammed to accept a second remote.

It sounds to me like it would be a lot easier and cost effective to replace the entire system taking into account today’s technology and the new requirements

why not simply replace 486 with newer PC, copy the DOS program over. Then write a .NET app and send data to PLC.

I agree that if it's a true full-duplex protocol that it might be hard to intercept.

But my reading of the application is that the existing PC and MGI need to remain installed and operating, and the CompactLogix is not going to need to poll the MGI itself, but rather just listen to its replies without the context of the command.

If the system is using a simple ASCII half-duplex poll-and-response protocol, then that should be straightforward, especially if there's some nice line-feed/carriage-return terminators.

I didn't mention it before but I will now: passive "serial sniffing" with a PC used to be difficult and tricky with multiple ports and fancy y-shaped cords. But the Stratus Engineering EZ-Tap is a spectacular value for making it easy to capture the data passing between two RS-232 devices.

https://stratusengineering.com/product/ez-tap/

If I was going to log this data, I would probably try to do it outside of the CompactLogix/FactoryTalk route and run an embedded PC and send the data straight to SQL.

I can't find my ordinary EZ-Tap but I plugged my Versa-Tap into a Raspberry Pi and it came as an FTDI USB/Serial device, enumerated as ttyUSB0.

Even if you have no intent on using PC-based middleware, the EZ-Tap is a terrific value and will give you clarify into what's passing on the wire, rather than looking at the occasional blinking LED.

I did something simular earlier this year when i had to reverse engineer an old RS232 communication protocol when upgradinging a control system.
Basically i used two USB-RS232 dongles in my laptop and then used breakout boards with DSUB connectors and screw terminals (to skip the soldering). Then i connected the RX and TX to the RX in the DSUBs to the dongles and sniffed them using some simple serial logger, that way i had each end of the RS232 split from each other which was very helpful.

Nova5 said:

an rs232 serial multiplexer may work.

Click to expand...

Although our PC isn't that old, we have 232 from a PC to a multiplexer. That multiplexer goes to the machine that the PC interacts with and a separate output from the multiplexer goes to another PC that logs data. Has worked for years.

Thank you everyone for the replies. After many small changes the initial issue of crashing the existing system has been fixed! Looking at the sniffers that you all posted the key was that there was only a single line attached, whereas I had both Tx and Rx connected. Once I dropped the TX line we were not crashing the system and the data light was flashing kn the 5069-Serial.

After fiddling with the configuration and going against what the MGI manual and current PC program are doing, we were able to read in correct data using Tera Term on a laptop. The current PC states 9600 baud, 7 data, Odd parity, 2 stop bits. The configuration that works on Tera term is 9600 baud, 7 data, no parity, 2 stop bits.

We arrived on site this morning, I changed the configuration to match Tera Term, ran the machine and the 5069-serial card is now faulting and throwing a framing error on the transmission of the MGI. When reading the data in the tag monitor, it's the same junk data that we would read into Tera Term when configured for Odd parity. When changing the configuration to basically anything else, I receive no data whatsoever.

We are on hold with rockwell right now regarding it but I can't take this hold music much longer.

Is there any reason why we are seeing good data on our laptop but bad data on the PLC with the exact same configuration? Is there any way rockwell has a raw terminal like Tera Term so I can read in all serial packets coming in through the PLC? Currently I'm using a CPS to move the serial data into a string and looking at the string element by element but this is not super user friendly.

Once again, thank you so much for the assistance. And any thoughts are appreciated.

To those saying replace the system, that is the eventual goal. The issue is that this machine is still in use for active contracts, so before the replacement can happen, plant engineering for the customer has to prove to quality assurance that a compact logix is capable of generating near identical data to the current existing system in order to justify the ability to switch over. Everyone working in this project, both us and the customer, hates the existing system, but I got assigned the project halfway through and now it's just the fun part of making it all work.

Parky maybe can help, meanwhile these.



http://www.plctalk.net/qanda/showthread.php?t=126389



https://www.linkedin.com/pulse/appl...eric-chen?trk=read_related_article-card_title

SandwichMagic said:

Is there any reason why we are seeing good data on our laptop but bad data on the PLC with the exact same configuration? Is there any way rockwell has a raw terminal like Tera Term so I can read in all serial packets coming in through the PLC? Currently I'm using a CPS to move the serial data into a string and looking at the string element by element but this is not super user friendly.

Click to expand...

Are you connected to the computer at the same time and can verify that the computer receives different than the PLC?
Have you tried to send the same message to the PLC from your computer and checking the received string?

I think MSBit is sequentially last in RS-232C; is it possible laptop is 8N2, and parity bit is being read as the last i.e. MSBit?

25 pin?