BigBudBalls
Well-Known Member
Well as the saying goes, "if it has tits or gears, its gonna give you trouble"
If an I or O fail, is because of poor design on *your* part 99.9% of the time.
The PLC is a MUCH more reliable solution over a ground up roll your own. And far better then a PC based system. ( unless windows and its programs never crash. same for linux or other fits-all-do-all OS) A crashed program/OS is no better then a stuck I/O.
AB? I'd never use a AB brick PLC. Too pricey for what you get. AutomationDirect gives way more bang for the buck. DL06 is nice and can add in a ethernet module.
For AB, I start with 5/03 and a rack.
I'm also perfectly fine in my ability to program a PLC and safety interlocks.
As to the flood, thats a poor design. Yes a stuck valve caused the overflow, but where was the safety alarm when the water hit the floor?
Or the flow meter seeing a flow for 12 hours?
(and what about a simple MODbus? No killer software)
If an I or O fail, is because of poor design on *your* part 99.9% of the time.
The PLC is a MUCH more reliable solution over a ground up roll your own. And far better then a PC based system. ( unless windows and its programs never crash. same for linux or other fits-all-do-all OS) A crashed program/OS is no better then a stuck I/O.
AB? I'd never use a AB brick PLC. Too pricey for what you get. AutomationDirect gives way more bang for the buck. DL06 is nice and can add in a ethernet module.
For AB, I start with 5/03 and a rack.
I'm also perfectly fine in my ability to program a PLC and safety interlocks.
As to the flood, thats a poor design. Yes a stuck valve caused the overflow, but where was the safety alarm when the water hit the floor?
Or the flow meter seeing a flow for 12 hours?
(and what about a simple MODbus? No killer software)
ha until you have an input or output fail when you aren't there. I programmed a tank filling automation sequence where I worked, and it worked great for the application. After I left that job I was talking to a co-worker from that job about something else, and during the conversation he told be that the valve that I was using to allow the water to enter the tank had stuck (mechanically) open and they came into a flood the next morning.
That is something to consider when implementing a PLC. Imagine a mechanical component failing. Depending on what that component is, and your faith in your programming and equipment i.e. your ability to react to the failure, you could take out your grow, your grow room, or worse. Especially if you are a novice programmer I wouldn't do it. Taking NO/NC contact and energizing a coil is a piece of cake. Having the knowledge to program safety circuits takes some experience.
As far as getting information to a web browser, I'm not real familiar with picos, but most lower end AB does not have ethernet, but in some cases you could tie an AIC module to the PLC and get ethernet through that. The issue becomes transferring the WORD information out of the PLC and then either using some intensive VB code to create a front end for it, or get something like Wonderware and create a GUI from that. Then the PC running Wonderware could have a second eth card installed going to the web and you could just RDP to the PC from remote locations, and control/monitor that way. At any rate quite elborate. May be good for someone growing huge amounts of weed, and wanting to keep clear of the grow site, but still have the process completed. But if you just have a small grow going then I would think money wise and effort it's not worth it. How ever you proceed good luck![]()