NC vs NO

Possibly Dick Morley, who invened the first PLC.


mmh, maybe but I remember back in 1989.....when I was young :doh2:I learned to program with the older stuff.

This older stuff was an hand-help programator: Siemens and I think TI (the brand doesn't matter).


The way to program the TI was something like


00 enter (line 0)
01 (start line with and-function
00 (input)
00 (byte 0)
01 (bit 1)
01 (and)


and so on



Who of you remembers something like this and do you also know when the first ladder-software was used?
 
Who of you remembers something like this and do you also know when the first ladder-software was used?

Many of the early PLCs used a specialized "cassette loader" for programming. There was often a different device for each model as well as each brand. The program logic was stored on audio tapes or specialized cassettes. Each programmer was about the size of a carry-on roller bag. There were also handheld programmers that didn't have storage capabilities. I remember walking into a machine builder's closet and seeing about 20 feet of four or five high shelves filled with programmers.

https://www.automation.com/automation-news/article/the-dawn-of-the-programmable-logic-controller-plc

As far as I know, the first PC based programming software was by Greysoft in Mequon, WI (Milwaukee suburb). I think Square D was the first PLC supported - first offered in the early eighties I think. AB at first discouraged PC based programming because of revenue loss, but they eventually gave in and bought the technology.
 
here's a quick preview of the YouTube videos...

"There can be some serious shock hazards in this particular topic." - Video 2

Love it :); too bad you're not in the business any more.

Btw, I got it right for video 1, and I think I know why, and I feel pretty darn good about that. I can also guess why CompactLogix might be different.

It's amazing, no matter how complicated something gets, it always seems to come back to bookkeeping.

ETA:

Go look for a 1
"eXamine If Closed" misleads
Bit-Box concept wins.
 
Last edited:
I can also guess why CompactLogix might be different.

yes - CompactLogix is different - and ControlLogix is different again ... Specifcally, ControlLogix and CompactLogix have scan cycles that are different from each other ... and neither one of them have the same (simple) 1-2-3 sequence used in these beginning videos ...

Classic pedagogy, like a presbyterian sermon: tell 'em; tell 'em again; tell 'em what you told 'em.

sort of - but if you look closer you'll see that the teaching method is to:

(1) give the students a PROBLEM ...
(2) and then help them work out a SOLUTION ...

this type of training is NOT suitable for everyone - but if you can get the right team of students in the class, you can keep them working - and learning - nonstop for 12 hours a day - with only a short break for lunch ...

as the old saying goes: "build a better mousetrap ... " and so on ...

Love it - too bad you're not in the business any more.

I surely do miss it - but my wife convinced me that it was time to quit ... (amazing how "convincing" a wife can be) ...
 
CompactLogix is different
My brother told me in some programs he buffers all inputs into local memory in the top rung, and outputs buffered bits at the bottom rung, and does not touch input and or output bitboxen anywhere else in the program. For a non-I.read-inputs/II.execute/III.write-outputs PLC, that makes it work as if it was a PLC-5 or MicroLogix i.e. predictable. That must be a standard trick, eh?
 
That must be a standard trick, eh?

let's say that it's "common" - but I wouldn't quite say that it's "standard" ...

quite a few old-school programmers still don't fully trust the new asynchronous scan cycle used by the "Logix" platforms - so yes, you'll see the "I/O buffering" idea used quite a lot ...
 
Yes, and it has the additional benefits of being able to see all of your I/O in a clean arrangement without having to dig through tag folders, as well as making it easy to move a point to another channel without a mess of find/replace all over the program and HMI.
 
quite a few old-school programmers still don't fully trust the new asynchronous scan cycle used by the "Logix" platforms

Is it a matter of trust, or is it wanting (or needing) a consistent set of inputs to work with throughout the scan?

"Left to right, and down" means the abscissa is signal* and the ordinate is time, to use a plot analogy (e.g. in sheet music the abscissa is time and the ordinate is frequency).

* plus time, maybe

So if I [Go look for a 1] at a particular input on [N] rungs and/or branches, then an asynchronous I/O scanning system gives me a minimum of [2N] cases, and theoretically as many as 2**N cases, I need to think about, instead of just one.

I suspect it would rarely matter for normal operation in most processes, but that level of indeterminacy would wreak havoc with any troubleshooting efforts, especially for a rare or transient problem.

So I may have to do the analysis to determine which critical subset of inputs to buffer, at which point it may be more productive to simply buffer them all, to save time.

So it may not be only an issue of trust; I'm just sayin'

"Old-school" sometimes means "Fool me once ..."
 
Last edited:
My brother told me in some programs he buffers all inputs into local memory in the top rung, and outputs buffered bits at the bottom rung, and does not touch input and or output bitboxen anywhere else in the program. For a non-I.read-inputs/II.execute/III.write-outputs PLC, that makes it work as if it was a PLC-5 or MicroLogix i.e. predictable. That must be a standard trick, eh?

No, not at all. In fact, never.
 
Back
Top Bottom