My 2c :
Regarding software stability : I think we see a lot more complaining about Rockwell on this front because it's so prevalent in the anglosphere. I have some experience with Rockwell, Siemens, Schneider and Omron (Sysmac). The platform I had the least trouble with was Sysmac.
With Rockwell, I've had weird crash issues (opening their IO-Link gateway config page inside Studio V31 has 1/3 chance of outright crashing Studio, 1/3 chance of failing to open, the watch window thing, configuring drives randomly crashing, etc), I've had weird corruption issues (AOI prescan routines suddenly failing to execute, PLC not communicating with PanelView requiring a redownload of the PLC program, etc).
Some days it's pretty infuriating, but then again all platforms are in their way. I was writing a program with SoMachine 4.3 SP2, and the FBs I had written incorporated methods. I was gonna write the program in LAD but each time I tried to call a FB method in LAD it wouldn't let me. Had all sorts of exceptions popping out trying to compile (to be clear, unhandled exceptions in SoMachine itself). I ended up settling on SFC with actions in ST (where method calls did work) and transitions in LAD.
Regarding UX and language implementation : Rockwell's ladder editor is IMO bar none the best. I just think they should borrow a page from Sysmac, get rid of the CPT and CMP instructions where you can't see what's going on and allow us to just write ST in the middle of ladder with value monitoring. I think Mitsubishi also allows this. It's a great little feature.
The ST editor is improved but needs more work. I don't like how parameter passing works (can't pass a parameter in the call if it's not set to "required", so in stock TONR for example, you actually can't pass anything in the instruction call, it all has to be outside). Also in general it's very divergent from all other platforms. The syntax should be brought a bit closer to IEC standards.
Finally, also wish you could change the whole colour scheme, not just the logic window. White and blue kills my eyes.
Regarding the beaten horse : I write most of my code in LAD. I'm not particularly in love with LAD (or any PLC language) but in my neck of the woods, clients big enough to have specs usually either require it or Rockwell. It makes sense to use LAD in Rockwell for most things because their other language implementations are worse IMO, so it kinda ends up being LAD by default. I'll use other languages for tasks that make more sense in them if I can. My preference would be for seamless LAD and ST like Sysmac.
I think it's unfortunate that there is this mental blockage with ST at least in NA. I've met loads of maintenance guys who didn't want to be anywhere near it because it's "computer language" and "complex". They could get by no problem with their other machines written in LAD but any time the plant people bought something made in Europe and forgot to/didn't specify LAD in the contract and it arrived in ST, it'd become this incomprehensible arcane thing even if it were mostly typical boolean logic they'd have no problem to troubleshoot in LAD. In this respect, unfortunately it also makes sense to write in LAD.
It's not that they were unable to learn or even didn't want to per se, they were just scared like how some people become scared of math, think they're bad at math and it ends up being a self-fulfilling prophecy. Thing is especially with Rockwell it's not any more complex. It's just differently written. I think this reputation is also because the ST editor pre-V30 was just terrible. If inline value monitoring was on by default I think it'd help tremendously to destroy this block. Also, more and more of the younger generation has at least dabbled into "traditional" computer languages so that will help too.
Now on platforms that implement a lot more of the OOP paradigm, that's a different discussion and it stops even being about language per se IMO. I'm not even sure how much of it is implemented in languages other than ST on these platforms since it tends to be demonstrated in ST only, and the kind of people who'd write OOP-heavy PLC programs would probably be extremely familiar with textual languages. It's more about how deep in the paradigm you dive considering maintenance in NA usually expects to be able to go into PLCs. Cause if personnel is lost with Rockwell ST, they're going to be 6 feet outta the map when they see a SUPER^ method call or FB-heavy OOP design patterns, whether they're in LAD or ST.
Regarding software stability : I think we see a lot more complaining about Rockwell on this front because it's so prevalent in the anglosphere. I have some experience with Rockwell, Siemens, Schneider and Omron (Sysmac). The platform I had the least trouble with was Sysmac.
With Rockwell, I've had weird crash issues (opening their IO-Link gateway config page inside Studio V31 has 1/3 chance of outright crashing Studio, 1/3 chance of failing to open, the watch window thing, configuring drives randomly crashing, etc), I've had weird corruption issues (AOI prescan routines suddenly failing to execute, PLC not communicating with PanelView requiring a redownload of the PLC program, etc).
Some days it's pretty infuriating, but then again all platforms are in their way. I was writing a program with SoMachine 4.3 SP2, and the FBs I had written incorporated methods. I was gonna write the program in LAD but each time I tried to call a FB method in LAD it wouldn't let me. Had all sorts of exceptions popping out trying to compile (to be clear, unhandled exceptions in SoMachine itself). I ended up settling on SFC with actions in ST (where method calls did work) and transitions in LAD.
Regarding UX and language implementation : Rockwell's ladder editor is IMO bar none the best. I just think they should borrow a page from Sysmac, get rid of the CPT and CMP instructions where you can't see what's going on and allow us to just write ST in the middle of ladder with value monitoring. I think Mitsubishi also allows this. It's a great little feature.
The ST editor is improved but needs more work. I don't like how parameter passing works (can't pass a parameter in the call if it's not set to "required", so in stock TONR for example, you actually can't pass anything in the instruction call, it all has to be outside). Also in general it's very divergent from all other platforms. The syntax should be brought a bit closer to IEC standards.
Finally, also wish you could change the whole colour scheme, not just the logic window. White and blue kills my eyes.
Regarding the beaten horse : I write most of my code in LAD. I'm not particularly in love with LAD (or any PLC language) but in my neck of the woods, clients big enough to have specs usually either require it or Rockwell. It makes sense to use LAD in Rockwell for most things because their other language implementations are worse IMO, so it kinda ends up being LAD by default. I'll use other languages for tasks that make more sense in them if I can. My preference would be for seamless LAD and ST like Sysmac.
I think it's unfortunate that there is this mental blockage with ST at least in NA. I've met loads of maintenance guys who didn't want to be anywhere near it because it's "computer language" and "complex". They could get by no problem with their other machines written in LAD but any time the plant people bought something made in Europe and forgot to/didn't specify LAD in the contract and it arrived in ST, it'd become this incomprehensible arcane thing even if it were mostly typical boolean logic they'd have no problem to troubleshoot in LAD. In this respect, unfortunately it also makes sense to write in LAD.
It's not that they were unable to learn or even didn't want to per se, they were just scared like how some people become scared of math, think they're bad at math and it ends up being a self-fulfilling prophecy. Thing is especially with Rockwell it's not any more complex. It's just differently written. I think this reputation is also because the ST editor pre-V30 was just terrible. If inline value monitoring was on by default I think it'd help tremendously to destroy this block. Also, more and more of the younger generation has at least dabbled into "traditional" computer languages so that will help too.
Now on platforms that implement a lot more of the OOP paradigm, that's a different discussion and it stops even being about language per se IMO. I'm not even sure how much of it is implemented in languages other than ST on these platforms since it tends to be demonstrated in ST only, and the kind of people who'd write OOP-heavy PLC programs would probably be extremely familiar with textual languages. It's more about how deep in the paradigm you dive considering maintenance in NA usually expects to be able to go into PLCs. Cause if personnel is lost with Rockwell ST, they're going to be 6 feet outta the map when they see a SUPER^ method call or FB-heavy OOP design patterns, whether they're in LAD or ST.
Last edited:
