bit toggling

[akreel]

all processors have the "built-in" message timeout/error/done status bits that Peter is suggesting you use.

I find that "built-in" functions don't always cover all your bases. Usually I incorporate the built-in function, then tack on something extra if I'm not satisfied. But, you're right to avoid doing things the hard way.

To use this example, what if you wanted a slave device to realize that the master had quit polling it? zxninja is on the right track to solving that problem.

AK

 

[msinclair]

To use this example, what if you wanted a slave device to realize that the master had quit polling it? zxninja is on the right track to solving that problem.

In the case that you describe, what I would do is to map the MSG error/done/timeout etc. functions into a "status word" for the master. That "status word" would then be one of the pieces of data that would be read by the slave device. In that way, I'd get just about everything that was needed.


If the slave should take very different actions based on whether it fails to "read", or the master fails to "read/write", then the methods suggested by Phillip and Greg make pretty good sense to me.

Marc

 

[Guest]

PhilipW's method works and is simple.

Processor A writes to Processor B

First Bit of the message word(s) assign to Communications Status
A sets the bit in the message
B reads the bit in one rung and resets it
While the bit is low run a timer in rung 2
Timer times out Communications is lost

Simple 2 rungs and Joe Blow night shift understands

Processor B writes to Processor B

You get the picture.
If not put the mouse down and step away.

 

[(8{)} ( .)]

Two points to ponder.

1) I recommend sending an integer instead of a bit. Missing a single bit toggle is much easier than missing a change in integer.

2) We use a method where each processor reads from the other. The 1st word of each data block is a constantly changing register. If the register stops changing for a few seconds (usually 5) we flag an alarm.

My recommendation is to keep it as simple and as standard as possible.

Good luck,

(8{)} ( .)

 

[Pierre]

I am writing logic that will send a bit back and forth between two processors to varify that communications are good...

zxninja

Althought you will receive many ideas on how to do this, I beleive the simpler the better.

The next one who will have to troubleshoot those systems will find it VERY easy to figure out what you have done and this is good.

PLC B writes 1 to PLC A
PLC A detects a value of 1 and resets it to Zero

PLC A writes 1 to PLC B
PLC B detects a value of 1 and resets it to Zero
Values of 1 or Zero each starts a timer. When they don't change you have a com error.
Real simple. Real good.

 

[PhilipW]

I thought I read that there is a limit to the amount of produced/consumed tags that you can have in a controllogix system. In a system here we had to use messaging because we were sending over 20 dints of data back and forth between processors

Yes there is a limit, but it is normally MUCH larger than 20 DINTS. The CLX processor supports up to 250 "connections". To calculate the total number of connections used you need to account for all the local and remote modules (and the connections associated with each), plus the produced/consumed messages, cached messages, and block transfers.

If you had a particuarly large system that was already close to the 250 connection limit then adding 20 seperate DINT tags might have pushed it over the limit.

A better way would have been to combine all 20 DINTS into a single array or UDT, and shifted them as 1 tag, that would have consumed only 1 connection.

There is a limit on how big a single produced/consumed array can be, I think from memory it is about 500 bytes. There are some other restrictions as well, relating to comms module capacities, but most folk don't get anywhere near them.