Open source PLC hardware

W

Thread Starter

William Sturm

Maybe it makes sense to start a new topic, since we have gone from Ladder Editor to homegrown PLC hardware. I propose that we spawn this new topic from the this original thread: http://www.control.com/thread/1264535992#1265998918

To summarize...

CWW said:
"Or if you can tear yourself loose from the wide bus thing and go thoroughly modern, you could now implement with a serial bus ([email protected]) and the plethora of I/O expanders from Microchip,etal. and have a very low cost backplane and still make very respectable scan rates with cool stuff like interrupt on change at the cost of software complexity"

"Even better than that from a cost standpoint is that the expanders I was looking at don't need a uP to do the interrupt on change (report on exception), and a card would need little more than a local regulator( to use 24V power), the chip and 24V interface"

"I envision PC mount wire clamp connectors for the world end ( the little blue jobs you see all over) and pin headers and sockets for the bus end."

KEJR said:
"Using an 8 bit micro (I'm partial to AVR) on the IO cards to talk to the bus is a good idea especially since you can program them to be event driven on change of state"

"Developing a backplane for a serial bus is rather easy once the mechanicals are taken care of"

M Griffin said:
"If you are looking for a design for creating your own backplane bus system you might want to look at I2C or SPI buses. There are a lot of chips which support these protocols and I can't think of a better way of getting a low package count design."

"If you are thinking of putting a microprocessor on each I/O card, then you might want to give serious thought to using USB as your I/O bus. It might not be an obvious choice at first sight, but it has a number of advantages." See this link for details: http://www.control.com/thread/1264535992#1266016850

First of all, I think this idea has merit. It would be neat if we could design and develop some open source hardware with schematics, board layouts, and firmware open to all. I would suggest that we agree on a CAD and PCB package that is freely available. I have had good luck with TinyCAD and freePCB. Then we need a simple and basic design.

We should agree on board sizes and interconnects. Some possibilities for board sizes are the ExpressPCB MiniBoard size, 2.5x3.8". This is popular do to their 3 for 51 dollar deal. Also, any board that can snap into a snapTrack might be nice, maybe 2.75 or 3" wide by x length. USB connectors or 10 pin headers are good candidates for interconnects.

We could have some very standard I/O boards and possibly more than one style of CPU, since we will probably never agree on one.

I was thinking of a serial bus also, parallel buses have numerous issues. I think most PLC's have gone from parallel memory style buses to serial backplanes long ago.

SPI is very simple, but it requires a chip select for each device. Having said that, a 10 pin ribbon could have power, ground, TX, RX, and 6 address lines for a total 64 devices. Each device can have multiple I/O points.

I2C is also practical, it uses 2 wires and has an addressing scheme. I2C is more complicated and somewhat slower, but it is also widely supported. I have used I2C on a 4 wire phone cord with modular jacks for an I/O bus.

I also like M Griffins idea of USB, it is more complicated, but I agree that the advantages are numerous. Then the I/O can be used with a PC as well as a micro-controller. Micro-controllers are commonly adding USB endpoints these days. Could we use USB connectors on a backplane? That way, our baords could be used in a backplane or standalone. Do any microcontrollers have a USB master? Maybe not... If not, then the USB would be great for PC comms from the CPU board, and maybe a serial bus still makes sense for the I/O backplane.


Bill Sturm
 
What I had in mind when I suggested USB as a backplane bus was that the backplane would just be a USB hub. That is, it would be a PC board with one or more USB hub chips (these are single chip solutions) and USB PC board connectors. This would be mounted to the back of the card cage. There would also be a 24VDC to 5VDC converter to provide logic power to the I/O card circuits (but not for the actual I/O).

The I/O cards would each have a mating USB connector on the back. A card was plugged into the rack the USB connection is made. Also, the card logic circuits will have power, so the PC (PLC) will recognise its presence right away. The actual I/O (inputs, relays, etc.) would of course still need power via a front connector in the conventional fashion.

