"Open" Hardware.

P

Peter Wurmsdobler

Kipton,

> The approach we are taking is to have the I/O on a 8051 board, and
> communicate the I/O over 10 base T Ethernet to a Linux box using IP.

This sounds great. How will the linux box get i/o information on IP? Could you give me a sort of c-code example, how the linux box could quesry and set remote io?
FYI: "http://www.sixnetio.com/special_index_pages/index_linux_ipm.html":http://www.sixnetio.com/special_index_pages/index_linux_ipm.html

will acomplish a similar job.
peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax _______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
P

Peter Wurmsdobler

Curt,

> This is a spec for a PLC form factor, PLC compatible, PLC cost
> competitive machine that will do mostly discrete IO and PLC grade A/D
> and D/A. It will also handle anything you can get in a PC104 module.
> With no GUI, a fanless industrial grade CPU of modest horsepower will
> provide superior performance to most PLC families.

I totally agree with you. Any fancy computation can be done on cPCI or PCI architecture, which costs much mor and might be an overshoot in may cases. What could be suficcient is a single PC104 CPU board with one additional board providing either a couple of digital io points or rather a devicenet/ethernet or whatever network io board. You can put this in a half-a-brick enclosure, put Linux on it, and on top a run time system executing PLC code. peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax _______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Peter

It's interesting that there doesn't seem to be a machine to machine protocol that's open and well suited to automation. Socket to socket would be ideal of course, as it's then suitable for intra machine as well as inter machine use. A very useful model for automation use
would be simply a virtual array of registers. This would trivialize communications even in RLL. The problem with a lot of the closed
offerings is that they have a lot of high level cruft and bloat thst results from adapting IS and office software mechanisms when the job to be done in the automation world is often trivial and rather obvious. Most are examples of using 50,000 lines of code to move an integer from one register to another. Horrendously inefficient. For IO, I favor Modbus and Modbus/TCP. Not that they are fantastic, but because they are nearly ubiquitous and nearly open enough and doable without custom silicon.

Do you have some favorites for consideration?

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux. _______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Peter

And the part that a lot of folks seem to be missing is that my bus is strictly for running PLC style IO, in limited quantities. With all but the more basic CPU cards you have the option of PC104-plus which is a PCI spec addition to the ISA like PC104. So you can run very high speed modules by simply stacking them on top of the CPU. This gives you very good capabilities in a
PLC form factor package. You aren't really giving up anything if the "PLC" bus is downsized to suit cost and purpose. And of course, our favorite 10/100mb. Ethernet is usually integrated into the CPU and not hobbled by either of the
expansion busses. All I'm doing is providing the
"standard equipment" to be used like a PLC at PLC speeds.

Regards.

cww

PS I wonder how Jiri's doing?

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux. _______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
P

Peter Wurmsdobler

Curt,

Socket connection would be my preference also, but on top a higher level protocol ist needed, such as passing a struct or so.

> Do you have some favorites for consideration?<

Modbus/IP would be a starting point, as the protocol is very straight forward and it is publicly available. I also thought of something the PuffinSCADA guys have developed for UNIX systems. They have also a ModBus driver, but maybe their protocol can be implemented natively, if I understand their work correctly.

Or develop something from scratch? What information has to be exchanged, published by or request from a control system component? registers?
values of i/o points?, or even even PLC programs and rungs? But in which format then. Just some thoughts.

Or OPC ? (this is a joke),
peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax _______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
K

Kipton Moravec

We are not that far yet. I am meeting with my partner tomorrow (Sunday) maybe I can have an answer for you then.

Let me not speculate on the exact calls until I talk to my partner.

To keep it simple I think you ask for the status, and it will dump all the inputs in one burst. (There is not that many bytes total.) To write you do the same thing, one structure for all of the outputs. Again not so many bytes. I am guessing 20 bytes. It keeps the number of packets transmitted and received low. We will provide a Linux driver that you call from C with the MAC address of the unit for straight IP (non routing), or the IP address if you want a routable TCP/IP address.

At the moment I think you will configure it initially via RS-232 and a terminal program. The parameters will be stored in EEPROM.

These things could change as everything is very fluid at this time. I expect things will be more locked down in a couple of weeks.

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

Peter Wurmsdobler

Kipton,

> To keep it simple I think you ask for the status, and it will dump all
> the inputs in one burst. (There is not that many bytes total.) To
> write you do the same thing, one structure for all of the outputs.

This sounds simple, straight and predictible. Given your remote io is on an ethernet segment, once could integrate in a potential PLC run time
system a call read (IP,*image) and write (IP,&image) read from the device and a write to the device, respectively. How to set it up? Could the PLC query in the sense : tell me what you have! or does the PLC have to know the remote i/o in advance?
peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax _______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
K

Kipton Moravec

Right now we have one customer with one very specific board for controlling the flow of dangerous chemicals.

However, I see this as being a family of boards, It would be nice to have
a unit with a bunch of digital I/O and some 4-20 mA inputs and outputs too. I think each board type will have a unique identifier, so you can lookup the structure based on the board type.

I have been toying with the idea of offering a web socket for TCP/IP enabled ones, so you can see it from your web browser. This will help confirm it is online, and you can make sure the data you get from your PLC was interpreted correctly

The PLC will have to know the remote I/O anyway, whether I tell it to you or not. You will have to map devices in the PLC to the I/O somewhere. My digital input #1 has to get mapped to say "Manifold Solenoid Status" depending on what you wire to that input.

Even if I told you I have 16 digital I/O that does not mean they are hooked to anything, you still have to know which ones are hooked up.

The first board will also have a LCD display interface, so you can display messages on the remote control panel. For example, the unit has a 4-20 mA pressure gauge, the current is read by the unit, it sends the data to the PLC, the PLC can choose how to interpret the signal, and then what to display. You may want to display the pressure reading, or a message like "Low Pressure".

Kip

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

Aye, and there's the rub. For the greatest utility, each machine would want the data plugged into it's addressable map so these can simply be treated the same as any other point. This would be trivial for comms between two LPLCs or two PUFFINS. When you mix them up, you have need for a machine independent representation on the wire similar to what is done in say, NFS. And it would be nice if the size was dynamic so you are not passing any more data than is needed or sending floats when short ints would do. So maybe an ordered linked list of structs with say ints sent first and then floats. Or the traditional approach of a header that gives number of ints, number of floats and housekeeping. Each machine could then dynamically allocate buffers and attend to mapping them to registers. This would also allow for asymmetrical maps as would almost certainly be the case for SCADA or other primarily one way communications. The beauty of this approach is that all this could be handled
automagically and the registers would just be there. This would all of course, be systems programming, fast and efficient.
I would think this could be coded to operate at wire speed.
For a first pass, x86 GCC native representation should work.
If the closed world wants to play, we could rev in the machine independent stuff or simply let them worry about it :^).

Or we could go for buzzword compliance and use XML or something and send an order of magnitude or two more data to accomplish the same task while invoking 100 times more code.

Those last two statements were jokes.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

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

I like the backplane idea rather than stacking IO on the PC104. It lets us run a substantial IO count at lower cost than stackable modules. And it gives about the same IO count granularity that PLC users expect. ie plugins of 8 or 16 inputs or outputs or perhaps two analog. The modules can be very simple and inexpensive. An 8 input module could have for example: 74HC register @50 cents 2 quad bidirectional optoisolators @$ 4.00 each. resistors at negligable cost and connectors of your choice. The board blanks will be small and cheap in quantity. This is verses more than $100.00 for any kind of PC104 module. That's why I'm doing the backplane. There's simply no point in doing another outragiously expensive platform, that area is well covered.

Regards

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

Harald Albrecht

David Nimmons wrote:
> Observation:
> XML data combined with XML-RPC provides a very good way to
> communicate to the outside world, ie; HMI, etc.

