Another I/O Question for the list

C

Thread Starter

Curt Wuollet

Hi all

I have been checking out low cost I/O options for the LinuxPLC. Phil found some stuff from Optimate that meets all my criteria save one. The problem is the protocol. This is a major headache and I'd like some opinions from the field. Ethernet I/O is very desirable as it lets us avoid the whole fieldbus issue. Ethernet I/O is fast, the network is cheap and ubiquitous and the installed cost is at least an order of magnitude cheaper than proprietary fieldbus (and there is no Open fieldbus).

The problem is in the protocols. This is the second EIO solution I have looked at. The Opto22 ENET racks were the first. They are expensive
but support Modbus/TCP, the closest thing to an Open Protocol. The problem is, they don't support it very well. It's an add-on. What they want you to use is a published proto based on IEEE1394 (firewire) block transfers. This is those packets over ethernet not firewire.

This is a non-standard proto that is used by them alone as far as I can tell. It would be much faster than their implimentation of Modbus/TCP
because they support only five (5) of the Modbus/TCP operations.

This new Optimate stuff is much cheaper, offers higher density, but the protocol used is entirely proprietary. It is not even published that I could
see. Phil says they're Linux friendly so, I'm sure they will give you the info to write a driver.

This is what is destroying the promise of Ethernet. Everybody whos uses it puts their own proto on top of it. This turns Ethernet which is a great Open success in the IT industry, into simply another non-interoperable mess. To use Ethernet sounds good for advertising but the way they are doing it negates most of the value IMHO.

What do we do, support the closed protos to get functionality or hold out for interoperability?

Regards
cww



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

Johan Bengtsson

I say both, eventually, the question is more about where to start. The more support for different hardware the better....

/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
 
W

Wallinius Mattias

Sorry guys,
I am listening to the very interesting discussions on this list, but I have to make people dissapointed when it comes to I/O over ethernet. It's not, as most people tend to assume, cheaper to have ethernet I/O in normal
industrial automation. Looking at only the hardware and installation costs it's much more expensive than Profibus DP, Devicenet and so forth. If the Puffin PLC shall be widely used a support for all of the major fieldbuses must be implemented. This is a reality I am sorry to say. If support for three our four of the fieldbuses is added then this will be sufficient. There is a market place out there and that must never be forgotten.

/Mattias Wallinius, Systems Engineer.
Tetra Pak Converting Technologies AB
Ruben Rausings gata
S-221 86 Lund
Tel: +4646361248
Fax: +4646362504
Email: [email protected]


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

Phil Covington

> I am listning to the very interesting discussions on this list, but I have
> to make people dissapointed when it comes to I/O over ethernet. It's not, as
> most people tend to assume, cheaper to have ethernet I/O in normal
> industrial automation. Looking at only the hardware and installation costs
> it's much more expensive than Profibus DP, Devicenet and so forth.

Just to state that Ethernet I/O is more expensive is not good enough... Would you like to give us some supporting evidence for your claim?

> If the
> Puffin PLC shall be widely used a support for all of the major fieldbuses must be implemented.

I don't think anyone here is advocating *ONLY* supporting Ethernet I/O... Of course, to be useful, the LPLC will have to support as many different I/O system as there are people interested in writing drivers for them :)

I think that Curt was asking the question about I/O since he wants to at least get some code going for the LPLC. He was not advocating supporting only that type of I/O. Curt, I think, wants to get something together so that people can download it and try it. This will hopefully get people interested in supporting the project again and will provide a starting point for future refinement and development.

>This is a reality I am sorry to say. If support for
> three our four of the fieldbuses is added then this will be sufficient.
> There is amarket place out there and that must never be forgotten.

The reality is that there is no code yet for the LPLC. There has to be a starting place and it won't support everybody's favorite I/O (unless that person takes it upon himself to code that part).

I think that it is important to get some code going before anyone starts to ignore the marketplace ;-)

Phil Covington

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

Wallinius Mattias

Ethernet is about 2.5 to 3 times more expensive to install on a printing machine than Profibus DP. And there is also the fact that even though you are using switched ethernet, still ethernet has some problems with overflow of buffers and non deterministic behaviour. The OMAC or GM boys have done some work as well and state some different ideas but still there is a small
amount of uncertainty about ethernet. We have encountered these problems during testing and therefore we actually know this! I know that you are trying to get things rolling and I admire your
commitment, it's not that. I merely think that using some other type of communication for the I/O would create more interest. I also know from my own experiences both with RTLinux and with RTAI that the support for Ethernet drivers are there and easy to use. I am currently writing an RTAI driver for Profibus DP, using the Siemens 5611 card and I am willing to make it available to the discussion group whem it is finished. As for all of us the amount of available time is the problem.
/Mattias

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

Curt Wuollet

Hi Wallinius;

You must be getting your Ethernet at the wrong place, please explain. Here I can get an 8 port hub for less than a profibus connector, wire at < $.10 per foot, and 10/100BaseT cards for $30.00. and 8 inputs and 8 outputs of ethernet distributed I/O for about $15.00 a port. Just the
wire for profibus for an equivalent area would be double the cost of the whole Ethernet setup. I think I'm missing something. Or you've gotta tell me where you're getting your Profibus stuff :^).

