Square Wave Pulse Generator

Watch dog pulse between two devices.
This is not a good idea. One of my customers got bit by doing this. It turned out the watch dog routine in the PLC was timing out because it didn't see the bit change. The problem turned out to be the PLC was polling the bit synchronously to the bit changing off then back on so the PLC did not see the bit go off.
It is best to increment a integer and check to see if the integer changes.
 
It is best to increment a integer and check to see if the integer changes.

This is my preference too, the kicker being that if the third party system I'm interfacing has someone stubborn and not open to make a rolling counter, I don't have to change my logic to match his code.

I'll keep incrementing and point him to the LSB.
 
This is my preference too, the kicker being that if the third party system I'm interfacing has someone stubborn and not open to make a rolling counter, I don't have to change my logic to match his code.

I'll keep incrementing and point him to the LSB.

I prefer to use a "bit-chase"....

In PLC1....

XIC PLC2_Bit OTE PLC1_Bit

In PLC2....

XIO PLC1_Bit OTE PLC2_Bit

The bits will just keep on toggling, at the comms rate. It is easy to use a simple grace timer in both PLCs if it ever stops.


In A-B Logix5000, I use the "CONNECTION_STATUS" member of a Produced/Consumed tag to determine if a remote PLC is "Connected", and "Running". This is a much faster method, as it doesn't rely on cyclic messages and grace times, the Connected and Running bits are updated at the RPI of the "Connection" to the remote controller.
 
I prefer to use a "bit-chase"....

In PLC1....

XIC PLC2_Bit OTE PLC1_Bit

In PLC2....

XIO PLC1_Bit OTE PLC2_Bit

The bits will just keep on toggling, at the comms rate. It is easy to use a simple grace timer in both PLCs if it ever stops.

Doesn't this put you in a similar situation highlighted by Peter N.? Though with a small chance of happening?

This is something that people do miss quite often and in the Siemens world can be a world of difference as the PUT/GET instructions always work no matter what the state of the processor is.
 
Doesn't this put you in a similar situation highlighted by Peter N.? Though with a small chance of happening?

Not at all - the bits have to keep toggling, because of the XIO inversion in one PLC - either will do.

It can't get synchronous, because there's no inherent timer. If the bits stop toggling, the message instructions aren't working, for whatever reason - eg. PLC Died, in Program Mode, Powered Down, etc., or the comms system is "broken" in some way.
 
Daba - that was my standard also for precisely the same reasons. Each end had two timers one enabled by the on condition and the other by the off condition. Preset of each to a reasonable time, 2 seconds for example. If either times out the communications have stopped.
 
Last edited:
Not at all - the bits have to keep toggling, because of the XIO inversion in one PLC - either will do.

It can't get synchronous, because there's no inherent timer. If the bits stop toggling, the message instructions aren't working, for whatever reason - eg. PLC Died, in Program Mode, Powered Down, etc., or the comms system is "broken" in some way.

In my limited knowledge of Rockwell stuff and how the data update works, it is possible that the data is updated and the code hasn't run... unlike situations where the data is read at the beginning of the cycle and written at the end.
Obviously these would be quite limited and you had to go out of your way to make it happen, but there's a potential for it, no?

Or am I completely wrong?
 
Daba - that was my standard also for precisely the same reasons. Each end had two timers one enabled by the on condition and the other by the off condition. Preset of each to a reasonable time, 2 seconds for example. If either times out the communications have stopped.

I economised, and only had 1 permanently-enabled timer in each PLC. I used one-shots to reset it on the rising and falling edges of the handshake bit.

I also got caught out by the "square-wave" handshake bit, (not my programming, I must say), which started to go awry when additional comms blocks were added to an old system.

It altered the comms rate of the blocks where the "handshake bits" were, and they became synchronous to the period it was inspected in the partner PLC.

Not wanting to store up a future occurrence if things got changed again, I ripped it all out, and came up with the "inverted cyclic bit". Started using this method of comms checking around 1988 or thereabouts. I never did give it a name, but I suppose "Inverted Cyclic Bit" is as good as any....
 
In my limited knowledge of Rockwell stuff and how the data update works, it is possible that the data is updated and the code hasn't run... unlike situations where the data is read at the beginning of the cycle and written at the end.
Obviously these would be quite limited and you had to go out of your way to make it happen, but there's a potential for it, no?

Or am I completely wrong?

The comms has to work, AND the code must be executed in both PLCs for them to toggle on and off, irrespective of data update times or anything else.

I have put that exact methodology in all projects I have done for many years, and haven't had a single failure.

It is the simplest and most efficient way to ensure everything is working as it should....

EDIT : It passed every single "failure-mode" test our various clients threw at it in their "Factory Acceptance Tests"
 
Last edited:

Similar Topics

Hello Forum, I have a machine being commissioned that takes a flat sheet of metal and forms it into a series of convolutions. Each convolution...
Replies
7
Views
5,571
Hello, Does anyone have any tips on how to generate a square wave on RSLogix 5000? Thank You!
Replies
11
Views
8,363
I have an existing machine with an IFM RN6057 encoder (dat sheet attached) fitted. This encoder has 2 outputs: - SSI singleturn - Incremental...
Replies
2
Views
3,675
I have some A/B ML1500's and SLC5/05's that need backup power. I bought a UPS but a sticker on it says its output is essentially a square wave...
Replies
0
Views
3,151
This is a very stupid question, but leave it too me to ask it. I was wondering why is it IMPEDANCE of a inductor is 2PI(FL) for a square wave...
Replies
12
Views
7,375
Back
Top Bottom