Sign in to follow this  
Followers 0
Div_by_zero

embedded c versus PLC (fun topic)

13 posts in this topic

Thought this would be a fun, constructive topic: Age-old debate where I work. One side of the argument is that you can do a lot more with embedded c (or ++). There are almost no limitations. My side (the opposing side) is that while that *may* have been true 10+ years ago, it's really not anymore. I also believe that when working with PLC's, the programmer can focus much more on the MACHINE (i.e. what is being controlled), whereas with embedded c, so much focus must go into the CODE itself and the machine almost becomes an afterthought. Granted, this is a PLC forum and not a c forum so I am guessing there's gong to be a strong bias toward PLC's, but what are some thoughts on this?

Share this post


Link to post
Share on other sites
I agree, also Bubba ( the guy who maintains the equipment at 2:30 am) is not going to understand C.

Share this post


Link to post
Share on other sites
I agree that there's no way Bubba is going to be sticking his head into C source code at 2:30 AM, but at the same time he's not going to be re-writing any ladder logic either.

Share this post


Link to post
Share on other sites
apples and oranges: PLC is hardware, c is programming language

Share this post


Link to post
Share on other sites
Disagree, the ability to view the program is a very helpful troubleshooting aid. Bubbas are usually a lot bigger then programmers. A happy Bubba is a happy programmer.

Share this post


Link to post
Share on other sites
challenge accepted (on "disagree"). so let me repeat: C is a language. PLC is not a language. ... apples and oranges. but i agree that blindfold is not helpful while programming/debugging (and for the record - i never claimed otherwise). btw. the last two statements are contradicting: bubba > programmer bubba = programmer

Share this post


Link to post
Share on other sites
OK I could have worded it "ladder logic" versus c, but really that's not 100% accurate because we now have structured text, function blocks, etc. I figured that most people would have known what I meant anyway. PLC platform versus embedded c platform, that is the comparison being discussed.

Share this post


Link to post
Share on other sites
Sometimes they're the same person. Me Edited by Mickey

Share this post


Link to post
Share on other sites
i believe that once the learning curve is behind, any programmer is thinking in terms of project and task, rather than code or syntax. after working with different products (PLCs, PCs, MCUs, FPGA) and languages, i would say that programming in ladder is by far the easiest (...and i love it). ladder is meant to be intuitive, graphical, easy to use, very limited functionality, very low learning curve and definitely not something one can ever forget. C is much more open, flexible, powerful and works on any platform but learning curve is steeper and if not used regularly, one can quickly get rusty. i can take any guy that was developing 3+ years with embedded C and show him how to install software, configure PLC, program something in ladder and download to target in less than 2 hours (and we can still have coffe and donuts, talk about weather etc). without further assistance, in about a week, he/she will be on pair with guys that did ladder for living for ten years. reverse is impossible (for someone who only programmed ladder to match that using C), at least in same time frame. there is a reason for that. embedded guys usually put lots of effort to make PLCs and ladder robust and friendly. but this is why PLCs cost $$$ and MCUs are usually $2.

Share this post


Link to post
Share on other sites
Hi, Beeing myself a hobbie C programmer and an PLC programmer for feeding purposes I use to prefer from far the PLC structured text programming than the ladder one. First of all because I've never considered ladder programming as beeing algorithme able, it is only about sorting out the result of simple logic equations. But is for sure quickly understandable. The other point is that a ladder routine cannot be considered predictive as it has to be completely evaluated as reverse instructions may occur by the end of the lines (ie : the NOT in siemens S7 reversing the previous evaluation) when a structured text / ASM is predictive by definition. Just to say that the result of A and B is likely to be evaluated twice faster in structured text than in ladder. If the plc software provides its own C-like langage, there would be no point using C, but C is still the lowest level langage available (apart from ASM) and that makes it the most powerful, as long as you know how/what to do. The other advantage of C is the fact that it is now an old langage though still in the TOP 2 most used, and we can consider that compilers on which programmers have been working for 30 years or so can produce an optimized final code. We have a problem with PLC compared to computers, execution time is something we really care about, any langage producing garbage and/or unefficient code is as much CPU ticks lost. Not long ago, on this topic I explained how the Siemens LIST (ASM-like) programming was fast and powerful, though programming needs more skills than ladder : no question about that ! There is one thing I'm certain of, as PLC will become more and more powerful, nothing will change because they will suffer from the Wirth's law for exactly the same reason our computers do. Higher level langage, lazy and/or hurried programmers leading to garbage code and slowing uselessly the UC down as they get faster in execution. Especially as our PLC are not only simple logical testers any-more and can have to handle (more or less) complex algorithms I'm sure most of us have already seen dang complicated equations that could be simply done 10 times faster with at least half the lines. Really, the langage is only a small part of the job, you can use anyone, if you don't know what you're doing, well, the result ain't worth a s*** all the same. Regards.

Share this post


Link to post
Share on other sites
I do not agree with C for industrial control run by a computer generally Computers are not the most secure environment for programming machine control. Even industrially hardened computers are not as secure as a PLC because the darn things have hard drives! I am also not generally in favour of FBs or STL because when you have someone on the phone on the other side of the country and you are trying to explain STL inside an FB to a maintenance guy who only uses the software as a trouble shooting tool occasionally, it just does not compute. Then you have to spend a day or so getting there, 30 minutes work and a day or so to get back home. No thanks. I do not even do floating point maths inside an FB if I can help it - may be a bit more work in ladder but the guy at the other end of the phone can read numbers to me and I can interpret what is happening - STL inside an FB - he would not know where to look. A mate of mine still programs nearly everything he does on a computer in Fortran - any of you program in Fortran? He still reckons it is the most efficient and the smallest code - I do not - never been there. With the facilities available in my favourite brand, I really do not have to get involved with any of the other stuff - there are plenty of ladder functions available. Comms - a different kettle of fish! Also known in Oz as 'black mans magic' - no offence meant - just the Ozzie sense of humour at work.

Share this post


Link to post
Share on other sites
I've done both. Would you care to guess which controllers eventually got removed and replaced by the other? Would you care to guess which one had the nicer HMI and better datalogging? Use the tools that are best suited for the job. The only justification for an embedded controller now is something that is massed produced where low cost is required and the application does not change. That, and government contracts where the justification is reversed and the contractor wants high billability.

Share this post


Link to post
Share on other sites
Hi, For sure I wouldn't waste my time tryin to code a full application with C, and using a computer is even worse, most of the time, a multitask CPU would be doing anything but running your program. At least not any computer with an OS such as windows. As a reminder, the basic question was about limitations. Yes C can do a LOT MORE than a plc can, if it does the same, it will do it faster and more efficiently (depends on the PLC though). But it has to be dedicated to one particuliar task like creating your own electronic with micro-controler. If for any reason you need a task to be perform at high rate, what PLC could probably do it ? You're going to buy some dedicated electronic that will be likely programmed with C... Nonetheless, PLC should ALWAYS keep a low-level langage in their langage set, because PLCs have more and more to do and you don't wanna waste time on easy things that have become complicated because of high level langage. I have here a Logix 5562S that need to manage 6 physical axis and 3 virtuals (Sercos Kinetix 6k) and I expect it to spend its time controlling my axes, not converting gray to binary. I use the gray to bin exemple because it is the classical low level fast thing to do that becomes long and slow on a high level langage. Think about it, what would you do if you were asked to do the math on such a PLC ? Would you loop the bit-to-next bit XOR the way you do it with paper and pencil, like : Binary.15 := Gray.15; for i:=14 to 0 by -1 do Binary.[i] := Binary.[i+1] XOR Gray.[i]; end_for; when it should takes about 6 lines of UC native instructions, all the math in the stack, would take no more than 10 UC clock ticks to be done. This loop, for only one value of I is already slower than that. And why is that ? Only because you don't have the instruction performing a bitwise shift even though it is part of any RISC instruction set ? Say with LIST programmed S7 this conversion is likely to be at least 20 times faster than the loop thing : when one is already back to controlling the axis, the other one is still calculating a ridiculous conversion... For sure, most of the time the loop will do the job all the same, just to say that when it comes to be critical, some PLC just can't do it...for now. I'm not saying PLC are not good at doing thing, be sure I bless Rockwell everyday for having this stuff, (almost) plug'n'play, doing all the maths by itself etc... And I sure don't wanna spend my next 2 years developping in C what just took me 1 month. Div_by_zero said about C : "there are almost no limitation." I wouldn't say "almost", there are NO limitation : If a system can do something, you can have it done with C. I Use to compare things to cars, you can buy a fancy 4x4, good looking, comfortable, automatic shift, GPS, Satellite radio, fridge, cups holder, TV sets and DVD player for the children, A/C, fully equiped : most of the time you might go where a sedan wouldn't, but you sure ain't gonna follow a NIVA where it goes, because it is unconfortable, doesn't have electronic stuff, is ugly, but it was build for one purpose only : go anywhere. At last, TConnolly is just right : "use the tools that are best designed for the job" : and sometimes, embbeded C/C++ is this tool. Edit : I've just seen this topic, the guy thinking he might have a PLC playing tic tac toe. I had not think about it, but here is something PLC just can't do. If you need some decision-making, in most cases you'll need recursivity, even for a very basic min-max algorithm (that is likely to be used for a tic tac toe). And I know not any PLC being able to perform recursive functions. The only option left will be to precalculate (that means you and me) all the configurations possibles and program it. That is something that will take hours to program for a PLC versus 10 mins with C. Obviously, I was never asked by my customers to have a tic-tac-toe or chess playing machine, but decision making will be something done either by a computer or a dedicated chip. Edited by drx

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0