Regards

cww


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

Wallinius Mattias

Well as I wrote Hubs are no good in a machine, actually they are out of question, non deterministic. UTP is not applicable in a machine unless you put it in shielded pipes, pretty expensive I can assure you. STP cable is
impossible to buy for < $.10 per foot, at least in Sweden. I have never paid more for a Profibus connector than a hub??? I know that for personal use buying stuff like Profibus is impossible but we are talking control equipment here not "home automation". I agree that the issue with pricelists and then reductions are a commersial mess but that's the way it is. What I refer to is an investigation we have made where the actual cost for an ethernet application was 2.5 to three times more expensive on the machine than Profibus. I merely suggested this in order to make the project more attractive to more than believers. Just to mention to you we don't pay more than about $ 0.5 /meter Profibus cable. Do you want the equipment? I would gladly send you some cable and connectors for free and I might be able to arrange a Profibus card for you as well.
;-)
/Mattias

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R
A quick comment to the contrary:

On an OEM machine control system we build (for a competitor of Tetrapak, as it turns out), we use a PC/104 motherboard with built-in ethernet
communicating over a crossover ethernet cable to a H2-ECOM module from AutomationDirect.Com. We use the PLC as a PLC, and the HMI as an HMI
(meaning of course, we're not using a PC-based control solution.) We wrote all of the code for both the PLC and the HMI.

I did not evaluate any serial options, having ruled them out as too slow, comparatively. (The H2-ECOM is good for about 3 mbps.) Because this is a fairly consolidated application we were able to use a single cable, avoiding any questions about hubs, etc. Also, the machine lends itself to the cabling, given that we use the frame as "conduit".

I could have done this via a serial protocol less expensively, though I do not believe it would have been either faster or easier. Yes, it would have been less expensive, but not significantly so (savings would be $275 we pay for the H2-ECOM module.)

Using the AutomationDirect hardware (whether a combination of a CPU like the D2-250 and ethernet module, or using a base controller like the H2-EBC) gives the added benefit of converting from ethernet to serial at the base PLC rack. On the application above, some machines have an I/O count which we cannot achieve using only one PLC base. By adding the D2-RMSM and D2-RSSS (Remote Master/Remote Slave pair) we can extend the I/O count, as well as the dispersion, significantly.

Regards,
Rob Martin
Systems Engineering Manager
JAC Manufacturing Inc.

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

Curt Wuollet

Hi, Wallinius.

On a machine I'd do thinnet coax daisy chained. This limits you to 10mbs but eliminates hubs. You can get hardline for the greasy spots. Understand
that I'm not doubting you, just wondering how you can do Profibus that cheaply. The card is a good example. Here for a PC Profibus master they want close to $1000.00 (I looked at SST for the LinuxPLC) Connectors are $80.00, Cable $1.50 a foot. On a machine you wouldn't use much cable perhaps. I lead a dual life, during the day I do Industrial Automation and at night I am trying to do the LPLC along with Linux consulting. The day job can afford to do proprietary networks, but, one of the things I want as a selling point for the LPLC is that it uses commodity hardware to maximum advantage. I am a big fan of Ethernet I/O because it's the native network for Linux and, if the establishment folks don't render it useless by putting 500 different incompatible protos on top of it, it will become the defacto standard before long. There's 1000 times more Ethernet in the world than all the proprietary offerings combined. We should be able to capitalize on that. If you could donate a card, hold tight until someone wants to tackle a Profibus driver. There's code out there, but we will need some glue to get it to work with the IO scheme. My main concern right now is something that people can buy out of petty cash to play with the project.

Regards

cww

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

Noel Yarborough

Check out the Ethernet I/O solutions from AutomationDirect (AutomationDirect.com). The H2-ECOM is a ethernet base controller and is available in both 10 Base T and fiberoptic, both support IP/IPX and UDP/IP.
the 10BT controller goes for $259.00. Add a base (6 slot $130.00, 9 slot $170.00) which includes power supply, I/O modules (8 pt 24vdc in $42.00, 32 pt 24vdc in $108.00, 8 pt 24vdc out $46.00, 32 pt 24vdc out $102.00) and you have a very nice low-cost I/O solution. A good variety of analog modules (0-5VDC, 0-10VDC, 4-20 mA, RTD, T/C, etc)is also available at resonable cost. The Optimate I/O is cheaper, but I think this is the better solution.
I'm currently using the AutomationDirect I/O with think-n-do software (thinkndo.com) on NT without any problems.
Good Luck...
 
Phil Covington:
> I don't think anyone here is advocating *ONLY* supporting Ethernet I/O...
> Of course, to be useful, the LPLC will have to support as many different
> I/O system as there are people interested in writing drivers for them :)

I think the above paragraph is really the key to the question.

LinuxPLC will *not* be a monolithic monster. It will be a modular kit.

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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