Strange request possibly

[Ken Roach]

The Channel 1 DB-9 port on the MicroLogix is definitely a very ordinary, garden-variety, bog-standard, off-the-shelf, general-purpose, run-of-the-mill, standard RS-232 serial port.

If the connection between the HMI and the DM Board is literally just two wires, it is very probably "2-wire RS-485", which is a different voltage and transceiver standard. It also definitely requires a third conductor, which is sometimes the ground plane or even earth ground.

You could get a 1763-NC01 breakout cable that allows the MicroLogix 1400's Channel 0 (which combines the terminals for an RS-232 transceiver and an RS-485 transceiver in the same physical plug) to connect to the two data conductors.

Or, you could get an RS-232 to RS-485 converter, which often provides isolation between the devices. The A-B 1761-NET-AIC is popular with the MicroLogix.

But I don't think you should try to hook anything up at all until you understand the roles of the "master" and "slave" and have information about how the HMI driver is logically configured.

 

[drbitboy]

...
But I don't think you should try to hook anything up at all until you understand the roles of the "master" and "slave" and have information about how the HMI driver is logically configured.

+1 to everything Ken says, but especially this.
-

 

[Ken Roach]

Clarification/correction: on the MicroLogix 1400

Channel 0: Mini-DIN8 round combination RS-232/485 port
Channel 1: RJ45 Ethernet port
Channel 2: RS-232 port

I wonder if you could connect an RS-232/485 converter but omit the Tx pin on Channel 2, and detect the Modbus Master poll from the HMI (maybe using the CS2:x communication status registers), and transmit the same Modbus Master poll command. It wouldn't get actually transmitted on the RS-485 data conductors because the Tx pin on the RS-232 side is disconnected.

Then you would receive the Modbus Slave reply (because the Rx pin is connected) and use the onboard Modbus firmware features to decode it and check the checksum and place it into data table registers.

It would probably only work if the HMI is doing exactly one Modbus message, and no others, and if the time between poll and answer is long.

"Sniffing" Modbus passively using the ASCII serial port and string instructions would require expertise. It's the simplest industrial serial protocol there is, but the MicroLogix OS just isn't equipped to handle even CRC16 calculations.

 

[drbitboy]

... but the MicroLogix OS just isn't equipped to handle even CRC16 calculations.

I am not sure OP cares about CRC16. It's nice to have, sure, and without it there would be no way to know if/when things go south and they are getting bad data. But once they have a stable physical/electrical connection working, is it really necessary? If CRC16 is critical, then the 1400 should be replaced by a RaspberrryPI.

Debugging should all be done on a PC listening with a USB-RS485 converter.
-

 

[drbitboy]

https://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf#page=40


That should not be difficult to implement in MicroLogix; maybe they do not have to discard the checksum.

The bigger problem would be determining the start and end of requests and replies in ASCII reads; perhaps there is a delay between the end of one reply and the start of the next request.

 

[sbasham]

I do have to leave the HMI connected to the DM Board, The company won't allow any protocol information out. I just want to read the RTD's value that connects to theDM board and send our process PLC (which is not connected to this system) a digital signal to say there is a low temp on this Undertank heat system. I do have the free version of the HMI software and so it lets me upload the program(that's how I know it's 3x addresses that the HMI is reading for temp.) I cannot download to the HMI to change the program without purchasing the software and just for this I'd rather not have to. I definately cannot change the DM board because I have no idea what platform it is using,(although schneider electric has built this board for Chromalox)Also when they add the DM board as a new device to the HMI software i guess it does say the DM board is a slave device address 16(sorry my mistake). And it says SIO type RS422/485(2 wire) I do have an O-scope but I'm not sure what to do with it to tell me anything. Also I definately don't want to hook up to the two -wires(and the ground) until I can figure this out.That's why I'm turning to you geniuses! :_)

 

[Ken Roach]

Systems where you need to add functionality but are prohibited from making changes are necessarily difficult, and often expensive in time and effort.

If this were my system, I would connect to it with my RS-485 data tap (a Stratus Engineering Versa-Tap) and examine the serial traffic to verify that it really is ordinary Modbus and that it's reading 3xxxx Input registers. Modbus is simple enough that you can often decode it by hand, especially assisted by tools like the Chipkin Automation Modbus Parser. Another fun tool is the IO Ninja Modbus analyzer.

Unless I had no other tools available, I would not try to implement this in a PLC. I would get a Linux computer with an RS485 interface and recruit a Python programmer.

 

[drbitboy]

