Linux Driver Standards (was BUSN: Blackout of 2003)

M

Michael Griffin

I didn't think your original explanation was complicated. Your reply is quite detailed, but it doesn't really answer my question. If you have an application program and a communications protocol driver, how do the two meet? How does the data get from the driver to the application?

You could simply provide a library and compile the driver into the application. However, this means re-compiling to add or change a driver. Many people would find this inconvenient or impractical (especially if they couldn't shut the program down).

The question isn't how you get the bytes out the ethernet (or serial) port, the question is how do you move the information between the application and the driver?

I would forsee you need to provide the following components:

1. Physical communications port.

2. Low level port driver (this may be provided by the O/S).

3. Protocol driver (e.g. modbus, profibus, etc.).

4. The application interface API (you suggested this as a register map).

5. The missing piece of the puzzle.

6. The application software.

The question is, what is #5? Whatever it is, it should preferrably be some existing standard rather than something new you had to invent for the purpose.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
C
Hi Ralph

I pretty much agree with what you said, but it kinda reinforces my point. Your 1000 transformer management system and the machine maintenance application would both be far better served on a PC than any PLC type system I've seen so far. And yes, with the vast memory and tremendous amounts of compute resource on a desktop they would be trivial apps. Even the current trend towards horrific inefficiency and glop like VB can be tolerated.

But the tools used for definite purposes like automation, should be scaled and suited to the other end. PLCs don't have unlimited resources and efficiency matters. And very few PLC applications grow to the scope where this degree of overhead makes sense.

And supporting and reinforcing dependence on the monopoly is the way to stay planted in the past rather than moving forward to better methods. The recent IP unpleasantness should be clear warning of the consequences of embedding proprietary IP. Imagine ever trying to stay in business should Microsoft play games like SCO and call in their markers. This whole industry is owned by Microsoft as it operates only at their leave. If you don't believe that, try running without them, as I do. That's a very good reason in my book not to depend on anything they control. In any other context, this degree of exposure would be considered insane for most businesses. But it's somehow acceptable and people even recommend that _I_ do so, or even encumber our project in this manner. Must be something in the water, I don't see them as being that trustworthy.

Regards

cww
 
L

Lynn at Alist

Please... if we can create an easy solution that mets 70% of the application space (ie: PLC) but a dozen 'other' needs are not met - should we NOT settle the 70%? Should we just throw up our hands and say "oh, it's hopeless"? There will never be a 'prefect' API solution for all applications. For any proposed API, you or I could find a application that doesn't fit the API. That doesn't devalue the API.

I wasn't thinking of anything as complex as some other writers are suggesting - those could be a HIGHER level above this one. Just 1st phase a simple "int read_ints()" or "int write_ints" that could be mapped to Modbus/RTU or DF1/SLC500 style or SNP R% reads etc. read_ints takes a parameter structure rich enough to satisfy MOST PLC protocols and causes data to be loaded into a packed memory array pointed to as a parameter.

LE/BE would be implicit in your code - if your machine is LE & protocol BE, we'd need some #define to enable the appropriate swapping. At Digi our code tends to use the BSD style hton/ntoh type functions which are #def'd or null depending on the HW we're compiling on.

- LynnL, www.digi.com
 
C
Hi Michael

I'm not sure I understand what you're driving at. In the example of A PLC, the application would interact with these virtual registers and data types in the same manner as native registers. In a SLC 500, the ints would be INT registers and you could move, copy, increment etc in your ladder logic. Peer to peer this would work the same on both ends. On a Linux box you could use pointers or an array or what ever you like that can point to memory. In a S10 robot they would become Karel variables, an array would probably work best there and I don't recall, but I think you could associate them with enumerated types in Pascal fashion. All have some native way to deal with variables of various types. IO would probably work much like modbus where 16 outputs or inputs would be mapped to a register. The idea is not to have your missing link, but for the mechanism to be transparent. Each would require the parsing and mapping per the rules but this is mostly straightforward system programming. Let's consider the simplest case, TCP/IP on ethernet as just about everything has this transport/protocol available. In Linux it could all be done from userland, I believe, on other platforms it would vary but for example, the SLC could simply have another "file" type to provide this extension. Some sort of config record would provide the format, click on int once and float once and you would have 64 new INT registers and X new float registers (I'm not sure how AB stores floats offhand) Enter an IP address and assign labels, etc. as you build the rungs. Print the list of labels for use on the other end and you're ready to rock.

Imagine how many of the problems we see here would be solved if when you copy a value to a register on your 90/30 (so I'm not picking on AB exclusively) it simpy updates a register on your ABB or in my Linux program and vice versa. A great deal of the traffic here deals with various kludges and gateways and converters and whatnot to accomplish this same goal, often through the use of two dissimilar protocols or special ($$$) hardware and considerable head scratching.

By making it do only one very useful thing (like most *nix tools), you have a very well defined and straightforward job implementing on each platform and it's very simple to use. Define the format, give it an IP address and hit go. All it would take is a little cooperation.

Regards

cww
 
C
Hi Lynn

Exactly. That would suit my needs. I merely use the register model as it's common to nearly every automation machine. It would be a good idea to use standard network ordering tools for sanity's sake. We'd simply be extending what *nix systems have been doing for decades to the new nodes on the net.

Regards

cww
 
Curt Wuollet:
> Just to prove this doesn't have to be complicated, let's establish say
> an 8k frame to put this stuff in.


Curt, the problem isn't coming up with a protocol. The problem is a lack of will to interoperate.

As long as there's no will to interoperate, it'll be Tower of Babel. Where standards are made, they will be clunky, 8-headed monsters that the vendors will subvert anyway.

If there were a will to interoperate, some standard would emerge.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
Jiri
 
C
Hi Jiri

The key to the will to interoperate is the very reasonable expectation
that products will interoperate. The Tower Of Babel is a very big issue
for a lot of people in isolation. The very nature of the problem is such
that everyone has to solve the same issues and waste lots of time and
energy each in their individual case. Almost every issue we see here has
been solved before many times and yet the solutions must be rediscovered
over and over again. If the scientific community worked this way, people
would be announcing the same discovery over and over and progress would
be nearly non-existant. The scientific community operates in a more open
fashion and as a result people can build on the discoveries of others.
Scientists are eager to publish and soon there are many others taking
advantage and last years discoveries are taken for granted.
An improvement on the status quo would be for folks on this forum to
post their solutions and reduce wheel reinvention. But, more to the
point, some things simply shouldn't be problems to be solved when you
pay very big bucks for some fairly modest electronics and the requisite
software to make it work. With ubiquitous networking in the general
computing field considered to be absolutely normal and a given, with
even appliances being routinely networked and even cars reaping the
benefits of embedded networks, Why should it be tolerated that our
tools be used in enforced isolation? You expect that any $300 computer
from any vendor will plug right on to your home network and will work
with your ISP. It would be considered junk and returned if it didn't.
There is no longer any reason that this shouldn't be the case with the
gear we use as it is certainly more important that the nodes on your
automation system work together than if your PDA can talk to your MP3
player.
My point in running through how it could be done simply and efficiently
is to focus on the points that it won't happen if people accept the
burden of making it work themselves and that there is absolutely no
justifiable reason why they should. It should be a given, it should be
basic functionality and it should have happened a long time ago. But
the vendors will be very happy to continue selling us expensive junk
and acting in their best interests only as long as it isn't a "must
have" when the check is being signed. When it is a basic expectation,
it will happen. In the meantime, we can expect the announcement of
something called a wheel every week and see a dozen questions on how
to get around.

Regards

cww
 
T

Thomas Hergenhahn

Hello Michael,

> I can understand some concern about whether >the backplane could be a bottleneck. If the >IBH-Link could be a DP slave, then the >S7-315-DP-2 has a DP master integrated...
Don't know wheter IBH-Link can be DP Slave. Can only tell you that I use the DP master for distribibuted I/O only.
>
> I have one project in particular which I am >doing research on now, that involves updating >some PC based test equipment. I was thinking of >adding an option for a profibus interface (the >PLC would command the PC to conduct a test) and >this seems like a nice low cost solution.
I think this can equally well done by reading some flags which are interpreted as commands by the PC program (and writing back data and "command done" flags).
>times per second (20 times would be better), >then most of the performance analysis logic can >be moved from the PLC to the PC...
As I got about 5 reads per second, I suppose you will not get 20 with MPI. I should propose to store multiple samples of data in a data block in the PLC and then read 5 to 10 samples at in one transmission and write back some command that lets the PLC reuse the memory afterwards.
>
> The ethernet gateway interface is also >attractive because this allows the use of any >of a number of small of PCs which are now >available. A PCI card always seems to add a lot >of bulk to any of the package formats I have >looked at.
>If the gateways can be DP slaves, then one PC >could monitor several machines without >connecting the different DP networks together.
That can be done with MPI also:
Connect different IBH Links to one network hub.
>
> I didn't see any detailed information on IBH's >web site.
Thought it has benn there, but I cannot find it anymore. Maybe, Im wrong, because a CD that came with the device had a layout like the web site..
>Is the technical information you got >reasonably detailed,
No, it isn't. It is enough to use the device with the software shipped with it (under windows only).

>and what did you find to be the best source for >it?
Sniffing the bytes and comparing it to what I found out about Siemens protocols before.
> I'm not sure if IBH is the actual >manufacturer (since Helmholtz seems to be >selling the same thing), or if they are who I >should be contacting about this.
Yes and there are more. I think, the original manufacturere is Hilscher
(www.hilscher.de), because I found the name in some data sent by the device.
But there may be more then one type of firmware, because deltalogic (www.deltalogic.de) offers what I should consider the same hardware in two falvours, with or without the capability to use it with Step7 programming software.
subject interests me greatly.
If you want the manual( PDF format,English?, at least German, I do not have the disk at hand now) which came with the device send me a private mail. You can find my address on:
libnodave.sourceforge.net

Thomas
 
M

Michael Griffin

On October 25, 2003, Curt Wuollet wrote:
<clip>
> I'm not sure I understand what you're driving at.
<clip>

There are different ways of connecting an application with a driver. OPC uses DCOM. A simple driver library could be linked (statically or dynamically) with the application by re-compiling and linking. There are other possible solutions. What would you do? What limitations would result? What classes of applications (SCADA, soft logic systems, etc.) would these limitations be acceptable for, and for which ones would they not?

--

************************
Michael Griffin
London, Ont. Canada
************************
 
R

Ralph Mackiewicz

Actually, OPC uses DCOM to remote the OPC client from the OPC server. If the OPC client and server are on the same machine, then DCOM is not needed.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
C
Hi Michael

This is more in the way of a service than a driver and would probably be done differently on each platform as part of the systems programming. As such it would likely be firmware on very small platforms and could be implemented on more elegant platforms in any number of fashions. On a PLC, configuring the service would put a hook in the scan loop to establish the connection on startup with other initialization tasks then check for data available and dirty blocks thereafter. Each vendor does something like this when a new card is configured and to add it to the scan. This would be very similar. On a system with a full featured OS it could be written as a daemon writing to a known address in the IO map or shared memory or whatever is most convenient. Or it could be done in the application itself for very closed platforms. So the interface would be native to the platform.

Limitations: All it does is make memory objects global. Not hard realtime. TCP/IP/Ethernet required. (For the simplest case) Might be too chatty for very dynamic IO.
Suitability: Suitable for all applications where this is what's needed.


Open Standards: Ethernet, TCP/IP ,Sockets, This protocol.

Actually. it's the antithesis of shoehorning a "do all be all" office automation scheme onto small simple hardware. That may well be suitable for high tag count SCADA or some few other situations where a PC that runs monopoly products is actually needed. Most of the traffic here is about simply getting a few numbers from a Foo 42 PLC to a Bar 666 PLC or a dozen register values to a PC program. Or vice versa. That should be built in and universal. And shouldn't pass through a MS tollbooth. The status quo, if it can be done at all, is way too expensive, complicated, time consuming and specific.

It would solve the vast majority of peer to peer communication needs and would eliminate needing a PC intermediary. Plug 5 PLCs or other controllers from various vendors into an inexpensive commodity hub or switch and they could exchange numbers or other basic data types seamlessly and almost without effort. They would just "be there". Many people are using Modbus, etc for this type of thing now. This would differ in being peer to peer and transparent with all the details hidden if desired.

This contrasts starkly with some of the bizarre schemes needed to simply pass a few numbers from one PLC to another, from very spendy coprocessors to dedicating IO lines to protocol convertors. This simply shouldn't be a problem for _us_ to solve in the age of ubiquitous and pervasive Ethernet.

I would be curious as to why this wouldn't work, given vendor cooperation :^)

Regards

cww
 
M

Michael Griffin

On October 27, 2003, Thomas Hergenhahn wrote:
(Re: Profibus/ethernet gateway in a D-Shell).
<clip>
> Yes and there are more. I think, the original manufacturere is Hilscher
> (www.hilscher.de), because I found the name in some data sent by the
> device.
<clip>

It appears that Hischer is the original manufacturer. They call it "Netlink" and they mention that they do custom OEM versions. It is likely that it is based on some of the chips and modules they also sell to OEMs.

It seems the correct web site address happens to be "hilscher.com", rather than "hilscher.de". The former does industrial communications, while the latter appears to make artificial legs.

> If you want the manual( PDF format,English?, at least German, I do not have
> the disk at hand now) which came with the device send me a private mail.
> You can find my address on: libnodave.sourceforge.net
<clip>

Thank you for the offer, but at this time my interest is not serious enough to put you to that trouble. I will follow this up further with Hilscher or their distributors when I my needs for it are more immediate.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
A

Automation Linse

Is anyone interested in helping me create a simple "Recommendation" for a nice low-level API to be used to create sharable/reusable code for simple PLC protocols? We will NOT be creating any code, just a simple document & API (model?) for talking to things like Modbus, DF1, SNP, HostLink, etc.

Grand goal would be if I share some Modbus code that follows this doc & API, then someone else using the same API with say DF1 would be able to absorb & reuse my code with a minimum of effort to add Modbus. Target is small embedded system - not Windows class solutions & not DDL or linkable modules. No bloat, VM, or everything-is-32-bit assumptions.

Anyone interested, contact me at lynn at iatips.com (plus the @ in the right place ;^)

Again, this isn't a coding project - but I'll probably create a simple Modbus code for the API as test/proof/example.

best regards
- LynnL, www.digi.com
 
Top