Anything wrong w/ using PLC and contactors to control exterior lighting?

[Todd0x1]

Allow me to get into this fray if it’s not too late. LOL

This is in early planning stages so not too late. I should have been a bit more clear on the ethernet infrastructure. All locations are on one site, so its one LAN. Each building has an ethernet switch with fiber between them. There are no existing PLCs, the existing ethernet infrastructure is for other uses. The lighting control PLC and modbus i/o modules would be on a separate port based vlan (or whatever they need to do to have the PLC lighting control on its own private network).

 

[RumRunner]

This is in early planning stages so not too late. I should have been a bit more clear on the ethernet infrastructure. All locations are on one site, so its one LAN. Each building has an ethernet switch with fiber between them. There are no existing PLCs, the existing ethernet infrastructure is for other uses. The lighting control PLC and modbus i/o modules would be on a separate port based vlan (or whatever they need to do to have the PLC lighting control on its own private network).

Okay, now I see .

Sure you can integrate your PLC lighting control using the Modbus Network. Just make sure that you get the Modbus-enabled PLC unit with an RS-485 port and network adapter to plug into your vacant ethernet switch.

You program your PLC from your PC or lap top and upload it to your PLC MODBUS unit via RS- 485 serial cord.
The PLC would drive those relays/contactors to control those lights.

Since the operation becomes "fixed" on the PLC end--the PLC doesn't need to be monitored.

You'd be bored watching those LEDs blinking in sequence indefinitely.

Seriously, you would want to make sure that those lights (the controlled ones) come on as programmed and off when they should be.
This is when you need to integrate SCADA (supervisory control and data acquisition) software and peripherals so you can monitor and operate those lights thru automatic command from the PLC and also be able to override the auto functions in case your PLC craps out. Some call it HMI (human-machine-interface)

Programming the PLC and integrating them into the panoply of protocols, hardware and software. . . I have to admit-- needs an understanding of the OSI network architecture.
It makes it easier to grasp the vagaries of the science of networking.

I know you can handle it-- if not feel free to consult a Network Engineer.

Be safe and healthy,

 

[SceneryDriver]

Teach, learn, and make with the Raspberry Pi Foundation

We are a charity with the mission to enable young people to realise their full potential through the power of computing and digital technologies.

www.raspberrypi.org

I like pie!

No. Just... no. A Raspberry Pi is not a device meant to control anything in an industrial control panel. They're meant to be used to teach the basics of Linux and programming. They're hobbyist toys.

I have one on my home network doing ad blocking. I love it. It works well for the most part, but I absolutely would not use a Pi in an industrial controls application. They're just not reliable enough. They have a disturbing tendency corrupt their SD card if not properly powered down, or for no real reason at all. The only way to recover from that is to wipe the card and reload, hopefully from a backup (you did make a backup, right?). If a Pi runs without issue for more than a year or two, it's rare.

Their I/O isn't hardened, and can't directly control anything larger than a blinky LED. You can't directly control a contactor coil with 3.3V I/O, which means you're now cobbling together even more not-meant-for-industrial-controls hardware, shields, etc... The cost of proper hardware is small in comparison to downtime and damaged customer relations due to crashed hobbyist-grade hardware.

PLC's are designed to run for decades and they do all the time. They also usually don't care how or if they're unceremoniously power cycled. And, you can get a replacement in ten years, if one does suffer a failure (lightning strike, etc...). Good luck finding a Pi 3B+ ten years from now, along with the particular distro of Linux you'll need to run that bespoke program you wrote for lighting control. Ladder logic is pretty easy to understand for most electricians; Python (or another "computer" language) is not. If they have no way to support it, they'll rip it out, and curse your name for supplying something they can't maintain. If they have questions, they can call the PLC manufacturer for tech support. Who are they supposed to call for Ras Pi tech support, other than the person who wrote the program?

And that's just the hardware. They're not Listed or Recognized components, and without jumping through a bunch of hoops, a panel built with one is unlikely to pass a UL inspection. Inspectors may not like them either, but probably because they don't understand them.

