bit toggling

I am writing logic that will send a bit back and forth between two processors to varify that communications are good. The first processor sends a bit, the second processor inverts it and sends the inverted sate back to the bit in the first processor. Timers are then set for double the message time. If the timers hit DN, then the bit has not been inverted and this flags a communication error.

In order to have a write to another processor, does the recieving processor need a read in order to accept the incoming message?

In order to have a write to another processor, does the recieving processor need a read in order to accept the incoming message?

Click to expand...

That depends on the make and model of the PLC. For most PLC's the answer is NO, for some it's YES. It can also depend on the communication channel and protocol used. So be more specific PLEASE.

Regards,

5000

These messages are being sent in controllogix5000 vs. 1.1 via Ethernet module...........

In this case the answer is NO, you don't need a communication instruction (MSG) in both processors, you need one MSG per communication. It doesn't matter if you do a write in the one or a read in the other processor.

But I've never tried to communicate a single bit with this instruction, don't know if it's possible. I've always used integers between SLC and/or CompactLogix and I've always done it on DH-485.

Kind regards,

Use Produce Consume Tags

If you can set up your ethernet to use produce and consume tags you can easily get rid of message instructions altogether. It's a lot cleaner and less hassle that way.

Re: bit toggling, WHY?

zxninja said:

I am writing logic that will send a bit back and forth between two processors to varify that communications are good. The first processor sends a bit, the second processor inverts it and sends the inverted sate back to the bit in the first processor. Timers are then set for double the message time. If the timers hit DN, then the bit has not been inverted and this flags a communication error.

In order to have a write to another processor, does the recieving processor need a read in order to accept the incoming message?

Click to expand...

I love watching you guys solve non-existing problems or try to do things the hard way. Why do you think toggling a bit is necessary? In the course of normal transactions you will receive a done or a error bit. If the error bit comes on then you have lost communications or at least you know the communications are not reliable.

The problem is that MSG blocks have a very long time out by default. You should reduce the time out to 1 second which I think is the minimum timeout.

Better yet, use the implicit IO ( UDP ) that LJBMatt suggested for some of your transfers and monitor the connection. If an implicit message connection goes 5 RPI with out a response then the communications can be considered lost or unreliable. Since the RPI is usually pretty fast ( 5-10 ms ), five RPI will occurs much faster than 1 second.

Now, if you need to monitor if the communications are good AND the CPU is working then I would just increment a register each scan and produce it in explicit output register. This way the other PLC can see that the number is changing and how fast it is changing.

I like Peter's point about making things overcomplex...I think we must have all been there more than a few times.

If you do decide to go ahead with the "bit toggling" idea, can I suggest that you don't try to interlock the two messages. It simply isn't necessary and just makes the scheme harder to troubleshoot because if it stops you have to figure out which is the chicken and egg.

It is simpler just to use two seperate MSG's that WRITE a 1 to an address in the other processor on a time interval, say 1 sec. When the other processor sees that 1 it clears it to 0.

When this address is 0 then start a timer for say 3 sec. Normally the first processor will WRITE a 1 about a second later and reset the timer, but if the timer completes then you know the comms/other CPU has failed.

Do this independently in each processor and you will have an easy bomb proof scheme.

Alternatively the use of produced/consumed tags can be implemented exactly the same was for a much faster scheme, although it now demands a network scheduling to make it work.

It seems to me that looking at one of the bits in the other processor's free-running timer and counting the time between state changes would do the job nicely. That is, if you can pick up a single bit with a message block (I believe there is some doubt on that).

Ok Peter,

Maybe we all don't see things from same angle all the time
but I think you are wrong here so here is something
I find quite often:

You have a network of PLCs and they are not quite side by side,
maybe they are even in the different buildings.
One PLC is doing all messaging (master) and all other PLCs
are simply reading and writing portion of their memory.
Now somehow connection gets lost (unplugged or damaged
cable, master PLC not running etc.)

How do you propose to let slave PLC recognise that connection
is lost? Wait until maintenance guy walks buy, plugs and boots
his laptop and scroll down the code till he finds bit that
holds the line and from there draws conclusion that
communication is not working?

Maybe your customers are not as demanding!?

I don't see the problem

panic mode said:

Ok Peter,

Maybe we all don't see things from same angle all the time
but I think you are wrong here so here is something
I find quite often:

You have a network of PLCs and they are not quite side by side,
maybe they are even in the different buildings.
One PLC is doing all messaging (master) and all other PLCs
are simply reading and writing portion of their memory.
Now somehow connection gets lost (unplugged or damaged
cable, master PLC not running etc.)

How do you propose to let slave PLC recognise that connection
is lost?

Click to expand...

With Ethernet/IP, the slave can just consume implicit data coming from the 'master'. If the slave fails to receive an implicit data packet after 5 RPIs then the slave knows there is an error. SIMPLE.

Using just message blocks the slave needs to read or write a packet every once in a while and check the .ER bit. Keep the time outs short. NO PROBLEM.

Now if not using Ethernet/IP AND the slave can not initiate the Etherent request THEN the master should just change a register in the slave. The master knows the connection is OK when the .DN bit turns on. The slave knows the connection is OK when the register changes from the last value. I don't think this is the best way to check for slaves being active as the master can use up many message blocks just checking connections.

Couldn't you just start a timer on PLC1:
Time delay on, 1000 milleseconds
If timer gets Done your communications have failed.

All PLC2 has to do is write a 0 to PLC1's timer's accumulator (ACC) within the preset time to stop it from being Done.

If 1 second isn't the time you need adjust the timer preset.

The MSG block has a timeout!

cnrservices said:

Couldn't you just start a timer on PLC1:
Time delay on, 1000 milleseconds
If timer gets Done your communications have failed.

If 1 second isn't the time you need adjust the timer preset.

Click to expand...

When the MSG block times out the .ER bit will turn on. You don't need a timer. The timeout can be adjusted inside each MSG block.
I recommend short timeouts like 1 second. I would use a timer only if I needed a time out faster than the 1 second minimum of the MSG block.

Precisely, for master you simply use .ER bit of the MSG instruction
but the simplest way to monitor any type of connection by the slave
is to monitor toggling value using pair of timers (because timeout
can happen with slave monitored bit at either low or high value).

This sure does put additional traffic on the network
(messages sometimes sent just to keep connection alive) but this
is what is nowdays required in high pace production enviroment
and it is available - for the price.
You pay for faster network a bit more to get more bandwith
and then - use the damn thing. It's stupid to buy high speed
network just to send occasional 10byte messages (like every 5 minutes).
Some people are just paranoid when it comes to optimizing
something to death. One day they wake up just to realize that
hardware is cheap and that it should be treated that
way - then they die...
If the i286 with 640k RAM was good for everyone forever, we would
never have GeForce 6

uragod



-----------------------------------------------------------------
take the money and run

Re: Use Produce Consume Tags

LJBMatt said:

If you can set up your ethernet to use produce and consume tags you can easily get rid of message instructions altogether. It's a lot cleaner and less hassle that way.

Click to expand...

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

I haven't used the ControlLogix line, but with PLC5 and SLC5/05 processors, I tend to use MSG reads only. These are easier to document, get the job done just as well, and as a side benefit, all processors have the "built-in" message timeout/error/done status bits that Peter is suggesting you use.

Marc