Since an I/O card is simply a USB device, it could be used as a stand alone device without a rack. Just plug a USB cable into the back of it, and it's ready to go. This suggests that the card size should be one that fits in a readily available box. This makes the concept however a bit more useful in different applications.

One basic type of card would be a USB extender card. It would just have a pair of USB connectors - one on the back and one on the front. To connect the PC to the rack, the card would be inserted an extender card at either end of the rack and then a USB cable plugged into it. To add more racks in a daisy-chain fashion, another extender card would be inserted at the other end of the rack and then cable connect to the next rack. This concept permits a rack connector at either end and also avoids tying up a USB connection if the rack doesn't need to be extended.

The rack backplane design should be able to be based off existing hub designs except for the layout (it will be wider than a typical hub) and that the power supply to it would be 24VDC.

Each I/O card would need an 8 bit MCU (microcontroller) to handle the USB interface, and to scan the I/O and translate the USB view of the I/O to the real physical design. If something a bit more complex was required (like a stepper controller) then a more complex MCU could be used for that application.

I am assuming this system would be used with a PC (or similar computer). I am also assuming that it would be possible to make each device appear as if it were a common USB class (e.g. mass storage) so that it isn't necessary to worry about drivers. For example, a digital I/O card could have three files. The first would contain "id" information (rack address, type of card, serial number, model, etc.). The second would be a read only file that contains the inputs. The third would be a read-write file that contains the outputs. The I/O memory map size for each device would be virtually unlimited for all practical purposes.

To a program using the I/O, reading and writing would just be ordinary ordinary file operations. That concept might not work with every application, but it seems like it should work with most of the ones that I can think of.

This is all based on the assumption that you intend this to work with an off the shelf computer with a 32 or 64 bit CPU and a capable OS with USB, Ethernet, etc. I'm not going to call this a PC, because there is hardware (e.g. see the "Sheeva Plug" mentioned by pvbrowser) which can't be described as a "PC" that would also fit this.

This is a reasonable requirement however. Designing and building a processor board is a much more difficult prospect than an I/O board, and there is lots of ready made choice available at low cost.

The target for this system would people doing soft logic systems, computerised test systems, or PC applications that need some simple real world interfacing.
 
I've put the following in a separate reply than the previous one because it deals with some slightly different issues.

At this point, there are a couple of different concepts available. There is the simple SPI bus proposal. This is cheap at low I/O counts, but has limited expandability and still requires some solution for interfacing it to an actual controller. There is the USB proposal which is a bit more complex to design (the I/O to USB interface), but which is much more expandable and which is very straightforward to interface to a PC (or other computer).

So, the question at this point is why do it? What is the objective? Or another way to put it is, what is the market or user base?

If the objective is simply lower cost, then it will have to beat existing systems. I'll give an example here of Automation Direct's Terminator I/O for Modbus/TCP (this isn't intended as a recommendation for their gear, I'm just referencing this because they have a published price list).

T1K-01DC TERMINATOR I/O DC PWR SUPPLY 12/24 VDC $99.00
T1H-EBC100 100MB TERMINATOR I/O ETHERNET SLAVE I/F $249.00
T1K-16B FULL SIZE TERMINAL BASE 3-ROW SCREW CLAMP $58.00
T1K-16ND3 16PT 12-24VDC SINK SOURCE INPUT $95.00
T1K-16TD2-1 16PT-12-24VDC SOURCE OUTPUT $103.00

Either solution will probably need a power supply ($100), so we will ignore that.

The AD bus interface is $250. The USB interface is $0 (we are assuming USB is built it). So far so good.

The AD base is $58. If we assume we need 5 I/O cards, then that is $290 for AD.

Lets assume 3 16 point input cards and 2 16 point output cards. For AD that is (3 x $95) + (2 x 103) = $491.

Total system price for AD (excluding PS) is 250 + 290 + 491 = $1031. The price ratio gets more favourable at higher I/O counts because you only need one bus interface until you have to break to another rack.

