Function Libraries

C

Thread Starter

Curt Wuollet

Hi all

Re:
The timer discussion and the many to follow that will compare how one vendor chose to implement verses another, I thought it a good idea to
remind folks that this is _Your_ project. If it comes down to two or three different behaviors that people want for the same function, we can do them all. Unlike the commercial vendors that insist on only the one "correct" way, we are free to emulate whatever is practical and you can get someone to write. There are cases where one will
preclude another, but I see no reason to be dogmatic and argue about those cases where we can reasonably support alternatives. This will allow us to attract a larger user base than if we choose to favor one function set.

At worst, if this causes the libraries to become too large, we can split it into compatibility libs where you link in the flavor that you are most comfortable with. ELF Shared libs are reasonably efficient. The only case where we might run into problems is for very small machines.

On a related note: I have received the Hard Hat Linux cd's and will be looking into these. The thing I was most interested in at present was
their scheduler, but even this may be rendered moot if the low latency kernel mods make it into the mainstream kernel. When I get a chance I am going to run down information on these modifications. If I find anything of general interest , I'll post a link.

The other part of the Hard Hat stuff is a kit to help develop small footprint versions for SBC's and embedded class platforms. I am interested in doing some work on a reference small platform to
make sure we stay within reason for non-desktop machines. I have yet to find much enlightenment in the docs and won't have much time for a while to play with this, but it would be cool to be
able to have a din rail mount lplc, for example. I haven't heard much from you folks if this is important to anyone else or is it simply an
eccentric obsession on my part.

It's late.........

Regards

Curt W.

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

Phil Covington

Hi Curt,

> Re:
> The timer discussion and the many to follow that will compare how one
> vendor chose to implement verses another, I thought it a good idea to
> remind folks that this is _Your_ project. If it comes down to two or
> three different behaviors that people want for the same function, we
> can do them all. Unlike the commercial vendors that insist on only the
> one "correct" way, we are free to emulate whatever is practical and
> you can get someone to write. There are cases where one will
> preclude another, but I see no reason to be dogmatic and argue about
> those cases where we can reasonably support alternatives. This
> will allow us to attract a larger user base than if we chosse to favor
> one function set.

This is definitely the way to go. Everyone has their favorite PLC, but the LPLC shouldn't get bogged down in trying to emulate any particular one. The place for this is in the logic engine...

> At worst, if this causes the libraries to become too large, we can split
> it into compatibility libs where you link in the flavor that you are most
> comfortable with. ELF Shared libs are reasonably efficient. The only
> case where we might run into problems is for very small machines.
>
> On a related note: I have received the Hard Hat Linux cd's and will be
> looking into these. The thing I was most interested in at present was
> their scheduler, but even this may be rendered moot if the low latency
> kernel mods make it into the mainstream kernel. When I get a chance
> I am going to run down information on these modifications. If I find
> anything of general interest , I'll post a link.

Don't hold your breath waiting for the low latency kernel mods. After following discussions of this sort by the kernel developers for a while now, I don't think this is very high on their list even though this would help in acceptance of Linux on the desktop by multimedia and game developers. Right now unmodified NT is much better than unmodified Linux in terms of latency (with W2K being even better yet from my own testing) and this is verified by the soft PLC programs that run well on unmodified NT ( with
modern hardware, of course). Linus' response was interesting in that he believes that with modern hardware there is little need for RTLinux. There was talk about incorporating parts of RTLinux into the mainstream kernel at
one time, but I don't think it will happen.

Still for servo, motion, high speed control, etc.. a patched kernel is going to be the way to go for now.

> The other part of the Hard Hat stuff is a kit to help develop small
> footprint versions for SBC's and embedded class platforms. I am
> interested in doing some work on a reference small platform to
> make sure we stay within reason for non-desktop machines. I
> have yet to find much enlightenment in the docs and won't have
> much time for a while to play with this, but it would be cool to be
> able to have a din rail mount lplc, for example. I haven't heard much
> from you folks if this is important to anyone else or is it simply an
> eccentric obsession on my part.

This, I think, is very important. Many people will not accept using desktop type hardware for control. They expect to see something that looks like a PLC ( not a soft PLC). If you want to do machine control with the LPLC, an industrial computer or desktop may not be practical due to the physical size of the machine, cost constraints, environmental conditions, or floor space requirements. A DIN rail mount LPLC would be exactly what is needed in this case. If the LPLC only runs on desktop type hardware, then it will be classified as another soft PLC and this will limit its use and acceptance. If it runs on an embedded CPU in a DIN rail mount rack, then it is a "real" PLC. The beauty of this is that the LPLC will have *both* the soft PLC and hardware PLC apps covered.

Regards,

Phil Covington

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

Ralph G. McDonald

Hi Curt & Phil

I agree with both of you on the importance of a small footprint LPLC in an industrial package.

We are using a lot of the small OPTO 22 packages and AB SLC. An ideal LPLC would be scalable to fit from small standalone systems to a network of LPLCs using various hardware configurations for
CPU and I/O. An initial test system can start out small and still be "real world" useful.

Do you have any idea yet for a small SBC as the first target.

I also received a copy of the Hard Hat Linux and found it has an interesting feature in that it will run on a PowerPC host with Yellow Dog 1.1 or 1.2. When I get a chance I will try it on my Mac at home.

Keep up the good work

Ralph

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