Hi, I like to say who I am so you could understand my background better. I'm a Responsible of maintenance in the car manufacturing plant of VW Brussels. I use LINUX since 0.99pl12 and always appreciated its stability !

My views are those of Industry :
a.. A PLC must be super reliable, so experimenting with special I/O cards is out of the question
b.. When using an industrial bus, choose something which is globally available
c.. Changes in the program must (eventually) be possible online (remember the possibility of changing FB5 while the program kept running !)
d.. PC's aren't very reliable, certainly not when they run Windows
e.. It is necessary to VIEW status of internal MERKERS (M0.1)
So... I think to have a chance a Soft-PLC should support an Industry Standard bus system to communicate with the "real world".

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Sky

Can't argue with any of those points except the special I/O cards. Those special I/.O cards are how we will have to support, for example, Profibus. Linux meets my reliability criteria, I would like to run on SBC's with less connectors and no mechanical components for hi-rel applications. Also cards will be the only truly high speed I/O in my book. Most of the FB
attached I/O I've tested can't support anything like the wire speed. The PLC masters I've tested are a joke as well. Linux can saturate a 100BaseT
connection so we ought to have an edge if we can find fast Ethernet I/O.

Hang around, it's just beginning to get exciting.

cww
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

I agree, the biggest point to have in mind is that there will not be ONE way to handle I/O eventually, most major fieldbuses will probably be supported eventually together with I/O-cards and other (serial, network etc).

An I/O card, properly manufactured of course, is probably a lot more reliable than any fieldbus ever will be. The internals of an I/O card is quite the same as the internals of any fieldbus based I/O, it is just a lot easier. The internal circuits operate at TTL levels or similar, but
that is true for industrial I/O:s as well and there is absolutely no reason optocouplers, relays and other components you see in "industrial" I/O can't be on an I/O card based on
for example the 8255 circuit.


(You don't have to use I/O cards if you don't trust them, but it will be the fastest and probably the most reliable I/O availiable)


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

[email protected]:
> there is absolutely no reason optocouplers, relays and other components
> you see in "industrial" I/O can't be on an I/O card based on for example
> the 8255 circuit.

I've seen a card like that and worked with it once. I even used to have a photo of a set leaning against my desk (temporarily mounted on a piece of chipboard and connected to a lamp for debugging, if memory serves) on the web, but it's not up now.

This particular model had each I/O point optocoupler/relay separate; so you could have any mixture of optocouplers and relays that you wanted, and also exchange damaged ones individually.

(The optocouplers were mounted on isolation boards outside the PC case, for ease of access and also because they wouldn't fit inside. That's what was on that chipboard, and eventually in an enclosure.)


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi all

