# puffinbus

P

#### Philip Costigan

Hi everyone.

I have been pondering on an idea put forward about the problem of proprietry busses (modbus, profibus, devicenet et. etc.) . Someone mentioned that to truly have an open source bus, we would have to create our own linux plc bus.

So I wrote some code to see if the idea was plausable. (its a bit scrappy at the moment but thats another story).

May I put this proposal to the linux PLC debate.

If we create an open puffinbus and imbed its code into the linuxPLC and not have any other bus protocol included in the code then the linuxPLC is kept small and well sort of standard. It is then up to the external bus types around to provide a bus filter/converter to drive their proprietry busses. This should keep some of the politics away from using proprietry stuff and it allows us to argue for years about which way to improve our own protocol.

O.K. the filter/converter may impose delays in updates etc. but this may encorage people to use the puffinbus as their standard bus instead of all the other ones.

If you wan't a better idea of what I'm trying to propose, just let me know and I'll put together a little prelim spec.

regards

Phil

P.S. Its only an idea at this stage so don't flame me yet.

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

J

#### Jiri Baum

Philip Costigan:
> If we create an open puffinbus and imbed its code into the linuxPLC and
> not have any other bus protocol included in the code then the linuxPLC is
> kept small and well sort of standard. It is then up to the external bus
> types around to provide a bus filter/converter to drive their proprietry
> busses.
...
> this may encorage people to use the puffinbus as their standard bus
> instead of all the other ones.

I wish...

The code isn't a problem, it's the hardware that's the problem.

I'm very much afraid we are going to have to do it quite the opposite way altogether - write, ourselves, the code for all the proprietary busses
around. It may not be the open way, but it's the only way to talk to them.

(OTOH, if we do manage to do them all, lplc may well become the universal traffic cop. Which would be kinda neat.)

Jiri
--
Jiri Baum <[email protected]>

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

C

#### Curt Wuollet

ROTFL, Yes, we could then propose our protocol to include every known protocol thus making them _all_ "standard". We, of course, would have to
find some way to waste a few years coming to that conclusion. In the meantime we can write a Linux PLC or something.

Seriously though, I have considered this, even to the point of designing hardware to run it on. What I conceive is an embedded Linux peripheral running a TCP/IP stack on which we could run any high level protocol we want. This rack would talk to small plugin cards with say 16 inputs or outputs of various types. The rack could run the lplc in "micro" applications or serve as ethernet attached remote intelligent IO for larger installations with the lplc on a PC platform. I
am seeking financial backing from the company I work days for or from another company or group in connection with my consulting practice. The protocol would be Modbus/TCP or one of our own design. This hardware could of course be put to other uses and so has a broader market than lplc. I would look at it as a kind of Ethernet protocol IO development kit. But, I'm pursuing it as a solution to the problem you describe. I'm serious enough about it to possibly change jobs to a
company who is interested in developing it if I can't find another way to make it happen. Truly open IO would solve an awful lot of problems and circumvent a lot of proprietary barriers. With the recently announced realtime networking one could easily make a deterministic, packetgram based, open protocol. All the pieces are there, but no one is putting them together. And the time is pressing, before Ethernet is so thoroughly decommoditized and proprietized as to render
it too, useless.

As far as convincing the other guys to bridge to our protocol, I wouldn't hold my breath. There's a reason they each have developed their own and it's not very charitable. They have less than no interest in interoperability, indeed, they see
it as a problem rather than a solution. It's only the users and integrators that are interested in solutions and, so far, they lack the committment to vote with their checkbooks. Hence, the lplc and by extension, open IO to provide an
alternative.

> O.K. the filter/converter may impose delays in updates etc. but this may
> encorage people to use the puffinbus as their standard bus instead of all the
> other ones.
>
> If you wan't a better idea of what I'm trying to propose, just let me know and
> I'll put together a little prelim spec.

I'd be interested in seeing it. IO is my depth on the lplc project.

Regards
cww

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

