With the risk of getting off-topic on some of this, I'll comment. This should be the last of it though as I think I've pushed it to the absolute limits.
#1 - Ladder Logic Hate is just plain stupid.
#1A - Ladder Logic reads to the eye easier then STL
#1B - 'Bubba' (if he's allowed access to PLC code can understand it
#1C - It is well suited for 92% of decision making cases.
#1A: Very generalizing but for those here in the US, most would agree. However, try and push that theory to those on the other side of the pond and you'll most likely get laughed at all the way out the door. I once had a colleague that could read and write ST and VB like it was nobody's business, but for the sake of his own life, could not grasp LD. I forced myself to code in ST just for the sake of learning it, plus having a CS background, it is more natural for me since its much like C and VB. Still, I can code in LD just the same. I recommend that anyone, when given the opportunity, code in either LD or ST, whichever one you're not as polished with, that way you can learn something new and/or get better with that language.
#1B: Not always. See 1A above. With that said, if one is persistent enough and practices, can pick it up and understand it.
#1C: Agreed.
#2 - 'Bubba' must understand the PLC Code
#2A - No, he doesn't. HMI's are cheap. Put up a message detailing the problem, point him to where to look to fix it.
#2B - 'Bubba' should NOT have access to PLC code online. This is both a security and safety issue.
#2C - In the case of a problem, 'Bubba' should understand that the PLC program hasn't changed. If something stopped working, it is a REAL WORLD DEVICE that failed, and needs to be fixed. (This applies to operators, supervisors, and management as well).
#2A: Well, if its anything AB PanelView, then no, its not cheap. If its a simple PC monitor, then yes, its cheap. But yes, I agree on messaging detail. What will always get my blood boiling is when a machine/line is down and all the HMI says is something like "Machine Fault" or worse yet, nothing at all and just a flashing red beacon light.
#2B: I can agree with this for sure. Too many fingers in the code and access to it running can lead to bad things, especially when you have no good reliable way of documenting who made the online change and when. I worked at a facility in TN where it was expected for skilled trades (electricians) to go online with the running PLC. They were pretty good and I rarely got called to a line. If I did get called, it was usually something with a robot, not the PLC. But there were times where I saw an Electrician online with a PLC and I thought to myself, "Okay, what the $@#$#@ is he doing?"
#2C: Agreed.
But how many places actually practice this? Everywhere I've been, anytime the machine/line goes down and the cause isn't immediately obvious, everyone outside the controls engineer says, "Oh, it must be a bug in the PLC program"
#3 - My PLC is better then Your plc
#3A - BS. I use PLC's from Rockwell, that perform well. At the same time, I use PLC's from Automation Direct that perform just as well, but the entire rack cost's less then a single AB Processor.
#3B - Many things I have run perfectly fine on SLC-500's, and PLC-5's. And ControlLogix. And Automation Direct. You size your PLC for the requirements of the application.
#3C - Running a primary (cyclic) task in 40 mSec vs. 0.02 mSec makes absolutely zero difference if your IO updates at 50-100mSec.
#3D - "My PLC Does Motion!" It may, but if you really need Motion Control, you need a real Motion Controller (Use Pete Nactway's, they are FREAKING AWESOME). And seriously, today, in 2018, many of what "Used To Be" Motion tasks aren't. Simple followers don't need motion control, as drives now-a-days can be relied on to take a speed (or torque) reference and hold it. Speed Matching the 12 bit analog reference to a nominal 100v/k tachometer days are over.
#3E - If you are building a new plant, pick ANY modern generation PLC, and run with it.
#3F - No matter HOW good your PLC is, for specialized applications, you might still need to turn to specialized systems, like National Instruments for serious, high-speed data acquisition and control.
#3G - You Should Choose (based on needs) to have Common, Non-Proprietary communications capabilities.
#3A and #3B: You're implying a PLC is a PLC and any will do. I just don't buy into that at all, sorry. I've done the performance and capability study comparisons (AB vs Beckhoff), comparing both "high Performance" classes from both vendors. It's been well stated in this thread and one other, so no need to rehash it all in this post. But in short, my conclusions are that if you have any sort of high speed operation, such as possibly this
Coca-Cola factory (?), it is far better suited for a super high performance PLC platform that puts a strong emphasis on speed at all levels (Processor, I/O, communications bus, program, etc). This is where Beckhoff leads the pack, by a very large margin in my opinion. If you're just doing moderate pick-and-place, some conveyors, light curtains, etc, then yeah, any PLC will do. But if that's all you're doing, then why spend the outrageous cost on AB? Just go with something from AutomationDirect. Or spend a bit more on a low end Beckhoff PLC and you'll still get the benefits of their fast I/O and EtherCAT?
#3C: Agreed, and again, this is why you go with Beckhoff, because they have very fast sampling rates for their analog I/O and some screaming fast discrete I/O
(XFC I/O). You're only as fast as you're slowest component, so don't leave out the fast I/O when spec'ing a machine. Of course you'll need a fast comms bus too -
EtherCAT (Beckhoff).
#3D: Eh...I'm not as fluent with Beckhoff's motion library as I wish I were, but we are using strictly their motion library (does come at an extra cost) for motion control on one of our machines. It works just fine and pretty extensive so my guess is that its a fully capable motion controller within TwinCAT. No need to buy dedicated motion control hardware. With that said, yes, I agree that Delta Motion controllers are a fabulous piece of hardware, easy to program, and screaming fast. I integrated an
RMC150 motion controller about 4 years ago in one of our machines for servo valve control and it works great. There's only one drawback to their motion controllers though that I see:
they currently have no support for EtherCAT. I wanted to move register data from the motion controller directly over EtherCAT into the TwinCAT PLC. Couldn't do it that way, which was a real bummer. Anyway, I digress
#3E: See 3A, 3B, and 3C.
#3F: Well, if you're rolling with a "traditional" PLC (AB) and doing specialized applications, then chances are you will have to turn to specialized systems like NI, like we did. If going with Beckhoff, a PC based PLC controls platform, then your chances of having to turn to something else because it can't do it decreases dramatically. We still use NI hardware and Labview, but its not married to our machines anymore. We now just use NI stuff for lab bench, one-off type testing that doesn't need to be integrated into the machine.
Well, that was long and I'm tired and really do need a
I think I've stated my case enough and hopefully didn't **** off the moderators too much with carrying on this thread. Cheers.