Ras Pi's are neat toys. They certainly serve a purpose, but that purpose is not industrial controls. To suggest otherwise is a potential hazard. You can get a proper PLC (with Ethernet) for not much more than a Pi. Honestly, it's probably cheaper to use a PLC, once you factor all the time and other crap you need to make a Pi control anything. Don't saddle your client with an unreliable and unmaintainable system when a better alternative exists.

< rant off />


SceneryDriver

 

[Todd0x1]

Agreed. Rpi is not suitable for anything that has to just work forever. I have used them, made a pretty cool touchscreen controller for a crosspoint video switcher out of one, but thats not the right hardware for something like this. Especially when a $160 PLC does the job.

 

[petersonra]

I just saw an ad from automation direct that features this device they are now selling.

 

[SceneryDriver]

I just saw an ad from automation direct that features this device they are now selling.

View attachment 2552140

I've seen these too. I wouldn't touch them with a 10' stick. An Arduino-based solution just isn't maintainable or easy to modify for the average maintenance electrician. Nope, nope, nope!

I like most of what AD sells. I use a lot of it. Just not anything Arduino-based. Ever.


SceneryDriver

 

[petersonra]

I've seen these too. I wouldn't touch them with a 10' stick. An Arduino-based solution just isn't maintainable or easy to modify for the average maintenance electrician. Nope, nope, nope!

I like most of what AD sells. I use a lot of it. Just not anything Arduino-based. Ever.


SceneryDriver

I would not use it for anything that was general purpose type control. C is just a horrible language for that. But if I needed some text processing or number crunching along with my ladder logic, it might well fit the bill.

 

[Todd0x1]

The $160 PLC I had in mind was the Click from Automationdirect. I have one sitting infront of me left over from some other project. It has ethernet + RS485. 8x 24vdc input and 6x relay output.

The arduino PLC is interesting in that it would make a good replacement for bare pcb arduino in situations that dictate its use, but my application is better served with a 'real' PLC.

 

[ptonsparky]

A CLICK is what we used in a riding arena.. No HMI because it was installed before an office was built in one end of the building. Multiple input locations for on/off with a time delay to stage a shut down after so many hours of operation.. Used the horrible cheap contactors. Guilty.

 

[RumRunner]

The $160 PLC I had in mind was the Click from Automationdirect. I have one sitting infront of me left over from some other project. It has ethernet + RS485. 8x 24vdc input and 6x relay output.

The arduino PLC is interesting in that it would make a good replacement for bare pcb arduino in situations that dictate its use, but my application is better served with a 'real' PLC.

It’s amazing how many electronic products on the market --that you will find almost as a good as those you mentioned . . . “REAL” PLC.
Arduino kits and Velleman of Germany have all kinds of components that will make hobbyists and DIYs happy.
I built my Home Theater Surround Sound from a Velleman Kit. I had a good run with it with the kids when I used it for the AVATAR movie when it first came out.

The thundering effect of the sound track makes for a movie house effect. I built it with six speakers with built-in tweeters. So it has a total of twelve speakers. Amazing.
They are nice but they are not for industrial application. Real PLCs are robust and can take a lot of abuse so to speak. I agree with the other poster.

Back to electrical panels with integrated PLC unit.
The panel can be assembled with all relevant devices to provide/control of the power being supplied to each individual lighting circuit.
UL listed/approved relays, power supply, astronomical timers (redundant feature if desired) and photo sensing devices can be installed inside the control panel.
Some AHJ require samples of specific component that are installed for custom-built units.

I know L.A. is picky about something outside industrial application. Yours would be classified as “institutional” or commercial. Where there is occupancy of certain number of people- - it raises the red flag.

There are small PLC modules that have “burned-in chips” that can be programmed to perform a fixed operational routine.
A small unit--the size of a shoe box is made by Hitachi. Hitachi Module EH-150 is a popular industrial module. Siemens and Allen-Bradley also make their own version.

You can program this network communication module—or any protocols to do this routine and never have to make any changes again.
I’ve used a few of them in the past for CNC (Numerically controlled machine). They come in 12 to 16 input /outputs which you can leave some unused [open] if not needed.. . . just designate them “NULL” in your ladder diagram. You can activate them as your need arises. At the time it cost $1500 a pop.

