Ladder Logic, Line-by-Line, Flowcharting

[recondaddy]

Hello everybody!!

Since my last post, I've started a new job as a manufacturing controls engineer (plant job). I spent the previous four years working for a systems integrator (Rockwell Solutions Provider). As such, my only experience was with Rockwell products and ladder logic.

Since I've taken this new position, I'm suddenly in charge of maintaining and improving everything from PIC-controlled machines (line-by-line programming), distributed motor controllers (line-by-line programming) Steeplechase-controlled machines (flowchart programming), and ladder logic. It's been a helluva lot of fun learning the vast array of different technologies.

It's also been educational, now that I've been exposed to other programming methods, to see the subtleties between the various methods. For those of you with experience in more than just ladder logic, I'd like your insights, as well.

Looking at the way ladder logic executes, it is scan-based, and the cycle for solving logic is performed by reading all the inputs, processing user logic (solve the rungs), and then writing the outputs and updating registers.

So, it has the ability to deal with multiple machine processes in a parallel fashion (all at one time). Is there really any way that such behavior can be mimicked in line-by-line programming (PIC microcontrollers) or in flowchart programming? Or, are these methods strictly for use in step-by-step applications?

I can see where seemingly parallel operation could be achieved by distributing several programs throughout separate controllers on the machine, but can PLC behavior be implemented with only one controller?

Thanks!!

P.S. Is there another term for the type of programming we do in PICs besides "line-by-line"?

Edited to add:

I guess the better question to ask is, "Can simultaneous control of multiple machine processes be achieved with a single line-by-line or flowchart program?"

[TConnolly]

Here is how I have done it in C

/*define subroutines*/
int state0(), state1(), state2(), state3(), state4(), state5(), state6(), state7(), state8(), state9();

/*array of pointers to state subroutines - the compiler will
assign the pointers to the functions at compile time*/
int (*statefunc[])() = {
state0, state1, state2, state3, state4, state5, state6, state7, state8, state9
};


main() {
.
.
state=0;
LOOP:
  .
  .
  .
  state = statefunc[state]();
  .
  .
  .
goto LOOP; /*most efficient loop for infinite loop
}

A pointer to each state function is created in the statefunc array at compile time. The correct function for the current state is called via pointer in the loop. The functions don't require any internal looping (in fact they shouldn't have any), and each returns the state for the next loop.

I've used the same general construct several times on embedded controls - its versatile and easy to expand. However I've been strictly PLCs for well over a decade.

I did one "Think And Do" system in 2002. I didn't really care for it as a platform.

[recondaddy]

That's some good stuff, Alaric.

I guess the first issue that sticks out in my mind, though, is the use of timers, for example. In line-by-line (PIC) programming or flowchart programming, we use delay statements in order to pause execution of the program before moving on to the next line. So, no other logic can be executed until that "timer" has expired.

In ladder logic, a timer can be enabled, and while the timer is running, the PLC continues its scan and is free to execute other logic. I can't really see how this function could be accomplished in line-by-line programming, but then I don't have a great deal of advanced experience with it.

Perhaps incrementing an integer for each scan that an input condition is true (enabling the "timer") until a constant is reached would accomplish this purpose. The issue that jumps out at me, though, is the potential variation in scan times as the program changes or grows. While incrementing an integer, every scan, it might take 1ms to reach 1,000 scans, today, but after making changes to the program, it might take 1.2 ms, tomorrow. That could really mess with your timing issues.

Don't get me wrong -- I'm becoming more and more a fan of ladder logic, especially as I see the seeming limitations of other types of programming. I just really want to have as strong of an understanding of these other types as I do with RLL.

[James Mcquade]

The way you explained the scan is correct for most plc's.
Note that i said most. Modicon solves in a different manner.
the program is solved by going top to bottom and left to right. So short rungs gets solved quicker than long rungs.
it also complicates the way you write programs.

ab has a plc simulator program if i interpet your question correctly.

regards,
james

[bernie_carlton]

When I did this in 'C' I used a fixed scan repetition. One of the functions was to update all enabled timers. Then in the individual states the code would enable the timer with a certain preset then, on each pass, just look for the completion bit to be set. They were fairly simplistic timers with the preset increment to be 1 scan time.

Like Alaric's example we used states for each machine section. We had multimple sections so we called the state processing for each section.

WARNING - Reminiscing - skip if you don't care about old **** stuff.

This was an old STD Bus 'XT' compatible CPU. We tapped off an unused timer in the main timer chip and triggered the unused (in that implementation) Non Maskable Interrupt. The NMI triggered a saving of the current of DOS (remember that?) state, created a stack, called the machine processing, then returned control back to DOS. As there was no rotating media there was no problem and DOS had no idea it had been interrupted. The Pro-Log engineers thought that we had to have a seperate CPU for the machine processing but we didn't. Of course were were too tricky for our own good and when they went to '286 systems the unused timer and NMI were both being used so we had no upgrade path. But it was fun while it lasted.

[TConnolly]

The controller I was was using had a library function int timer() which would return an unsigned long from the system timer for the number of milliseconds since it had been reset. Because I was resetting the system time every time the state returned to state 0 I didn't worry about rollover on the system timer but handling it wouldn't have been difficult.

For individual timers I created a struct which contained the elements .mark, .elapsed_time, and .timer_preset. For timing I used two functions.

void init_timer(*tmr, preset) { /*initializes a timer*/
*tmr.mark = timer();
*tmr.preset = *tmr.mark + preset;
}