So, if the objective is price, then the target system price would be less than $1000. You could probably find cheaper I/O than the example that I've quoted, so the price would probably have to be a lot less than this. This is only going to be worth while for someone who is installing a lot of these. The SPI design probably has the edge here provided you can design a cheap interface to it.

If the target is capability, then there is a lot more potential for interest. The market here would be people who need capabilities that they just can't get off the shelf but would still want to be able to integrate it into a rack. This suggests that you would want a backplane design that has lots of speed and a large per-card addressing capacity. The USB design seems to have the edge here.

So, the question is, what is the target for this idea? The reason for doing it will have a significant role in determining the design.
 
C

curt wuollet

I did a little checking and a well supported, popular board for this is the beagle board. It's kinda spendy at $150, but most of the work's been done and you can always find the cheapest unit that'll do the job later. The Beagle Board would make a really snazzy PLC. You can plug in a LCD and it does audio and video and it has USB but no direct ethernet. I looked all over for a "plain jane" board, but all the newer processors have all the media gear built in. I'm sure someone makes a basic Linux micro board without all the bells and whistles, but having something that has a good following and community is important as it's very tedious to reinvent the wheel by yourself. It has two open SPI ports and enough GPIO to do the device select and the SPI driver work is in an advanced state. There are literally hundreds of small embedded Linux platforms to choose from now, I was amazed. Almost too much of a good thing. And it's available OTS from DigiKey. www.beagleboard.org Sort of an unofficial community supported TI product, which is amazing also.

Regards
cww
 
See this video
http://armdevices.net/2010/01/19/sheeva-plug-2-0-and-plug-computer-3-0-at-ces-2010/

They deliver the board to OEM at a price of 50$.
In future we will probably see more ARM based hardware that is capable to run standard linux distributions. They use SOC (system on chip) which provides nearly everything you need.

Now you could add a USB/RS485 converter to the board (may be some I/O) and put it in a different box which suits better to industrial applications.

What i mean "do not reinvent the wheel".

I think all is needed is Modbus RTU remote I/O.
If you can do it OK otherwise use one that is available.

The advatage of these plugcomputers is that you can develop your own software for that system using standard linux tools.

I will try this device and will run a pvserver from our pvbrowser on that system.
Thus you can do data acquisition, PLC logic and visualization server on this tiny device.

Our pvbrowser is client/server (almost like web browser + web server). With pvbrowser client on your desktop you can surf everything you can reach over TCP.
 
Hi everybody,

Curt propose to look at the BeagleBoard but I don't think it's the platform we need. The unit provides 3D graphics and stereo audio that we don't need. It targets the market of home appliances. I can't find any specification for temperature range and I conclude that environmental specification is not in their design criteria.

Curt also proposed serial communication between boards and I think it's the way to go.

Michael proposed USB as a backplane and I like the concept. It may fit perfectly for local communication, Ethernet (with POE) being better for field apparatus.

However I do not like the idea of using the mass-storage driver class as the basic building block. Mass storage is atomic at the file level. Various file locking methods exist to make it atomic at lower levels but our project needs simple method for access at the bit level.

Our PLC will probably end-up as a multi-tasking device. It may even end-up as a multi-processing model. I feel that a mass-storage driver for I/O will be difficult to manage. A bit-map driver class may be more appropriate. Does it exist in any form?

USB specification limits to 127 the number of devices. It seems to be a limiting factor (most mid to high end PLCs offer more than that). I would like to introduce the concept of a multi-level USB bus where a device at level 1 may be a scanner for a bus at level 2. As an analogy, a rack would have a USB scanner for it's local devices and it would report to the PLC all rack data as a single large bitmap. For remotely located racks, we would need "USB over Ethernet" for enumeration purposes. Does that already exist?

I'm glad the Puffin/whatever project is back.
 
C

curt wuollet

The extra electronics would jack up the per point cost quite a bit, but for some applications it would make sense. And the cost of a uP with the right stuff is coming down. In the meantime, there's an outfit finishing up a family of low cost boards that looks promising at around the needed price point. I don't know if there would be the kind of support and activity around these that you would get with the Beagle Board.

