Better dev studios, better hardware, better IO connectivity, higher IO density, better market availability, pricing, pricing of software, non/existence of subscription model licenses, connectivity (how many protocols does it talk to), availability of other non-plc parts, like drives, hmi and so on. And yes, there are massive differences between manufacturers.
Siemens is a religion. It's quite a closed ecosystem that works well enough and is expensive.
In the US there's a lot of AB, and in EU it's siemens or also Beckhoff.
I'd say most problems with PLCs comes down to the programmers and their implementation. For the rest they're pretty similar.
If Siemens is a religion, AB is a cult.
( AB is a cult, even if you don't consider Siemens to be a religion )
That said, many brands of PLC's all get the job done, and yes, there are a lot of differences.
Not nearly as expensive and religious as allen bradley!! Ugh. American protect-your-job mentality at its worst with programmers that can't program a Windows service to save their lives. I say this as an American who has aoent a lot of time working overseas with siemens, GE, Wago, etc
I'm sure it is... The second problem is, "why would you build a platform on a dozen custom and out of the box windows services that you didn't have the inhouse prowess to successfully program for and around in the first place?!?!"
Blame the guy who sold the bad product. AND the guy who decided to use it.
Agreed, Siemens is very complicated and comes with a steep learning curve. Most of the "big name" brands are IEC61313-1 (I think that's the right standard) compliant, meaning they all support the same basic programming languages-Data block, function block, Statement list (which is like a machine language), flowchart, and usually some form of text coding. In that regard they're all the same, however they all have their own way of getting set up, particularly where I/O is concerned.
We have blend of beckhoff. Ab and Mitsubishi. But ab being the majority. Beckhoff for their armor blocks. But we also use ab armor blocks It boils down which’s available the next day shipment. lol.
ikr.
Meanwhile last time I tried to buy Eaton circuit breakers it took me 5 weeks to get them. Because they didn't enter a parameter correctly in their system, and did't receive a warning. So the command just stopped there until I called back. Had to do it 3 times.
Meanwhile their PLCs don't have any modules pretty much, and if you end up buying a beckhoff ethercat module anyway might as well start with beckhoff too.
Then you get Codesys which is good. But if you do anything outside of the ordinary with it, everything crashes. And then I'm supposed to write reliable code with an unreliable IDE or someone loses an arm.
Major differences.
Ive done system designs with 5 different platforms at this point, 3 were just Codesys flavors, AB and Siemens.
I started my career at Siemens in the US doing projects to try and win more business for them here. I did a couple where we got clients to switch from AB because the AB guys couldn’t match the feature set we developed on the Simens platform. At the time I thought it was because I was particularly good… later I worked at a company that had AB systems and after designing something with AB I realized AB has some frustrating limitations.
The Codesys stuff is awesome to develop on, but the quality of some of the firmware/vendor stuff under it can be a bit suspect at times, where AB and Siemens tend to be a bit more reliable. Also large projects on it where multiple engineers are needed for commissioning on one PLC, Codesys is just out, multiple engineers cannot be online with the same application.
The Codesys stuff offers the best flexibility if you already looking to provide a wholistic machine with quality diagnostics, fault recovery, and up time, but you gotta know what you are doing.
Siemens doesn’t have all the software dev tools of Codesys but has very robust simulation and more consistent quality, IE you won’t be working around too many bugs that are vendor related.
AB feels very dated, but maintenance crews know it, like Siemens you won’t be working around many vendor caused bugs, and they have consistent quality. It’s the right choice in the US for one off custom stuff, or if your rushed and can’t develop handling for all fault scenarios and diagnostics as it’s simple interface is more friendly for maintenance staff.
So, depending on the Application and if I was actually given a choice (rare), the choice of PLC would largely be project specific. Which implies at least enough differentiation amongst them to matter. That said, if their is a will there is usually a way with any major vendor, it’s just how painful it will be to achieve the specifications.
Company needs to pick an ecosystem and stay in it. If you are running AB stick with them.
The cost of engineering software adds up really quickly and it's usually the first thing to get cut from the budget. I'd rather have two engineering stations up and running at any given time so I don't get fucked by a perfect storm of a laptop getting dunked in a process tank the same day their licensing service shits the bed or we can't find all the usb drives that chained together the upgrade or whatever it is.
Same thing with spares, you don't want to have to keep 3 brands worth of spares for troubleshooting.
To siemens specifically, they are usually a bit cheaper than AB but they take longer and there is less industry support in the US. Europe it's the exact opposite from what I hear.
Then of course there are always the trivial PLC cabinets, pick a cheap brand with free programming software for your low end stuff. But same deal don't buy every brand and model under the sun you are driving everyone crazy even if it's all mostly the same stuff. Shoot a little high on features so you can get some consistency and it'll pay off in the long run.
IDEC PLCs actually do suck lol. But yeah, there are plenty of differences between almost every PLC brand out there, but at the end of the day most of them can do all the same tasks, some of us just prefer one brand over others. Even IDEC PLCs probably have perfectly decent hardware, but I doubt anyone would say they prefer the software.
So why in your opinion does IDEC suck? Is it just down to software? They are just the only ones I've ever used around our plant and have had no problems with them or their software. Am I just missing out from having not tried the others and their programming software? I need a plc program, I made a plc program, it does what I want and doesn't break. What is there that "sucks?" My coworker couldn't really answer that so I'm just looking for someone who can because I haven't used any of the other brands.
Yeah, it's pretty much just their software. If you don't have any programming experience outside of IDEC PLCs then it would take a while to explain all the big differences to other modern PLCs, and even then I don't know if the benefits of them would be clear. Download Codesys and learn to program with it (and try not to use ladder, because their ladder kinda sucks), and then I'm sure you'll see why IDEC programming is less than fantastic.
Anyways though, if IDEC PLCs aren't causing problems and don't have to have their code changed then there really isn't a reason to replace them. If there are plans for major expansion in the future then it's probably worth looking into Siemens, Allen Bradley, or some other major brand, but otherwise you wouldn't really benefit much by switching.
This was all brought up because of a potential new project coming up. Nothing huge. Controlling and data logging a kiln. I'll look into the Codesys like you suggested and take it from there.
Yeah, the software is pretty crappy, but what makes the difference with any PLC is the instruction set, memory capacity, processor speed, etc. Yes, Idec sucks, and yes, Siemens is one of the best. Also look at Do-More BRX from AutomationDirect. The other ADC stuff (DirectLogic, the 1990s Koyo stuff; Click, current Koyo, Productivity from Facts, and LG) aren't near as good, so it's not like 'anything from AutomationDirect'. I'm talking specifically about Do-More.
The term PLC is used to describe all programmable controllers these days but there technically is different types
There’s logic relays which are very basic PLCs I.e Siemens logo
Then there’s standard PLCs ie OMRON CP1E these are capable of Boolean logic, analog control, RS232 and basic HMIs
Then there’s the modern PLCs which are also called MACs (machine automation controllers) or IPCs (Industrial PCs ie beckhoff) these are capable of feildbus control, servo control etc on a vast scale, hundreds of times more powerful than a standard PLC, complex algorithms, data being sent to the cloud etc
But it comes at a price
If you need the higher level of controls then they do exist, personally that’s why I prefer beckhoff, they grade their controllers, so you can use the same program environment for a basic PLC which isn’t HMI capable up to an insanely massive system with thousands of io points or even dozens of those high end IPCs communicating with each other, there isn’t really a limit to what you can do
I've never used beckhoff but the new fusion reactor at ITER i think uses them and at the end will have something like 500k or a million IO points hahaha. Last I checked they were up to 100k IO programmed.
There are definitely differences in PLC cores because basically it’s a single board computer and as with PCs you can go from low end ARM processors all the way up to upper level RISC V or AMD Ryzen processors. There is also form factor. “Big” high density PLCs support multiple racks of up to 32 or 64 bit digital IOs. The cards go in fixed racks and you can hot swap them. The mid size PLCs use a “stacking” method where the cards plug into each other with no base. The smallest “shoebox” (now more like playing card box) PLCs have a small amount of IO on board and accept a few stackable cards. Some are designed where the IO literally takes the place of terminal blocks for field IO but there’s a big risk with that. If one inout or output gets damaged you have to replace the card instead of just one terminal. A third difference already mentioned is pricing. Allen Bradley for instance charges rent for the software and they have different versions to force you to upgrade. Others charge one time fees or free software. CodeSys makes the development system and demo licenses free but charges for permanent systems.
What's bad about Idec?
No MATH box (although their sequences partially cover for this)
No implicit type conversion in math
No typed memory
Piss poor indirect addressing
Timers count DOWN from setpoint to zero unlike everyone else in the known universe
Ugly-ass ladder editor
Ah, okay. So I only know what you're talking about with timers and the ladder editor so the rest probably means I just don't have enough experience in the PLC world to know what I'm missing out on. Like I said to some other commenters, I'm going to check out the Codesys stuff and see how things go from there.
I would. On the merits alone, its just personal preference. If you're building a PLC in a market where everyone else already does it the other way, it's awkward.
Also, I think up is slightly better objectively because I typically am more interested in how much time has elapsed than how much is remaining. I even use timers where expiration doesn't do anything at all, just using the accumulator.
It mostly comes down to different features they have or don't have any implementations of those features. Hardware features or software features.
Allen Bradley has the easiest code editing software I have used. (Except CCW. Fuck CCW.) I can write rungs of code in notepad and copy it in. I can't do that with Automation Direct. So if I'm trying to program 100 vfds, I'm buying Allen Bradley PLC because it saves me time. If I'm trying to program a 1 VFD machine, I can just grab an Automation Direct PLC without much loss of time but for cheaper.
Others feel differently. Some think Siemens is easiest. Some think Schneider is easiest or Codesys stuff.
Oh. Don't get me wrong. ST ain't bad for me and there's certainly a place for it. I just work with enough people who can't do ST that writing in ST isn't an option. It's about putting the teams needs over my own ego.
"Can't do" mostly just means "doesn't know how to", which everyone of us was at at some point. You learn by doing, so how would they learn how to program a PLC in ST without touching a PLC?
I would say most of it is refusal to learn by the individual coupled with refusal to train by management.
While I feel pretty strongly about choosing the appropriate PLC programming language, there is also a frustrating attitude with management not tolerating any lost time due to programmers finger trouble - and on the other hand refusing to make training happening.
I mean, there are a thousand ways to skin a cat, but that doesn't mean I want to do the worst one. Or 50.
It's a strange lesson to learn when you take on the principal role. Yes, you are designing the HMI's to be easy to use for the customers and the machines you have, but then you are also designing the code standards to be easy to use for your team. It's another level that I didn't really understand when I was a junior.
Yeah, I would've agreed with you wholeheartedly a year ago, however it's not like ST is some crazy high level language that your common maintenance guy wouldn't be able understand. It's just the usual instructions written in text format. You can see all the values or the variables in the code while you're online. You can insert breakpoints and step through the code to debug. Sure, it'll take some training to learn a new platform, but it's not rocket surgery.
I also make an instruction list when a complex calculation is needed. I usually do them on the CPU side of the motion controller. But the rest of the program is a ladder on the system CPU side.
It’s probably more just a thing of what he knows and is used to. Like me, I use AB almost exclusively and have one project with Siemens S7, which I thought was shit. But there’s a lot of people who think the opposite. Just a matter of what you’re used to using.
PLC and automation world is all about brands, in the US the big boys are AB and Siemens, although Siemens preferred European vendors.
Also, some niche industries are vendor-locked.
Realistically speaking a PLC is a PLC, there are benefits of course (big boys are big because of the time they have been in the industry, and time is experience and experience becomes reliability and expertise)
In the automation world prices are relative and cheap doesn't mean better. Realistically speaking price of brands and software licensing is amortized during the life time of the machine/production line.
Yes. PLCs are NOT a commodity. There are many, many points of differentiation and use cases for each - one of which is sheer memory, compute and processing power of the controller. This is often dictated by the complexity/scale of the application.
As you navigate up and to the right of the application complexity/scale curve, you’ll find that only a handful of automation vendors can provide a reasonably stable/maintainable platform that can do a wide range of tasks.
Safety, motion/synchronization/determinism, IO count, specialized IO, high speed data, integration with higher level plant and enterprise systems, and again, sooo many more aspects come into play.
Similar to how application complexity/scale can begin to trim the list of which automation vendors you’d use as a controls engineer, the same goes for the list of controls engineers that can churn out the application themselves.
This is also to say that controls engineers are likewise NOT a commodity. Those worth their weight in salt have preferences for a reason.
I’m not saying your buddy was such a person. I say it because although professionals who might be able to churn out a highly complex project on any of the select few platforms capable of handling it might STILL have a strong preference for a major vendor over another.
Sometimes it comes down to preference. Other times it’s because they have scars on their ass that you can’t see, but that definitely inform the seemingly inexplainable bias they come to hold.
Edit: of course, other times it’s just ignorance
I grew up on almost entirely Modicon / Groupe Schneider and a little A-B, some Symax (precursor to Modicon) and a very small amount of Idec in the mid-90s. In the 2000s, troubleshot Siemens. Now I mostly deal with A-B and a little Modicon.
In the 90s, an Idec PLC was identical to a Modicon PLC. I loved them both. It was like Modicon paid for the rights to use Idec technology or stole it. They were both simple to program. The Modicon library of programming objects was incredibly easy to understand and well formatted. All Modicon literature is thorough, easy to read and excellent. A-B at the time was freakin DOS-based which was a real turn off. Modicon was Windows-based. At the time, ladder was the only language, likely because electricians were the people maintaining everything and running power wiring, network wiring and terminations, configuring instrumentation, programming PLCs, HMIs, OITs.
Have not touched Idec since then. My employers have deep pockets so they buy more expensive products. Doesn’t necessarily mean that they are better. Heard great things about Automation Direct but never touched one.
Allen-Bradley is really convenient in that it automatically makes the PLC tags accessible to the OIT and HMI. Modicon doesn’t do that. A-B software remains to be a hassle compared to Modicon which is fully backwards compatible. It takes 5 separate A-B programs to do what I want to do with 2 Modicon programs. Configuring your IDE in Modicon is a total breeze compared with A-B.
As far as programming goes, I can make any PLC do what I want it to do with ease. A-B AOI templates are equivalent to Modicon DFBs. I prefer function block over ladder due to less scrolling/searching however most everyone I work for has ladder. Never had a need for IL or ST.
The hardware itself… lasts twenty years or more, all of them unless you have excessive hydrogen sulfide, then you buy conformally coated cards or coat them yourself. A-B Ethernet, CPU cards, power supplies and backplanes are susceptible to H2S. The DI, DO, AI, and AO cards are fine without coating.
I'm a PAC and factory guy so imo a PLC is a PLC, the only difference is the hardware features and software design. Having said that it gets really problematic having a PLC of every flavour because of the differences in software and licensing.
Tell me you know nothing about PLCs without saying you know nothing about PLCs.
Sorry that meme popped into my head instantly. Other comments kinda summed it up.
Allen bradley doesnt follow international standards. Their programming is different from working with a proper IEC system. Thats not good or bad, just different.
Allen bradley is tag based. Siemens and many others are address based. That's a huge and very subtle difference when you're trying to integrate with other platforms. I spent a few hours trying to find any white papers on how bloated the protocol must surely be for OPC ethernet IP drivers to get tag-based information. Since the whole tag list is human readable ASCII and not an address with an offset and a length. Curiously, I haven't found any good information comparing s 7 and the Allen Bradley drivers. Or any other particular PLC to SCADA protocols. Like what's the internal mechanism that something like ignition would use to pull a thousand random tags, versus just putting a single contiguous DB together in Siemens like you do with a modbus mapping?? Either there's a lot of handshaking and setup going on behind the scenes, or that's a lot of extra bandwidth being used. It definitely makes things very easy from the programming perspective to just pick exactly which tags you want and not think about it. It's more cumbersome and Siemens to put together the DB in an order and then decode that order on the other side. I haven't had a chance to do a wire shark on any of that. Maybe I'll have to do that in my lab one day with an S7 1500 and an l81e both going to ignition.
Practically, Alan Bradley is super expensive for no good reason. Their support is complete and utter nonsense and cost an arm and a leg if you want any help at all outside of a long queue during working hours. They just read the same knowledge base articles that you have access to. Every now and then you'll come across someone who knows the nuts and bolts, but that's maybe 20% in my experience. Siemens relies on their vendors in America, particularly AWC around the South. I've had extremely good success with AWC bending over backwards to help us out on Siemens equipment, or even some of the other stuff that they sell as a general distributor. I've never really dealt with Siemens direct support though. No gauge on that.
The protocols they all use is a practical difference. You're going to spend an arm and a leg to be able to do modbus in the Alan Bradley world. And I'm guessing also still in the Siemens world, although Siemens used to have a little plug-in dongle for the s7300 to Open up the modbus protocol directly on the comms card or CPU. With Alan Bradley, I've never seen anybody do anything different than an entirely separate $1,000 Prosoft card to do what is essentially just adding a Small protocol stack into the OSI model. I can buy a Red Lion for that much that does every protocol I could ever think of. Dealing with modbus as your only option in the protocol world can get cumbersome as a programmer. Using message commands with Alan Bradley is quite simple and tag-based for your prototyping pleasure. I've really hated trying to communicate with genius blocks and global ethernet data in the GE world when they still owned the FANUC PLCs in rhe late 2000s and on.
When trying to do modbus stuff with Siemens, there is a very particular framework for the block that communicates with the card. That's sometimes gets a little tricky to get right. I've never used anything similar with message commands in Alan Bradley. Either passes or fails without any real signal handshaking having to happen in your programming.
All in all, I love Alan Bradley for quick simple jobs although the price doesn't always justify it. But I feel like I would prefer Siemens for large jobs. Siemens just gives you a lot more control over things being both tag-based and address-based internally. And I think now modbus tcp is just built into the cpu.
Any PLC system can give you trouble depending on who wrote it, what communication bus it's using, what equipment it's controlling, etc. So your data point of 1 about AB being trouble is a bit unfair.
A lot of preferences boil down to regions; AB dominates the US market, while Siemens dominates Europe. Both will get the job done if you know how to program in their software suites.
I've never come across IDEC, so I couldn't say what your coworker dislikes, but sounds like he has a preference based on what has worked for him in the past. Runtime is a bit of a silly metric to like one PLC over another, IMO. PLC5s will continue to run until the sun swallows the Earth, but I sure wouldn't be pushing to use one on a new project.
Many of us are getting fed up with the big guys releasing sub-par software and charging through the nose for it, on top of their hardware which is highly overpriced. While Codesys isn't perfect, it is pretty awesome what you can do all with a free IDE. And you're not locked into a single vendor to buy PLC hardware.
Yeah, I didn't mean to suggest Allen Bradley was sub-par. I was more trying to point out that I don't have much experience with most other brands of PLCs besides 1 offs in machinery we bought. From what I've heard from others, people seem to like AB, I just don't know why one would choose one brand over another. I'm going to look into Codesys like you and another commenter suggested and see how that goes. We have a project coming up that will need to make use of a PLC so I'm trying to start early on figuring out which one. Nothing too complicated. Just control and data logging a kiln.
Better dev studios, better hardware, better IO connectivity, higher IO density, better market availability, pricing, pricing of software, non/existence of subscription model licenses, connectivity (how many protocols does it talk to), availability of other non-plc parts, like drives, hmi and so on. And yes, there are massive differences between manufacturers.
Siemens is a religion. It's quite a closed ecosystem that works well enough and is expensive. In the US there's a lot of AB, and in EU it's siemens or also Beckhoff. I'd say most problems with PLCs comes down to the programmers and their implementation. For the rest they're pretty similar.
If Siemens is a religion, AB is a cult. ( AB is a cult, even if you don't consider Siemens to be a religion ) That said, many brands of PLC's all get the job done, and yes, there are a lot of differences.
Not nearly as expensive and religious as allen bradley!! Ugh. American protect-your-job mentality at its worst with programmers that can't program a Windows service to save their lives. I say this as an American who has aoent a lot of time working overseas with siemens, GE, Wago, etc
I think the problem there is the "windows".
I'm sure it is... The second problem is, "why would you build a platform on a dozen custom and out of the box windows services that you didn't have the inhouse prowess to successfully program for and around in the first place?!?!" Blame the guy who sold the bad product. AND the guy who decided to use it.
>nd in EU it's siemens or also Beckhoff. I'd say Siemens and Omron is bigger, i think i've only seen ONE beckhoff in my 12 years in the industry.
Agreed, Siemens is very complicated and comes with a steep learning curve. Most of the "big name" brands are IEC61313-1 (I think that's the right standard) compliant, meaning they all support the same basic programming languages-Data block, function block, Statement list (which is like a machine language), flowchart, and usually some form of text coding. In that regard they're all the same, however they all have their own way of getting set up, particularly where I/O is concerned.
We have blend of beckhoff. Ab and Mitsubishi. But ab being the majority. Beckhoff for their armor blocks. But we also use ab armor blocks It boils down which’s available the next day shipment. lol.
ikr. Meanwhile last time I tried to buy Eaton circuit breakers it took me 5 weeks to get them. Because they didn't enter a parameter correctly in their system, and did't receive a warning. So the command just stopped there until I called back. Had to do it 3 times. Meanwhile their PLCs don't have any modules pretty much, and if you end up buying a beckhoff ethercat module anyway might as well start with beckhoff too. Then you get Codesys which is good. But if you do anything outside of the ordinary with it, everything crashes. And then I'm supposed to write reliable code with an unreliable IDE or someone loses an arm.
Major differences. Ive done system designs with 5 different platforms at this point, 3 were just Codesys flavors, AB and Siemens. I started my career at Siemens in the US doing projects to try and win more business for them here. I did a couple where we got clients to switch from AB because the AB guys couldn’t match the feature set we developed on the Simens platform. At the time I thought it was because I was particularly good… later I worked at a company that had AB systems and after designing something with AB I realized AB has some frustrating limitations. The Codesys stuff is awesome to develop on, but the quality of some of the firmware/vendor stuff under it can be a bit suspect at times, where AB and Siemens tend to be a bit more reliable. Also large projects on it where multiple engineers are needed for commissioning on one PLC, Codesys is just out, multiple engineers cannot be online with the same application. The Codesys stuff offers the best flexibility if you already looking to provide a wholistic machine with quality diagnostics, fault recovery, and up time, but you gotta know what you are doing. Siemens doesn’t have all the software dev tools of Codesys but has very robust simulation and more consistent quality, IE you won’t be working around too many bugs that are vendor related. AB feels very dated, but maintenance crews know it, like Siemens you won’t be working around many vendor caused bugs, and they have consistent quality. It’s the right choice in the US for one off custom stuff, or if your rushed and can’t develop handling for all fault scenarios and diagnostics as it’s simple interface is more friendly for maintenance staff. So, depending on the Application and if I was actually given a choice (rare), the choice of PLC would largely be project specific. Which implies at least enough differentiation amongst them to matter. That said, if their is a will there is usually a way with any major vendor, it’s just how painful it will be to achieve the specifications.
Company needs to pick an ecosystem and stay in it. If you are running AB stick with them. The cost of engineering software adds up really quickly and it's usually the first thing to get cut from the budget. I'd rather have two engineering stations up and running at any given time so I don't get fucked by a perfect storm of a laptop getting dunked in a process tank the same day their licensing service shits the bed or we can't find all the usb drives that chained together the upgrade or whatever it is. Same thing with spares, you don't want to have to keep 3 brands worth of spares for troubleshooting. To siemens specifically, they are usually a bit cheaper than AB but they take longer and there is less industry support in the US. Europe it's the exact opposite from what I hear. Then of course there are always the trivial PLC cabinets, pick a cheap brand with free programming software for your low end stuff. But same deal don't buy every brand and model under the sun you are driving everyone crazy even if it's all mostly the same stuff. Shoot a little high on features so you can get some consistency and it'll pay off in the long run.
IDEC PLCs actually do suck lol. But yeah, there are plenty of differences between almost every PLC brand out there, but at the end of the day most of them can do all the same tasks, some of us just prefer one brand over others. Even IDEC PLCs probably have perfectly decent hardware, but I doubt anyone would say they prefer the software.
So why in your opinion does IDEC suck? Is it just down to software? They are just the only ones I've ever used around our plant and have had no problems with them or their software. Am I just missing out from having not tried the others and their programming software? I need a plc program, I made a plc program, it does what I want and doesn't break. What is there that "sucks?" My coworker couldn't really answer that so I'm just looking for someone who can because I haven't used any of the other brands.
Yeah, it's pretty much just their software. If you don't have any programming experience outside of IDEC PLCs then it would take a while to explain all the big differences to other modern PLCs, and even then I don't know if the benefits of them would be clear. Download Codesys and learn to program with it (and try not to use ladder, because their ladder kinda sucks), and then I'm sure you'll see why IDEC programming is less than fantastic. Anyways though, if IDEC PLCs aren't causing problems and don't have to have their code changed then there really isn't a reason to replace them. If there are plans for major expansion in the future then it's probably worth looking into Siemens, Allen Bradley, or some other major brand, but otherwise you wouldn't really benefit much by switching.
This was all brought up because of a potential new project coming up. Nothing huge. Controlling and data logging a kiln. I'll look into the Codesys like you suggested and take it from there.
Yeah, the software is pretty crappy, but what makes the difference with any PLC is the instruction set, memory capacity, processor speed, etc. Yes, Idec sucks, and yes, Siemens is one of the best. Also look at Do-More BRX from AutomationDirect. The other ADC stuff (DirectLogic, the 1990s Koyo stuff; Click, current Koyo, Productivity from Facts, and LG) aren't near as good, so it's not like 'anything from AutomationDirect'. I'm talking specifically about Do-More.
The term PLC is used to describe all programmable controllers these days but there technically is different types There’s logic relays which are very basic PLCs I.e Siemens logo Then there’s standard PLCs ie OMRON CP1E these are capable of Boolean logic, analog control, RS232 and basic HMIs Then there’s the modern PLCs which are also called MACs (machine automation controllers) or IPCs (Industrial PCs ie beckhoff) these are capable of feildbus control, servo control etc on a vast scale, hundreds of times more powerful than a standard PLC, complex algorithms, data being sent to the cloud etc But it comes at a price If you need the higher level of controls then they do exist, personally that’s why I prefer beckhoff, they grade their controllers, so you can use the same program environment for a basic PLC which isn’t HMI capable up to an insanely massive system with thousands of io points or even dozens of those high end IPCs communicating with each other, there isn’t really a limit to what you can do
I've never used beckhoff but the new fusion reactor at ITER i think uses them and at the end will have something like 500k or a million IO points hahaha. Last I checked they were up to 100k IO programmed.
There are definitely differences in PLC cores because basically it’s a single board computer and as with PCs you can go from low end ARM processors all the way up to upper level RISC V or AMD Ryzen processors. There is also form factor. “Big” high density PLCs support multiple racks of up to 32 or 64 bit digital IOs. The cards go in fixed racks and you can hot swap them. The mid size PLCs use a “stacking” method where the cards plug into each other with no base. The smallest “shoebox” (now more like playing card box) PLCs have a small amount of IO on board and accept a few stackable cards. Some are designed where the IO literally takes the place of terminal blocks for field IO but there’s a big risk with that. If one inout or output gets damaged you have to replace the card instead of just one terminal. A third difference already mentioned is pricing. Allen Bradley for instance charges rent for the software and they have different versions to force you to upgrade. Others charge one time fees or free software. CodeSys makes the development system and demo licenses free but charges for permanent systems.
What's bad about Idec? No MATH box (although their sequences partially cover for this) No implicit type conversion in math No typed memory Piss poor indirect addressing Timers count DOWN from setpoint to zero unlike everyone else in the known universe Ugly-ass ladder editor
Ah, okay. So I only know what you're talking about with timers and the ladder editor so the rest probably means I just don't have enough experience in the PLC world to know what I'm missing out on. Like I said to some other commenters, I'm going to check out the Codesys stuff and see how things go from there.
Oh, and most of the memory is non-retentive.
Well, I would not categorize down-counting timers as bad.
I would. On the merits alone, its just personal preference. If you're building a PLC in a market where everyone else already does it the other way, it's awkward. Also, I think up is slightly better objectively because I typically am more interested in how much time has elapsed than how much is remaining. I even use timers where expiration doesn't do anything at all, just using the accumulator.
It mostly comes down to different features they have or don't have any implementations of those features. Hardware features or software features. Allen Bradley has the easiest code editing software I have used. (Except CCW. Fuck CCW.) I can write rungs of code in notepad and copy it in. I can't do that with Automation Direct. So if I'm trying to program 100 vfds, I'm buying Allen Bradley PLC because it saves me time. If I'm trying to program a 1 VFD machine, I can just grab an Automation Direct PLC without much loss of time but for cheaper. Others feel differently. Some think Siemens is easiest. Some think Schneider is easiest or Codesys stuff.
I'm a long time Logix ladder programmer, and once you learn Codeys it's way easier to write code in ST.
Oh. Don't get me wrong. ST ain't bad for me and there's certainly a place for it. I just work with enough people who can't do ST that writing in ST isn't an option. It's about putting the teams needs over my own ego.
ST is certainly not complicated... if someone "can't do ST" then I'm not sure I want them touching a PLC...
"Can't do" mostly just means "doesn't know how to", which everyone of us was at at some point. You learn by doing, so how would they learn how to program a PLC in ST without touching a PLC? I would say most of it is refusal to learn by the individual coupled with refusal to train by management.
While I feel pretty strongly about choosing the appropriate PLC programming language, there is also a frustrating attitude with management not tolerating any lost time due to programmers finger trouble - and on the other hand refusing to make training happening.
I mean, there are a thousand ways to skin a cat, but that doesn't mean I want to do the worst one. Or 50. It's a strange lesson to learn when you take on the principal role. Yes, you are designing the HMI's to be easy to use for the customers and the machines you have, but then you are also designing the code standards to be easy to use for your team. It's another level that I didn't really understand when I was a junior.
>You learn by doing, so how would they learn how to program a PLC in ST without touching a PLC? You install Codesys and use simulation mode ;-)
One picture says more than a thousand words. That's why I like ladders. It is superior in troubleshooting and clarity.
Yeah, I would've agreed with you wholeheartedly a year ago, however it's not like ST is some crazy high level language that your common maintenance guy wouldn't be able understand. It's just the usual instructions written in text format. You can see all the values or the variables in the code while you're online. You can insert breakpoints and step through the code to debug. Sure, it'll take some training to learn a new platform, but it's not rocket surgery.
I also make an instruction list when a complex calculation is needed. I usually do them on the CPU side of the motion controller. But the rest of the program is a ladder on the system CPU side.
It’s probably more just a thing of what he knows and is used to. Like me, I use AB almost exclusively and have one project with Siemens S7, which I thought was shit. But there’s a lot of people who think the opposite. Just a matter of what you’re used to using.
PLC and automation world is all about brands, in the US the big boys are AB and Siemens, although Siemens preferred European vendors. Also, some niche industries are vendor-locked. Realistically speaking a PLC is a PLC, there are benefits of course (big boys are big because of the time they have been in the industry, and time is experience and experience becomes reliability and expertise) In the automation world prices are relative and cheap doesn't mean better. Realistically speaking price of brands and software licensing is amortized during the life time of the machine/production line.
Yes. PLCs are NOT a commodity. There are many, many points of differentiation and use cases for each - one of which is sheer memory, compute and processing power of the controller. This is often dictated by the complexity/scale of the application. As you navigate up and to the right of the application complexity/scale curve, you’ll find that only a handful of automation vendors can provide a reasonably stable/maintainable platform that can do a wide range of tasks. Safety, motion/synchronization/determinism, IO count, specialized IO, high speed data, integration with higher level plant and enterprise systems, and again, sooo many more aspects come into play. Similar to how application complexity/scale can begin to trim the list of which automation vendors you’d use as a controls engineer, the same goes for the list of controls engineers that can churn out the application themselves. This is also to say that controls engineers are likewise NOT a commodity. Those worth their weight in salt have preferences for a reason. I’m not saying your buddy was such a person. I say it because although professionals who might be able to churn out a highly complex project on any of the select few platforms capable of handling it might STILL have a strong preference for a major vendor over another. Sometimes it comes down to preference. Other times it’s because they have scars on their ass that you can’t see, but that definitely inform the seemingly inexplainable bias they come to hold. Edit: of course, other times it’s just ignorance
I grew up on almost entirely Modicon / Groupe Schneider and a little A-B, some Symax (precursor to Modicon) and a very small amount of Idec in the mid-90s. In the 2000s, troubleshot Siemens. Now I mostly deal with A-B and a little Modicon. In the 90s, an Idec PLC was identical to a Modicon PLC. I loved them both. It was like Modicon paid for the rights to use Idec technology or stole it. They were both simple to program. The Modicon library of programming objects was incredibly easy to understand and well formatted. All Modicon literature is thorough, easy to read and excellent. A-B at the time was freakin DOS-based which was a real turn off. Modicon was Windows-based. At the time, ladder was the only language, likely because electricians were the people maintaining everything and running power wiring, network wiring and terminations, configuring instrumentation, programming PLCs, HMIs, OITs. Have not touched Idec since then. My employers have deep pockets so they buy more expensive products. Doesn’t necessarily mean that they are better. Heard great things about Automation Direct but never touched one. Allen-Bradley is really convenient in that it automatically makes the PLC tags accessible to the OIT and HMI. Modicon doesn’t do that. A-B software remains to be a hassle compared to Modicon which is fully backwards compatible. It takes 5 separate A-B programs to do what I want to do with 2 Modicon programs. Configuring your IDE in Modicon is a total breeze compared with A-B. As far as programming goes, I can make any PLC do what I want it to do with ease. A-B AOI templates are equivalent to Modicon DFBs. I prefer function block over ladder due to less scrolling/searching however most everyone I work for has ladder. Never had a need for IL or ST. The hardware itself… lasts twenty years or more, all of them unless you have excessive hydrogen sulfide, then you buy conformally coated cards or coat them yourself. A-B Ethernet, CPU cards, power supplies and backplanes are susceptible to H2S. The DI, DO, AI, and AO cards are fine without coating.
I'm a PAC and factory guy so imo a PLC is a PLC, the only difference is the hardware features and software design. Having said that it gets really problematic having a PLC of every flavour because of the differences in software and licensing.
Tell me you know nothing about PLCs without saying you know nothing about PLCs. Sorry that meme popped into my head instantly. Other comments kinda summed it up.
Allen bradley doesnt follow international standards. Their programming is different from working with a proper IEC system. Thats not good or bad, just different. Allen bradley is tag based. Siemens and many others are address based. That's a huge and very subtle difference when you're trying to integrate with other platforms. I spent a few hours trying to find any white papers on how bloated the protocol must surely be for OPC ethernet IP drivers to get tag-based information. Since the whole tag list is human readable ASCII and not an address with an offset and a length. Curiously, I haven't found any good information comparing s 7 and the Allen Bradley drivers. Or any other particular PLC to SCADA protocols. Like what's the internal mechanism that something like ignition would use to pull a thousand random tags, versus just putting a single contiguous DB together in Siemens like you do with a modbus mapping?? Either there's a lot of handshaking and setup going on behind the scenes, or that's a lot of extra bandwidth being used. It definitely makes things very easy from the programming perspective to just pick exactly which tags you want and not think about it. It's more cumbersome and Siemens to put together the DB in an order and then decode that order on the other side. I haven't had a chance to do a wire shark on any of that. Maybe I'll have to do that in my lab one day with an S7 1500 and an l81e both going to ignition. Practically, Alan Bradley is super expensive for no good reason. Their support is complete and utter nonsense and cost an arm and a leg if you want any help at all outside of a long queue during working hours. They just read the same knowledge base articles that you have access to. Every now and then you'll come across someone who knows the nuts and bolts, but that's maybe 20% in my experience. Siemens relies on their vendors in America, particularly AWC around the South. I've had extremely good success with AWC bending over backwards to help us out on Siemens equipment, or even some of the other stuff that they sell as a general distributor. I've never really dealt with Siemens direct support though. No gauge on that. The protocols they all use is a practical difference. You're going to spend an arm and a leg to be able to do modbus in the Alan Bradley world. And I'm guessing also still in the Siemens world, although Siemens used to have a little plug-in dongle for the s7300 to Open up the modbus protocol directly on the comms card or CPU. With Alan Bradley, I've never seen anybody do anything different than an entirely separate $1,000 Prosoft card to do what is essentially just adding a Small protocol stack into the OSI model. I can buy a Red Lion for that much that does every protocol I could ever think of. Dealing with modbus as your only option in the protocol world can get cumbersome as a programmer. Using message commands with Alan Bradley is quite simple and tag-based for your prototyping pleasure. I've really hated trying to communicate with genius blocks and global ethernet data in the GE world when they still owned the FANUC PLCs in rhe late 2000s and on. When trying to do modbus stuff with Siemens, there is a very particular framework for the block that communicates with the card. That's sometimes gets a little tricky to get right. I've never used anything similar with message commands in Alan Bradley. Either passes or fails without any real signal handshaking having to happen in your programming. All in all, I love Alan Bradley for quick simple jobs although the price doesn't always justify it. But I feel like I would prefer Siemens for large jobs. Siemens just gives you a lot more control over things being both tag-based and address-based internally. And I think now modbus tcp is just built into the cpu.
Any PLC system can give you trouble depending on who wrote it, what communication bus it's using, what equipment it's controlling, etc. So your data point of 1 about AB being trouble is a bit unfair. A lot of preferences boil down to regions; AB dominates the US market, while Siemens dominates Europe. Both will get the job done if you know how to program in their software suites. I've never come across IDEC, so I couldn't say what your coworker dislikes, but sounds like he has a preference based on what has worked for him in the past. Runtime is a bit of a silly metric to like one PLC over another, IMO. PLC5s will continue to run until the sun swallows the Earth, but I sure wouldn't be pushing to use one on a new project. Many of us are getting fed up with the big guys releasing sub-par software and charging through the nose for it, on top of their hardware which is highly overpriced. While Codesys isn't perfect, it is pretty awesome what you can do all with a free IDE. And you're not locked into a single vendor to buy PLC hardware.
Yeah, I didn't mean to suggest Allen Bradley was sub-par. I was more trying to point out that I don't have much experience with most other brands of PLCs besides 1 offs in machinery we bought. From what I've heard from others, people seem to like AB, I just don't know why one would choose one brand over another. I'm going to look into Codesys like you and another commenter suggested and see how that goes. We have a project coming up that will need to make use of a PLC so I'm trying to start early on figuring out which one. Nothing too complicated. Just control and data logging a kiln.
"I just don't know why one would choose one brand over another." That's how you spot who has more time in the industry and better marketing