Skip to main content
shopping_basket Basket 0

Classical Automation enters Alien World of IT: Part 1

Volker de Haas started electronics and computing with a KIM1 and machine language in the 70s. Then FORTRAN, PASCAL, BASIC, C, MUMPS. Developed complex digital circuits and analogue electronics for neuroscience labs (and his MD grade). Later: database engineering, C++, C#, industrial hard- and software developer (transport, automotive, automation). Designed and constructed the open-source PLC / IPC "Revolution Pi". Now offering advanced development and exceptional exhibits.



July 2, 2019 15:38

You are a very attentive reader and you are right: This circuit would not work as described. It would work like a NAND function because I have inverted the output unintentionally: Only if both buttons are pressed the LED will turn ON. When supposing an OR, you probably interpreted the buttons as NO (normally open) which would make them inverting the logic at the input too. First of all the symbol for the logic gate is the old but still common ANSI/IEEE Std 91/91a-1991 standard symbol for AND (positive logic). At the output, I do use negative logic as the LED is connected to positive voltage. That means: Whenever the AND gate's output logic LOW the LED is ON.
The inputs are both LOW when the buttons are in their default position (NC) because they connect the input to GND = LOW. Only when both buttons get pressed, both inputs get HIGH (due to the pullup resistors). The result is a HIGH at the output, which turns OFF the LED. So instead of using an AND gate I should have used a NAND gate to make things working as described or I should have used positive logic at the output (which was my intention) and connect the LED to GND instead of +5V. Shame to me and many thanks to you showing this fault. I will edit the picture as soon as I'm at my office again.

0 Votes

July 5, 2019 07:36

EDIT: I have changed Pic. 1, LED is now connected to GND making the output positive logic. With the inputs being also positive logic (push buttons are NC type (normally closed, so GND at input per default) this should now work as described in the article.

June 25, 2019 12:21

Pic 1. does not work as described. It's an OR: A + B = C. Engineers are such a pain.
Even with the logic error, I liked it, can't wait to read more.

0 Votes

[Comment was deleted]

  • Moderated

[Comment was deleted]

May 8, 2019 07:30

Dear VdH,
Much like MikeJones, I enjoyed your article a lot, even though cleaning my desk from my nostalgic tear drops menaced to ruin the experience.
Most in the same way you (and him) did, I traveled the path from punchcards to Raspberry Pi and (I)IoT, passing through BASIC, PASCAL, FORTRAN, C, C++ and C# (I even know what Algol was, even though I have never used it), from Rockwell's AIM65 and Intel's MCS85 to the current ARMs.
I can't wait for the next issue!
My point is: both worlds are converging, many times against their proponents will. The computing power these new approaches have for us, developers, has never been so big, and keeps increasing as much as the systems keep shrinking in size and (not always) in price.

Thank you, VdH!


May 9, 2019 07:54

Dear arodulfo, Yes, those 2 worlds definitely do converge and the monetary pressure for it is so strong and convincing that unwilling proponents cannot prevent this process. So it is a better strategy to bow to the changes and use the opportunity to be part of great visions. So let's share some more Dino "generation A" stuff: remember the times when you did not need tweezers and glasses to change data medium but 2 strong arms to change the removable disk (RL02 with 10 MB) of a PDP11/10? Remember you needed an ear protector when printing your listings on LA36 DecWriter? When you used the 8" RX01 drive to save at maximum 1/4 MB per medium, you do know why floppy disks were called "floppy": two layers of cardboard with a piece of plastic in between. But the system could boot from these 256 kBytes! Never heard of an 18-bit bus? DEC's PDP11 used it... Imagine a RAM which needs 1mm per bit... it was called "ferrit-core memory"... Ever used "wire-wrap" instead of a PCB to build a complex digital device with dozens of 74xxx ICs?

May 9, 2019 07:54

@arodulfo Part 2 is available now!

May 8, 2019 07:32

You wrote my history!


May 9, 2019 07:53

@RickCKnight So let's share some memories!

May 7, 2019 07:19

Hi VdH
Loved this article as it took me back so many years!
Started my experience with "computers" way back in 1970 when the machine was jam packed with valves and broke down on a weekly basis! This machine had 32k of Ram The language was something called "Algol". I really do remember the green punch cards - average program would require about 200 of them. Submit to the operator and go back the next day to get a single sheet of (green lined) paper with the words "Syntax Error" - and that was it - no clue as to where the error had occurred!
Loved the article and look forward to the next installment!
Having been involved, over the years, with both systems it seems to me that PLC systems are, in a lot of ways, emulating IT systems. A lot of PLC manufacturers now incorporate interrupt (or event) driven functions. Would you not agree?
Maybe eventually systems may become indivisible?


May 8, 2019 07:31

@MikeJones Good to know that I'm not the only Dino out there ;-) Some weeks ago, when I talked about punch cards at lunch, a quite young colleague said to me "you're not "gen X" you're "gen A". At the meeting after lunch, they dropped a punch card on my table (don't know where they found it) as a present for me. I started punching holes in it with my pencil and said: "...all right, so I'm writing today's protocol...". Yes, you're right: Both worlds will definitely melt together in the near future. This was the reason to write these articles. I'm absolutely convinced, that we can earn lots of experience and knowledge from both worlds. Most modern PLCs do already run under some kind of RTOS and several (like the REVOLUTION PI) even use a Linux OS. So internally they do use classical software patterns of the IT world. But many of today's automation engineers still love to use the EN61131-way to set up their control programs. So Siemens and others are trying to limit the event-driven parts of their PLCs to Gateway-Functions (OPCUA / MQTT). Real Event-driven and distributed control systems would need to implement EN61499 which was defined to implement component/module based programming. EN61499 has innovated from cyclical control mechanisms to event-driven control. As far as I know, some people have implemented an EN61499 software on REVOLUTION PI. For me, it seems that EN61499 is sadly only an academic vision (I don't know any PLC which is sold with EN61499 software toolchain). I do know that a group has implemented a component- and JAVA-based PLC software ("") on this hardware platform. But to my experience, the market does not (yet) demand a switch to such innovative new models for automation controllers.

May 7, 2019 07:22

Fig 4 FDB is mirror image

0 Votes

May 8, 2019 07:31

@dickcummings Yes, you are absolutely right! I've already corrected it. Thnx for being attentive and posting it.

Related Content

DesignSpark Electrical Logolinkedin