D

#### David Nimmons

The answer is 'D', all of the above. Final answer Regis. ; )
I believe we need to support all of the hardware available and probably also need to come up with a free open protocol, like a real fieldbus
standard, maybe. I do not know what everyone here has in mind for a finished product as I have not gone through all the archives yet, but I think one ideal application would be for plug replacement modules, i.e, an Allen Bradley
PLC 5 module, a Modicon module, etc. I know that saying is easy and doing is much harder, but, I believe there would be an incredible market for an
open solution that could plug into any existing installation.

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

P

#### Philip Costigan

O.K.

This is a bit of a first for me so it may lack in the translation. I'll even try ascii graphics.

The proposal.

1. Ethernet is everywhere so that should be our easiest and logical choice
of network type to use. It must of course be separated from office
networks etc.

2. The protocol that we develop should have the ability to pass data about
the device that is being comunicated to.

eg. The first thing that the lplc does after reading the config
file and finding a line that reads somthing like..........

[RIO]
base1 "remote base 1 at filler 4" at 192.168.4.23 port 6001

it should connect to that remote system and then request a
config from the remote point. somthing like......

lplc sends: r
remote base replies [RIO]
mcn4fillsol "machine 4 fill solenoid" at 0.0
mcn4run_lamp "machine 4 run lamp" at 0.1
mcn4full_lamp "machine 4 full lamp" at 0.2
mcn4full_sw "machine 4 full switch" at 0.3
mcn4level "machine 4 tank level" at 1
mcn4temp "machine 4 tank temp" at 2
[\RIO]
lplc sends: ack (or somthing equiv)

The lplc would then have to associate or alias the
required points in its own map to the remote map that it
just recieved.

lplc now armed with the correct knowlege of its remote io
will then start driving outputs and recieving input data
to and from the remote system using a method where by only
io that changes is sent over the network and if no change
exist then only the first word of the map is sent so as to
keep everyone happy that comms is still up.

3. The remote base would then take the data being sent to it and redistribute it to the io that it is controlling ( ref ascii example ).

OK I can see flaws and thats expected. things like what if someone changes the remote map while it is all up and running etc. etc.

I'm sure we'll work these things out.

ASCII stuff (here goes)

office network

______________________________________________
| |
| ----------------
| | |
| | office |
| | computer/s |
----------------------- | |
| | -----------------
| --------|
| |(local)| -----------------
| | [RIO] | modbus | |
| | base0 |---------------| modbus i/o |
| Lplc | | | |
----------------------- -----------------
|
|
| puffinbus tcp/ip
---------------------------------------------------------------------------
| | |
| | |
--------------- ----------------- -----------------
| | | | | |
| [RIO] base1 | | [RIO] base2 | | [RIO] base3 |
| | | | | |
--------------- ----------------- -----------------
| | | device/net
| | --------------------------
| | | | |
| | -------- -------- --------
| | |dev 1 | |dev 2 | |dev 3 |
| | -------- -------- --------
| |
| | profi bus
| -------------------------------------------------
| | | |
| ----------- ----------- ------------
| | dev 1 | | dev 2 | | dev 3 |
| ----------- ----------- ------------
|
| modbus/tcp
-----------------------------------------
| | |
----------- -------------- ---------------
| dev 1 | | dev 2 | | dev 3 |
----------- -------------- ---------------

I hope this isn't too much but I just want to place a seed into the lplc project.

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

J

#### John Volpe

Hi y'all,

Time to stop lurking as this subject is an area in which I have much experience. PLC's are usually in the cloud portion of my system diagram and I am usually designing the low level hardware interfacing to the PLC.

Please excuse my ignorance with the internals of the lplc............

As I see it we might consider this problem on two levels.

