PLC'S and RLL vs PC's

dogleg43

Member
Join Date
Dec 2005
Location
Indiana
Posts
520
An alternative title to this post could be "The more things change the more they stay the same."

There is another thread currently active here right now named: "PLCs are going software? Soft-PLC vs Hard PLC". The attached file that I saved from about 25 years ago is relevant to to this active thread. It may be somewhat dated but I'd be interested in reading some new perspectives on it, especially from younger PLC programmers.

I don't have a dog in this fight as I am now retired, but still interested in the PLC & controls industry.

See attached file.
 
It was a very interesting read indeed. I noticed many people are moving away from 120VAC to 24VDC plc i/o, so maybe in the future, we will have sensors that run better with even less voltage, like 12V or even 5V, so then PLCs will start moving towards that route.

Maybe instead of wiring 16 gauge wire from PLC to sensors, we will have PLCs that can accept M12 connections directly, making installing prox switches into a PLC a whole lot easier. Could you imagine shopping for an input card, and setting your filter to 4-pin or 5-pin, M12 or M8 connections, etc.? I'm sure someone will come up with it soon, if it's not yet already available. Maybe an i/o card that auto-detects and adjusts for voltage somehow, so if someone plugs 120VAC sensor into a 24VDC input, it can autoconfigure itself or something like that. They already have volt meters that can do that, so why not an input card?

I think PLCs will be around for some time, but they will just have more improvements and advancements being added to it.
 
An alternative title to this post could be "The more things change the more they stay the same."

There is another thread currently active here right now named: "PLCs are going software? Soft-PLC vs Hard PLC". The attached file that I saved from about 25 years ago is relevant to to this active thread. It may be somewhat dated but I'd be interested in reading some new perspectives on it, especially from younger PLC programmers.

I don't have a dog in this fight as I am now retired, but still interested in the PLC & controls industry.

See attached file.

The soft PLCs that I have been pitched recommend 'limited' other software installed on the PC to limit compatibility problems.

ALL of the windows-based solutions have issues staying current with windows service patching

The linux-based solutions are much-better behaved but linux does not like unscheduled power loss. Good backups preserve the program. But not the latest data. Data is important.

There are a couple of systems available that are based on actual RTOS implementations. These are moderately interesting ... but only moderately.

Raspberry PI based systems are better at surviving power loss ... but you need to spend some money isolating the IO from the PI. It seems crazy to buy the PI for $50, use open source software for free, and then spend $50 - $100 PER POINT for digital IO and more for decent Analog IO.

It would be nice .. for me .. if you could buy IO from the industry leader in 120VAC Digital IO - whoever that happens to be ... per your criteria of course. And connect it to your present PLC. And have the all of the diagnostics that I would get with my vendor's priorietary IO. Duplicate that for 24V digital, Analog IO (0 - 5V, 4 - 20 mA, et al), RTD multiplexors, weigh scales, flow meters, etc etc etc

If any of the Open source projects looked better, I'd give them a try. But they don't .. at least so far. I see open source having a big negative - no support. If my mill is down and I need help - there is no one to call. Support MATTERS. A forum is good. But phone support and someone who will get on a plane and fly in to assist with weird problems ... is MANDATORY

For context, I've worked with PLCs of various vendors for 30 years. Mostly Rockwell, GE, Modicon .. a bit of Siemens, Mitsubishi, Reliance. First as a consultant, then as an end user.
 
Good article on one's opinion.

