From flowchart to ladder

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 tutor.

Karl

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!

You can get the controller that you choose and write the program for it and start learning and testing.

You can parallel all the inputs and outputs with memory bits.

After your control program, write some rungs that simulate the machine operation.

Such as: If Cylinder_Extend_Valve start ~3 second timer, when timer done turn on Cylinder_Extended_switch. That way you can "press the start button" in simulation and see that the entire sequence works, before ever touching a wire on the machine. If you have spare buttons you could even wire in your

The difficulty I had in getting into ladder logic from other programming is you have to program the sequence by knowing all rungs are scanning all the time and the sequence is controlled by conditions like step 1 done enables step 2, step 2 done enables step 3...

RogerN

But unlike hardwired relays, executes sequentially, just over and over. So only define each output once, or last definition always wins. Also, write rungs as series for AND conditions (inputs) and parallel for OR conditions, just like wiring relays.

couple of local vendors that of

There are a few local vendors that offer training on their products, do you have any preferences like AB or such?

Tom Gardner fired this volley in news:LrmdnQNQ3fAexQTSnZ2dnUVZ snipped-for-privacy@giganews.com:

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 PLCs.

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 internet connection.

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.

Have you looked at at Aurdino G-code software?

The Aurdino family has a lot of boards to chose from, and there is at least one website that shows you how to convert one of the super cheap Aurdino proggrams into a controller by cutting a few traces, and adding a few jumpers. Those boards are under $10, and sometimes under $5.

'USBASP' or 'USBISP'. I have the articles saved on a backup drive, but I can find the links or email them to you.

"Michael A. Terrell" fired this volley in news:9Nadna5eMbHABQTSnZ2dnUVZ snipped-for-privacy@earthlink.com:

No! Tell me more!

Lloyd

I'll have to look for the websites again, but I was looking for 'Aurdnio+CNC' when I stumbled across a reference to it.

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.

I'm gradually working toward trying to make a library of functions to make it easier to write PLC type programs in an Arduino. This will allow the Arduino to control several things at once instead of doing one thing at a time. I think the correct name for it is non-preemptive multitasking. The loop runs through continuously as fast as it can, like PLC scans, and conditions control the sequence. So far my biggest "PLC like" addition is a time on delay. I also made a counter function using the same data structure type as the counter. Anyway the timer is a single function that can be called multiple times using a different timer data for each event I'm using a time delay for. If I want to read a sensor every 0.1 seconds, read another sensor every 5 seconds, and update the display every half second, no problem.

I got my load cell scale working pretty good so far but still have several things to add. For one l only have it displaying in decimal pounds, I want to add units later. I'm wanting to be able to plug in different load cells to this scale display depending on what I'm wanting to weigh. Once I get a load cell set up and calibrated, I want to be able to name that load cell data structure an appropriate name and save to eeprom. Then if I change scales I should be able select the load cell data name from the display and load the relevant calibration data and is should be ready to go.

RogerN

"RogerN" fired this volley in news:j4udneIZbZYCrQfSnZ2dnUVZ snipped-for-privacy@earthlink.com:

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.

Lloyd

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

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.

RogerN

"RogerN" fired this volley in news:x5SdnSGsJvgqqAbSnZ2dnUVZ snipped-for-privacy@earthlink.com:

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 prescribe.

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!

LLoyd

That's awesome, if you have seen the example programs these days you know where I'm coming from.

I was taught things like:

Loop: If start_button_not_pressed then goto Loop motor_run_contactor = 1 Loop2: if stop_button_not_pressed goto Loop2 motor_run_contactor = 0 goto Loop

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

Loop: 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 ... ...

goto 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.

RogerN

A little off the topic here, but do you think that INA125 board would be able to work with a single 5V supply? Maybe with a little modification?

RogerN

"RogerN" fired this volley in news:Cc6dnWXz0qTMbgbSnZ2dnUVZ snipped-for-privacy@earthlink.com:

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.

Lloyd

On 4/28/2012 8:37 AM, RogerN wrote: ...

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...

--