# Linux and I/O connectivity

D

#### Daniel Boone

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.
With a little investigation, I have been able to locate a project out of Luxembourg that developed a Solar Energy plant completely on
the Linux platform while utilizing InterBus as the fieldbus (URL:
<http://www.santel.lu/projects/wallace/interbus.html>). These guys have even included their own tarball of the InterBus fieldbus driver for Linux
(<http://www.santel.lu/projects/wallace/interbus.html>). It blew me away the first time I found this. If you want your own copy of the I/O driver, it's there.
Furthermore, I have found that the company National Instruments has developed their own Linux platform software (LabVIEW) for controls and data acquisition (LabVIEW Full Development System for Linux) for about $2,000. So, as I see, there IS a future for Linux in controls. -Dan Boone Q: What's the national anthem of the jungle? A: Tarzan Stripes Forever _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc C #### Curt Wuollet Welcome Dan'l We don't get that many historical figures here :^) Hadn't seen the InterBus port, I'll check it out. 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.

Again, Welcome!

Regards

cww

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

K

#### Ken E.

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?? 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. (

~Ken

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

C

#### Curt Wuollet

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.

Regards

cww

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

C

#### Curt Wuollet

Hi Ken

These are the types of card that I mention as the only reasonable solution at present. SBS has done the conformance testing, bribed the ODVA, kissed the right posteriors, etc., etc. to call their card a branded DeviceNet tm. product..
SST also make some along with Softing, Synergetic (who _wants_ to work with us), and a few others. Typically they have an on board processor that runs the protocol and maps things to a mailbox and registers in a memory window.

We can use these cards with little regard for the proprietary protocol licensing, yada, yada, yada. But as you mention, you get source for the firmware. That source is almost always licensed and can't be a part of the project and there is some question about software derived from carnal knowledge of that software. That's why I have been working with Synergetic to GPL their driver. That we can use or copy or modify without problems. The problem is that we are a
Free, Open Project in the most litagious, proprietary, avaricious segment of the computer industry and proprietary intellectual property sneaking into the project is a trojan horse for someone to shut us down at will. That's why our
relationship with Synergetic is important, they have the products and are willing to do what it takes to avoid compromising our code base. It's worth quite a bit not to have to do a hostile reverse engineering job. If we can make this relationship work we have a cooperating vendor with no legal problems for all the protocols they support. This_is_crucial for us to support those protocols that people want to use. We _must_ eventually support all those protos and having a vendor that wants to help us do it sidesteps one
of the biggest and potentially fatal roadblocks in our path. If I could afford to I would take a leave of absence to make this happen as the number one goal we have is to talk to everything within reason. This is coming from someone who is loathe to get in bed with any proprietary vendor. It is a real breakthrough on the connectivity problem and we need to capitalize on it.

Regards

cww

PS I am not lecturing Ken here, this is important for all on the project. It is an epiphany I had, and I really want to stress what a break this can be.

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