Fieldbuses and serious intentions for controls, was Linux and I/O connectivity

D

Thread Starter

Daniel Boone

Curt,
Definitely, you're right about the costs inherent with installing a fieldbus type system. They always require a formal controller board at
the top (DeviceNet, Profibus, InterBus, LonWORKS, etc.) which introduces considerable cost to the project. However, it is my experience that having that controller board takes the burden from the programmer. Using a controller card means they won't have to worry about what's
going on down at the lower four layers of the ISO/OSI network model. The programmer can then free up to write code for the upper three, including the wonderful Application layer.
(The code necessary to support below the fourth layer can get horrendous.)
With DeviceNet, Profibus and InterBus (not sure about LonWORKS), there is no licensing fee beyond purchasing a controller board for the
computer. Otherwise, that would really suck. Their controller boards handle pretty much everything, save setting up the IRQ, I/O port address and MPM addresses.
The audience we're catering to, especially via this organization, may eventually be the paying audience that wants the Puffin PLC to run
their dairy farm, manage their material handling system, build their automobiles (hey, we can dream, can't we?), or refine their oils. In this market, the company is not going to be enamored with the idea of it being totally free, but will definitely want it to be robust.
Regarding the IEC-61131 side, I can offer some information, as I use this in my job.

-Dan

***********************************************************************************
Curt wrote:

"On the fieldbus thing, It's not that we're enamored with Modbus. It's that
Modbus is pretty close to Open by our definition. That means we don't have
to license anything, buy anything, join anything, or even sign anything to use
it. Most other offerings may be open by _their _ definition, but what that
typically means is that if we throw a lot of money their way and watch the
licensing or join the association or sign NDA's then we're free to use it.
Or that their licensed product will work with any licensed product, with
licenses requiring $25,000.00 worth of conformance testing. As you can see
this type of extortion is not compatible with the nature of our project.
Especially since the budget for buying proprietary products is up to $0.27.
If you can find a way that we can impliment those protocols without massive
cash outlay and compromising legal agreements, I'm all ears.
The only route that seems open for supporting these is to write for cards
that have the protocols embedded. That way all the proprieties belong to
the company that makes the card. This has the disadvantage of being
rather expensive. It does however have advantages in that these rather
busy protocols run on their own processor.

On the IEC-61131 side, we can definately use some detailed knowledge as
eventually we will want to support these."


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

Curt Wuollet

Hi Daniel

Read the post I did today. We're mostly in agreement. If we are going to be in the
proprietary fieldbus game we have to acccept prices that bear no relation to value.
The coprocessor cards will allow us to support those protocols. We have a vendor who wants to make it possible for us to support those protocols and we had ought to embrace that relationship. We also need Modbus/TCP as it is simple enough to do in software and at least an order of magnitude less expensive in any real
world application because it runs on commodity network gear..
Trying to support some other protocols in software is full of IP problems and legal
headaches. It would be much cheaper to use a straight CAN card and do the DN in software but, that is where we run into the compliance testing and certification scam. I am of the opinion that we had ought to have a reasonable alternative
in line with the low cost of the system but support $$$$$$Buses if that's what the user needs.

Oh, please don't send html mail, some people use pine, etc.

Regards

cww


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

This is a great thread, and as a multiple fieldbus vendor I'd like to add my comments,
interspersed...

>> From: Daniel Boone <[email protected]>
>> People,
>> I have been touring the Puffin Project site and have signed on as a
>> member (?) out of ambitious interest. Although I am not a hardcore C/C++
>> programmer, I do work with the IEC-61131-3 languages as a consultant.
>> I would also like to respectfully submit an idea to the project on
>> other I/O methods. Although the Modbus is a longstanding protocol, there
>> are also others available which offer more reach and capacity for the true PLC
>> programmer. Specifically, I feel that we should actively include other open
>> bus protocols under the umbrella of IEC-61158.
>> Within the definition of IEC-61158, these are truly open fieldbuses
>> which allow one to design a control system of much greater capacity and
>> speed than the Modbus protocol. Included in this definition are Profibus and
>> InterBus. Both are German-made fieldbuses with a strong following in the
>> automation sector.

I 100% agree with the sentiment of Dan's question -- even though IEC61158 is politically embarassing, it recognizes that fact that no one bus will be perfect for everybody. It incorporates Foundation Fieldbus H1 & HSE,
ControlNet, Profibus, DeviceNet, Pnet, Swiftnet, WorldFIP and Interbus-S, all under a single standard.

It naturally raises the question of how to support these with LinuxPLC...

Curt said:

>> On the fieldbus thing, It's not that we're enamored with Modbus. It's
>> that Modbus is pretty close to Open by our definition. That means we don't have
>> to license anything, buy anything, join anything, or even sign anything to
>> use it. Most other offerings may be open by _their _ definition, but what
>> that typically means is that if we throw a lot of money their way and watch the
>> licensing or join the association or sign NDA's then we're free to use it.
>> Or that their licensed product will work with any licensed product, with
>> licenses requiring $25,000.00 worth of conformance testing. As you can see
>> this type of extortion is not compatible with the nature of our project.
>> Especially since the budget for buying proprietary products is up to $0.27.
>> If you can find a way that we can impliment those protocols without massive
>> cash outlay and compromising legal agreements, I'm all ears.

This is a complex issue, and it will take a fair amount of time to come up with a legally unentangled, functional, application-ready LPLC implementation. Note that most of these protocols use special ASICS. Naturally Ethernet
comes to mind as an alternative to all of this, but there are many applications where Ethernet is a poor choice for industrial I/O.

>> The only route that seems open for supporting these is to write for cards
>> that have the protocols embedded. That way all the proprieties belong to
>> the company that makes the card. This has the disadvantage of being
>> rather expensive. It does however have advantages in that these rather
>> busy protocols run on their own processor.

That's the kind of solution I provide, and I can vouch for the fact that using a co-processor card instead of your host CPU has a lot of performance
and modularity advantages. For example, there are a number of vendors who provide passive CAN cards and DeviceNet stacks for Windows, but the performance is very limited, and if your hard drive does anything, all network communication goes away for 200 msec while the OS does hard drive stuff.

Dan said essentially the same thing:

Curt,
Definitely, you're right about the costs inherent with
installing a fieldbus type system. They always require
a formal controller board at the top (DeviceNet, Profibus,
InterBus, LonWORKS, etc.) which introduces
considerable cost to the project. However, it is my
experience that having that controller board takes
the burden from the programmer. Using a controller
card means they won't have to worry about what's
going on down at the lower four layers of the ISO/OSI
network model. The programmer can then free up to
write code for the upper three, including the wonderful
Application layer.
(The code necessary to support below the fourth
layer can get horrendous.)
With DeviceNet, Profibus and InterBus (not sure
about LonWORKS), there is no licensing fee
beyond purchasing a controller board for the
computer. Otherwise, that would really suck.
Their controller boards handle pretty much
everything, save setting up the IRQ, I/O port
address and MPM addresses.
The audience we're catering to, especially via
this organization, may eventually be the paying
audience that wants the Puffin PLC to run their
dairy farm, manage their material handling system,
build their automobiles (hey, we can dream, can't we?),
or refine their oils. In this market, the company is
not going to be enamored with the idea of it being
totally free, but will definitely want it to be robust.

-Dan

>> Oh, On a somewhat related note, Perry Sink of fieldbus card fame also
>> writes for several trade publications. He has been conducting a sort of
>> email interview with yours truly on The Linux PLC. These questions and
>> answers to possibly show up in said trade publications as an article and/or
>> interview.

Yes, look for such material in at least two major control magazines in early 2001.

>> Curt, I can see your point, but there are available solutions, such as =
>> devicenet Bus MAster cards which include an API on how to use them and =
>> source code for the firmware. (SBS-Greenspring's IP-Deveicenet is one ... =
>> ) Surely one would not need to have conformance testing and highly =
>> detailed knowledge of the spec just to interface to this card??

This is true, and if using such a card gives you a satisfactory I/O solution, then developers can focus their efforts on programming GUIs and HMI.

>> I have one
>> of those cards at my company, but , unfortunately I don't have any =
>> devicenet IO devices to plug into it, so I can't really do any decent =
>> testing with it. :eek:(
>> ~Ken

Synergetic has recently completed a Linux driver which operates with all our co-processor based cards - DeviceNet, Profibus DP/FMS, Interbus,
ControlNet, AS-Interface and CANopen; master and slave in most cases. Ethernet implementations are in development.

This was mentioned in an earlier thread, at
http://www.control.com/control_com/974754005/index_html

The driver is GPL, and details + free downloads at
http://www.synergetic.com/linux

I'd like to invite anyone on the LPLC project to play with this driver and contribute any improvements.

For purposes of making this driver a standard part of the LPLC suite of tools and solutions, I'll do my best to accomodate developers with appropriate hardware. Please contact me directly if you're interested.

Sincerely,

Perry

Perry Sink | Synergetic Micro Systems
[email protected] | www.synergetic.com
+1/ 630.434.1770 | 630.434.1987 fax

____________________________________________
Embed DeviceNet, Profibus and even WWW capability
into your products: See http://www.synergetic.com/oem

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