500 msec Pulse using multiple Controll Logix PLC

Good afternoon to all. I am new here and seeking your vast knowledge. I have been tasked with pulsing the alarm light in multiple machines with multiple PLCs with a 500 msec pulse. So what they want is when any machine or any number of machines are in alarm that the alarm light pulses in sync with each other. All PLCs clocks are synced together. does anyone have a suggestion on how to do this. I have tried to creating a periodic task but can not get all the PLCs to flash in sync using this. Seems to be scanned dependent. Thanks in advance.

Equipment: All Processors are 1756-L83E programming lang. RS5000 v28

Sure. Use interposing relays to operate all of the alarm beacon lights from a single PLC output.

Bit_Bucket_07 said:

Sure. Use interposing relays to operate all of the alarm beacon lights from a single PLC output.

Click to expand...

MUCH less work than trying to get all the lights to pulse in sync using messaging or syncing clocks. That sounds like a nightmare.

Why in the world do they care if they are blinking in sync? That sounds like a plant manager with OCD... The only reason I can think that it would matter if they were in sync is if you can see them all at the same time, in which case, just use one light! If you can't see them all at the same time, why does it matter?

Good luck regardless, I would go with Bit_Bucket's suggestion though for sure.

You could use the Get system variable GSV command pull the clock data into a memory location.

look here
http://www.plctalk.net/qanda/showthread.php?t=76740

Then you find the bit in the seconds counter that flashes at almost .5 seconds. If all the clocks are in sync they should be the same... The whole in sync thing seems to be a waste of an engineer's time or a training exercise.

Goodluck

I don't know how they do it, but ALL (hundreds) of wind turbines near my house flash the red aircraft beacons perfectly synchronized...it is pretty cool heading down the highway at night... unless you are a large bird or something, then it is probably less cool.

If this is an actual requirement and not a "can't you just?" it can be done.
Bit_Bucket_07 has the simplest way to do it.
If you don't like the idea of a relay cycling once a second forever (I don't), let a PLC do it.
Put in a small PLC that does nothing but run stack lights.
It accepts signals from multiple PLCs (either IO to IO or message) and controls all the stack lights.
Since this PLC supplies the "flasher" for all the lights, they are in synch.

Well I finally googled it up:

http://ask.metafilter.com/250906/Lights-on-wind-turbines-all-in-sync-but-how

That is for my curiosity, for a real world machine application that I had to do myself, I would probably opt for some sort of time synch using an existing network infrastructure and if that wasn't good enough, tell the powers how much it will cost to hardwire the lights all to one controller as suggested or buy the GPS units.

As for the hardwired method, if you use a solid state relay to generate a flashing signal that is always flashing, route that all over the place, and then let each local controller engage a relay for its own stacklight, they all blink in unison, but less wear and tear...

Super easy and looks awesome.

Use time sync and a GSV to get the CST clock. (not system clock)
Use the lower dint value and MOD it with 500000. Use the lowest bit of the result as a flashing bit.

Simpler I think....

Use a Periodic Task in one PLC to generate a DINT that increments every 500mS.

Map (or alias) your flashing output to bit 0 of the DINT

Produce this "master" tag for as many "slaves" you have.
EDIT : make sure you check the box "Send Data Change Event....", AND include an IOT instruction in the periodic task to send the event.

All the other PLCs, consume the DINT, and use an EVENT task, triggered on data change of the consumed tag.

Map (or alias) your flashing outputs to bit 0 of the DINT.

This method you only have code running when it needs to....

Geoff Whites solution will always suffer from scan-times being asynchronous between the various PLCs.

I’ve learned over the years (using this web site) that if someone presents a problem that leaves all of the field seasoned experts asking “why would you want to do that?”, it’s probably homework. Think about it guys, how many times do we get the “I need to create a program for traffic lights in this little town” question? Has anybody ever seen a PLC being used for traffic lights? No, but it makes a great learning exercise because it’s got both inputs and outputs, timers, counters, etc… Maybe I’m wrong on this one but why would you need all of the lights in a plant synchronized to flash at exactly the same time? You wouldn’t. Having said that, if the clocks in the PLC’s are already synchronized then it’s simple. Use the clock to synchronize a timer that is continuously running (every 60 seconds reset the timer). The timer is setup for one second. When the timer reaches 500mS use a compare function to enable a bit. Have all of the PLC’s monitor for an error and when one does error it sends a signal to a host PLC which in turns sends out another bit that goes high. When both the bit tied to the timer and the one tied to the host PLC go high the rung with the comparison goes true and the timer will now turn the output (for the stack lights) on for 500mS every 1 second.

Firejo said:

......... Having said that, if the clocks in the PLC’s are already synchronized then it’s simple. Use the clock to synchronize a timer that is continuously running (every 60 seconds reset the timer). The timer is setup for one second. When the timer reaches 500mS use a compare function to enable a bit. Have all of the PLC’s monitor for an error and when one does error it sends a signal to a host PLC which in turns sends out another bit that goes high. When both the bit tied to the timer and the one tied to the host PLC go high the rung with the comparison goes true and the timer will now turn the output (for the stack lights) on for 500mS every 1 second.

Click to expand...

You think that is simpler than my method ?

daba said:

Simpler I think....

Geoff Whites solution will always suffer from scan-times being asynchronous between the various PLCs.

Click to expand...

Really? You think that a flashing alarm light is going to have a problem with jitter of one scan?

Geoff White said:

Really? You think that a flashing alarm light is going to have a problem with jitter of one scan?

Click to expand...

It's not the logic scan time that will produce the most "jitter", it's the respective RPI's of the output modules, which could be as high as 750mS, now that would be noticeable !

We need to make sure the outputs are updated as soon as the "synchronised clock data" changes, regardless of the output module's RPI.

We can possibly write a raft of code to do this, or we can use "system-level" functions to do it for us, which makes our lives much simpler.

And we can be kind to our network bandwidth on the way.... If our Produced tag (with data-change notification enabled) had an RPI of 750mS, and we change that tags data value every 500mS in a periodic task (remembering to IOT it, which I originally forgot), the transmission on the RPI time will never occur, and we are only transmitting meaningful data - i.e. it has changed.

At the receivers, they "consume" the tag, which is only produced when the data changes, and trigger an Event task to do whatever is necessary to our outputs (eg. mapping). We don't need to IOT those either, because by default there is an automatic output update at the end of every task.

Minimal coding, and that code only runs when it needs to, no timers, no messages, no GSV's - it all works using the infrastructure provided.

Geoff White said:

Really? You think that a flashing alarm light is going to have a problem with jitter of one scan?

Click to expand...

Forgot to mention I have seen logic scan times exceeding 150mS under certain circumstances - that would be most noticeable on our outputs, especially if they were asychronous.

Thanks
I had a problem with jitter, just increased the default RPI 20 and its working fine