Real Time? Was: Shared memory / persistence / io polarity

C
<clip>
> AB makes cards that allow a computer (that;s us) to be the I/O scanner
> for thire RIO. I ension supporting this very ealry in the project.
>
> Dont' other PLC vendors make such cards?

Hi Stan,

Yes, they certainly do, but, I expect their support for this project to be less than enthusiastic and it's extremely difficult to write drivers without cooperation. It's not easy with cards where they give you all the information you need. Some may give you the information, but, only under an NDA. This is worse than no cooperation, because it legally pollutes the project if any of it gets in. I would expect we can find an independent that is sympathetic and wants to become the reference provider of IO boards for the project. Almost all board vendors make as much money selling drivers and libraries as they make on hardware. I'm hoping the buying power of this group will sway a
board vendor to address this market. We, of course will graciously accept any cooperation from the PLC makers who would like to sell us
IO. That's where their money is also. We already have a board vendor who would like to help on some proprietary IO. Those of you who have
or want that type of IO should definately take them up on their offer. Reverse engineering can be done but you really have to want a driver
badly to put in the effort. Ron Gage can tell you about that. His driver required, I'm sure, a lot more work than if AB was helping. A board with one big asic in the middle and no docs could be a black box forever.

Regards,

Curt Wuollet

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 20:45:47 2000 wrote...
>
>I have never said industrial I/O shouldn't be supported from day
>one. As a matter of fact I think that is already taken care of.
>Wasn't that the thing that set of the entire project?
>
>Do you have any idea of what a 8255 is?

No, I must admit that I don't.
>
>Are you sure you don't have them or something similar in your
>industrila devices I/O rack?

No, but frankly I don't care. I buy them from a reputable vendor who provides spec sheets for the totally assembled product. These cards are built in a fashion to withstand the handling (mechanical and electrical) that they get in an industrial environment. The manufacturer also provides a stock of repair/exchange parts that I can call upon at 03:00 on a Sunday night.

Get the picture?

>I am quite sure you do have something similar in them :)
>
>This is not something we really don't agree about, (totaly
>regardless of if you think that or not) but we are actually
>talking about more or less different parts of the I/O rack and from different points of view.
>
>Let's drop this discussion it does not lead anyware in the current
>state of the project. We can resume it at a later stage if you want.

Suits me, I have no problems with what you are doing on it. Just no plans to ever use it :)

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat, Jan 22, 2000 at 08:07:25PM -0500, Stan Brown wrote:
> On Sat Jan 22 20:45:47 2000 wrote...

> >Do you have any idea of what a 8255 is?

> No, I must admit that I don't.

> >Are you sure you don't have them or something similar in your industrila
> >devices I/O rack?

> No, but frankly I don't care.

Fair enough, but if you don't know the details of actual I/O, *don't argue with people who do*. Concentrate on the parts you *do* know about.

8255 is one of the standard chips for computer I/O. It's not an entire I/O package; it's merely the heart of one.

It's also the part of the package that programmers need to worry about. As far as the computer is concerned, an 8255 is an 8255. Whether the thing on the other side is a printer or a multi-kV-isolated contact doesn't matter
from the software side.

> I buy them from a reputable vendor who provides spec sheets for the totally assembled product.<

Yes, but here we are discussing the *internals*. We are putting together the PLC. Eventually, there will be spec sheets like that, but for the time being we are working on the details.

Oh, and by the way - I don't know if you have one in your industrial I/O rack, but there's definitely an 8255 sitting in your office. There's one in every PC. The printer port, if memory serves.

Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri, Jan 21, 2000 at 06:16:59PM -0500, Stan Brown wrote:
> On Sat Jan 22 00:32:44 2000 wrote...

> >What?
> >They are as important to run in real time as the controlling
> >engine=2E It makes no sense at all to solve the logic at regular
> >intervals it no data is exchanged with the rest of the world=2E

> >All I/O task do not need real time, but whenever the controlling
> >engine do the I/O need it too=2E (and the other way around)=2E

> if reading in the inputs for a given piece of hardware takes 3 seconds
> (not unreasonable for some devices). Then it does not need to be run in
> real time.

> I think you misunderstand real time in this context. Substitute "deterministic" and see if things don;t get clearer.<

In our context, "real time" means "won't be pre-empted by something that has no business pre-empting it".

An input that takes 3 seconds - no, it probably doesn't need to be real-time. But if any part of the project needs to be real-time, then at least some of the I/O has to be.

That is:
critical control - real-time
critical I/O - real-time


Other control and other I/O can run real-time or not, whichever is handy.


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
>Hi All
>
>Reality time. Directly attached IO cards are the only "native"
>IO this project has. If you want the best performance, this is
>what you will be using. No fieldbus, no network, will ever come
>close to what you can expect from optimised IO on the bus.
>Every PLC comes with native IO and this is ours. That said, we
>should be looking at some. In a sense, Ethernet IO is "native"
>since networking is a big part of Linux, but, It is very early
>in it's development and not at all standardized. Use IO boards
>where you would use IO modules on a standard PLC and you will
>gain all the same benefits, simplicity, speed, and function.

Reality time, again. If you don't support a wide range of existing industrial I/O, in all its forms, then you are basicaly fooling yourself if
you think that this is going to be anything more than a hobby.

To be sure, there are a large number of 'native (?)' boards that can be plugged in to ISA/PCI card slots. These cards provide interfaces to just
about any I/O network (Profibus, DeviceNet, AS-interface, DH+, AB RIO), providing support for these cards _IS_ the project to a major extent.

To my mind we will also need to interface directly to existing PLCs, even on RS-232 where necessary. This is an _open_ project, in all senses of the word.

To be a success, in the way that many people (on the list) seem to be expecting it. This project needs to produce products that are better than
the existing commercial products.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon Jan 24 04:25:53 2000 Mark Hutton wrote...
>
>Reality time, again. If you don't support a wide range of existing
>industrial I/O, in all its forms, then you are basicaly fooling yourself if
>you think that this is going to be anything more than a hobby.
>
>To be sure, there are a large number of 'native (?)' boards that can be
>plugged in to ISA/PCI card slots. These cards provide interfaces to just
>about any I/O network (Profibus, DeviceNet, AS-interface, DH+, AB RIO),
>providing support for these cards _IS_ the project to a major extent.
>
>To my mind we will also need to interface directly to existing PLCs, even on
>RS-232 where necessary. This is an _open_ project, in all senses of the
>word.
>
>To be a success, in the way that many people (on the list) seem to be
>expecting it. This project needs to produce products that are better than
>the existing commercial products.
>

Well said. I am afraid that some people on this list have in md building a total replacement for existing PLC's, including hardware (both the CPU and the I/O). I think that if we don'ttake advantage of the exisitng comercial (and well acepted) I/O structures, we doom this project to be yet another "little computer control system" These have not had any significant acceptance in industry.
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

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