Trying To Make Two Controllers Talk Over I/O Wires

A proprietary DCS (with non-modifiable Ethernet capability) is trying to output a 15-bit value (0... 32767 range) on its 4-20 Analog Output card to a ControlLogix PLC employing a 1734-IEBC Analog Input Card.

Can't seem to get it to work.

Has anybody else done this (Controller-to-Controller of Analog values via I/O channels), and are there any special (electrical or I/O Card) considerations to make this work?

Should be trivial.

Have you measured if a 4-20mA signal is present ?
Have you measured if a voltage is present over the input terminals on the receiving side ? There must be a voltage (usually between 1-5V) because there is a shunt-resistor in the analog input that converts the current signal to a voltage signal.

Show us your diagram of the setup.

Jesper,

Looks like this isn't going to work. The wiring is apparently good now, but the resolution on the numbers isn't sufficient. Trying to send a bitword with 2, 5-bit fields (in bits 0-4 and 5-9), followed by 5, 1-bit fields. The resolution isn't there. Can't really compress or remove any of these fields.

Maybe use OPC with a go-between machine? I *think* the proprietary DCS is OPC compliant.

Why not use multiple analog channels?

Maybe I'm missing something but seems like all you have to do, is wire directly from the analog output of the first card to the analog input of the second card. The first card outputs a 4-20 mA signal and the second card receives a 4-20 mA signal.

There may be issues with noise if you are wiring over a long distance. Good grounding practices will be important. I think a signal conditioner may help with this too but I haven't personally used one for this type of application.

Getting an analog input to display the exact value the other PLC is giving is going to be almost impossible. Say an output of 16352 [0011111111100000] would read 16348 [0011111111011100], close - but that would mean a few bits would be wrong, and if it involves the 16384 value bit that could change every bit after that.

I would suggest replacing the cards with digital IO and running a 18+ conductor cable between if the run isn't to great.

Agreed,

If you want a binary number transmitted, transmit it in binary. Use serial or digital IO.
D/A then A/D means they will never match. That being said if all you need is 10 bits and you have 16 bit resolution on both ends, you should be able to get the high order bits to settle down pretty well. Just don't use the low order bits they will be random.

mellis said:

you should be able to get the high order bits to settle down pretty well. Just don't use the low order bits they will be random.

Click to expand...

That was my first thought. But then if the transmitted number is 16385 {16384 + 1] but the received value is 16383 that would turn the 16384 bit off and every bit under it on when only the 1 bit should be on.


0100000000000001 16385

0011111111111111 16383 Every bit but '1' is wrong


And if you don't use anything under '256' bit then all the bits used are wrong for a read error of -2.


EDIT: If the data can be transmitted slower, maybe set up a serial communication type pulsed signal to monitor. Start bit or 2, 15 data bits all timed as equal pulses, then a pause of a full second. The receiving PLC can see the start bit(s) then start recording On.Off for each of the 15 tags following. This might mean the data takes 1ew seconds to 30 seconds to be transmit. If an update once a minute is OK then this should work.

OK, now I understand what you are trying to achieve.
I think it is simply not possible. As others have pointed out a small error in the analog signal will give a huge error in the digital bitpattern.


Honestly I think it would be easier with just a digital signal. I think I once saw someone implementing a crude serial protocol over a digital signal.
If it is just 15 bits that has to be transmitted it wont even be that hard.


edit: That seems to be Aabecks suggestion as well. I think it will be much faster tham 30 seconds. It can go as fast as the propagation delay of the output and input signals allow. If you conservatively sets it to 10 ms, you still have 100bps. So with 15 databits, a parity bit and possibly 2-3 stop bits, you get approximately six 15-bit words transferred per second.


edit again: The limiting factor will probably be if the programs on either side can update fast enough. To send is easy. To receive is the hard part, because you would have to reliably detect all the bits with no gaps. So my guess is that the receiving side must update at 2.5 times faster than the rate of the bits that are being sent.