int query_timer(*tmr) { /*checkes if a timer period has elapsed*/
return timer() > *tmr.preset ? 1 : 0;
}

init_timer would only be called just once; query_timer could be called as frequently as needed to see if the required time had elapsed without holding up the rest of the loop.

Its a common misconception to think of RLL as a primitive low level programming language - but when you try and do some of the things that RLL does so easily with C (or any other language) then you start to appreciate the behind the scenes things that RLL does for you.

[TConnolly]

My reminiscing....

Originally Posted by bernie_carlton

Of course were were too tricky for our own good and when they went to '286 systems the unused timer and NMI were both being used so we had no upgrade path. But it was fun while it lasted.

One of the first tasks I tackled with my current employer was to replace a home grown data logger kludged from a 4.7mHZ XT running a program someone wrote in QBASIC that polled four controllers through the serial ports and then wrote the data to the local HD. They had once tried to replace it with a 286 but the original programmer used for/next counting loops and trial and error to work out the timing delays for communication and the 286 ran the delay loops so fast the system wouldn't work. So for years they scabbed together old parts and somehow kept that thing running. It took an afternoon to bang out a Turbo-C (remember that?) program to replace it and run on a then modern 486. The system is long gone now.

[bernie_carlton]

When I started they were doing machine monitoring and display using a Commodore 64.

[Steve Bailey]

When I started they were doing machine monitoring and display using a Commodore 64.

Back around 1988 the division of the corporation I was working for had a sudden surge of orders. We imported another engineer from a different division to come in and help us work through the backlog. On his first day, we proudly showed him the workstation we'd set up for. A Commodore 64 with a 12 inch black & White TV for a monitor and a tape drive for backup and data storage. The biggest perk was that he could watch reruns of Hogan's Heroes during breaks.

[Gerry M]

Glad to see your having fun. It is nice to work on a variety of systems.

The flowchart style should have a built in parallel equivalent (this parallel operation usually waits for each parallel leg to finish before continuing). Or, use decision blocks to execute the different subroutines (equivalent to a case or switch statement).

I know for me, the biggest difference with flowchart vs. ladder was handling the bits. In flowchart you either turn the outputs off or on in each flowchart block. So each instruction is really equivalent to a Set or Reset in ladder. This required a little bit different mindset than ladder. Ladder is better for this.

Overall I prefer the flowchart slightly better, only because it has a natural flow to it, so you can find where the program is operating quicker than ladder. aka. troubleshooting was always easier and faster especially when someone else wrote the code.

Anytime I wrote logic in a C or vb app. I used very few timers. That is a definite strength of ladder over PC style code.

[Doug-P]

Originally Posted by recondaddy

Looking at the way ladder logic executes, it is scan-based, and the cycle for solving logic is performed by reading all the inputs, processing user logic (solve the rungs), and then writing the outputs and updating registers.

The usual A-B diagram shows input, processing, output, housekeeping. There is no separate phase called 'updating registers'. Updating of the data table happens all along during the program scan. That is, at that instant just before the output image table update occurs the entire data table is fixed until the start of the next input image table/program scan.

Of course, an asynchronous I/O scan, as in Contrologix, upsets this neat little scenario.