The 1st I'll call a local zone controller. Where a single PLC/PC (Possibly/probably part of a larger network) controls a number of I/O points. I would suggest using a Fieldbus, CAN Bus or equiv. network for this segment. The Remote I/O points could be made from "cheap" embedded processor cards with a network I/O device. Each remote I/O device could contain a small number of I/O points and send data to the lplc to be placed in a local I/O map for processing (? Note ignorance of lplc structure ?). I could easily see a remote I/O device with 16-32 I/O points at < USD$200. Of course these I/O points could also be A/D converters, F/Value converters etc. The remote I/O device could be configured to send data in any number of ways (Solicited, State Change, Interval etc.). In addition these Remote I/O devices could be used without an lplc as part of a dedicated (read : Non Customer Programmable) controller system. The 2nd level is the network of lplc devices connected by a native Linux network. This level I'm not expert enough to comment on. John Volpe Engineer, Electronic Design Services Inc. P.S. : As my company is a family owned business, I'm sure that we would be able to at least prototype some Remote I/O devices as described above for development and testing. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc J #### John T. Volpe Curt, The part I'm considering is the low level I/O section of your description. Not the embedded lplc, but the plugin cards as described below : "This rack would talk to small plugin cards with say 16 inputs or outputs of various types. The rack could run the lplc in "micro" applications or serve as ethernet attached remote intelligent IO for larger installations with the lplc on a PC platform." I'm looking at this from a packaged product point of view and see the following card types : Packaging : 1. Card which plugs into the PuffinBus backplane. The backplane would carry the communication link and power. Field termination would be on the card edge via screw terminals. It could be housed in a card cage with hot pluggable cards in a form factor to be decided. 2. DIN Rail mountable units with field termination for the I/O, communication and power. 3. Individual I/O blocks in flange mountable cases again with field termination for I/O, communications and power. Processor options : 1. Small devices with 8-32 I/O points could use a small micro like an AVR (Atmel) or PIC (Microchip). These are cheap and fast, though not quite as available right now as I would like. 2. Larger intelligent devices might want a more powerful processor. Though, if a users needs more power than an AVR or PIC, they should consider using an already existing controller card with 16 or 32 bit processor and network interface with custom programming. I can do a lot with even an AT90Sxxxx (AVR) or PIC16Cxx (PIC). Power : I think we need to support both low voltage DC power as well as AC line power. (If this is productized we will need look as UL/FM/CSA/CENELEC etc requirements. But that would be my problem). Protocol : SIMPLE SIMPLE SIMPLE and OPEN. CAN would be a very good fit for this device. Allocating 2 bytes of each data message for Data Type ID, Configuration Information. etc would leave up to 48 bits of I/O per message packet. CAN can (I prefer the Cha Cha) communicate at up to 1Mbaud in a standard configuration with complete CSMA/CD and automatic error retransmit (No processing required). How does this sound ? I can put together a proposal with design details and let you and the group decide if it is worth further development. John _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc C #### Curt Wuollet I'm already there with a paper design that requires a lot less engineering, runs embedded Linux (already ported) and all the software can then belong to the project. In fact a lot of the artwork is already done. It would be largely cut and paste. It is configurable either as a standalone micro lplc or as remote IO for a lplc running on a PC. Running Linux on the remote makes a lot of sense as we keep both ends open. The processor is spendier, but the fact that it is ready to run mitigates that. This also uses the free TCP/IP stack, free tools, etc. The remote software is then no different than other Linux programming except for size constraints. We also get serial port programming with the exixting tty discipline, built-in watchdog and failsafe. This processor communicates with modular IO cards across a low pin count bus. This bus is tentatively I2C, but I'm looking for something faster, The cards would be perhaps 2"x2.5" and would provide 8 digital inputs or 8 digital outputs or 4 A/D or 2 D/A. Those cards have not been worked through yet, but there are I2C chips available with the indicated functions. The project needs: Orcad resources as the exixting artwork is in Orcad. (provided by the vendor) Quite a bit of cut and paste and some (very little) new layout. A development system, approx$1200.00.

IO card design and artwork (this is where you come in if you want).

Board prototypes:

I2C integration:

assemble & test

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