http://www.glomationinc.com/products.html

Oh, and surfing around, here's a place to look at who the likely candidates are for commercial Linux automation products.

http://www.osadl.org/Members.osadl_members.0.html

I think TI has seen that Linux is good business.

I found the Immediate C project there fascinating.

Regards
cww
 
W

William Sturm

I don't have a lot of time today, but I wanted to respond to some of the ideas so far.

Our objective should not be lowest cost, although a low cost is always welcomed. We should be looking to provide a system where the user has more control over their destiny. Software can be understood and debugged by anyone who is qualified and interested in doing so. Hardware can be understood and repaired in a similar fashion.

1. Our typical applications could be:

a. Small automation systems where the user has complete control over the hardware/software. OEM machinery suppliers would like that. We are competing with small PLCs, but not on the same playing field. We have advantages that they will likely never have. There may not be a PC in this system except for programming and troubleshooting. The SPI bus may be the way to go here.

b. An I/O system for a PC based softlogic system. We could have some onboard intelligence or not, who knows. The USB idea is excellent for this style of system.

We may want to look at a tiered system. Maybe SPI for the rack level interface, and a "bus coupler" to talk to a host computer. The bus coupler might be USB or Ethernet. If no host system is present, then the bus coupler runs a local control program. We will still want a USB port for programming or debugging. The hardware could be similar or identical, the firmware will change.

We should not want to develop any high speed boards, if we have a CPU, then it should be a microcontroller with 10-50 MHz clock speeds and internal memory. Obvious choices are ARM, AVR, PIC... If we have a need for speed, the numerous small form factor PC's are an obvious good choice.

Bill Sturm
 
C
Hi Michael

> I've put the following in a separate reply than the previous one because it deals with some slightly different issues. <

> At this point, there are a couple of different concepts available. There is the simple SPI bus proposal. This is cheap at low I/O counts, but has limited expandability and still requires some solution for interfacing it to an actual controller. There is the USB proposal which is a bit more complex to design (the I/O to USB interface), but which is much more expandable and which is very straightforward to interface to a PC (or other computer). <

Ah, but there's the beauty of the newest crop of Linux SBCs You don't really need to give up one to have the other. The SBCs I've been looking at support serial( several, 232 and 485), USB(several both host and device). Ethernet, I2C, SPI, A/D, and some other less germane items for $50 (in qty). The beginning of this tangent was a desire for a PLC like box, rack and modules. I advocate using one of the onboard busses for the backplane and cards. This could be I2C or SPI. I chose SPI because the overhead is less than 12C where the addressing is in band and fast scans were a desire. This is brought to a pin header and would plug into the backplane. The expanders are compatible with these levels. A discrete card would plug into say an 8 or 10 pin header, MISO, SIMO, CLK, CS, power and ground these last two would be double. A card would only need a regulator from 24 to it's VCC, the expander, and drivers for an output card or level shifters/isolators for an input card. Very low card cost for 16 pts. There are also many SPI A/D, D/A that would plug right in, but I haven't checked out what they would need for glue. These chips were made specifically to lower component count. At this point, you would have a pretty inexpensive PLC for the usual stuff. And you could have an A/D or two. And a few buttons. But, if you want remote I/O there's Ethernet, USB, 232 and 485 Serial. Upscale the processor a few bucks and you can have a LCD touch panel. Since all of these will now do what _you_ want rather than the sometimes useless dedicated ports they put on PLCS, you have a very, very, capable machine. If you want to make a local rack with USB, that's cool too. But it would cost more with questionable gain for local I/O.

> So, the question at this point is why do it? What is the objective? Or another way to put it is, what is the market or user base? <

Because the boards are stuffed with features and interfaces, you could cover the original objective of a fast PLC with an RTOS available _and_ nearly any other small PLC objective within reason. And a great many others.

> If the objective is simply lower cost, then it will have to beat existing systems. I'll give an example here of Automation Direct's Terminator I/O for Modbus/TCP (this isn't intended as a recommendation for their gear, I'm just referencing this because they have a published price list). <

----- snip ----
> So, if the objective is price, then the target system price would be less than $1000. You could probably find cheaper I/O than the example that I've quoted, so the price would probably have to be a lot less than this. This is only going to be worth while for someone who is installing a lot of these. The SPI design probably has the edge here provided you can design a cheap interface to it. <

I can't imagine not at least matching that, in any reasonable qty. Software notwithstanding. Even at the basic PLC level, the very high degree of integration with the recent silicon makes this at least arguably competitive. The card silicon, the expander, 16 pts is a couple dollars in qty 1. The bare board and wire clamps would be the dominant cost. Plus any mechanicals, which can be pretty simple. The passive components would be nominal. The problem before was ports and the glue chips. A chip that wires directly into the bus and provides the points lowers the card cost a lot, and it could be a 2 layer board.

> If the target is capability, then there is a lot more potential for interest. The market here would be people who need capabilities that they just can't get off the shelf but would still want to be able to integrate it into a rack. This suggests that you would want a backplane design that has lots of speed and a large per-card addressing capacity. The USB design seems to have the edge here. <

In this case you _can_ have it both ways. IFF you have an OSS software system that would be productive for normal :^) automation folks.

> So, the question is, what is the target for this idea? The reason for doing it will have a significant role in determining the design. <

Yes, but it isn't as definitive when you can have everything including the kitchen sink in one low cost package. In other words, the lowest cost choice for the local I/O doesn't in any way limit the other capabilities which would be far richer than what is on the PLC market. This latest bunch of processors come with incredible capabilities, they even throw in a DSP for good measure. The mobile market has been very, very, good for embedded procs. If one of these SBC makers decided to do the deed, they could make a PLC very inexpensively. They already make host boards and add-ons. With a few K$ and a web site, this could be a reality. You never know, if I don't find a job soon, I might even give it a go. Here's a packaged Linux Computer with I/O modules. What you do with it is your business. It would be Open because it would be obvious. All OTS but the boards and those wouldn't hold any secrets either.

Regards
cww
 
C
I agree completely, for your server based system where everything is on the wire, these would be cool if you can get your stuff on it. I've found some that have everything you could want for Open networking and comms, built in.

Regards
cww
 
C
Hi Bill

> I don't have a lot of time today, but I wanted to respond to some of the ideas so far. <

> Our objective should not be lowest cost, although a low cost is always welcomed. We should be looking to provide a system where the user has more control over their destiny. Software can be understood and debugged by anyone who is qualified and interested in doing so. Hardware can be understood and repaired in a similar fashion. <

The interesting part is that the trade-offs aren't severe. For example, you won't achieve low cost by going slow. All the low cost processor boards I've seen are at least 200 MHz. And the lowest cost board bus to use, also happens to be one of the easiest to understand and work with. SPI with the SPI enabled IO chips can be really simple. I wasn't having any luck sleeping last night so I got out the virtual mylar, Rubylith, and tape and "taped up" an input card. Nothing fancy, 16 sinking inputs. If someone will host it, I have a .png that I will send them so we can look at it. All through hole, 2 chips and 32 resistors. 3.5" high and 2.5" deep. 2x7 pin header for the bus and 17 wire clamp terminals. The same chip can be used for a sourcing card and sinking and sourcing output cards. The output card would add a couple driver chips. This could be shrunk with SO devices and surface mount but that wouldn't be as easy to repair and the processor will probably set the height at about 3.5" anyway. I would probably have to add some pins for autoconfig.

> 1. Our typical applications could be: <

> a. Small automation systems where the user has complete control over the hardware/software. OEM machinery suppliers would like that. We are competing with small PLCs, but not on the same playing field. We have advantages that they will likely never have. There may not be a PC in this system except for programming and troubleshooting. The SPI bus may be the way to go here. <

Exactly, but with the current crop of boards, USB, Ethernet, serial ports and at extra cost, a touch LCD come along for the ride.

> b. An I/O system for a PC based softlogic system. We could have some onboard intelligence or not, who knows. The USB idea is excellent for this style of system. <

The same box could be an Ethernet or serial slave at no additional cost. Just a program change.

> We may want to look at a tiered system. Maybe SPI for the rack level interface, and a "bus coupler" to talk to a host computer. The bus coupler might be USB or Ethernet. If no host system is present, then the bus coupler runs a local control program. We will still want a USB port for programming or debugging. The hardware could be similar or identical, the firmware will change. <

We can have it all in one.

> We should not want to develop any high speed boards, if we have a CPU, then it should be a microcontroller with 10-50 MHz clock speeds and internal memory. Obvious choices are ARM, AVR, PIC... If we have a need for speed, the numerous small form factor PC's are an obvious good choice. <

Not much choice there, it would cost more and be a lot more work to design around a low function uP and it wouldn't be OTS.

Regards
cww
 
In reply to gaga: I'm not sure if USB mass storage would be the proper device class for this, as I don't know what the effect of having 100 storage devices appearing on a typical computer OS would be. The point however was to illustrate the advantages of emulating the interface for a common existing device. This way:

a) You don't have to write or support drivers for it.

b) People would be able to use it just by plugging it in without needing to install drivers.

c) You wouldn't need to write new language bindings for it - you would simply use existing ones (e.g. almost every programming language can read and write files).

Again, as I said the mass storage class may have some unacceptable side effects, but perhaps some other profile would work. Bit access or file locking shouldn't be a problem however. For boolean values you could have one byte per address. If you have multiple processes or threads which need to access the I/O you would probably want to have a server process proxy those requests anyway.

As for the number of devices, if you have a very large number of I/O then you almost certainly also need distributed I/O. In this case you would need to use Ethernet with a communications terminal for each remote I/O rack. If you are going to use remote racks over Ethernet, then you would probably want to use an existing protocol like Modbus/TCP.

Direct USB connection would only be for low cost connections to local racks. I suspect that medium size (no more than a few dozen devices) applications are probably almost all of the potential market for this sort of thing anyway.

The direct connection USB system would be a bit different from traditional I/O concepts in that each module is addressed directly rather than via single address space. That results in a bit more overhead when you are dealing with very simple digital I/O.

However, it is a lot more convenient when you are dealing with things that have larger quantities of data, or which need to stream data continuously. A good example would be if you wanted to design a module that captured waveforms rather than just read single analogue values. That is something that would be very nice to have for a lot of production test systems since it would make data acquisition a lot easier.

There are trade-offs in every system design. That is why I had asked earlier what the intended focus was. If the idea is just "cheap" digital I/O, then that consideration will dictate the design and SPI or I2C are probably good choices. It is going to have to be *really* cheap though to make it worth while doing when you take into consideration what you can already buy off the shelf.

If the idea is to be able to provide capabilities that you can't currently get in industrial I/I systems, while still being reasonably economical, then SPI and I2C are probably too limited in capability.

I'm not going to be one of the driving forces behind this project, so I'm just providing a few ideas that people might want to consider. Perhaps none of those ideas would work in practise. Whether any of them are even worth considering though depends on what the actual goals would be.
 
W

William Sturm

Curt said: "The same box could be an Ethernet or serial slave at no additional cost. Just a program change" and "We can have it all in one"

I was thinking of the I/O cards with USB instead of SPI. Serial would be no problem at the I/O level, but slow. Ethernet would add significant hardware and software to the I/O boards. At the host level, you are correct. I'm thinking of 2-3, I/O cards, bus coupler, and optionally a PC. I am looking at the USB idea for the I/O instead of SPI. It is easy to find low cost micros, such as a PIC24, with USB host or slave. These are 2-3 dollars in low quantities and have 20-30 I/O ports. They also have enough processing capability to act as a bus coupler, instead of a Linux board, if we choose to do so.

Curt said: "Not much choice there, it would cost more and be a lot more work to design around a low function uP and it wouldn't be OTS."

I'm not sure I agree with that statement, one or two 3 dollar PIC's can be a nice PLC host processor with Ethernet or USB interface to a PC. I would prefer to not use an OTS board. I think we should work on I/O and maybe we will end up with 2 or 3 options for an embedded CPU board.

Find my web site and email me the file, I can make us a page.

Bill Sturm
Abbeytronics LLC
 
C
I don't think it is at all irrelevant. It doesn't seem very Open, but it is recognition that Linux is a great platform for automation. As I've mentioned in this thread, it isn't visionary to see that the new high function, low power, processors would make a great PLC because they have the power and resources to run Linux at embedded price points. No more designing around ancient technology to save a buck. And no more need to run minimal software because you are using the least powerful processor that will do the job. And the tremendous activity around embedded Linux means that the number of people who can put everything together is much higher than the exclusive embedded club of the past. Even the majors are moving towards PAC rather than PLC because it's easier to work with a more powerful platform. One has to wonder what this machine costs. I may just have to register and find out. I never thought I would have to thank the cell phone folks, but this side effect can, and I think will, have a profound impact in automation. Especially if we can wrestle control of the market from the hyper-proprietary to more Open and user-centric entities.

Regards
cww
 
C
It need to be said that your input is greatly appreciated and any difference of opinion is purely technical or because I'm misguided :^). USB would be plug and play and I see it as good for rack to rack or to add the odd peripheral to the mix. But it would require quite a bit of intelligence on each card for the local rack and very few people (in this audience) really understand it. At that point, each card would actually be a standalone PLC, or could be. Smart Cards would certainly be an option as you could simply plug them in. The extremely simple cards are in response to comments that it should be easy to understand and fix. USB seems cheap enough in commodity products, but getting the first drawn and fabbed and tested would be pretty spendy. CAN would be another option, but also seems a bit heavy for a cardbus. I am curious what WAGO/Beckhoff use on their racks, it's obviously some sort of serial bus, but they don't talk much.

Regards
cww
 
C
> I was thinking of the I/O cards with USB instead of SPI. Serial would be no problem at the I/O level, but slow. Ethernet would add significant hardware and software to the I/O boards. At the host level, you are correct. I'm thinking of 2-3, I/O cards, bus coupler, and optionally a PC. I am looking at the USB idea for the I/O instead of SPI. It is easy to find low cost micros, such as a PIC24, with USB host or slave. These are 2-3 dollars in low quantities and have 20-30 I/O ports. They also have enough processing capability to act as a bus coupler, instead of a Linux board, if we choose to do so. <

SPI can run at 10Mhz. With the overhead of USB, and running on a PIC, I doubt that the serial would be any slower, these are very small amounts of data. I think either would be fast enough. But, if the physical layer doesn't add much cost, it could certainly be done. In fact with a 3.5" high card, which is needed for the connector for 16 lines, there would be plenty of room on the backplane for both. But, if you want to make an I/O box to talk to a PC with direct IO from the processor, that is, yet another approach, but apart from a PLC type rack with the usual amenities that we started from. But I would make such an animal with both USB and Ethernet as USB is at present "PC only" and good for about 30 feet. The Ethernet would give you distance and some hope of working with other (non-open) automation gear. I am considering SPI for inside the box data transfer only.

> Curt said: "Not much choice there, it would cost more and be a lot more work to design around a low function uP and it wouldn't be OTS." <

Yes, we are talking about different machines. I would like a "standard" rack type PLC running Linux with user serviceable electronics. A remote IO rack could be more "all in one" and doesn't need much horsepower.

> I'm not sure I agree with that statement, one or two 3 dollar PIC's can be a nice PLC host processor with Ethernet or USB interface to a PC. I would prefer to not use an OTS board. I think we should work on I/O and maybe we will end up with 2 or 3 options for an embedded CPU board. <