Language Difference:
The ladder logic language vs text language is a whole other debate in itself, in which I've been down that rabbit hole a few times. Most PLC vendor's controllers have support for both ladder and structured text languages, so it's almost a moot point now. I would't go with any PLC or IPC vendor that didn't have full support for all 5 of the IEC-61131 languages. IEC-61131 is an international standard, and if X-vendor isn't following it with their line of controller, then they're off my radar. Now, the article makes the same arguments for ladder logic over structured text that every pro-ladder person makes, in that ladder is "easier" to comprehend. Not always true. I've said this so many times but its like talking to a wall with some people - it depends on who you are and what your background is. Just because its "easier" for you, doesn't mean its easier for the next person too. I've been around very bright engineers (not particularly controls/electrical engineers), that for the life of them, they could not pick up ladder logic. But they could write a sophisticated VB program like it was nobody's business. This wasn't just an isolated incident either. I've been witness to this more than a handful of times. Yes, for one that has no PLC programming experience but they have an electrical background, most likely ladder is going to be easier for that person. However, you get an Electrical Engineering graduate that would have had extensive textual programming experience in his/her course work (Matlab, C++, Python, etc), but hardly, if any ladder programming experience (Ladder logic is usually not even introduced in EE curriculum), well, what language (ladder or textual) do you think he/she is going to be more proficient with?? The article shows a rather simplistic ladder example as their way to prove ladder is easier. Do something much more complex than that and you will equally see that ladder can also be more difficult as well. A big bullet point for structured text language over ladder that the article fails to mention is this : text based language is transferable or good for cross platform use. In other words, if I learn textual PLC language (structured text), I can use that skill to program other devices, such as robots, windows based HMI programs, implement machine learning with languages such as Python, etc...as I'll be able to pick up those other text languages rather easily from my structured text background in PLCs. But with ladder logic, it is good for one thing and one thing only - programming a PLC controller. Outside of a PLC, ladder is useless!! Which is just one reason I try to pound it in any controls engineer's head : LEARN STRUCTURED TEXT, and USE IT!!! You'll be grateful for it later. Well, you learn by doing. So do it.

The Hardware Difference Between PLC and PC based system
The article is assuming that we PC based guys are using off-the-shelf personal computers for our controls hardware. Maybe back when the article was written, that was mostly the case. Yes, today you could use a PC you got at Wal-Mart to control your machine, but then again, with enough work, you could probably use a Raspberry Pi too. Now, I wouldn't do either of those nor recommend. There are reputable controls vendors out there that design and manufacture IPC's that are, just like "black box" PLC, made for industrial use and machine control. Now, knowing that, we can now look at the performance differences. I'll use just one of our PC based machines in our shop as an example:

Intel I-7, 2.6 Ghz, 8 cores.
32 GB DDR4 RAM
320 GB M.2 Drive (x2) in RAID 1
2 Display ports
4 Ethernet network ports
4 USB 3.0 ports
Physical size: 5" x 5.2" x 4" (mounts on DIN Rail in control cabinet)

First off, we can see that my CPU speed is pretty fast. Not the fastest, but fast nonetheless and probably faster than most "black box" PLC cpu's out there, unless you're willing to spend $10K+ on the CPU alone for your "black box" PLC. More importantly, is my core count. So what advantage do I have with that you might ask? Well, at least with my particular IPC and controls software, I can split the cores and assign any number of tasks in my PLC project to any CPU core that I choose. I can also assign a particular scan time to each core, down to as short as 50µs scan time per CPU core if I want. In short I have 8 CPUs with selectable scan rates as high as 20 khz each. Huge advantage! Show me a "black box" PLC that can do the same. And mind you, this isn't even a super high end IPC that I've got here. I could spec one out with up to 64 cores if need be! Having this capability alone not only helps me optimize the speed and performance of my machine much better than with the conventional "black box" PLC, but also helps me, in some cases, eliminate the need to integrate 3rd party hardware/software in cases where a "black box" PLC isn't up to the task.

"The PLC is designed to be mounted in an electrical cabinet unattended".
So are today's IPCs! As stated, ours mounts directly in the control cabinet on DIN rail.

Now, because I'm using a PC based PLC here and not a "black box" PLC, I can install my HMI sofware directly on the same hardware where my PLC program resides. Besides the obvious advantage of not needing another piece of hardware, such as an expensive proprietary PanelView, to run my HMI software, I also have the advantage of speed and responsiveness on my HMI. I've noticed a huge difference in communication speed between my PLC program and HMI program simply because they are both installed on the same hardware. It is a very noticeable difference that can easily be seen with the eye. Which brings me to the next advantages of IPC over "black box" - the ability to install 3rd party software directly on my IPC. This allows me to eliminate many of the stand-alone PCs in various places on the production floor that are needed for this or for that. Saves $$ in the cost for those PCs and also the precious space needed to keep them, not to mention managing and networking them all.