Another thought on the serial comm type.


Instead of skipping off bits, time the pulses - short if the bit is off, and if it is on have the pulse long enough for a timer on the receiving PLC to time/DN and set the tag on. This might be better, as if the signal was dropped mid-way through the receiving PLC might consider them all off.

First half done.

Attached is a CLX routine [ver20.04.01] for the sending of 16 tags in an array Serial_Send_Data[xx].

I made it with 0.125 second pulses and off times. 2 Start Bits, then 16 data bits.

If the tag is OFF the data pulse will be on for 0.020 seconds, if ON then the full 0.125 seconds. After data pulse 16 it will time 5 pulses OFF before starting over.

At this rate it will cycle every 5 seconds. When I get the other side to read I will see how low I can go on the pulse timer to try and shorten that and still get accurate readings.

When I get back from a customers I will work on the receive routine.

You guys are too much! And I really appreciated your enthusiasm, but this older proprietary DCS (44 Controllers in total) won't be able to implement serial comms; they're barely able to run at a 300ms rate, and the programming toolbox is "bare bones"! They only succeed here because there is nothing time-critical, and they have a proprietary TCP/IP protocol they use to communicate data values amongst each other.

Any very-limited comms they currently do with "satellite" PLCs is hard-wired, and always just a single digital input (for a permissive, say).

I'm afraid the only solution is to drag 16 digitals each way (unless the OPC interface could be made to work). There's room in both cabinets for these cards; it's just kind of a klunky solution. It would be two floors, and about 50-60'.

======
FYI: The data words being sent each way are actually a compressed version of the proprietary transfer protocol the DCS uses to link up a Transfer IN module with a Transfer OUT module in its own world. Normally it does this over it's TCP/IP Ethernet protocol, but in this case we're sending it out the I/O to a PLC (because the new system needs to communicate with the old system's modules).

The Compressed Data Word looks like this:

Bits 0-4: Own Address ("my" address) **

Bits 5-9: Partner Address ("the other guy I'm trying to link up to") **

**NOTE: Indexes are actually being used in place of the native addresses because the addresses are too large

Bit 10: Master Indicator ("who is controlling the transfer")

Bit 11: Sync Indicator ("We've completed the handshaking protocol to Link Up, but no valves are open yet. ")

Bit 12: Continue Indicator ("Now we're opening valves")

Bit 13: Complete Indicator ("The transfer is done")

Bit 14: Spare

Bit 15: Purified Water Status Indicator (not related to transfer, just 'piggybacking')

The two partners "link up" by exchanging partner information and verifying that one is Master and the other is not. Then they send Sync and Continue while the transfer is running to Pause and Un-Pause the transfer ... until the Master removes both Continue and Sync and indicates Complete. So one partner is in the lead, while the other is following along with the handshaking signals.

I guess all this could be made to work serially IF we had two capable systems on each side - but we don't. The proprietary system runs under a 680x0 chip and Unix variant OS, but the programming environment is DOS-based and layered to all but completely remove access to the underlying system capabilities.

Wholly untested but I think it will work

If one of the PLC's needs a slower signal rate, just increase the time settings on each routine.

Increasing the pulse time from 0.125 to 0.5 seconds and the Tag Off time to 0.100, ON is over 0.400 would slow the comm's down, but get the data transmitted in under 20 seconds.

Gonna give this analog card thingy one last shot. Cut the data word to 8 bits by removing the Partner Address and PUW fields (moved to dedicated DO), then rescaled to 0..255 and got some very stable-looking AO mA readings for several test bit patterns. We’ll see if the AI will be as good.

Now, each parter will just send it’s OwnAddress, and handshaking bits. This will still work, but now each side will have to manually populate their local Transfer Group’s PartnerAddress with their OwnAddress (instead of pulling it from the return data word). Not as “confirmed” but good enough.