Several manufactures use BACnet, CANbus protocol (this is a centralized system used on vehicles) and LONworks, but Hitachi, the one I’ve worked on uses MODbus+.
But you don’t have to be concerned how they function in your application—they work behind the scene.

This module is usually mounted outside the lighting panel with it’s own enclosure where you can see those tell-tell lights without opening the lighting panel.
The “burned-in” memory in the chip stays fixed until a re-flashing become necessary --which is rarely needed. This “burned-in memory” is similar to your PC BIOS (Basic Input/Output System) on your computer motherboard. Very little chance of getting corrupted which contributes to its robust performance.
You want those lights to come on at night [of course]. . . so, very little is there to worry about that will conflict with the primary intent of the design criteria.. . . or make an exception during eclipse maybe ?

You really don’t need a super complicated set-up that would mimic those dancing lights showing Shakira--undulating on a jumbo-tron (billboard) in the middle of Times Square.

You may have to consult MCC/Panelboard mfg shops to determine the space inside to accommodate those relays--since those lighting panels don’t have room for extra devices.

Best.

 

[SceneryDriver]

I would not use it for anything that was general purpose type control. C is just a horrible language for that. But if I needed some text processing or number crunching along with my ladder logic, it might well fit the bill.

Agreed. C is a horrible language for industrial controls.

Regarding text and math: maybe, but most modern PLC's can do that just as well. AutomationDirect's BRX, AB's Logix lines, and Beckhoff all do math and string handling just fine. I'd be hard pressed to think of an application that NEEDED an Arduino solution.

If I sound jaded and grumpy about the Arduino/Ras Pi/BASIC Stamp thing, it's because I am Over my career, I've had to clean up several messes left my other people trying (unsuccessfully) to cobble together hobbyist grade junk into workable and reliable systems. And then I'm the bad guy, telling the client that they have to spend MORE $$$ to do it right/again.


SceneryDriver

 

[SAAPI]

Okay, now I see .

Sure you can integrate your PLC lighting control using the Modbus Network. Just make sure that you get the Modbus-enabled PLC unit with an RS-485 port and network adapter to plug into your vacant ethernet switch.

You program your PLC from your PC or lap top and upload it to your PLC MODBUS unit via RS- 485 serial cord.
The PLC would drive those relays/contactors to control those lights.

Since the operation becomes "fixed" on the PLC end--the PLC doesn't need to be monitored.

You'd be bored watching those LEDs blinking in sequence indefinitely.

Seriously, you would want to make sure that those lights (the controlled ones) come on as programmed and off when they should be.
This is when you need to integrate SCADA (supervisory control and data acquisition) software and peripherals so you can monitor and operate those lights thru automatic command from the PLC and also be able to override the auto functions in case your PLC craps out. Some call it HMI (human-machine-interface)

Programming the PLC and integrating them into the panoply of protocols, hardware and software. . . I have to admit-- needs an understanding of the OSI network architecture.
It makes it easier to grasp the vagaries of the science of networking.

I know you can handle it-- if not feel free to consult a Network Engineer.

Be safe and healthy,

Automation Direct makes a family of "Click" PLCs that are reasonably priced - and more importantly, you can actually buy them (the big guys I find impossiable to deal with). I've had a good experience with the ones with ethernet/RS-485.

Modbus however if you are unfamiliar with it - can take some getting used to.

 

[ptonsparky]

Automation Direct makes a family of "Click" PLCs that are reasonably priced - and more importantly, you can actually buy them (the big guys I find impossiable to deal with). I've had a good experience with the ones with ethernet/RS-485.

Modbus however if you are unfamiliar with it - can take some getting used to.

Rainy here today. I now have a CLICK monitoring the chest freezer temperature and the run times via the compressor line temperatures. Along with an EA9 HMI, I will get a text when it goes above 7 degrees. We moved it to the basement where we will not access it as often.

I've had it controlling the Off/On along with dimming of a 0-10 v LED fixture in the past but that was a borrowed 2x2 troffer for a trial run.

 

[RumRunner]