Another reason that external boards are used for ttl to real world translation is that, once you have hardware in front of it, the pin is dedicated as an output or input. It would be quite possible, although expensive, to have a
card that can handle both based on the mode setting of the 8255. For that matter, the cards are simple enough to make to order or kit with parts to stuff a position as either an input or output. There will be an interesting
interaction here with the I/O process and setup/configuration stuff. I have looked over the driver I put in cvs and it looks really well done. (I didn't do it). I have been pondering how to check if the software setup matches the
hardware setup to see if we can detect what's an input and what's an out. This would let us prevent configuring outputs as inputs, etc. With a pull up on outputs for example and a pull down on inputs, We could set the card up for all inputs initially and read what the config is supposed to be.. Maybe the guy from Sealevel could arrange something? Jiri, have you thought
about using a util to write the config file?

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

I don't think we can rely on that for two reasons:
1. Depending on how the output stage are made on a
particular card it may behave differently. This would be ok if we decided that part but not otherwise, and that would make a lot of already exixting cards unuseable.
2. Some I/O points will be inputs, and the state of those signals won't follow the pullup/down resistor, they will follow the signal on whatever they are connected to. Regardless of what you assume as being an input some signals will simply have the other value at startup.

This should simply be user configurable, we could later make a 8255 based I/O card and call it something special where the configuration is read at startup by using some of the signals for that instead of I/O.

There is a long way to go before this however....


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

I was just thinking out loud. I have a ComputerBoards CIO-DIO48 on order now, compliments of Heartland Engineering, my day job (shameless plug with thanks). The sensing idea was kinda tied with our own hardware. Or possibly hardware made by a cooperating vendor (hint).
The way these boards work now, we have to save this state on setup and recall it on init. This would be related to Jiri's config for the mapping and it should be common to both for sanity's sake This is by way of saying that the reference I/O will probably be the CIO-DIO48 card. Provides 48 I/O points selectable in groups of 8 or 4 as outputs or inputs. TTL levels.

$99.00 from www.computerboards.com, needs a
50 pin female to female cable @ $ 25.00 and a
50 pin terminal board @ $69.00 to be handy. This is just to get the info in the mail archive

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Curt Wuollet:
> Jiri, have you thought about using a util to write the config file?

No problem, especially since there's already an "include" directive provided for by the Great Namer.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

I'm trying to follow the discussion on I/O. Please correct any invalid assumptions. One concern seems to be over whether the PLC program itself talks to I/O or whether an I/O driver talks to the I/O directly (i think). You can put some native? support for 8255 type chips in the code but not all I/O cards work with 8255s. The chip was introduced in 1978 (wow!) and isn't in great supply nowadays. Many I/O board companies have reproduced most of the functions of an 8255 in an ASIC (or a programmable chip). Current
sourcing/sinking capabilities are limited in an 8255. 24 lines isn't really optimal. However, standards exist for a reason. Most 8255 designs now have external buffering to drive solid state relay modules. Sealevel produces an ISA bus 8255 board, but chose a discretely buffered, Xilinx based 32 line digital I/O for the PCI bus.

It seems that specifying a standard API for doing I/O would alleviate some concerns. Maybe speed is the issue.

Another concern seems to be how to verify the validity of the I/O pins. I don't understand ??? Johan is correct in stating that inputs will follow whatever is connected to them. Help me understand this issue please.

We would be happy to provide some hardware if you need it. I don't want to sound too commercial or salesmanlike, here. Thanks.

Tom O'Hanlan

ps: Does Koyo manufacture the hardware for Optimation? They have really low prices. Maybe a standard (mechanical and electrical ie: 16 in, 8 out, etc)could be drafted for I/O modules so that I/O could be open sourced as well!

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

> I'm trying to follow the discussion on I/O. Please correct any invalid
> assumptions. One concern seems to be over whether the PLC program itself
> talks to I/O or whether an I/O driver talks to the I/O directly (i think).
> You can put some native? support for 8255 type chips in the code but not all
> I/O cards work with 8255s. The chip was introduced in 1978 (wow!) and isn't
> in great supply nowadays. Many I/O board companies have reproduced most of
> the functions of an 8255 in an ASIC (or a programmable chip). Current
> sourcing/sinking capabilities are limited in an 8255. 24 lines isn't really
> optimal. However, standards exist for a reason. Most 8255 designs now have
> external buffering to drive solid state relay modules. Sealevel produces an
> ISA bus 8255 board, but chose a discretely buffered, Xilinx based 32 line
> digital I/O for the PCI bus.

We are not using the CIO-DIO 48 for its engineering excellence. It is representative of a whole class of Digital I/O boards that use the 8255 and are largely compatible with one another. Also, for this stage I want it to be cheap so folks can follow along out of petty cash or out of pocket. (although I'm very glad my day job offered to buy it.) It also makes a good example because it's well known and simple to program for. I also have a standard Linux char driver for it. I am wide open to other I/O that has Linux drivers already available so I don't have to stop right now and write one. This way we make usable I/O available for a whole family of boards and we have our simple example. Right now it's the easiest.

> It seems that specifying a standard API for doing I/O would alleviate some
> concerns. Maybe speed is the issue.

That's what we are attempting to work out with this example. We have two votes for using the standard char driver API and Jiri thinks a
userland driver would be just as easy. We may do it both ways and see. One API for serial, direct attached, ethernet and fieldbus I/O would be great but I doubt it's practical unless you want to consider the interface to the mm an API. There's more than one interface on some types as they need to be set up in ways that we don't want to do with the MM and there are other "out of band" functions. The char driver handles these with ioctl() calls. There won't be any for some types.

>
> Another concern seems to be how to verify the validity of the I/O pins. I
> don't understand ??? Johan is correct in stating that inputs will follow
> whatever is connected to them. Help me understand this issue please.

That was simply me wishing there was some way to tell whether a pin is physically configured as an input or an output. We can do that if we make our own card or get someone to provide for it on their card, but on a standard card, probably not.

> We would be happy to provide some hardware if you need it. I don't want to
> sound too commercial or salesmanlike, here. Thanks.

no problem, loans or donations would be gladly accepted. That's not commercial. Stuff that's software compatible with something else is a lot more interesting. That way we don't have to write so many drivers. Stuff with Linux drivers will get immediate consideration.

> ps: Does Koyo manufacture the hardware for Optimation? They have really low
> prices. Maybe a standard (mechanical and electrical ie: 16 in, 8 out,
> etc)could be drafted for I/O modules so that I/O could be open sourced as
> well!

The unit I have in my hand has Optimation screened on the boards so I doubt that it's Koyo. The really low prices have a lot more to do with
profit margins than manufacturing cost in this market. They want to compete. For example, an dual 8255 board shouldn't cost $100.00 either.. We don't need too many more standards in the automation field, everybody's got their own already :^)

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

The system will work as a set of several processes, each process doing a small part independant of the other processes. One (or several) will run the PLC-program, some my run PID-loops, somw will handle inputs and outputs.

Exactly what processes to run in a certain computer will depend on what you want to have done (tradidtional PLC/PID-loops/fuzzy logic/whatever) and the I/O you have (8255/profibus/ethernet/serial/whatever). Yet some processes will then handle HMI if you want that, data logging if you want that, whatever.
In the middle of this is a part handling all the (internal and external) points.

The 8255 I/O process is one of the simplest and can still actually be useful in the end. It is one of the first to write because it will be both a reference for future I/O processes and a test starter for people with a relatively small budget.

The 8255 I/O will be at of the faster end, fieldbuses will be at the slower (but more "industrial") end.


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Thomas B. O'Hanlan:
> I'm trying to follow the discussion on I/O. Please correct any invalid
> assumptions. One concern seems to be over whether the PLC program itself
> talks to I/O or whether an I/O driver talks to the I/O directly (i
> think). You can put some native? support for 8255 type chips in the code
> but not all I/O cards work with 8255s.

The PLC program will talk to I/O either through kernel drivers, or through user-space I/O processes (which I sometimes sloppily call `drivers', hence the above-mentioned concern).

It will be able to talk to any number and combination of these. Thus it should be able to interface simultaneously to an 8255 card, serial or ethernet I/O and - hopefully - a fieldbus or two (or even two of the same kind of fieldbus).

> It seems that specifying a standard API for doing I/O would alleviate
> some concerns.

For user-land I/O processes, much of the API is already in place, and currently being coded and documented: the Shared Memory Manager. By the end
of the week there should be an example of how it works.

> Another concern seems to be how to verify the validity of the I/O pins. I
> don't understand ???

The 8255 can be configured so that a pin is either input or output - but any further hardware (optoisolators, relays, conditioners) is
one-directional. Curt was trying to think of a way of automatically detecting whether a pin is wired to input h/w or output h/w.

(Probably the easiest way would be to give the optoisoltor/relay/etc modules extra pins which encode what kind of module it is and have those
readable via an additional 8255 or something. But that would put us in the hardware-manufacturing business, where we do not want to be.)


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Another point I discussed with a developper last week :
He was using a proprietary bus (IR) for his specialised camera's (LASER measuring) and he asked my opinion on the development they were planning to do since the IR was NO LONGER SUPPORTED. They plan on moving to Ethernet components which are cheap and which can be supplied by many sources...

So, I think the main topic is I/O should be based on a standard which WILL BE SUPPORTED for many years.
My ideal PLC looks as follows :
a.. cheap hardware (PC migth be it) where we only use the standard things. Visualisation NOT on the controller for reliability reasons. Linux as OS is a good choice.
b.. An interface to the outside based on something standard (Profibus, Interbus, Ethernet)
c.. I/O on ruggid modules which connect to the BUS

 

Hi Sky

Now you've pretty much got the whole idea of the Linux PLC. Generic, to take advantage of the economies of scale in the PC biz.

Standards: Wherever possible, Open Standards, because proprietary standards have been used to lock in users and grossly inflate profits.
Proprietary standards also cause enormous difficulty in integration, by design. And in general, they make automation much more difficult
and expensive than it has to be. I view this as just short of criminal.

Community owned and GPL'd so it can never be made proprietary and will remain free and TRULY OPEN. The established companies fear anything truly open because it means they have to compete on price and merit. They even know their customers want open solutions and that's why their advertising is full of "Open" and their product lines are even more closed and proprietary than before. They think their customers are so stupid they don't know the difference. It's so bad that in this industry, "open" means nothing. This project aims to fix that.

On your last point, we will support any I/O that we legally can and someone is willing to write drivers for.

Regards

cww.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

That's right Curt, I know an example of a well known company which offers its products as an Open Distributed Control System, we asked a proposal for a DCS we were requiring, when we evaluated the proposal we didn't find any open but an ethernet network at the highest level.

Regards


> and merit. They even know their customers want open solutions and
> that's why their advertising is full of "Open" and their product lines
> are even more closed and proprietary than before. They think their
> customers are so stupid they don't know the difference. It's so bad
> that. in this industry, "open" means nothing. This project aims to fix
> that.



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc