Is LinuxPLC heading down the "proprietry" hardware path?

C

Campbell, David (Ex AS17)

There has been much discussion on this lately about hardware & IO interface boards. The following email has been formatted for a fix pitch font (includes ASCII art) so don't complain if the formatting looks "wierd". My opinion (which doesn't count for much as I only wield a soldering iron for the odd serial cable) is as follows: 1) LinuxPLC should have a common framework to allow interface development for connecting to ANY hardware vendor IO rack providing the protocol document is in the public domain (or at least obtained without signing any non-disclosure agreement). 2) We should not be attempting to replicate existing vendors solutions. This means we should spend effort designing and constructing IO boards. There are several reasons for this: 2.1) Safety certification - Impossible (or extremely difficult) to obtained for a GPL (or similar) hardware implementation 2.2) Economies of scale - How many people are prepared to make a 1,000 unit run of a IO module board? 2.3) The PLC market is rather cut-throat already (highly competitive). 2.X) EXCEPTION: Low IO count or specialised IO (eg: student introduction to PLCs) where "fool proof" safety is sufficient and "idiot proof" is not required. (with reference to email threads about "unknown powerup state of 8255" is not acceptable in an industrial environment). This area is largely ignored by 99% of the vendors. Curt Wuollet has raised the issue that there very few hardware vendors that offer ethernet support for PLCs at competative prices. I have several questions which need to be answered: 1) What advantages does ethernet give over serial? 1.1) Higher speed? 1.2) Longer cable runs? 1.3) Lower total cost? (including cabling) 1.4) "multi-threaded" access? (two machines simulataneously accessing one PLC) 2) What price are people prepared to pay for ethernet access? 2.1) Nothing? 2.2) US$100/PLC? 2.3) US$200/PLC? 2.4) US$400/PLC? I believe Curt may of touched on an area where LinuxPLC could spread like wildfire through the automation arena. Practically every IO device with a serial port appears to support MODBUS (some better than others). I have just done a web trawl looking at ethernet<=>serial interfaces, typically this involve terminal servers which have a port price varying from USD$100 to USD$400/serial port (32 to 4 port devices respectively). Hence I ruled out these devices almost immediately (although Shiva does appear to have a relatively cheap single port device, since their acquisition by Intel this device has vanished from the face of the internet). I looked around for other solutions, I came across print servers which support bi-directional parallel ports. There were a couple of print servers (notably 3 port devices, 2P+1S) which supported serial printers. There was a lack of information whether the serial port was bi-directional. If a cheap bi-directional parallel port<=>serial convertor exists then it might be possible to use LinuxPLC as a "generic" MODBUS-TCP <=> MODBUS-Serial convertor. The following table is some pricing of network printservers: Unit Price Port Price Netgear 2 port USD$122 USD$61 Netgear 3 port USD$200 USD$67 DLink 2+1 port USD$154 USD$77 [1] Netcomm 3 port USD$232 USD$78 Netcomm 1 port USD$92 USD$92 DLink 1 port USD$116 USD$116 HP JD-170x 1 port USD$144 USD$144 [1] 2 Parallel + 1 Serial, assuming serial port is uni-directional. If serial port is bi-directional then it makes the DLink product very attractive. [2] All prices based on Australian web-sites converted to USD, hence prices will vary from country to country. [3] Netcomm => http://www.netcomm.com.au/ On to the next part of the problem: Parallel to serial convertor Black Box USD$119 DataPro SXP325-256 USD$119 Pacific Custom Cable USD$68 Patton 2030 USD$??? (not listed) [1] CableXpress USD$79 [1] http://www.patton.com/, huge range of serial convertors It appears that the interface hardware will be around USD$130 per port. I suspect that it could be done for less... Personally I believe the above prices for convertors are twice what they should be. Now to put the whole thing together: +-----+ +-----+ +-----+ +-----+ | P C | | P C | | P C | | P C | +--+--+ +--+--+ +--+--+ +--+--+ | | | | --+---------------+-------+-------+---------------+-- | Ethernet / MODBUS-TCP | +-------------+--------------+ | LinuxPLC MODBUS-TCP Driver | +-------------+--------------+ | +-------------+--------------+ | LinuxPLC Core Libraries | +-------------+--------------+ | +---------------+----------------+ | LinuxPLC MODBUS-Serial Driver | +---------------+----------------+ | +---------------+----------------+ | UNIX socket to TCP-IP socket | | process (glorified pipe) | +---------------+----------------+ | | Ethernet/TCP-IP ------+-------------------+-------------------------- | +----+----+ | Print | | Server | MODBUS-Serial +-+-----+-+ | | | +-----------------------+ \/ +-------+ | +----+ IEEE 1284 <-> RS-232C +-----+ PLC | | +-----------------------+ +-------+ | | +-----------------------+ +-------+ +----------+ IEEE 1284 <-> RS-232C +-----+ PLC | +-----------------------+ +-------+ Feel free to comment, critise or flame the above idea. I am attempting to find a niche area in the current PLC market where LinuxPLC could thrive. Anyway, thats my 5 cents (2 cent coins have been withdrawn from circulation in Australia, worth about USD$0.02). Comments Curt? David Campbell _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