Automation Direct makes a family of "Click" PLCs that are reasonably priced - and more importantly, you can actually buy them (the big guys I find impossiable to deal with). I've had a good experience with the ones with ethernet/RS-485.

Modbus however if you are unfamiliar with it - can take some getting used to.

“CLICK” PLC uses the same protocol as most Japanese (or other mfg) involved in designing PLCs
Modbus is the protocol used to gain compatibility with other PLC mfg whose units are aimed of being accessed from the internet. Language programming could be using C++.

Designers shy away from using C++ language due to its syntax complexity. Gaming program designers (geeks) love this language especially, since they have a lot of time on their hands.

But electricians/technicians don’t have to worry about this segment . . . all they have to know is how to operate the thing. Just push those buttons and you’re good to go.
Automation Direct is just a distributor---they don’t have engineers to design their product.

 

[SAAPI]

“CLICK” PLC uses the same protocol as most Japanese (or other mfg) involved in designing PLCs
Modbus is the protocol used to gain compatibility with other PLC mfg whose units are aimed of being accessed from the internet. Language programming could be using C++.

Designers shy away from using C++ language due to its syntax complexity. Gaming program designers (geeks) love this language especially, since they have a lot of time on their hands.

But electricians/technicians don’t have to worry about this segment . . . all they have to know is how to operate the thing. Just push those buttons and you’re good to go.
Automation Direct is just a distributor---they don’t have engineers to design their product.

 

[Todd0x1]

Automation Direct is just a distributor---they don’t have engineers to design their product.

Actually automation direct is owned by Koyo, the manufacturer of the PLCs that AD sells. Other products in their lineup are distributed, some exclusive and some not.

 

[RumRunner]

Automation Direct also called PLC Direct is a subsidiary of Koyo.
The Koyo "branch" is the engineering arm while Automation direct is the distribution arm.
Most enquiries and manuals are made by AutomationDirect.

Much like Amazon promoting products by different manufacturers.

The following was lifted from Automationdirect:

Each member of the technical support team works in a technical suite designed with a full array of the company's products used for problem duplication and resolution. The warehouse operation is continually being updated and fine tuned for maximum effeciencies with an order shipping accuracy of 99.98%. Apart from the staff required at the central office, Automationdirect.com is really a "virtual" company, consisting of the "Federation of Companies." The Federation is a group of independently-operated businesses, some of which use Automationdirect.com as the. . . .

 

[paulengr]

Have to disagree with the anti-C stuff. At one time if you wanted to do motion control, it was ALL done in C. Most automated assembly machines had “amplifiers” which were really just beefy DC power supplies for the servo motors converting a +/-10 V control signal into whatever current the motor required. High speed counters provided feedback plus some digital and analog I/O for sensors or to talk to the production line PLCs. Today the motion PLCs have the same motion control code base either embedded into the drive controller or as a separate process or processor running some canned code. We’ve progressed to the point where raw C programming isn’t necessary. But if you came from PC programming it’s easy to do hardware work with C.

C by the way was originally written because programming in assembly is very tedious. C makes the tedious part easy. It was designed for system level things like writing compilers, device drivers, and operating systems. So it’s perfect for writing a PLC or a motion controller or a robot. It’s a great language for say grabbing a bunch of data and doing all the data processing in some complex data analysis like say chemical analysis or vision processing that Cognex won’t do natively, especially when you need performance. In fact that’s one of the key words...when performance is critical and you are pushing hardware to its limits. Data logging temperatures is not really a “C” thing. Plus until recently for hobbyists, C and Unix operating systems were free and the controllers were inexpensive. Toyo has broken this barrier. So these days I wouldn’t bother. You can do string processing in ladder logic but it’s tedious, just as tedious as attempting to do motor control in C.

