Pure C, to do anything significant, relies on the programmer to be intimately familiar with the core system, it's OS, memory management, intelligent use of pointers, (good habits) OR will teach the programmer to rely on non-standard, platform dependant libraries, masses of global's, and functions that are in desperate need of refactoring (bad habits).
C++, with the STL (assuming your compiler supports it) almost forces good habits. Unless you are one of those people that must 'optimize std::string'.
In almost all cases, PLC programming is an entirely different animal. Even with the vast universe of instructions that go beyond the simple boolean algebra that is (ultimately) the foundation of even modern PLC's, the entire construct of PLC's is to execute a sequence of instructions, in (mostly) a linear fashion, to accomplish a specific goal. Inputs are extremely limited, and totally type constrained. The same for outputs.
Memory management really doesn't exist, in a sense, all variables are static. With the current generation, there is a differentiation between local and global scopes, but even that is minor.
Knowing any 'thoughful' programming language will help one to develop and debug a PLC program, but the usual paradigms don't necessarily apply.
The heart and core of even advanced PLC programs is simple boolean algebra. Decisions based on the result of that algebra might cause a call to a much more advanced function, but the advanced function is more like an API call than an actual integral programming construct to PLC logic.
I still find it the best, to do the 'Top Down' approach, with some changes. My first round of creating a PLC program is always to break the overall task (machine) down into discrete units, each of which could theoretically operate independent of the others.
Then, even before writing logic code rung 1, I try to decide the best method of organizing the data that I'll have to deal with for each unit. Ideally, I'll come up with either a User Defined Data Structure (UDT for Logix5000, DB for S5/S7, something else for other PLC's, word-boundry mapping on fixed file systems, etc) first. Even if there are memory locations reserved for a function the unit doesn't have (not every motor has a brake, for example, but every unit's data structure can handle engaging a brake, releasing it, and doing both in an automatic or manual mode).
Once the data structures are defined, the actual program logic seems almost trivial by comparison.
Hrm.
Maybe it's a lot like C after all
Alaric said:
Learning C will either cause you to develop some bad habits, or it will help you develop some good habits,