Do you mean XML-RPC or SOAP with RPC?

My .02 euro (note that there is no plural-s for euro): XML-RPC is surely
easy to implement because it is straight to its functionality. No
unnesseary twinkles. However, it is not buzzword-compliant. And it has
no W3C behind it or one of its working groups. SOAP/RPC is a beast. But
you get more support for the whole infrastructure. It is
buzzword-compliant. It has a W3C working group, an official W3C standard
(recommondation). And for its future you will surely get green lights
for your projects easier from managers if you mention "SOAP" -- but not
for "XML-RPC". You will also probably have fewer arguments with firewall
administrators...

Back to my metamodels...
Harald
--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-97703, Fax: +49 241 80-92238

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

Richard Ahnen

Gentlemen,

Wouldn't a platform such as this:

"http://www.applieddata.net/products_master.asp":http://www.applieddata.net/products_master.asp

...has local I/O for E-stop
string & other watchdogs,

& anybody's Ethernet, ModBus RTU, or CAN I/O work well for your purpose(s)?

They already have a Linux image for this platform.

Richard Ahnen
R&D Engineer

GILMAN
A Member of the Johann A. Krause Group
________________________________________________
Gilman Engineering & Manufacturing Co. LLC
305 W Delavan Drive, P.O. Box 1367
Janesville, WI 53547-1367
Phone: 608-741-4787 Fax: 608-757-7028
email: [email protected]
_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Dave

David Nimmons wrote:
>
> 1 question and 1 observation:
>
> Question:
> Would the hardware from Sixnet not provide a suitable platform?

It will, if we can work out all the details. It should be a great platform. PC's will continue to be a great platform. I am addressing a specific market that those two don't. Something that will directly replace a PLC at comparable cost so I can compete in that arena.
I can do what I need to do with a PC and cards and cables and my translator boards. I can't fit that in the enclosures that most PLC's live in. And it wants a display and it's filters cleaned on a regular basis. It may even need cooling on our factory floor. So, another PLC goes in and my next chance is 10 years down the road. There are valid reasons PLC's are popular. I just want LPLC in a package that could reasonably drop in as a replacement. And I want fanless, filterless, industrial tough hardware at a competitive price point. The point that it offers vastly superior capability is moot if you can't compete with a standalone PLC and win.

> Observation:
> XML data combined with XML-RPC provides a very good way to
> communicate to the outside world, ie; HMI, etc.

I agree.

The Hardware:
Let's be clear, I am not proposing that this be THE home for LPLC. This is something I am doing to address the general problem that PC based automation suffers from lack of suitable hardware to go head to head with PLC's in cost and form factor. It is also an experiment to see if Open Hardware can be viable. The fact that I belong to the LPLC project does not mean that I am requiring anyone to support this or bend development efforts to suit. I do intend to run LPLC on it if at all possible and will donate the design to the project for lack of a better home for Open Hardware. I may even decide that it's simply not doable and quit. It's something I can do and something I see a need for. It's a cww project. I of course would welcome support and help because it's an open project too.

The Transparent Ethernet IO thing is something I am proposing for MAT/LPLC. It would of course run on the hardware I propose as well as any other hardware that LPLC will run on. It's an idea that has been banging around in my head for quite a while. I think it would be great if instead of <put protocol/transport here> and all the hassles and setups and licenses and such that that entails, we could simply specify that N registers from this machine be visible on that machine. Poof, communications just became as simple as writing to or reading from a register.
I think this is doable and a really neat way to accomplish the task and couldn't get any simpler for the user. It's clearly doable on Linux hardware, I would like for it to be possible on other hardware that supports TCP/IP. To that end we want to keep it as simple as possible as most other hardware doesn't have a full OS.
I think users of any hardware would like something like this to communicate between machines as the present alternatives are ugly, costly, and in many cases impossible.

Regards