Unless I had no other tools available, I would not try to implement this in a PLC. I would get a Linux computer with an RS485 interface and recruit a Python programmer.

+1.

Even if I was told the final implmentation had to be on a PLC, I would start with a Linux (or WSL on Windows) laptop and an RS-485 interface as Ken suggests: the initial development time saved would pay, several times over, for the purchase of even a brand new laptop and interface. Linux/Python would make this an almost trivial exercise, assuming it is indeed Modbus RTU. Porting to any other platform once everything was understood would be but the canonical "exercise for the student."

 

[sbasham]

I do have to implement using a PLC. But, judging by everyones comments,it sounds like I will fail in this endeavor. My boss seems to think it's easy and it might be for him. I do have the ability to buy a few tools to accomplish this, I just hate to spend much and still fail. I really need to succeed at this and only have little time to apply myself to this.

 

[drbitboy]

...I really need to succeed at this and only have little time to apply myself to this.

Too bad, it is an excellent opportunity to learn.

Have you hooked up the oscilloscope yet? That, and a little patience and time with The Google, will tell you if it's RS-485 (voltage levels); it should also tell you baud rate, parity, and stop bits. And that is all you need to get started.

Once you know it's RS-485, you can safely hook up the 1400's mini-DIN RS-485 A/B pins and start sniffing bytes, and put them in a data file (array), perhaps with timestamps.

Then you can parse the data against the Modbus RTU protocol (see earlier links) to figure out what is going back and forth.

 

[Steve Bailey]

The easiest way to do what you want would be to add the ML1400 to the network as a Modbus slave and modify the Modbus master to add another Modbus write command to send the 3x data it received from the DM card (Modbus device 16) to the ML1400.

Unfortunately, that option is not available to you.

The alternative is to physically add the ML1400 to the network and write ladder logic that examines all the traffic on its serial port. When it detects the Modbus read command from the master to device 16, it will need to capture the response from device 16 and extract the data.

The command from the master to device 16 will be a string similar to this:

10040004XX

That is a command asking device 16 to send the contents of addresses 30000 - 30003

where:
10 is the modbus address (hex) of the slave
04 is the modbus command, in this case read 3x memory
0000 is the starting address in the slave of the requested data, in this case 30000
0004 is the number of 3x words, in this case 4
XX represents two bytes for the CRC checksum which I did not calculate for this example.

The response to that command from device 16 will be the next set of characters you detect on the network and should look like this:

100408ddddddddYY

where:
10 is the modbus address of the slave
04 is the command it is reponding to
08 is the number of bytes of data
dddddddd represents the actual data
YY is the CRC checksum

My example above asked for 4 words, starting at address 30000. The actual exchange between the HMI and device 16 is quite likely different and depends on how much 3x data is displayed on the HMI. You will need to manually examine the traffic on the network first to determine the actual modbus exchange you're interested in.

 

[sbasham]

thank you everyone for your replies. I really didn't expect such a great response( I mean i'm new and had no idea it would be like this!) So i joined as a paid membership because i was very happy that you guys take the time even with a newbie who's knowledge is extremely limited(everything I know i've had to figure out myself by just trying to do it.
Anyhow,Steve Bailey i am taking your advice and going the easiest way and I am going to purchase the Proface HMI editing software so I can write the 3xxxx data it receives from the DM board to the 1400AB. I just hope if I run into any problems you might give me another tip or two to help me along LOL!

 

[Steve Bailey]

I don't know enough about the capabilities of the Proface to be sure, but it might not be quite that simple. Commands from the the HMI to read data from the PLC are typically executed periodically as needed to refresh the data displayed on the screen. Commands from the HMI to write data to a slave are typically executed based on an event such as tapping an object on the touchscreen. You probably need to write the 3x data to the ML1400 periodically rather than when someone touches a button on a screen. Before cutting the PO to buy the software, ask Proface tech support if that's possible with the model you have.

 

[sbasham]

that's a good idea,i see what you're saying. I do know it's capable to be able to write some ladder logic in the editing software, so, i will talk to tech support and try to verify before i buy it. Thanks!

 

[drbitboy]

... but the MicroLogix OS just isn't equipped to handle even CRC16 calculations.

At least not easily, although it can be done: see the attached PDF (see reference implementation at this link); preliminary testing on a MicroLogix 1100 Series B suggests about 100ms* to calculate the Modbus checksum for a message of 72 characters.

So I agree with Ken: while it can be done in the MicroLogix OS, why would you want to when there are other simpler options (RaspberryPI, etc.), unless you had to?

* distributed over three scans; 100ms is the default scan watchdog timeout.