Most PLCs that have an event-triggered extension language would have to be
qualified as doing "preemptive multi-tasking". Once off in a module, you
can't service the ladder until the routine returns. Some don't even permit
servicing I/Os _during_ the routines, only setting internal registers that
will be transferred to the hardware once the ladder loop resumes.
Right off the bat I can't think of a single PLC instruction that I can't
duplicate in an Arduino. The key to the whole idea is that you NEVER go
"off in a module" where you can't service the ladder. I linked a program I
wrote for a bulb machine I wrote using a Mitsubishi PLC that operates 16
stations. There isn't any part of the program I wrote that needs any kind
of multi-tasking, even though all 16 stations do their thing at the same
time. It's just a matter do doing one thing at a time, but doing it so fast
that it appears to be done all at once. You simply don't program to make
the processor wait for something to happen.
Here's an example from radio control, if you've ever messed with a somewhat
modern radio control system, with an 8 channel R/C system, you can have 8
servo's connected to the receiver and they will all do what you command them
to do simultaneously. In actuality, the transmitter sends a 4.5 millisecond
sync pulse then a series of 8 pulses (for 8 channels) ranging from 1 to 2
milliseconds. A 1.5 millisecond pulse sends the servo to mid position, a
1ms pulse sends the servo all the way one way, a 2ms pulse sends the servo
all the way the other direction. So in millisecond time, one servo is
controlled at a time, but in human time all servos are controlled at once.
Same thing with the PLC program I wrote for the bulb assembly machine, it
has over 5000 instructions, only 1 instruction is executed at a time but
since all instructions are executed dozens of times per second, it appears
everything is happening at once.
I guess the point I'm trying to get at is that in machine control you can
write a bad programs that use multi-tasking, that has a thousand threads
each holding up execution until the programmed event. Or you can have a
single loop that is written to detect the conditions you are looking for to
process the program. The only time I need interrupts is to do something
like serial communication or track an encoder position. Seems like the more
modern technology I see, the more I'm amazed with the Commodore 64.
Your point is well taken, and anyone experienced in low-level programming
( say interrupt-driven M/L) would be easily able to do what you
You may easily be able to do that in an Arduino programming environment
(in which I presently have insufficient experience), but it's not always
possible in commercially-available PLCs. This conversation was taking
the tack about how you can do things like that with a PLC.
I am from the old-school M/L situation, where I not only wrote the
application, but usually wrote the underlying OS and designed the
hardware. In that scenario, it is "easy" to do simultaneous control of
numerous processes. Just get out the assembler, and DO it!
That's awesome, if you have seen the example programs these days you know
where I'm coming from.
I was taught things like:
If start_button_not_pressed then goto Loop
motor_run_contactor = 1
if stop_button_not_pressed goto Loop2
motor_run_contactor = 0
Things like that completely tie up the processor waiting for a button to be
pressed, and the processor will do nothing else unless there are interrupts
or some sort of multi-tasking operating system to handle it.
What they should be teaching would be more like
If start_button_pressed then motor_run_contactor = 1 (or do other
processing that button press requires) // no holding up processor waiting on
a button to be pushed
if stop_button_pressed then motor_run_contactor = 0
... //here you can do things that need to be done if the button has been
pressed or not.
... // or add other code that can execute every loop
Now to prevent something like the processor being tied up, and not
responding to the buttons, you would use a watchdog timer to reset if a
single iteration of the loop took too long.
I learned to stop programming like the typical examples and start
programming free running loops by both a more experienced programmer and by
learning to program PLC ladder logic.
I can't speak for others but I know learning by bad examples made it more
difficult for me to get a program to handle more than one thing at a time.
A source of value...
I've followed Jack's "Embedded Muse" from its inception--interesting
ideas come through frequently and the tales of experience are worth the
look if for no other reason...
Not directly applicable to PLCs but if you're writing embedded code or
otherwise involved w/ hardware/software interfacing, it's good stuff...
From a distant past, did a lot of work for Remotec on early versions of
what evolved into the Andros Mark V robots. The specific version we
shipped was for man-replacement use in commercial nuclear power plants
and was equipped w/ a manipulator or optional instrumentation package.
It was three Motorola 68k's (two onboard/one operator console) in VME
bus running under CP/M w/ the control software written in Forth...
That was about 10 years prior to this press release when Remotec was
still a relatively new startup...
Dang time goes by...that would have been more like 20 years earlier when
did that work...
Sure, it will. The reason I don't like to do that is most DAQs handle
swings of at least +-5v, and many +-10V. If you use a DAQ with +-10V input
swing, and a load cell amp that only swings +0.5v to +4.5 volts, you've
'wasted' a lot of bits of precision on the DAQ.
If given the choice I code a state machine controlled by global
Boolean variables, which roughly correspond to the relay coils. The
comments that describe its operation come first and replace a
I learned to decipher and then design relay ladder logic shortly
before PLCs came out.
MAN I HEAR YA. If i don't use it, I'll lose it. I keep writing stuff
for my CNC control to try and keep it. It takes me ten times longer
than it used to and I just don't see mistakes in coding like I did
twenty years ago. Still, if I quit trying, I'd just as well fold up.
I almost bought the PLCs and software offered on automation direct.
I'd suggest you try that offer. You'd be real smart to *pay* for a
Fifteen or twenty years ago, AB and a couple of others were the only
decent PLCs around, and everyone used them for everything.
Now there are lots of Pacific Rim companies making dandy, inexpensive
You might investigate TRI-Plc. They are inexpensive "board" solutions
(no fancy plastic cabinet). Despite that basic nature, they're capable,
reliable, and easy to learn. They have hundreds of sample programs in
their downloads area to help you learn.
They're also readily expandable, with extra ports, extra program or data
memory, and a real-time clock. It has an event-triggered BASIC language
extension built-in, and all the programming utilities and simulator come
with it for free. It's also web-enabled. Just plug it into your
network, and you can access and program it from anywhere you have an
It's a cheap way to get into the groove. Then if you want to go to a
'classic' brand, you'll have some experience under your belt.
On 4/26/2012 10:30 AM, Lloyd E. Sponenburgh wrote:
Funny you mention them, I have a 8 I/O relay model kicking around here
somewhere. I had forgotten all about it and I forget exactly what we
got it for...probably some hair-brained idea that got shelved. I'll dig
it out and re-reserech it.
What are phase diagrams? My cousin would make a diagram that would have
square "bumps" on a line that would show if a relay contact or a switch
was on or off. Each contact set would have a separate horizontal line
and somehow he would create the logic by the state of each bump. Is
trhat a phase diagram?
Rockwell has a phase manager, but it was just coming out when I
retired. I played with it a little when one of their software gurus
came out to visit for a couple of days to bounce the concept off me.
Phases are like "Load ingredient A, Load Ingredient B, Stir, Cook,
etc. One I left off that I used more was sequential function chart.
On the projects I worked on I used a lot of function block, some
structured text, a little sfc, and damn little ladder. You can get
most types to do a job, but some are easier for a type of job than
others. For continuous processing (flow meters, pumps, etc) function
block beats ladder hands down. For discrete manufacture(more on-off
type logic), ladder may be the way to go, although I don't like the
stuff and would probably use a different tool. You can find a
downloadable demo for RSLogix 5000 for playing around good for 90
days. It'll give you a good idea of the different types and what they
do, but cost for a working license is what you'd expect for corporate
type projects. They do have cheaper products for smaller jobs. All
of the big control software outfits pretty much conform to S88 now, so
the tools are similar overall, although there are considerable
differences in the details. I sure preferred rockwell to siemens. I'm
guessing there is no german equivalent to "user friendly".
When I first started using Rockwell's software, as a beginner they
reviewed my code under a secrecy agreement. Then they drove over with
the software guru mentioned above. Strange meeting, he sat with me in
my office, showed me some tricks to get everything to work (involving
some vestigial ladder), and the other five people including other
Rockwell folks and our local vendor stood around trying to figure out
what the hell we were talking about. Then they invited me to do a
presentation at one of their user conferences. Fun days.
The guru is a brilliant guy, but they'd moved him to management by the
time I retired.
One thing I'd want is a system that supports indirect addressing. You
name the variables names that make sense and don't worry about where
they're stored. That was not the case in old plc programming, like
plc-5's. Variables were named by their location, which is a real pain
in the ass.
Sorry to run on, you got me going remembering the old days. My job
description was never programmer, but r&d technical leader. I
programmed stuff I designed because I liked it, although it's a poor
career choice. Mostly they hire contract programmers, cheap.
Everything I ever need a machine to do is simple. My target project
controls two hydraulic cylinders. The machine makes solid-fill end
brushes. One cylinder holds the cup in a die, the outer cylinder
inserts a bundle of wire, then the first cylinder goes to high pressure
and pushes the cup further into the die that crimps it. As it is now,
there are 3 hydraulic valves, five limit switches and two palm switches
in series. Eight 3 to 4 pole-double throw relays and a 24VAC
transformer is all that's in the control box. This is fairly simple
with a bit of trickiness. It runs fine now but it seems like a good
project to cut my teeth on while eyeing more complex machines.
Are the two buttons in series to keep the operators 2 hands on the buttons
while the machine is running?
A nice way to do two hand trip control in a PLC.
Have a timer to start timing on these 2 conditions, button 1 is ON and
button 2 is OFF, OR button 1 is OFF and button 2 is ON. The timer may be
something like a half second or so. This timer rung will have a third
condition that holds it on, that is the timer is done and either button 1 or
button 2 is ON.
This prevents the operator from tying down a button and operating from just
1 button. Since the timer seals itself in if either button is ON, both
buttons must be released to reset the start condition.
Ok, the next rung would be if button 1 is ON and button 2 is ON and Timer is
not done, then start the sequence.
If the 2 hand trip control sequence is started the turn on clamp cylinder
If Clamp cylinder is extended to the clamp position, extend the insert wire
If wire insert cylinder extended then turn on high pressure to clamp
Dwell timer for high pressure?
if high pressure step complete then retract cylinders.
if cylinders retracted and buttons released then cycle reset.
The cycle start condition from the buttons will need to be in every rung
that causes motion so that when a button is released the cylinder stops.
Perhaps you could have it so that it remains in cycle unless both buttons
are released. That way if operator needs to he can release either button,
the motion will stop, but the sequence will continue once the operator holds
the other button again. This would sort of be like a jog mode allowing
operator to stop and continue the sequence.
Just some ideas.
Yep, that's the cycle, it can be even simpler without the added safety.
The HP cycle end is a limit switch and the operator can hit a switch
that's in series with it and reset the machine. No need to jog it or
troubleshoot, we get about 1 in 2,500 that something goes wrong. I
certainly like using the timers though!
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.