Choosing the right PLC

[drbitboy]

Ot

OT: This raises the question though: how to troubleshoot ST without the visual feedback; are HMI screens one, or the only, option? Is there some equivalent of adding a debug print statement like I have to sometimes in other languages?

 

[Toine]

There is a wide variety of ways to troubleshoot ST code. How one does this depends among other things on the programming software and the HMI.

Most of the time I use some flavour of CoDeSys. It allows me to see values of variables "live" in code while the development software is online with the PLC. Bear in mind that one typically sees the value at the end of each cycle, which is not necessarily the same all across the piece of ST code. For inspecting a value at a very specific point in code you can use breakpoints. Code execution then halts at that specific point in the program.

I can also display bits and values on an HMI screen or web visualisation. And then there is the option to write values to a log file, which can later be retrieved from the PLC by means of FTP. All have their merits. None is as easy as observing online ladder logic.

I find that experience helps as it develops a feel for the type of issues you may run across and how they would typically mess things up. Coding discipline helps a lot. E.g. strict indentation of code, enough comments, sensible naming of variables.

 

[busarider29]

Local support is very important no doubt, but the buck doesn't stop there. First and foremost, from my experience, the platform has to do what you need it to do now, and in the future. A PLC is not just a PLC and they are not all created equal. For instance, say your current requirements state you only need analog inputs that sample at <= 3khz. Most PLC vendors can meet that requirement. However, what happens when, sometime in the near future, an addition to your line or machine requires an analog sampling frequency of >= 50 khz?? I use that example because I've been there. There's only a select few PLC vendors that can meet that. So keep that in the forefront - The PLC has to do what I need it to do now, plus plenty of headway if I need more performance in the future. To me, performance is #1. I always want to be covered for any future need that might arise. Otherwise, you end up integrating other vendor hardware/software, and that gets expensive, messy, and complicated.

PM me for my one PLC vendor recommendation.

 

[kamenges]

Originally posted by busarider29:

To me, performance is #1. I always want to be covered for any future need that might arise.

I disagree with this in almost all real world applications. This is like saying "I need a small pick-up truck to pull my 1/2 ton trailer but some day I might want to pull a 20 ton trailer so I better buy a Class 8 truck". NOOO!! Size the platform to the application. Don't skimp but don't buy significantly more than you need either. All things being equal performance costs money. Dong this once might not be a big deal. Do it 20 times a year like I would be doing and it becomes a real sum.

Keith

 

[busarider29]

I disagree with this in almost all real world applications. This is like saying "I need a small pick-up truck to pull my 1/2 ton trailer but some day I might want to pull a 20 ton trailer so I better buy a Class 8 truck". NOOO!! Size the platform to the application. Don't skimp but don't buy significantly more than you need either. All things being equal performance costs money. Dong this once might not be a big deal. Do it 20 times a year like I would be doing and it becomes a real sum.

Keith

I think you missed my point. What I'm saying is that if brand-X PLC platform only has analog I/O that samples at most, 3Khz, but brand-Y has analog input cards that can sample as high as 100 khz or less, depending on the requirements, then I'm going to look more at brand-Y. You're right, I'm not going to buy the most expensive highest performing PLC there is so that I'm covered for every possible scenario, but I want a PLC vendor that gives me a lot of options and high performing processors and equally important - a wide variety of I/O. I can purchase low sampling I/O now for my needs, but the vendor also needs to have higher performing I/O available for any future needs I might have. If I have a future special case scenario, such as a measuring application that requires an analog input that samples at >= 100 khz, the vendor can provide it and its easy to add to my existing PLC I/O. Those are the kind of things that I'm looking for in a PLC. Because once I pick that PLC brand, I just married my company to them. And if there's a future scenario where the PLC can't do what you need it to do, well, then you get to explain to your bosses why you picked that brand to begin with.

If I'm looking at a PLC brand to go with, I'm looking way beyond just simple stuff on the surface (local support). I want to know what kind of processors they use. Are they proprietary designed by the PLC vendor or are they a big name processor (AMD, Intel, etc..). Does the PLC support muli-core CPUs? What's the highest sampling frequency of the I/O? What kind of I/O do they have? Any specialty I/O? What Industrial communication protocols do they have support for?? Any of the high speed protocols, like EtherCAT? How about motion, HMI, safety, and the list goes on. If all you care about is "local support", most likely you'll end up in a scenario at some point where you're integrating some other hardware or software from another vendor. And as stated earlier, then it gets expensive, messy, and complicated.