"The PLC is very strong in its "Open System" compared to others. The selection of pluggable modules is very large and covers almost any future need"

This mostly depends on the particular PLC vendor. They all have plug in modules but not all of the vendors can claim they can cover almost any future need. This is why when I get the question, "What PLC brand should I go with?". My answer is almost always, "Go with the one that will cover you not just for your needs now, but future needs as well". One of my particular needs is that the IPC (or "black box" PLC) has to be able to acquire noise and vibration signals at >= 100 khz sampling. Standard analog inputs must sample at >= 10 Khz. Not all PLC/IPCs are created equal because not all of them are capable of these requirements. Most, if not all "black box" PLCs that I know of can't do it. So then you're left with integrating, which then gets expensive and complicated.

From my experience on this forum and others and being in the controls world for the past 20 years, it appears to me that most of the anti-PC Control rhetoric comes from the older, more senior crowd. Maybe they had a bad experience with PC 20+ years ago and they never forgot it and were never willing to give it another fair chance. Maybe they are just stuck in their ways and are reluctant to change and try something different? Who knows? But if it's up to me and I have the choice, I'll always pick IPC over "black box" until "black box" can prove to me they are the better, overall solution again.
 
Last edited:
busarider29, you are a one-percenter, just like the guy who needs the $50 PLC with 4 inputs and 2 outputs. Granted, you need what you need and I'm not arguing that point. But 100kHz sampling rates and 50 usec scan times? Well north of 99% of the industrial processes in the world will never come close to that level of performance requirement.

But, you say, I can get that level of performance for the cost of a normal plc. And in a vacuum that is a great point. But if PC-based open systems were that easy to make fly they would have taken over already. No matter how you look at it, PC-based open systems will put more demand on the implementer to make sure everything goes right. For a one-percenter like you, the control requirements are for far out in left field that the effort to implement ANY tool is going to be insignificant relative to the demands of the control task. But for the other 99% of us, something that we can just slap on a panel, plug a couple modules into a backplane and get moving with no system configuration requirements is pretty attractive, especially if you are doing it on different platforms every other time you are doing it.

The inflexibility of the PLC is really its greatest strength in some ways. Yea, there's a whole host of things you can't do but it is pretty hard to get yourself in trouble at the system level as well. Flexibility with responsibility; if I don't want (or need) to take responsibility, then I don't get flexibility.

The whole futureproofing thing seems a little crazy, too, unless you are putting limits on it that you aren't expressing. By "future needs" I assume you mean supporting more of the same stuff you currently support. If not, then you are going full Nostradamus on us. The cheapest plc on the market today can do things that the original Modicon plc could never touch. What were those guys supposed to do to futureproof their system? They were using the best thing available at the time...and it still wasn't enough? So I guess from that standpoint you are saying buy the highest performance PC and I/O system you can get your hands on (just in case)...but you aren't. You already stated you don't buy the most expensive IPC that you can. History has shown me that the majority of machines die with the control system they were born with because that control system was all that was required to get the available performance out of the physical machine when it was built. Even today when we upgrade control systems on existing machines we generally don't get any better performance. The machine simply isn't physically capable of it. So I tend to choose the platform that will support the system I am engineering today and will worry about the platform I need tomorrow (since that is my customer's choice anyway).

In the end, use the tool for the job. I don't need a multi-axis CNC chop saw to cut firewood. I'll use my chainsaw instead. Even if they were the same price, why would I take on the learning curve of figuring out the CNC system when I can just pull the starter cord on my chainsaw and go.

Keith
 
Good article on one's opinion.

Language Difference:
The ladder logic language vs text language is a whole other debate in itself, in which I've been down that rabbit hole a few times. Most PLC vendor's controllers have support for both ladder and structured text languages, so it's almost a moot point now. I would't go with any PLC or IPC vendor that didn't have full support for all 5 of the IEC-61131 languages. IEC-61131 is an international standard, and if X-vendor isn't following it with their line of controller, then they're off my radar. Now, the article makes the same arguments for ladder logic over structured text that every pro-ladder person makes, in that ladder is "easier" to comprehend. Not always true. I've said this so many times but its like talking to a wall with some people - it depends on who you are and what your background is. Just because its "easier" for you, doesn't mean its easier for the next person too. I've been around very bright engineers (not particularly controls/electrical engineers), that for the life of them, they could not pick up ladder logic. But they could write a sophisticated VB program like it was nobody's business. This wasn't just an isolated incident either. I've been witness to this more than a handful of times. Yes, for one that has no PLC programming experience but they have an electrical background, most likely ladder is going to be easier for that person. However, you get an Electrical Engineering graduate that would have had extensive textual programming experience in his/her course work (Matlab, C++, Python, etc), but hardly, if any ladder programming experience (Ladder logic is usually not even introduced in EE curriculum), well, what language (ladder or textual) do you think he/she is going to be more proficient with?? The article shows a rather simplistic ladder example as their way to prove ladder is easier. Do something much more complex than that and you will equally see that ladder can also be more difficult as well. A big bullet point for structured text language over ladder that the article fails to mention is this : text based language is transferable or good for cross platform use. In other words, if I learn textual PLC language (structured text), I can use that skill to program other devices, such as robots, windows based HMI programs, implement machine learning with languages such as Python, etc...as I'll be able to pick up those other text languages rather easily from my structured text background in PLCs. But with ladder logic, it is good for one thing and one thing only - programming a PLC controller. Outside of a PLC, ladder is useless!! Which is just one reason I try to pound it in any controls engineer's head : LEARN STRUCTURED TEXT, and USE IT!!! You'll be grateful for it later. Well, you learn by doing. So do it.

I agree with some points, maybe most of them - learn all of the languages that the platform supports, use the language that fits the task, and ladder is not taught to EEs (I learned FORTRAN first .. ICK ... GOTO LABEL anyone?)

I disagree with some points - Structure text is similar to programming and scripting languages elsewhere, but not the same. In my admittedly limited ST experience, it does not port directly to robots, motion systems et al.

The Hardware Difference Between PLC and PC based system
The article is assuming that we PC based guys are using off-the-shelf personal computers for our controls hardware. Maybe back when the article was written, that was mostly the case. Yes, today you could use a PC you got at Wal-Mart to control your machine, but then again, with enough work, you could probably use a Raspberry Pi too. Now, I wouldn't do either of those nor recommend. There are reputable controls vendors out there that design and manufacture IPC's that are, just like "black box" PLC, made for industrial use and machine control. Now, knowing that, we can now look at the performance differences. I'll use just one of our PC based machines in our shop as an example:

Intel I-7, 2.6 Ghz, 8 cores.
32 GB DDR4 RAM
320 GB M.2 Drive (x2) in RAID 1
2 Display ports
4 Ethernet network ports
4 USB 3.0 ports
Physical size: 5" x 5.2" x 4" (mounts on DIN Rail in control cabinet)

First off, we can see that my CPU speed is pretty fast. Not the fastest, but fast nonetheless and probably faster than most "black box" PLC cpu's out there, unless you're willing to spend $10K+ on the CPU alone for your "black box" PLC. More importantly, is my core count. So what advantage do I have with that you might ask? Well, at least with my particular IPC and controls software, I can split the cores and assign any number of tasks in my PLC project to any CPU core that I choose. I can also assign a particular scan time to each core, down to as short as 50µs scan time per CPU core if I want. In short I have 8 CPUs with selectable scan rates as high as 20 khz each. Huge advantage! Show me a "black box" PLC that can do the same. And mind you, this isn't even a super high end IPC that I've got here. I could spec one out with up to 64 cores if need be! Having this capability alone not only helps me optimize the speed and performance of my machine much better than with the conventional "black box" PLC, but also helps me, in some cases, eliminate the need to integrate 3rd party hardware/software in cases where a "black box" PLC isn't up to the task.

An FPGA can be fast. So are Graphics cards. When used for what they are designed to do. I find this a weak argument on its own though I agree with the basis. It's fast enough for control. 64 cores? It would be a challenge for me to hold any concept requiring 64 parallel cores inside my head. Much less configure the RTOS to do what it needs to do ...

"The PLC is designed to be mounted in an electrical cabinet unattended".
So are today's IPCs! As stated, ours mounts directly in the control cabinet on DIN rail.

Now, because I'm using a PC based PLC here and not a "black box" PLC, I can install my HMI sofware directly on the same hardware where my PLC program resides. Besides the obvious advantage of not needing another piece of hardware, such as an expensive proprietary PanelView, to run my HMI software, I also have the advantage of speed and responsiveness on my HMI. I've noticed a huge difference in communication speed between my PLC program and HMI program simply because they are both installed on the same hardware. It is a very noticeable difference that can easily be seen with the eye. Which brings me to the next advantages of IPC over "black box" - the ability to install 3rd party software directly on my IPC. This allows me to eliminate many of the stand-alone PCs in various places on the production floor that are needed for this or for that. Saves $$ in the cost for those PCs and also the precious space needed to keep them, not to mention managing and networking them all.

Installing an HMI on the same box as the control is not something that I would do. It makes the control system less reliable. Talk to anyone that designs (and debugs) operating systems. User-interface systems have the highest risk for unplanned operation. Because the interact with PEOPLE .. and PEOPLE do things that designers would not thing of doing to a computer in their WORST CASE SCENARIOS.

"The PLC is very strong in its "Open System" compared to others. The selection of pluggable modules is very large and covers almost any future need"

This mostly depends on the particular PLC vendor. They all have plug in modules but not all of the vendors can claim they can cover almost any future need. This is why when I get the question, "What PLC brand should I go with?". My answer is almost always, "Go with the one that will cover you not just for your needs now, but future needs as well". One of my particular needs is that the IPC (or "black box" PLC) has to be able to acquire noise and vibration signals at >= 100 khz sampling. Standard analog inputs must sample at >= 10 Khz. Not all PLC/IPCs are created equal because not all of them are capable of these requirements. Most, if not all "black box" PLCs that I know of can't do it. So then you're left with integrating, which then gets expensive and complicated.

I have never run into your requirements ... sampling at 10s of Khz ... 50 microsecond scan rates ... the only place I can think of that would need it would be power protection, where you are sampling the 60 Hz waveform, and then you'd need synchronized ADCs for 3 phases plus ground fault currents, plus 3 phase voltages. I'm pretty sure you are not doing that, and I would definitely not do that with a PLC!
 
Part II .. I've never run into the max size for a post!

From my experience on this forum and others and being in the controls world for the past 20 years, it appears to me that most of the anti-PC Control rhetoric comes from the older, more senior crowd.

Yup - that's me!

Maybe they had a bad experience with PC 20+ years ago and they never forgot it and were never willing to give it another fair chance.

Tell me what you are using and I will try it. Or at least investigate it ... as I mentioned in a previous post I have a few things that are required .. and support is one of them.

Maybe they are just stuck in their ways and are reluctant to change and try something different? Who knows?

We all are. It's EASIER to stay with what we know. It's FAMILIAR. You don't think you are stuck in your ways?

But if it's up to me and I have the choice, I'll always pick IPC over "black box" until "black box" can prove to me they are the better, overall solution again.

Well said - but I pick 'Black Box' over IPC until IPC can prove they are a better solution. And no salesman, no service company, has come to offer me one. I have not even received an invite to a webinar. Unless you count PLCDirect (I don't) and Ignition (an HMI/Scada system that appears to do control)
 
Do any of these PC based systems permit online programming? That always seemed to be the main difference btw real PLC’s and PC based systems. It’s been my experience that you have to have the ability to make online program changes.
 
Do any of these PC based systems permit online programming? That always seemed to be the main difference btw real PLC’s and PC based systems. It’s been my experience that you have to have the ability to make online program changes.

Hmm ... I thought that online programming changes, as well as online monitoring for troubleshooting ... were included in EVERY modern system - PC based or PLC based.

I would not consider it a control system if you had to edit/compile/download/start up your system again. Reminds me of 'burning an EEPROM'
:eek:!!Flashback!!:eek: ... 15 minutes under the UV lamp to erase it ... 5 minutes to download the new hex file using the EEPROM programmer ...

We have a continous process, so I don't even use Rockwell AOIs, since you have no flexibility. Also why I don't use produced/consumed tags .. shutting down all 12 PLCs at the same time happens once a year. And I've got other stuff that needs to get done besides sharing tags between PLCs!

Stopping the PLC and downloading changes is not an option. So I use subroutines (which are admittedly a bit more primitive - not even local tags!) instead because you can change them on the fly, keep all of the standardized subroutines the same in each PLC, etc etc. Messaging instructions between PLCs for interlocks .. again a bit primitive but they work.

Since I am inviting new and interesting possibilities ... anyone have options on subroutines for motor/valve control and messaging between PLCs?
 
LEARN STRUCTURED TEXT, and USE IT!!!

This is horses for courses. And if something is too "complex" for Ladder, I'd prefer C or Python or Node.js or gawk on a RaspberryPI so I can have at least basic library options and actually do something without having to first find a sort routine or code a red-black tree from scratch. Because ST feels like a cross between COBOL and ZX81 Basic (no :hork: emoji?). Yes, I know that is hyperbole and it's closer to Python in syntax, but the argument for any language is primarily the libraries it brings to the table, and ST is weak if not pathetic on that score, although it does have at least a little over some Ladder implementations there (MicroLogix doesn't have log or trig functions).


And don't forget that Ladder turns some of the maintenance staff into troubleshooters; they are not going to be programmers, but if they had to diagnose a process problem by looking at ST, then I doubt more than one in a hundred could do more than blink.



horses for courses.


... older, more senior crowd. Maybe they ... Maybe they ...

Read some of the detailed answers on this forum from those ancients: they have migrated from contact and coil to PIDs, VFDs and whatever-Net; they recall relevant bits of many UDTs at the drop of a hat; does it really make sense to suggest they are stuck in the mud? Would one of them not jump at the chance to use the "new" tech, if a project that needed it came up? Maybe they just have a finer-tuned filter for what is needed the job done.


Maybe they kept hearing the same tired sales pitch, for decades, that never quite delivered anything useful on 99%, if not 100%, of any projects they knew about, and certainly never enough to justify the investment of time required. In the meantime they continued to produce value to their clients with the stone knives of Ladder and bear skins of black boxes.


"You don't get to be old bein' no fool" - Richard Pryor as Mudbone

Browse the topics in this forum: how many are about coding? Not very many (5%?); the ST vs. Ladder religions are largely irrelevant to the rest.
 
busarider29, you are a one-percenter, just like the guy who needs the $50 PLC with 4 inputs and 2 outputs. Granted, you need what you need and I'm not arguing that point. But 100kHz sampling rates and 50 usec scan times? Well north of 99% of the industrial processes in the world will never come close to that level of performance requirement.

Whether I'm part of the one-percenter or not, that is not the point. The point is, if you can get an IPC that can do the exact same things as a "black box" PLC and a whole bunch more for the same price, or in some cases a lot cheaper, why would you not go with IPC?? Why would you continue to go with "less"?? Familiarity?? Too afraid to change? Too afraid to learn something new and a bit different? Because that's really what it looks like.

Say I've got a process where I'm producing electrical solenoids. It is required that each one of those solenoids have a number of tests done on them before they are to be put in the box, or put into an assembly. These tests are done at one of the last stations on the line. The tests include peak current draw, vibration (m/s^2), frequency of the vibration analysis, peak sound (db), to name just a few of the tests. You need high sampling frequencies and in some cases, very low scan rates to get accurate results of these types of tests. You are not doing these tests with a "black box" PLC. Ain't gonna happen. Now think about all of the manufactured electrical components that you see and use everyday. You don't think these types of tests are done on those too?? Still think I'm a one-percenter?? So....how are all the other manufacturers out there doing these tests on their manufacturing lines if they are using "black-box" PLCs?? Obviously they are integrating or having some other stand-alone device outside of the PLC that does the tests. On one side of our manufacturing facility, we are using the "black box" PLCs. On the other, we're using IPCs. I work on the side with the IPC's.

So, say you come and work here and we even give you the choice of what side of the house you want to work. You want to work on the side with the "black box" PLC. Of course you do! Of course you'll get your trusty AB controller you love so much and are so familiar with, that's true. But get this - you're also going to get National Instruments hardware with LabView programs, Matlab and those programs, and the Sigpod stuff too. Oh, you're not familiar with Labview and Matlab??? Oh well, you better figure it out because your line is down and they are waiting on you. Ohhhh.....so nice over here on the IPC side where everything is under one roof and done in PLC code (kicking back, sipping on my coffee).

Truthfully, we are looking for someone now that is familiar with those things (Matlab, Labview, etc...) since our Control's Engineers over there don't want to touch them. But our Controls Engineers over there on that side are the same guys like you that push so hard for "black box" and refuse to make the jump to IPC. Weird!!! Well, if you don't want to touch LabView, MatLab, etc, then you shouldn't have lobbied so hard for "black box". Now deal with it or find another job. That would be my hard stance on it if I were the manager. But I digress...

But if PC-based open systems were that easy to make fly they would have taken over already. No matter how you look at it, PC-based open systems will put more demand on the implementer to make sure everything goes right.
That is a perception, but that is all it is. The biggest reason PC hasn't take over is simply because in most facilities, they have mostly standardized to either "Black box" PLC, and in a lot of cases, a brand name as well. It's too hard and expensive to change. This is one big reason why all the PLC manufacturers fight so hard to get their product in your door, especially for new facilities. Because they know that once you commit just once, you're very unlikely to jump ship later.

There is another thread just recently posted on here, where there is an article showing the graph of X-vendor (IPC) vs Y-vendor ("black box") in sales. The graph shows it clearly, unless one just wants to claim "fake news" on it. IPC vendor is quickly catching up in sales each and every year over the past 5 years. Whereas "black-box" vendor, in that same time span, has flattened out. Yes, maybe IPC hasn't taken over "yet", but its gaining fast and it didn't have a 30+ year head start either. If you're the "black-box" vendor, you cannot simply ignore those graphs and numbers. You have to do something. So if you're the CEO, what do you propose?
 
Yup, I'm afraid to change. I like the fact that I order a plc, download the firmware, dump a program to it, and it runs for the next 20 years!

If I were doing a system that had a test station as described, I might opt to use an IPC for the test station, but the rest of the conveying, feeding, and packaging systems would be PLC controlled. And I'd be willing to bet the PC based test station would end up being the least reliable piece of equipment.

Anyone who has developed PC based SCADA systems will no doubt chime in about the latest unintentional operating system update that broke their system. I've replaced a few older SCADA PC's lately. VMWare has been a huge plus for that.

The great thing about our old obsolete PLC's is that they are a stable platform that changes at a glacial rate.

Horses for courses as someone previously mentioned.

Cheaper? The cost of hardware (PLC or IPC) is only part of the total price of a major project.

Structured text vs ladder? Introduce an extensively debugged, thoroughly beat up piece of structured text into a ladder environment, then deal with the blowback from folks who have to troubleshoot the system. Doesn't matter if the code is perfect, it will still be blamed. (I've been there; I also use ST often for calculations, looping routines, etc.)

Most of us live at a sort of technological intersection where various engineering disciplines, technicians, electricians, and operators meet.

There's another intersection where IT meets Controls Engineering.

These intersections flow smoothly when everyone understands the technology/speaks the same language. The leading/bleeding edge is counterproductive to that.

Lastly, I don't want to take the 2 in the morning phone call to fix my oh-so-clever leading edge solution because I'm the only one that understands how it works!

Cheers,

Andy
 
Whether I'm part of the one-percenter or not, that is not the point. The point is, if you can get an IPC that can do the exact same things as a "black box" PLC and a whole bunch more for the same price, or in some cases a lot cheaper, why would you not go with IPC?? Why would you continue to go with "less"?? Familiarity?? Too afraid to change? Too afraid to learn something new and a bit different? Because that's really what it looks like.


There is a huge cost associated with changing brands/systems. Not as big for an OEM, maybe, but huge for an end user. This is true for switching between PLC brands as much as changing to a different technology.



You call the PLC solution the "black box", but in my experience, those are the systems an end user can actually touch and troubleshoot, whereas anything PC based is sold locked down and untouchable.



Say I've got a process where I'm producing electrical solenoids. It is required that each one of those solenoids have a number of tests done on them before they are to be put in the box, or put into an assembly. These tests are done at one of the last stations on the line. The tests include peak current draw, vibration (m/s^2), frequency of the vibration analysis, peak sound (db), to name just a few of the tests. You need high sampling frequencies and in some cases, very low scan rates to get accurate results of these types of tests. You are not doing these tests with a "black box" PLC. Ain't gonna happen. Now think about all of the manufactured electrical components that you see and use everyday. You don't think these types of tests are done on those too?? Still think I'm a one-percenter??


There are lots of sensors and IO components that support integration into automation systems, besides a simple digital in or out. Siemens has, as an example, a CSM 1200 vibration monitoring card. It handles all the analysis and reports the results back to the PLC. There are also many energy monitoring systems out there, which could provide peak current draw. I've never looked into sound analysis before, but it's possible the vibration module could do that if you feed in a mic instead of an accelerometer.



I'm not saying it's done within the average PLC system, but it's not like it's fundamentally impossible. It's a similar concept to high speed counter cards in PLCs: you offload the really fast processing to the card, and then it just reports results back to the PLC as needed.



There is another thread just recently posted on here, where there is an article showing the graph of X-vendor (IPC) vs Y-vendor ("black box") in sales. The graph shows it clearly, unless one just wants to claim "fake news" on it. IPC vendor is quickly catching up in sales each and every year over the past 5 years. Whereas "black-box" vendor, in that same time span, has flattened out. Yes, maybe IPC hasn't taken over "yet", but its gaining fast and it didn't have a 30+ year head start either. If you're the "black-box" vendor, you cannot simply ignore those graphs and numbers. You have to do something. So if you're the CEO, what do you propose?

Most of the traditional hard PLC vendors have PC based products. Siemens has had a variety of them for far longer than I've been in the industry. Rockwell does, too (although on the other side of the coin, rumor has it that they sucked until recently).



If I'm the CEO of a PLC company, I'd want to start getting into those markets. Sure enough, that's exactly what they've been doing.
 
although it does have at least a little over some Ladder implementations there (MicroLogix doesn't have log or trig functions)

Sorry Doc- but I've got to jump in here to defend one of my favorite platforms, even though it's not particularly important to the conversation. The ML1400 does indeed have log and trig functions- it's the older MicroLogix series that do not. :)
 

Similar Topics

The past week we received a new piece of equipment from Germany which utilizes siemens controls. Typically in our company we use A.B. controls for...
Replies
4
Views
40
the conveyor can stop because of a safety sensor or safety switch. And also it can stop because of an object jam detector sensor. If the conveyor...
Replies
5
Views
119
Good Day to all of you, this is my first post, i will try to explain as best as possible, english is not my natural language. I am performing an...
Replies
0
Views
29
Hi All, Someone at work has put a PLC system on my desk, that's just been taken off an idle production line. He said "It's an S7 PLC. We don't...
Replies
10
Views
189
I have a project to automate four generator sets. The system will monitor and store the load demand of the factory. Once there's Power outage, the...
Replies
0
Views
55
Back
Top Bottom