C

Curt Wuollet

Let me sleep on it Dave, I've been so tightly focused on getting _any_ real world IO for LPLC that I haven't been thinking that far ahead. One of the goals of LPLC is to be the great go between for all the protos we can support. The Ethernet IO thing still has a window open and I'm determined to get us into that gap. The big guns in the industry are frantically trying to decommoditize Ethernet and we can save the world from that if we commoditize it. Where you're coming from is not gelling with me but I've been laying down tracks on the DIO48 thing for hours and nothing makes much sense tonight. I'll look at it again in the morning. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

C

Curt Wuollet

Hi Dave In a word, Yes. I guess I have assumed all along the we will be able to do things like this. What LPLC would offer is doing it with Automation Programmer tools rather than Linux systems programmer tools. We have talked from the very earliest about being a great go between. By the way, I make my living at the moment using Linux to connect incompatible automation junk. There must be a need as I'm still working :^) Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

H

Hugh Jack

I think care is needed to emphasize that while some of the group is enthusiastically discussing "proprietary" (yet free and open) hardware and software, the core controller will not require the "proprietary" hardware to run. In other words, you will not be forced to use the new hardware to use the Puffin PLC -- but you will have a choice. From other perspectives, this discussion is involving people who have not been working on parts of the project. So... it is not draining resources, or diluting the focus. Hugh _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

A

Andrew G.Treves

&lt;<message snipped>> To start with all that is required is an RS232 / RS485 driver either 2 wire or 4 wire to drive straight into Modbus. This then will drive a large variety of process control and PLC hardware with the appropriate coil and register mappings for the intended target. In particular most variable speed drives can be controlled this way. We have been looking for such a device for the last five years. PC cards and converters are readily available or you can knock something up on veroboard using a MAX485 chip. Andrew G.Treves, Peak District, Derbyshire, UK Tel: +44 (0) 1246 582219 Fax: +44 (0) 870 7062393 [email protected]9.net _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

A

Andrew Kohlsmith

> Where you're coming from is not gelling with me but I've been > laying down tracks on the DIO48 thing for hours and nothing makes > much sense tonight. I'll look at it again in the morning. I'd been watching this for a while... the DIO48 is the IO board discussed last week? Regards, Andrew _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

C

Curt Wuollet

By way of a reply and an announcement: What started small has grown a bit: In a few more hours we will have full industrial strength IO for Linux. Rather than compromise, I took a survey of PLC vendors IO specs and produced a fully compatible design. Pro Version: Design features: 24 Fully optoisolated sinking/sourcing inputs. May be strapped in groups of 8 for sinking or sourcing use with provision for fast or slow filtering. 5000 V. isolation group to PC. The option exists for adjusting logic thresholds. 24 Fully optoisolated NPN OC outputs with integral protection diodes. Common strapped in groups of 8 with 5000 V isolation to PC and XXX group to group depending on construction. Outputs sink .5 ADC. Very generous duty cycle and # outputs on specs. TBD but should be better than the big guys. External fusing. Provision for fixed or removable rising elevator contact terminal strips. Industrial layout and design rules. All through hole devices. Board should be sprayed with clear acrylic to maintain isolation in dirty environments. Hobby/lab version: Cheap, for when the PC is the machine and isolation is not a problem. 24 sinking voltage divider inputs with provision for filtering. 24 NPN OC sinking outputs with .5 ADC capability. May be used with or without terminals. Believe it or not, decent terminals are the single biggest expense for these boards.. The Hobby/lab artwork should appear in a week or two after I fab and test the pro board. There are a lot of lines and connections and there may even be an oops or two so I want to verify the artwork/design before I derive the second board, I will be offering the Pro version to the folks at my day job for fab and testing to meet needs we currently have. This is how I plan to test the Pro version. The Hobby/lab version will probably need to be fabbed and tested by the user. I will request that the proto house I use retain artwork/etc so boards can be ordered with fast turnaround. Artwork for both versions will remain the property of the LPLC project. They are produced in pcb, the free open source layout tool and are freely editable. The input and output cells can be used for other projects (if they work :^)) saving considerable time and effort to support other boards. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc