[N8VEM: 16953] ECB Opto-isolated Relay/Input Board

[Andrew Bingham]

One of the first boards that MITS did for the Altair was a relay board for
controlling industrial processes. In fact, my father used an Altair 8800
with the punch-tape reader to load mix designs and run an asphalt plant for
Pike Industries (http://www.pikeindustries.com/) in the late 1970s. We
talked about that this Christmas and he is going to see if that machine
might be sitting in a warehouse somewhere collecting dust. I've always
found it to be a neat example of a business using an early machine like
that.

As a mechanical engineer one my typical uses for any computer is to
interface it with some moving, shaking, or rotating device.

So, I was thinking it might be interesting to have an ECB card with
isolated inputs and outputs, that could be accessed as an I/O port to turn
devices on and off. There wouldn't be much practical use in using a
homebrew computer to do those tasks vs, say, a Raspberry Pi or Ardiuno, but
I think it could make for some interesting demos driven by homebrew
machines. And it's clearly part of the history.

Looking at the datasheets for the 8255, it seems that this could be
accomplished with 1-2 8255s and a set of appropriately selected relays. Or
perhaps there is an existing card that it could be grafted onto?

Any thoughts?

Andrew

[p***@public.gmane.org]

Hi Andrew,

This is neat idea ("N8VEM PLC", hehe). I think that for any SBC from the
N8VEM family, it would be a piece of cake to control lots of useful
processes. The digital inputs can receive signals from optical, inductive,
capacitive, mechanical sensors, 4-20mA lines. The digital outputs can
control not only relays, but also bipolar/MOSFET switches, triacs (there
are opto-isolated ones with zero-crossing detection!).

I would suggest though to allow also analog inputs via ADC. This will allow
the usage of the PLC to control thermal processes, which will further
extend the area of possible applications.

In terms of programming such PLC, it would be great if the PLC uses some
form of input understable for process engineers, and not Z80 assembly. A
ladder logic even in a text file could be a nice way to program the PLC.
This PLC program needs to be stored in a reprogrammable memory on the SBC,
and automatically launched at startup, which (as far as I know) is not
currently supported by neither ROM monitor nor CPM. Also the PLC program
will need to be easily updatable from a PC-host.

This is what I think. Regards,
picmaster


-------------------------------------
Mail.BG: Безплатен e-mail адрес. Най-добрите характеристики на българския пазар - 20 GB пощенска кутия, 1 GB прикрепен файл, безплатен POP3, мобилна версия, SMS известяване и други. http://mail.bg

[Andrew Bingham]

Well my initial thought was to make something really simple that you could
read to/write from the I/O port addresses and it would turn some relays
on/off or read the state of some inputs. That would work in pretty much
any programming language on the Z80.

As far as a complete PLC system with ladder logic, that's probably a bit
beyond my capability to come up with on my own. Although I think it would
be interesting to have an open source implementation of such a system. I
think the question would be, do you do 1 card with some kind of daughter
card for the connections for the various items, or maybe split it into
multiple ECB cards, 1 card for outputs, 1 card for inputs, 1 for ADC. I
have used things like that in the past in my work and the complexity can
get pretty daunting, with things like thermocouple signal conditioning,
grounding everything properly, etc.

(In fact I have often wanted to make my own open source data aq/control/plc
type system, after tearing my hair out trying to work with hardware and
software made by a major vendor whose initials might be "NI" and thinking I
could do better on my own)

Then there is the question of is it an actual realtime system, which I
don't think you'd get under CP/M. With custom assembly code, maybe.

Andrew

Post by p***@public.gmane.org
Hi Andrew,
This is neat idea ("N8VEM PLC", hehe). I think that for any SBC from the
N8VEM family, it would be a piece of cake to control lots of useful
processes. The digital inputs can receive signals from optical, inductive,
capacitive, mechanical sensors, 4-20mA lines. The digital outputs can
control not only relays, but also bipolar/MOSFET switches, triacs (there
are opto-isolated ones with zero-crossing detection!).
I would suggest though to allow also analog inputs via ADC. This will allow
the usage of the PLC to control thermal processes, which will further
extend the area of possible applications.
In terms of programming such PLC, it would be great if the PLC uses some
form of input understable for process engineers, and not Z80 assembly. A
ladder logic even in a text file could be a nice way to program the PLC.
This PLC program needs to be stored in a reprogrammable memory on the SBC,
and automatically launched at startup, which (as far as I know) is not
currently supported by neither ROM monitor nor CPM. Also the PLC program
will need to be easily updatable from a PC-host.
This is what I think. Regards,
picmaster
-------------------------------------
Mail.BG: Áåçïëàòåí e-mail àäðåñ. Íàé-äîáðèòå õàðàêòåðèñòèêè íà áúëãàðñêèÿ
ïàçàð - 20 GB ïîùåíñêà êóòèÿ, 1 GB ïðèêðåïåí ôàéë, áåçïëàòåí POP3, ìîáèëíà
âåðñèÿ, SMS èçâåñòÿâàíå è äðóãè. http://mail.bg

[p***@public.gmane.org]

Andrew,

As long as all digital and analog inputs/outputs are "registers implemented
somewhere on the ECB bus", there will be enough abstraction for the SW.
As you suggested, daughter cards can implement any analog/digital interfaces
needed. I've done thermocouples in my past, they're not rocket science.

About realtime execution - as far as I know, when you run application under
CPM, the OS gives the entire control to the executable. On a CPU without
privilegy levels, this means we can do anything - we can poll inputs as fast
as we want, or we can overwrite interrupt handlers and use them to respond to
timers and external events. The only issue I see is how to auto-execute the
application.

About the ladder diagrams - I was thinking about this in the afternoon. If we
get a formal specification (a text file with ladder representation, or any
other form of PLC spec), parse it, and generate Z80 assembly, translate it to
CPM executable. This way all the heavy-lifting is done on the PC side, and the
SBC executes a straight-forward logic:
- initialize the environment (setup timers/IRQs)
- read inputs from daughter board
- perform logic functions row by row (rungs?)
- update output to daughter board
- go to step 2

I think that such implementation can be pretty static (same blocks of code for
different cases), and the code can be just parametrised with actual values - an
easy job for Python text filters.

Here's and example layout of such project:
- io_driver.asm (routines for reading inputs/writing outputs, can be specific
for each daughter board HW)
- template[s].asm (one or more files with Z80 ASM constructs)
- plc_gen.asm (generated file with full PLC implementation, ready for assembly)

Andrew, what do you think about this?
@Others - please kick me in the butt if this discussion goes too far off-topic.

Regards,
picmaster

-------------------------------------

Разбра ли за зимните изкушения на СуперХостинг.БГ?
Вземи хостинг план със 75% отстъпка.
http://superhosting.bg/8years/?utm_source=Mail.BG&utm_medium=FooterLink&utm_content=FooterLink102&utm_campaign=Winter-2013

[Andrew Bingham]

Here is a link to an existing open source PLC system using ATmel
microcontrollers, with a software toolchain available:

https://code.google.com/p/open-plc/wiki/Main?tm=6

If you go with the "daughter card" idea, in my (n00b) mechanical engineer
brain it would make the most sense to have an ECB card with the address
decoding implemented on it to access several different minicards, and then
pin headers going to smaller cards that would live at those addresses.
Then you could have an input minicard, an output minicard, an ADC
minicard, an ADC w/TC signal conditioning minicard, etc.

I'm not sure if there is a lot to be gained there vs just having separate
ECB cards for each device. You'd only really save the ECB connector and
the address decode logic. And it would make it harder to locate the system
in a backplane.

Maybe try and lay the boards out with jumpers such that there are only 2
ECB PCBs, an I or O card and an ADC or ADC w/TC card, and let people build
what they need.

Andrew

Post by p***@public.gmane.org
Andrew,
As long as all digital and analog inputs/outputs are "registers implemented
somewhere on the ECB bus", there will be enough abstraction for the SW.
As you suggested, daughter cards can implement any analog/digital interfaces
needed. I've done thermocouples in my past, they're not rocket science.
About realtime execution - as far as I know, when you run application under
CPM, the OS gives the entire control to the executable. On a CPU without
privilegy levels, this means we can do anything - we can poll inputs as fast
as we want, or we can overwrite interrupt handlers and use them to respond to
timers and external events. The only issue I see is how to auto-execute the
application.
About the ladder diagrams - I was thinking about this in the afternoon. If we
get a formal specification (a text file with ladder representation, or any
other form of PLC spec), parse it, and generate Z80 assembly, translate it to
CPM executable. This way all the heavy-lifting is done on the PC side, and the
- initialize the environment (setup timers/IRQs)
- read inputs from daughter board
- perform logic functions row by row (rungs?)
- update output to daughter board
- go to step 2
I think that such implementation can be pretty static (same blocks of code for
different cases), and the code can be just parametrised with actual values - an
easy job for Python text filters.
- io_driver.asm (routines for reading inputs/writing outputs, can be specific
for each daughter board HW)
- template[s].asm (one or more files with Z80 ASM constructs)
- plc_gen.asm (generated file with full PLC implementation, ready for assembly)
Andrew, what do you think about this?
@Others - please kick me in the butt if this discussion goes too far off-topic.
Regards,
picmaster
-------------------------------------
Ðàçáðà ëè çà çèìíèòå èçêóøåíèÿ íà ÑóïåðÕîñòèíã.ÁÃ?
Âçåìè õîñòèíã ïëàí ñúñ 75% îòñòúïêà.
http://superhosting.bg/8years/?utm_source=Mail.BG&utm_medium=FooterLink&utm_content=FooterLink102&utm_campaign=Winter-2013

[Andrew Lynch]

-----Original Message-----
Sent: Friday, January 3, 2014 2:51 PM
Subject: Re: [N8VEM: 16979] ECB Opto-isolated Relay/Input Board

[snip]

Andrew, what do you think about this?
@Others - please kick me in the butt if this discussion goes too far off-topic.
Regards,
picmaster

Hi

I'm assuming this is meant for me. I encourage builders to make their own
boards and have since the start.

Please don't wait for me to endorse your inspiration just go ahead and make
it. Thanks and have a nice day!

Andrew Lynch

[Andrew Lynch]

Hi



There is an S-100 Parallel IO board that sounds close to but not exactly
what you describe. Basically it is an array of 8212 chips to send four
bytes of parallel IO and another for four bytes of receive IO. They are not
optically isolated though but that could be done relatively easily with an
intermediate board. These are raw TTL signals. It is similar to the Altair
PIO board you mentioned and useful for debugging S-100 code and controlling
signals.



If you want to reuse the S-100 parallel IO design for the ECB it would be a
relatively easy conversion. Thanks and have a nice day!

Andrew Lynch



From: n8vem-/***@public.gmane.org [mailto:n8vem-/***@public.gmane.org] On Behalf Of
Andrew Bingham
Sent: Thursday, January 2, 2014 9:02 PM
To: n8vem-/***@public.gmane.org
Subject: [N8VEM: 16953] ECB Opto-isolated Relay/Input Board



One of the first boards that MITS did for the Altair was a relay board for
controlling industrial processes. In fact, my father used an Altair 8800
with the punch-tape reader to load mix designs and run an asphalt plant for
Pike Industries (http://www.pikeindustries.com/) in the late 1970s. We
talked about that this Christmas and he is going to see if that machine
might be sitting in a warehouse somewhere collecting dust. I've always
found it to be a neat example of a business using an early machine like
that.



As a mechanical engineer one my typical uses for any computer is to
interface it with some moving, shaking, or rotating device.



So, I was thinking it might be interesting to have an ECB card with isolated
inputs and outputs, that could be accessed as an I/O port to turn devices on
and off. There wouldn't be much practical use in using a homebrew computer
to do those tasks vs, say, a Raspberry Pi or Ardiuno, but I think it could
make for some interesting demos driven by homebrew machines. And it's
clearly part of the history.



Looking at the datasheets for the 8255, it seems that this could be
accomplished with 1-2 8255s and a set of appropriately selected relays. Or
perhaps there is an existing card that it could be grafted onto?



Any thoughts?



Andrew
--
You received this message because you are subscribed to the Google Groups
"N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.