I am kinda focused on things programmed with, and running Linux to do the RTOS and high speed kinda things as well as run of the mill PLC service. But Open remote IO for a PC or ? is a high priority as well, and near and dear to my heart. I would prefer programming in an Open high level language, but a whole OS might well be overkill for an IO rack. A linux based rack PLC could certainly be used as an IO rack for another system, but not the other way around :^) The interesting part is the cost difference is decreasing every day. Otherwise Arduino (which see) would work too. Maybe another thread?

> Find my web site and email me the file, I can make us a page. <
Done.

Regards
cww
 
W

William Sturm

Curt,

I'm leaning back towards the SPI for board to board, because it is relatively simple We could have USB or Ethernet on a small master board, or just use a Linux PC. Why not both?

Bill Sturm
 
C
I'm getting confused, the visions are getting all mixed up :^) Not a bad thing, as there are a lot of good ideas floating through. So, I'm going to clear up what I am working on and perhaps Bill and Michael can add a stanza or two as to what they are thinking about. I was going to try to sort it out, but that's when I started getting confused.

What I would like to make is a more or less standard PLC. It would have a rack with a Linux processor integrated driving a local bus for the 8 slots. That bus tentatively would be SPI as all the function chips needed are in beginning of life and will be available for the forseeable future at low cost and they are SPI interfaced chips.

The processor board would be an OTS item, as I doubt I can make one more economically with all the features available, and do all the driver work and glue code. All are ARM based and run a relatively normal Linux and have drivers for their hardware features. The Beagle Board mentioned would be an example. Without anything in the rack or added on, the ideal processor would provide Ethernet, serial ports, USB, A/D and general purpose IO at system voltages. Most can also drive an LCD and many offer other bells and whistles. This would be fanless and low power and would replace needing a PC as it would run Linux applications within reason from flash or a SD card. I've seem one running Ubuntu. Applications would be cross compiled on a Linux host and transferred with tftp or the like. Target pricing is $50, but there are many boards that will work, as the only requirement for the rest of the PLC is that it supports SPI which all ARM processors do. The board would more or less be docked in the processor housing and cabled to the backplane. This would allow a choice of processor boards depending on need or budget amd gets around the lack of connector standards. 8 GPIO pins would be committed as slot selects.

The backplane would consist of a board with the SPI bus, power, slot selects and other features for 8 plug in cards, which could be 24V inputs, 24V outputs, A/D, D/A or anything else that will fit and speaks SPI. Because it will be short and controlled impedance the bus should be capable of 10 MHz operation. Power will be from an external 24V supply as that makes many approvals go away as does the DC only I/O at this time. I estimate <15 Watts exclusive of any output power sourced.

The cards would plug into a relatively low pin count connector and are tentatively planned at 3.5" high by 2.5" deep mounted in the customary vertical plane. Since the cards use SPI enabled chips, they have very low component count and are configured over the wire. I have done the printed circuit layout for an example 16 point sinking input card which Bill has graciously offered to make visible. I'm working on a BOM to get a cost estimate.

The rack would be perhaps 4" high by 3" deep with a more or less square enclosure at the left end for the processor and connectors for all the comm ports. The slots will be perhaps 1.25" wide which will give a total length of about 14". So this will look a lot like every other PLC. Cards will slide into guides with panel fillers attached to the card. I did the example card for 17 wire clamp terminals, but I'm open to other suggestions as I haven't seen a PLC connector arrangement I've really liked.

I've thought this through and this is what I came up with as what I can realistically do. There is nothing excessively challenging or avant garde. Basically it's a PLC that runs on Linux. If I do it, I will make the artwork for the boards available in PCB format so that it could be easily replicated. And the schematics as well. I may do basic demo software which would include the routines to configure and read and write to the cards. And the patches to the drivers for these chips. That will be the hardest part of the project. Time frame is funding limited.

If there is a demand, I may offer bare boards or ?. It should run any of the Linux automation projects with suitable resources, providing a platform for Linux automation software. If you swap other processor boards in, you could run almost anything. That's it, a _complete_ plan. Anything I've missed?

regards
cww
 
Top