cww
_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C
Maybe, I don't know enough about StrongArm in the areas of VMM, gcc and the like, maybe somebody else does. I know the uCLinux thing is out
because theres no VMM hardware. There are a lot of cool platforms out there. I'm going with x86 because it should be the easiest, if not the cheapest. I would like to see it running on as many platforms as possible.

Regards

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

David Nimmons

I am asking out of ignorance, because I really don't know. What is it you are trying to do that can not be done with the Sixnet stuff?

Curt Wuollet wrote:
>Hi Dave

>David Nimmons wrote:
>>
>> 1 question and 1 observation:
>>
>> Question:
>> Would the hardware from Sixnet not provide a suitable platform?

>It will, if we can work out all the details. It should be a great platform. PC's will continue to be a great platform. I am addressing a specific market that those two don't. Something that will directly replace a PLC at comparable cost so I can compete in that arena. I can do what I need to do with a PC and cards and cables and my translator boards. I can't fit that in the enclosures that most PLC's live in. And it wants a display and it's filters cleaned on a regular basis. It may even need cooling on our factory floor. So, another PLC goes in and my next chance is 10 years down the road. There are valid reasons PLC's are popular. I just want LPLC in a package that could reasonably drop in as a replacement. And I want fanless, filterless, industrial tough hardware at a competitive price point. The point that it offers vastly superior capability is moot if you can't compete with a standalone PLC and win.
>
>LinuxPLC mailing list
>[email protected] >http://lists.linuxplc.org/mailman/listinfo/linuxplc
_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C
Don't feel bad, I seem to be having a problem communicating what I'm
trying to do.

To overcome the resistance to PC control I am trying to remove the obstacles. Call these customer requirements.

It should look like a PLC.
It should cost less that a PLC or at least not more.
It should work like a PLC. No hdd's, floppies, keyboard, display, needed. It should offer a reasonable amount of IO in convenient increments like a PLC so the mix of input/outputs can be tailored to fit the task. All hardware should be industrial grade. It should support a variety of plug in modules that work like PLC modules. DC inputs, AC inputs, Sinking outputs, Sourcing outputs, etc. Field wiring should be reasonably compatible with PLC's. 24 V power should be doable as well. It should offer mounting like a PLC. DIN rail included. In other words it should be reasonable replacement for a PLC.

My requirements:

It should work like a PC and run a Stock Linux distro for development with a compatible pared down version for deployment. processors from 386 class to Athlon class depending on task. Should support full PC functionality for high end projects. No single sourced parts. Purchased parts should be widely available.
Should support fieldbuss, at least Modbus/TCP, Profibus, Devicenet. Completely Open and documented. User should be able to fix, modify, and even add their own modules. Someone with loftier goals should be able to use this as a start for bigger and better things.
Simple enough to build locally if desired. Practical to do so. Identical units commercially built by several vendors in competition
would be best. One would be good. Me if all else fails.

It should be noted that this idea has been done and there is hardware that closely resembles AB PLC's in outware appearance. It is extremely expensive and no linux drivers exist for anything. And I couldn't buy one, they're OEM. Same old lockin ripoff scam. In my view these don't solve the problem. SoftPLC sells some, for the approximate price of a Buick I could use that.

So the short answer to your question is: Be multi sourced, be competitvely priced and fit the same role as a PLC. Theirs is a great RTU, certainly the best from our perspective:^) I am working on the best PLC and/or IO rack from our perspcctive. They fit different places for different functions. I want a way to make LPLC a PLC when I need a PLC.

Regards

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

David Nimmons

I am aware of the existence of Sixnet but don't really know much in the way of details about their offerings ( Hope to obtain some of their stuff in the near future). So if I appear dense, I am. If I understand correctly, your objection is that they don't offer local I/O in a typical plc type chassis. Is that correct?

_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
Thread starter Similar threads Forum Replies Date
C Open Control 29
W Programmable Logic Controller - PLC 175
K LinuxPLC Project 8
K LinuxPLC Project 6
C Open Control 10
Top