Micro800 program structure

[CM-MercSol]

Hello all,
Just to give you an idea of my background, I'm new to the PLC world with a background in IT and currently pursuing my MSEE. I have supported controls engineers on and off for the past 5 years, so I'm aware of the field but not all the specifics.
Now I'm starting to do controls work using the AB Micro800 series (specifically the 820) and would like to hear some opinions on program structure.
I know that CCW subprograms listed under a device are worked through sequentially and cannot be called.
What are y'alls thoughts/tips/warnings on using user defined functions/user defined function blocks to create a structure akin to a program that utilizes subroutines? From what I can tell, in regards to using CCW, it's either use UDF/UDFB or orchestrate the process sequence with start/stop bits or flags.
It has been a bit confusing trying to use the latter of these two options since I come from the school of C-style programming.
I'm tempted to use ST but I'm trying to learn Ladder decently well since that's what I see used in my area.
Any insight on how others structure medium complexity process automation in CCW would be appreciated.
Thanks!

 

[drbitboy]

@CM-MercSol: Welcome to the forum.

To answer the basic question, I think you have grasped the fundamentals: the subprograms give you little control about when each is called*; UDF/UTFB are more akin to classes and OOP.

Also, somewhere in the Siemens website there is a document about how to structure a PLC program in the Siemens TIA Portal environment, and I think some of that could apply to CCW, even though CCW is like Fisher-Price compared to TIA (and TIA is like a camel i.e. a horse designed by committee).

* I think you can put a RETurn instruction at the beginning to skip executing a subprogram's rungs and instructions

... come from the school of C-style programming.

Maybe you are already there, but the primary issue is dropping the mindset that focuses on operators and operands composing statements, statements composing routines, and main(int argc, char** argv) as the conductor orchestrating which routines to call.

I know someone (my brother, not me, but a ChemEng like, and smarter than, me) with many successful decades of experience with PLCs working for a Fortune 500 company (and then some years with an integrator that still tries to get him to work during his retirement), who spent years trying to get me to grok PLCs by sketching out a Start/Stop Circuit pattern in latter logic at some point during every family vacation. I asked him what PLC programming was about. He looked up at the sky for about two seconds, and then said "Time."

Bottom line: the primary concept in PLCs is time, and the scan cycle is the clock. If you don't already know what the scan cycle is, don't do anything else until you do (cf. here).

PLCs are more akin to GAWK/AWK, if you are familiar with that filter; another analogy would be an event loop (Windows or X-windows), if you are familiar with that framework, although PLCs implement a built-in time-driven polled loop instead of an event-drive interrupt loop. The point is that for a PLC you only have to program** the equivalent of the initialization and the event handlers.

** Connecting and configuring the physical I/O, networking, cabling, is a whole 'ther thing.

Most C*** programs I, and probably you, have written are approximately 49.5% opening, reading and parsing input, 1% (often but one line) executing the fundamental purpose of the program, and 49.5% formatting and writing the output. In a PLC, that 99% I/O code is built-in and you only have to code the remaining 1%, but that 1% is will be run from start to finish again and again, continuously over time, as the inputs change and outputs are changed, and each time it is run it must be able to respond correctly to essentially any possible combination of input and output states.

So PLC program structure is less about what various elements you use and how you structure those elements, and more about when the elements are evaluated and/or executed. Once you think about the when, the what and the how will usually become obvious.

*** and C++ and C# Python and Perl and Fortran etc.

Once you grok the scan cycle and the fundamental time-based nature of PLCs, the rest of learning PLC programming** is no more than syntax, vocabulary and patterns; if you learned C, that should be a doddle.

 

[CM-MercSol]

Thanks for the reply.
I am very lucky that my formal training has revolved around real time programming, so that mindset was obliterated a long time ago Just trying to get some suggestions on the CCW way, which looks like you kind of blaze your own trail on this controller

 

[parky]

Traditionally, the PLC was to replace hard wired relays hence programmable logic controller, rather than have to re-wire & update drawings everytime a change was made the "RELAY LOGIC" was programmable, in general this was done where the development environment displayed ladder logic but the code loaded into the plc was just a bunch of hex codes where a simple interpreter took these codes & ran the logic. Traditionally a PLC before the program scan update the input image (The real Inputs) and store it in an image of bits, the main logic program wouls the sequentially go through the written code & at the end of scan update the real outputs.
Things have changed, there are now interrupts i.e. if an input changes while scanning the main program it is interrupted, processes the input (runs probably some logic outside the main code) then returns to the main program, there can be many interrupts like timed, coms etc. now nearly all plc's use a structered way of running programs i.e. the main sequence can run your code either sequentially or a block of code can be called with a call if required, the inclusion of standard functions/blocks either in-built, or roll your own has made the PLC's a very versatile piece of kit.
So you can program it in a way depending on the requirements i.e. a straitforward scan i.e. top to bottom or like many other languages jump around code, respond very quickly to real inputs, update outputs instantly, powerful maths, the advantages are that without the overhead of an operating system that has to respond to many different programs it is fast, can do on-line changes (Within limits) without stopping the process.
There are a number of ways to represent the logic or processes i.e. traditional ladder ideal for monitoring on-line with graphical symbols that show the status, function block diagram (FBD) that looks more like the traditional digital blocks i.e. AND/OR/NOR etc. & more recently structured text (ST) that is loosely based on Pascal.
Hope this helps.