C++ on the other hand is an abomination. It started out as a preprocessor. You take C++ code which it turned into C code which could be compiled. C++ the language is a bunch of object oriented gobbledegook jammed on top of normal C. Plus it uses a garbage collector so every so often your program just appears to randomly lock up for no reason as the garbage collector does it’s thing. I’ve heard this has gotten better but even if you don’t use C++ features even normal C code compiled with it randomly locks up. Plus mostly C++ just makes programs more buggy and hard to predict performance. Like memory leaks are practically guaranteed because the language almost encourages you to create them. So in other words it is just about the worst choice for control systems, either in the past or present. The only reason it is used heavily for anything is because it’s popular with Microsoft programmers and Apple programmers. Apple even wrote their own (Objective C) and so did Microsoft (C#) trying to escape the fact that C++ is garbage but unwilling to just adopt Java.

So my advice with C++ is don’t do it,

As to Modbys some comments are right, some aren’t. Modbus was started by Modicon. They were always pretty open with it. Modbus is highly compatible with standard PC serial ports other than using RS-485 for performance. The Ethernet variant simply embeds the same serial format into TCP packets. Now they publish it all for free on modbus.org. It is so simple most programmers can write code to use it in a couple hours. So it became sort of a de facto standard where just about every PLC and the more complex sensors can use it. In contrast AB and the ISA crowd decided to make things complex and expensive.

 

[Todd0x1]

I have never programmed a PLC before, I finally made time to play with the Click PLC I had sitting here. I made a program that used a couple inputs to control an output, with one of the inputs triggering a timer. (basic I know but the goal was to get it to do something, didnt need to be complex) I know have an understanding of how these work and I feel like it is a good solution for the lighting control project. Next I need to order a Modbus TCP I/O unit and get the two units communicating.

The lighting will be controlled by 3 idifferent means: Time Clock, Photocell, Manual on/off. For the time clock I was thinking to use a standalone time clock vs trying to do it in the PLC. Intermatic has a 7 day panel mount time clock. Having a more 'normal' time clock would be more user friendly for whoever ends up maintaining this and the PLC can live in the background.

I appreciate everyone's thoughts and comments on this.

 

[SceneryDriver]

I have never programmed a PLC before, I finally made time to play with the Click PLC I had sitting here. I made a program that used a couple inputs to control an output, with one of the inputs triggering a timer. (basic I know but the goal was to get it to do something, didnt need to be complex) I know have an understanding of how these work and I feel like it is a good solution for the lighting control project. Next I need to order a Modbus TCP I/O unit and get the two units communicating.

The lighting will be controlled by 3 idifferent means: Time Clock, Photocell, Manual on/off. For the time clock I was thinking to use a standalone time clock vs trying to do it in the PLC. Intermatic has a 7 day panel mount time clock. Having a more 'normal' time clock would be more user friendly for whoever ends up maintaining this and the PLC can live in the background.

I appreciate everyone's thoughts and comments on this.

Congrats on diving down the programming rabbit hole!

For remote I/O over Ethernet, just buy more Ethernet-enabled Click PLCs. They're as cheap or cheaper than standalone I/O, and you always have the option of putting some local "smarts" in each if you need it.

For the master PLC, I'd actually recommend the BRX line from A.D. They're more expensive, but they have some extremely useful instructions for an application like this. They have a GETTIME instruction that will update the PLC's internal realtime clock when programmed to do so. Most of the Click PLCs have a realtime clock as well, but no automatic way to update them from a remote time server. The Click's RTC accuracy/drift isn't exactly awesome (I know this firsthand), so someone will occasionally have to update it to keep it accurate.

The BRX can be set up as an Ethernet I/P master, and the Clicks as Ethernet I/P slaves, so using them as I/O should be a snap. I don't think you even need to put any code in the Clicks when used as Ethernet I/P slaves, if memory serves.

FInd a photocell with a relay output if you want to interface it to the PLC. You may not have to though - since the PLC has a realtime clock, you can match ON/OFF to civil dusk and dawn throughout the year, and it'll account for DST if you program it to.

Don't use a separate timer. That'll be a pain to maintain and (re)program. "Is the timer doing it, or is it something in the PLC?" If you need a user interface to adjust settings, add a small HMI. AutomationDirect sells the C-more Micro. They're quite reasonable cost-wise, and work well. The programming software is pretty straightforward too. Look at it this way - you can use it as an opportunity to learn more controls programming

https://www.automationdirect.com/adc/shopping/catalog/hmi_(human_machine_interface)/c-more_micro_panels/4_inch_panels_-a-_accessories/ea3-t4cl

SceneryDriver