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
"Or if you can tear yourself loose from the wide bus thing and go thoroughly modern, you could now implement with a serial bus (SPI@1.5mHz) 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."
"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.
This might be an alternative:
"Sheeva Plug Computer"
"Modbus RTU remote I/O"
"Visualization (pvserver running on plugcomputer)"
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.
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.
> 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.
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.
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.
Oh, and surfing around, here's a place to look at who the likely candidates are for commercial Linux automation products.
I think TI has seen that Linux is good business.
I found the Immediate C project there fascinating.
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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. <
I'm not sure if this micro PLC would be a good candidate for performance testing, but it may supply design direction.
Unless somebody has already seen this and decided it it irrelevant.
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.
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?
In reply to Bill Sturm:
> I don't see how we are straying from this idea. USB has been suggested instead of SPI. I say lets start with SPI, it is simpler. (although USB enabled microcontrollers are <
Simpler is better. I think a USB communication card in place of a CPU would be useful for expansion or remote IO, but not for the backplane interface.
> towards the Linux SBC concept, as we speak. Have you seen the boards from Technologic Systems, they have some under 100 <
These boards are pretty close to what I'm thinking to try. One of the boards is under 3" across, which would fit nicely in a Chassis even with the hardware. Bottom line is that I think there is a plethora of options here, which is good.
> USD and they look pretty robust. I'm not sure how to do a backplane and chassis, but ideas will come. <
I have some ideas about backplane/chassis. I think it can be made rather simple but elegant.
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?
Wow, stay out of work for one sick day and look what happens! :o)
I'm just going to reply globally to all of the posts so far...
Here is what I feels strongly about:
- Develop an SPI based rack with electrical and mechanical specifications.
- The rack can be used with a CPU or a communications module (i.e. remoteIO).
* Lets not get too detailed on what these are *Yet* There will undoubtedly be many options here.
* Using SPI as the [rack] bus will allow many options, from completely embedded AVR/Arduino to Marvell processors.
- The rack should be as small as we can make it (This is to compete with the bloated solutions that already exist).
- Make it as inexpensive for basic IO modules as possible. We want to leverage this system to be cheap when you have high IO counts. $50-$100 for 16 bits of IO is very reasonable and achievable in any decent quantities.
I think that developing the IO rack in itself is enough of a project for now. I don't think looking at embedded linux computers is a bad idea at this point because that is where we want to go, but lets not get bogged down with the exact System on Module right now. I think I prefer the modules that are more "stamp"-like since they let you dictate where the front panel connectors (USB, ethernet) will be located on the "carrier" module. We don't want to design a rack based system around one CPU module. The "linux stamp" is such a device, but so far it seems limited to a 200MHz ARM, which should be fine for most things, but not for everything.
I have developed IO boards based on a backplane before and I know some of the problems in doing it on your own. I was able to get it down to roughly a 3" x 3" board size while still using 16 IO points and 24VDC feed. I'd like to do some of the mechanical layout and board design if my "home time" allows for it (I have to young sons, so time is not that available). I've found that DIP devices are very much hard to find in some areas, so working with SMD is almost required. If we keep with 0.050" pitch SMD devices you can still hand solder them and use a 2 layer design.
Bill: I've not used a lot of free schematic/PCB packages, have you considered the Advanced Circuits free PCB tool? It is one of those deals where it is free software if you order the boards from them, but they are one of the cheapest in the USA for prototypes. I know a lot of folks use Eagle, but their board size limitation (for the free version) is limiting. I'll check out the software packages you mentioned.
BTW, the plug computer keeps saying it will be released for $50, but this seems to be a marketing thing for them to demonstrate that you could build a Marvell based "PC" for $50 in quantity. So far I don't know of anyone that is offering anything based on that chip for $50.
BTW, what do you guys think about bussing out the 24V on the backplane as an option? I've seen some of the slice IO guys doing this and it can shave down the front panel connector requirements (and wiring). We could limit the amount of current that the "bussed" 24V backplane could supply for power budget reasons, and anybody requiring more power would have to supply it to the front of the board. Just an option, and I don't think it is critical, but it would be nice to consider up front.
A lot of my previous post got cut off. I reposted. I have done a 16 sourcing output card and sent you the .png.
Backplane is pending. I'm leaning towards a skinny backplane, both for cost and to leave space for any other busses. I have inexpensive card guides and panels figured out, but the box would probably have to be fabbed. Don't need it to test. Don't know when I can afford to get a processor board and get cards fabbed, but there's a lot of checking and tweaking to do anyway. And I can draw schematics. They will be in Qcad, which supposedly can transfer to Autocad, but that hasn't been all that satisfactory when I've tried it before.
In reply to Curt Wuollet: I believe that the Siemens S7-300 series uses a dual backplane. There is one set of signals for basic digital and analogue I/O, and another set of signals for "intelligent" modules. You would probably want to provide for something similar.
I'm not sure where this project is going, but before everyone gets too deep into the hardware you might want to think about what software you are going to use with it. Programming right to the bare metal makes things "simple" from a hardware perspective, but it rather limits what you will be able to do with it. I think you would want to be able to run a standard Linux build on it, (e.g. Debian). That gives you lots of basic infrastructure software which you can run on it, such as http, ftp, ssh, and database servers. It also gives you good quality development tools (e.g. compilers).
If you look into ARM chips, though, you find out there are ARM chips, and there are ARM chips. ARM themselves don't make any chips, they just design them. Various companies license the designs, add peripheral logic and sell the resulting chips. However, different companies have licensed different ARM versions with different features (due to different design generations, or size, or power budgets). This means that software support is quite varied.
What this means is that just because you see that Debian has an ARM build doesn't mean that it will run on all versions of ARM. You also have to worry about whether the drivers are in-kernel, or whether the vendor has carried them as out of kernel patches. I imagine you would just like to load a standard distro, rather than a vendor specific build that uses a 5 year old kernel and doesn't have anything beyond a few basic packages. The situation for MS Windows CE is a lot worse by the way (virtually every board support package is a custom build), but I don't imagine that is any consolation to you.
This isn't specifically an ARM problem by the way. X86 chips have the exact same issues (particularly with the "industrial" motherboards). Some x86 CPUs won't run some software because they don't have some of the newer instructions. You won't run into this if you are using the latest super-turbo CPU with a jet engine on top. Some of the older, low power, or compact chips are only 386 compatible, and won't run software compiled to use the newer instructions. I've seen this happen, so it isn't a purely theoretical problem.
Back in the dark ages :^) when chip design was done on huge sheets of mylar and photo-reduced, printed circuit boards were done the same way. You took a sheet of mylar and used black tape strips for the lines and pre-cut dots for the pads. Rubylith was a red film that you applied for a second layer or ground plane. An exacto knife was our stylus. The "tape-ups" were done at 2x to 8x life size to get the precision needed and then photo-reduced and printed. Sometimes we had a draftsman to do these, but I did a lot of putzing with mylar, rubylith, and tape. It's so much more pleasant with layout software. But I still think of it as Virtual Tape. And, no, I have absorbed all the ferric chloride I need for a lifetime. I'll send them to a proto shop and if need be, a production house. But two layouts in two days would have been a very lofty goal the old way :^) It's just my nostalgic sense of humor that confused you.
> In reply to Curt Wuollet: I believe that the Siemens S7-300 series uses a dual backplane. There is one set of signals for basic digital and analogue I/O, and another set of signals for "intelligent" modules. You would probably want to provide for something similar. <
Yes, I have that in the back of my mind because the expander chips can use address lines and bus the chip select. But A/D and D/A from the same outfit do not. For now, I'm just going to use wired chip selects for all the slots so that you can put any card in any slot. But it would be nice to be able to address the chips. I could do it with a 1 of 8 decoder, but the software will probably be simpler with just using the GPIO for selects. Also an 8 channel 12 or 13 bit A/D or D/A will require a lot more data to be transferred than the digital IO. If the time to service gets to be where I should wait on an interrupt, I may want to do something else.
> I'm not sure where this project is going, but before everyone gets too deep into the hardware you might want to think about what software you are going to use with it. <
----- snip -----
Rest assured, I have no intention of going back to assembler :^) The boards I have been looking at do run Debian and the latest kernels. The only difference is that it's an ARM Linux like the netbooks. The other difference is the size of course, if you can pay for the storage, it could be self hosted, The only reason to cross compile is that development would be more comfortable on a desktop. If you add a screen, you can run any of the netbook distros. But, the reason for running the flavor they provide is that they have done the driver work to interface to their mix of hardware. This means I don't have to spend as much time in the dark world of kernelspace. With working drivers, you need only open the specialfile and use the read, write, etc. methods the driver provides. I may need to do some work to add the extra chip selects, but once that's done it should be everyday C programming to use the IO. It should be much the same as using any other IO open, read, write copy the buffers, etc. In fact that's why I want to go this route rather than a Rabbit, or PIC, or ? I want to write Linux software in C as it should be:^)
> If you look into ARM chips, though, you find out there are ARM chips, and there are ARM chips. ARM themselves don't make any chips, they just design them. <
----- snip -----
Yes, and I'm only interested in the ones with a MMU so they run a "standard" kernel. You can get the latest kernel from kernel.org, apply the patches. configure it with menuconfig and compile for the AIM version which is an IFDEF in the mainstream kernel. Then you make a UBoot and a kernel image for the flash or SD card. A little different than X86 but, soon AIM will be almost as mainstream as X86. I'm sure they outnumber powerPC, MIPS, etc. already. The people selling these boards are selling a running Linux installed and configured. The SPI is a bit special since there is no way to autodetect what's out there, but they should have it working. We will need to develop the routines needed to configure and interpret what the particular chip needs, but that should be above the driver level. I could just do X86, but AIM offers far more features with far less hardware and a lot less power for a lot less money. From an application level it should be more or less transparent. You write to Linux.
> What this means is that just because you see that Debian has an ARM build doesn't mean that it will run on all versions of ARM. You also have to worry about whether the drivers are in-kernel, or whether the vendor has carried them as out of kernel patches. <
----- snip -----
I had all the same concerns. I am going in with eyes wide open. There is enough factory support and community support where If need be, I could choose a Linux distro and port it to a board. I'd rather not but it makes me comfortable that it's not a single source deal. TI Atmel, Samsung, etal. _want_ you to be able to run Linux because otherwise they don't have an OS or a community. It's hard to sell chips without people to use them. If worse came to worse, you could choose the Beagle Board and TI supports it. That's what makes this exercise practical, if it was iffy before. These are great chips. If I could think of a better overall line of processors for the task, I'd use them. But the value proposition makes it a natural.
> This isn't specifically an ARM problem by the way. X86 chips have the exact same issues (particularly with the "industrial" motherboards). Some x86 CPUs won't run some software because they don't have some of the newer instructions. You won't run into this if you are using the latest super-turbo CPU with a jet engine on top. Some of the older, low power, or compact chips are only 386 compatible, and won't run software compiled to use the newer instructions. I've seen this happen, so it isn't a purely theoretical problem. <
No, but that is the beauty of buying a system with Linux running on it already, to a greater or lesser extent, that's their problem. A mitigating factor with the ARM is that more of the bells and whistles we need for automation are built into the chip. That makes it a lot more sane than a random assortment of chips added on because you know where to find the data. They provide enough where hobbyists can make good use of their products. And at that level, as they say, it doesn't take a rocket scientist anymore. I've done *nix on several processors, I know what I need to run should be portable. And these are all somewhat theoretical problems until someone tries it. But if it doesn't work on one board and port, it's easy enough to swap in one that will work. Netbooks didn't break all the Linux software, so it can't be all that bad:^). They use many different versions of ARM and whatnot.
I really do appreciate your "clued in" concerns though, these are exactly the things that need to be examined. It would be much worse if we were locked into a particular board that made life difficult. But, that's why I am splitting the system at the SPI bus. It's sort of a universal connector, you can plug any controller in with very little work. Even a desktop. It's very low risk at this stage. It's not like I'll get fired if there's a problem or two :^).
In reply to M. Griffin Regarding Linux on ARM and hardware interface:
I have found several ARM SOM projects that incorporate more or less standard linux distros. Now this doesn't mean you can load Ubuntu and start browing the web, but it is undoubtedly enough to start using RTOS and http servers. We would have to pick one that is widely supported. I looked up some details of the linux SPI driver last night, and while I am not an expert it seems to be very well done, allowing you to alter the addresses of your SPI chip selects, or even rewriting the C functions that facilitate the "chip select" setting (this is probably useful if you multiplex your chip selects). We could either recompile the kernel or compile a kernel module for the SPI. It didn't seem like a big barrier at first glance, but some more eyes on it wouldn't hurt! :o)
This company claims they can run linux off the shelf with this SOM:
The price isn't too bad for what you get either, and the form factor is great.
Again catching up, the Beagleboard _does_ run Ubuntu. I would attempt for something a little lighter, but if it runs fast enough and the PLC process still approaches real time, Why Not?
Ubuntu Server is somewhat lighter. Years ago I went down the path of making a lightweight distro but that was back when 256MB Disk On Chip devices were [relatively speaking] megabucks and you were lucky to find a board supporting Compact Flash. How the world has changed!
I think the bigger issue for automation is to make the distro mount the hard drive as Read only. Forutnately in Linux that is quite easy, and you can have a writeable partition as well for storing user files (such as programs to run). I wonder if someone has a distro for this type of thing just to make life easier?
I'm somewhat of an advocate of the Sheeva implementation because it seems like it will scale to a custom CPU in the future without a lot of pushups. I don't know if you could disect a plug computer, or possibly hack into the SD card slot to get at the SPI pins?
There is a newer model called Guru Plug or something like that that exposes more ports and has an HDD.
I think it is great that you are jumping into this project. I do feel is far too soon to be jumping into FR4 and "virtual mylar" before a signal specification is drafted. Although the SPI bus isn't that demanding why would you layout boards before deciding on what the features were first?
Here are some thoughts I had along those lines, some of which you had mentioned previously:
- Each "IO" slot gets the following signals:
* SPI clock and data lines
* Its own unique SPI chip select (Slot select?).
* 5V, Ground (Need to decide a power budget).
* 24V and Ground (Need to decide a beefier power budget to support driving valves, etc.)
- CPU slot will need similar, but probably wants to pass through the power supplies to the backplane, and needs enough pins for all of the SPI chip selects. I would vote for having at least 24 slot addressing because if the IO slots are small enough you can fit a lot of them into a 18" - 22" long backplane (Anything more is unreasonable in size to fab). We could all argue on the limit of the backplane size, but my point is that lets not limit the addressing capability at an early stage.
* The question is: do we bring out 5 bits of GPIO from the CPU card and have some decoder chips on the backplane, or bring all 20-24 chip selects out through the CPU card's connector? I don't exactly like having silicon on the backplane.
* Alternatively, could we just buss the 5 chip [slot] select "address" lines to each card, and fabricate the backplane in such a way that each IO slot gets its own unique address via "jumper" traces? This imparts some more complexity on the IO card since it needs to compare the two addresses, but for 5 bits this can be done in a PAL or even 74 series without a lot of pain or cost.
I don't think we should worry much about the more complicated IO cards. Reading a 16 channel A/D card will be as simple as addressing that chip select [slot] and reading in 16*16bit words. The controller software will need to have a file (or data structure) describing each slot's buffer size and how many bits [bytes? Words?] to read off of each one. Logically, in software the IO could look like a data structure, and, like MODBUS, it would be up to the program to interpret what the data means. I think its too early to get into this in detail, I just wanted to mention that ADC and DAC cards should be no problem as SPI doesn't define data size going into an out of chips [slots].
Why limit the backplane pinout to 8 slots? Is that just for your initial prototype, or is that the "standard"? I understand it is simpler, but for the added cost of 8 more pins on the CPU board backplane connector there is no reason the bus specification can be extended to 16 slots (or more). You mentioned "Cabling in" the SPI connection from a CPU residing outside the rack. I'd argue to put a connector on the backplane for featuring an "In rack" CPU and then you can either wire it to a "black box OTS" CPU, or down the road someone might integrate a full blown rack CPU or something in between. We can't say that a CPU won't be home grown for the rack, as even a simple to interface AVR MCU has SPI and would make a suitable "extreme low cost" alternative for C programmable controller for hobbyists and simple automation. This would give the project a wider audience. Maybe this would even be a good way to test the rack as Bill suggests (I still favor AVR over PIC, but use what you have :o)
I'm a bit confused as to who is doing what and what roles are to be. I would imagine that if you want community support that some common standards might want to be addressed, and it need not be overcomplicated. The goal of an open project like this should probably be to meet the most requirements of the most users without sacrificing too much for cost or complexity.
> I am aware of the facts you stated, I just wanted to clarify on this list that you can't actually buy a plug computer for $50, and to my knowledge there is not a $50-$100 "system on module" that breaks out SPI, UART, Ethernet, etc for this chip. If anyone knows of one it would be useful. <
Visit the Embedded World in Germany/Nürnberg and you can buy one of
these SBCs for 99 EURO: http://www.dilnetpc.com
> Why limit the backplane pinout to 8 slots? Is that just for your initial prototype, or is that the "standard"? I understand it is simpler, but for the added cost of 8 more pins on the CPU board backplane connector there is no reason the bus specification can be extended to 16 slots (or more). <
----- snip -----
There _are_ several reasons. One is how often you need more than 128 points in one cabinet. And if you do need more, adding a second rack is quite possible. Microchip provided addressing for 8 expanders on a bus, and that provides a clue even if I'm not using the addressing capability. The fanout for the drive lines is not specified and not all chips may handle the higher capacitance and load. When they are bussed, all the chips must be able to drive the bus. The second is distance and speed. SPI is an on board bus, it was not specified for long lines and there is no error checking and correction. As load and line length increase you might have to slow the bus to keep the error rate zero. Having long scans is undesirable for many reasons. And it might be hard to find enough uncommitted GPIO pins for 16 chip selects as these processors double up functions on the pins and you don't want to rob peter to pay paul. Eight may be a stretch with some boards. I have brought out the addressing pins in case the chosen processor doesn't have enough free IO pins. You could use addressing for the digital IO and hard selects for the chips that don't support addressing, that would be messy, but it will work. There is also a cost factor as a backplane much longer begins to be a special item and outside the protoshop comfort zone. And last but not least, I would rather have an 8 slot rack with a higher probability of working than pushing the envelope. I will publish the PCB files and you can extend the bus as far as you like. In short, we could extend our spec to any number desired, but physics still determine what you can really do.
> I'm a bit confused as to who is doing what and what roles are to be. I would imagine that if you want community support that some common standards might want to be addressed, and it need not be overcomplicated. The goal of an open project like this should probably be to meet the most requirements of the most users without sacrificing too much for cost or complexity. <
Hardware is a little different than software. I like all the input and have tried to meet the general need. But, I have been at this point before with much the same project but with a PC104 processor. That was a while ago and quite a bit of discussion ensued but little consensus and no hardware was produced. You simply can't implement hardware more than one way at a time. And since many of the ideas conflict, I take guidance from other attempts at Open Hardware and have decided I will produce a "reference" design. In deciding that, I have to take into consideration what I can realistically do. I intend to produce a working hardware PLC capable of running Linux. It will be capable of using many types of processor module as that is an area of divergence. It will use a SPI backplane as that is key to supporting diverse processor modules as _all_ can do SPI. I have done a few reference cards. Any other cards can be added. I will do the physical backplane so that another backplane can be added or it can be replaced with another type. But with hardware, the way to submit "patches" is to make hardware. I think I've gotten some agreement that what I intend to do should work. I intend to build it to find out. Is this the final solution? I doubt it. But, if it works, it will work for much of the work we do. And it's a start. I won't be able to do many iterations or changes, so I need this first one to "just work". I am doing this because at this moment in time, I know how to make the hardware, but I don't know how to do a collaborative Open Hardware project. I'm not sure anyone else does either, but we should keep trying to figure it out. It seems like all the ideas would produce completely different hardware, how do we bring that together?
The reason you need specifications is exactly because hardware can't be patched. Specs can be revisioned digitally, fast. You design on [virtual] paper before you commit to hardware. This is like software, but you limit the amount of release cycles (because it is real and costs money). What I am trying to avoid is random efforts of multiple parties with different requirements. It is counter productive when you find 10 groups of people doing almost identical projects, and if they converged the efforts could be better. I can understand your concerns about endless debates and no concensus, but because there are no specifications people are going to have a hard time seeing why you might want certain features. Specifications allow others to point out potential problems, anything from timing and impedance to required signal routing, dimensions, etc. Saying that a complete backplane system doesn't need a spec "because its SPI" is just not true. I don't think we need to get overboard either, but somewhere in between would be nice.
NFPA electrical code all installations have to be "listed", there are numerous listing outfits with UL being one
Sent from my iPhone
KEJR: "Why limit the backplane pinout to 8 slots?"
The following is a quote from a Siemens S7-300 installation manual: "No more than eight modules(SM, FM, CP) may be installed to the right of the CPU." Apparently, at least one major PLC vendor also seemed to feel that eight was a reasonable number.
Bill Sturm: "I have always thought that only certain cities and locales required UL listing. Maybe that has changed..."
I am not familiar with US laws or regulations, but for most countries I believe that any certification would have to be arranged by whomever is actually building the system (boards). You couldn't certify just the design anyway, as that does nothing to show that the system is actually built to that design. That's why for example if you contract a company in China to produce exact knock-offs of someone else's product your version of it isn't covered by the original certification. However, you *would* want to design the system such that someone wanting to built them would be able to get them certified in various parts of the world.
People get custom boards built all the time for industrial and commercial applications. I don't know how this is handled in the US, but in Canada you would typically get a "special inspection" for them at the same time as you get the rest of the machine inspected. Typically, if the voltage and current are low enough the inspector isn't very interested in the electronics anyway (there are different classifications of circuits). Anything with power fuses or transformers however would be looked closely at (and possibly meggered!). It is best to design it to use an off the shelf (and already approved) power supply to avoid problems.
In Europe I believe that people can "self-certify" things if they know the process. I believe you typically have to take a course and learn how to assemble a design documentation package and also keep records on how the items were assembled. However, I haven't been impressed with some of the results of this process as I have seen European equipment fail inspections in Canada that would never have complied with their own regulations either. Again though, I believe that each "manufacturer" has to do the CE process themselves.
Something that hasn't been discussed so far is design and documentation licensing. Under copyright law, software can't be redistributed by third parties without some sort of license. The same applies to any drawings, specifications, or documentation that you might produce.
I think you would want to put the design under a license analogous to what is used for "open source" software. The people doing the design work here would need to decide what they want out of it, but I imagine that something along the lines of requiring that the designs (drawings) be passed along to the customer along with the rights to make use of them, and to make their own further modifications. The license would also need do the usual warranty disclaimer, etc.
There is something called the "TAPR Open Hardware License" used for some electronic designs. However, some points in it looked rather problematical to me, so I wouldn't recommend it.
Someone like the SFLC might be able to advise what an appropriate license would be. There might be a few points about hardware which make directly applying a conventional GPL type license impractical. However, someone like the SFLC could probably offer some (free) advice on this. Open hardware designs are becoming a popular topic now, but there isn't a lot of existing information on how to go about it (like there is with software).
By the way, I believe that both SPARC and MIPS microprocessors are "open source" hardware designs. SPARC processors are used in high end servers from SUN and Fujitsu. MIPS processors are used in a lot of embedded designs, including industrial equipment (I believe that Siemens uses a lot of them). This isn't directly relevant to the I/O project, but I think it is an interesting point.
I am roughing out a draft of the spec dealing with the electrical signals and connectors and I have a few questions:
- Curt: what is the signal pinout on those boards you already did a rough layout? There are only 4 signals in SPI, what are the 6 extra signals doing? Why use the extra signals?
- Where should I publish the spec? Nobody really said much about Gilles suggestion for a wiki. Are we routing everything through Bill for now?
Just as a side note, am I the only one that is uneasy that these first two boards Curt has designed have absolutely no opto-isolation from the logic supply? That's fine for a minimalist hobby project, but to be used in real industry this will get laughed at. Your logic supply should be filtered and used internally for logic and separated from the field IO through opto-couplers.
The enclosure is an issue, I do not know of any ideas that are truly a perfect fit as of yet.
I was thinking of two concepts: One is a Hammond box with card guides, such as a #1590 or #1591, http://www.hammondmfg.com/1591icep.htm. These are not large enough for 8 slots probably, but they would be a reasonable start. We could also mount the backplane in a snaptrack, it could be any length but our widths will be defined for us.
Another idea would be to use Snaptracks or Phoenix card holders to hold the individual boards and a ribbon cable bus, this would of course require a parallel bus and address decoding on the boards.
We should agree on something before we go too far...
Well, that is a constructive suggestion. And the I/O boards that I did years ago and published here did have opto isolation. But many current PLCs do not, so I wouldn't get too uneasy about it, I would say it is the exception rather than the rule. It is also handy to use optoisolators that have back to back LEDs inside because you can connect the inputs as either sink or source. But there are a couple of things that shade against isolators for this first board. One is the space available for connectors, in my view isolated inputs that share a common are not isolated. So when I do that card, it will have to have 32 terminals or less inputs. The second is the speed factor. Photo Darlington couples turn on fairly fast but there is no place for the stored charge to go, so they are pretty slow, and worse, somewhat variable, in their turnoff characteristics. I want to characterize the system the first go around, so I am using the bare inputs with dividers. And no 15mSec filters. This is a "High Speed" card. And there is isolation between the bulk power and the chip power. The local 78L05 regulator provides a great deal of isolation between the two. That's the three terminals above the expander. The common grounds are a fact of life. I don't believe in floating grounds for industrial electronics with mixed wiring. If this expander proves suitable for continued development, I'll do an isolated version. I want to get something going to ground the discussion. In the meantime, if you want to tape up an input card, feel free. Here is what all the pins do on the connector. This is still subject to change.
1 16 +24VDC
2 INT B this is one of the interrupt on change pins, not used yet.
3 A2 Address bit for Microchip MCO23S17 only. Will reflect card slot.
4 A0 ""
5 SI SPI MOSI
6 /CS SPI Chip Select, Active Low.
7 Not committed will probably carry +5 from card for address bits. 8,9 GND, -24VDC
11 SCK SPI clock
12 SPI MISO
13 A1 Address bit for Microchip MCO23S17 only. Will reflect card slot.
14 /Reset Active Low.
15 INT A this is one of the interrupt on change pins, not used yet.
We have to be very careful with the numbering as a right angle connector can change left row for right. These are for the RA connector on the _solder_ side of the card as that affords visibility to line up the connector and also makes the bus layout better with no component side jumpers. This is one reason not to cast things in stone until you see how things will fit together a bit. I have a preliminary housing arrangement that will want the 1" card spacing version. Still looking for one that will work with 1.25" spacing as drawn. I'm going to send Bill new pics with the 16 pin connectors on the cards. Had to take time to fire up the lathe and milldrill and make stove parts. A wiki is fine by me, but I'm busy spec'ing parts to finish the layouts.
I was a bit harsh on the Opto isolation, there is probably room for both in a system. Every PLC or remote IO system I've used in the last 15 years has been opto isolated though (unless it was analog). We need to be careful with noise coupling from field devices (conducted (common ground), capacitive, radiated). I don't mind administering a Wiki or Google Docs. I'll look into it tonight.
I too think the chassis/mechanical is far dwarfing the electrical spec, and that electrical/mechanical is an iterative design process. I do think we need to nail down a few things or else there will be a lot of revisions going around. I started a CAD drawing of a front view of a chassis and I think we can easily do 0.75" pitch boards, something like 3" - 3.5" wide. You can get either 16 or 18 conductors in a pluggable "spring cage" connector, even with retention screws (very nice to know your connectors won't vibrate loose). For sheet metal I can mill/shear out prototypes but we will want to quote price in hundreds to make sure the project will make some sort of reasonable budget.
Well, I was racking my brain to think of a rack that wouldn't double the cost or require fabrication and that anyone has access to. I'm still looking, but I came up with something that will work at least to test and maybe in some applications. I was thinking of long narrow chassis and dismissed steel studding as hard to work with, and many have never seen it. Then I thought of wire duct, which we have all seen. I checked things out and we could use the narrow finger wire duct in a 3x3 inch size as a rack with a .5" pitch so it would work with a 1" board spacing. the backplane would mount in the trough and the fingers would support the boards. This could be mounted in a piece of solid side 4x3 or 4x4 duct and the cover could be slit into 1" pieces to make the board panels.
It could be arranged so that the space between the two was at the bottom and provides a trough for the wiring. It would look kind of bush league, but it's relatively cheap, would require little fab and no machinery and would be available anyplace. And it's fire rated, etc., Some one might even make end plates.
For any project that I've been involved in that required custom electronics, the most expensive things were usually the engineering, assembly labour, and the enclosure. The actual "electronics" was usually the cheap part.
I don't think the wire duct idea would be too popular with electricians because the boards would flop around too much. There is nothing to guide the assembly and hold everything securely.
For low volume, plastic is usually more expensive because you can't do much without making a mould. Metal is usually cheaper if you can do everything with a bandsaw and a brake.
The best thing that I can think of is to use an open rack card cage. If you use a eurocard size PC board, you can buy these already assembled off the shelf. You can also buy just the parts. Here's an example:
If you look at that link, you will see some bare racks. The racks consist of sheet metal end plates joined by aluminum extrusion rails. The screws go through the sheet metal and into the ends of the rails. That means you can cut the rails to any length and still add your own sheet metal end plates. The end plates are simple and custom end plates could be bent up on a brake. If you download the catalogue you will see the individual components. No doubt there are plenty of other sources of equivalent parts.
If you use a 25mm board spacing, then 8 boards will fit in 200mm. A standard length of the rail is 432mm. You could cut those in half to get 2 pieces out of each length. That would make each one a half width size for a 19 inch rack (which might be useful to some people). Card guides are also available (you should be able to get these from Vero as well).
If you make your own end plates you can of course make the card height anything you want. However, you would want to have a good look at the card guides if you want to make the depth less than a standard eurocard dimension. These sorts of little mechanical odds and ends are things that people don't want to have to spend a lot of time modifying.
If you know of some good surplus electronics stores, you might be able to get some old racks that you can scavenge parts from to build a prototype.
As an alternative to this, OKW make plastic enclosures that look like shoe-box PLCs. The boards would mount flat with the terminal blocks coming out the top and bottom. This looks very nice, but you are stuck with their enclosure design and probably can't source alternatives easily.
Yes, Isolation from the backplane P.S. to the IO power supply is usually what you are after (or at least for me and some colleagues).
I think .75" would be a bit tight for a card with a double stack connector. Those would be needed for either isolated inputs or multiple commons. And it would be nice to have room for some sort of LEDs to show input status. Tell me what you think of the wire duct idea I came up with. It doesn't even need painting. And if anyone has a scrap chunk of 3x3 narrow finger or 4x4 solid wire duct that they can spare.... It comes in 2 meter chunks and they are kinda spendy that way, although you could get 5 enclosures out of each piece. The spec I was using was for the stuff that Automation Direct sells. I think they get it from Hubbel. I would think Panduit and the others are compatible.
I haven't looked at double stack connectors because the pluggable versions seem to be kind of expensive (Pluggable TBs in general aren't' cheap...). Most high density Isolated Input cards I have seen are isolated from other types of devices, not from themselves. 24V inputs usually aren't noisy as they are mainly hooked to hall effect switches these days. In this way having one common per Input card is OK for everything I have done. If someone chooses to have multiple commons this will eat up more pins.
I can't argue with the expense of the wire duct idea. I am concerned about the mechanical strength mainly, and the perceived quality as well. We use some European duct at work that is somewhat delicate without the cover on it, but we might have some bigger "Panduit" style laying around that is more rigid.
I designed a 3 slot backplane chassis about 7-8 years ago that had no press brake bends to it and the cost to have it fabricated by a local sheet metal shop in QTY 25 was under $15. The cost for this system will be more, obviously. I'm used to seeing backplanes and chassis costing anywhere from $100-$300, so this initially doesn't seem out of the ballpark. The old design had a single cover plate that went over all of the boards (This part did have some bends on it), and I think for this system we want to have each IO card be removable without taking a cover off of all the boards. It might not be bad if we could come up with a standard connector cutout and always enforced pluggable connectors. Otherwise a "mass cover" is going to be difficult to use (who wants to remove wiring on board "A" because board "D" failed?).
I can't help but wonder if we could source some VME style extrusions. These have all of the hardware, tapped holes, rigidity, etc. The only thing we would have to do is fabricate some custom end plates, which at a prototype and production standpoint is very very simple. I know VME is prohibitively expensive as a whole system, but the actual extrusions in long lengths should not cost hardly anything. I'd be surprised if 8' of the stuff was more than $15. What I don't know about this idea is as follows:
- Can you get the extrusion?
- Can you get VME/CPCI card guides that are short? (We don't want 6"-7" deep cards!!) Card guides are built into the Euro rack system, so you can't just use any old card guide for short boards.
This is exactly what I was saying in my reply this morning. As you said, finding shorter card guides is the key. If anyone can find this out it would be very useful for the project. Also, pricing the extrusions in bulk would be helpful, but I can't imagine they are bad.
Here's another source of rack hardware. http://www.vectorelect.com/
They have two styles DIN and EIA. Card guides come in snap-in and screw mount versions. The snap-in ones are much cheaper. The following is an example only for snap-in guides.
Card guide: CG2-45S 80.52mm pkg 12 - $18.76.
Strut: TS169-6/90 16.85" ea - $19.61
If you use screw-in guides, then the strut is about half the price, but the guides cost twice as much (including screws and nuts). Lets round the above numbers off to $3.00 per pair of card guides, and $20 per strut.
Hole to hole centres on the strut are 0.75 inches (or 19mm). That allows for 22 cards on the minimum centres. That means that for 8 cards we can cut each strut into 2 full sections with one short section left over. So, for a full rack (with minimum card spacing), we need 2 struts ($40) and 8 pairs of card guides ($24). So, that amounts to $64 plus the cost of end plates, and any top, bottom, back, and side covers used. This can be considered the floor price for "rack" style packaging.
The DIN (Eurocard) packaging is somewhat more expensive and the minimum size is larger (these two points are closely related). I didn't shop around for these prices - I just used the first distributor that Vector listed. It's possible that someone may find better prices than these.
The packaging considerations will obviously have a strong influence on the board design because it will dictate certain board dimensions as well as the pitch between the backplane connectors.
(In reply to M. Griffin:)
Vector is tailored to the prototype market and in doing so is going to have readily available but more expensive hardware (I'm guessing). I would be willing to gamble that you can get a 20' length of strut inexpensively if someone will source it "onesy-twosy". I'm not saying anyone here should run out and buy 20' lengths of struts, but it would be good to know if there was a bulk source of this stuff for budgetary purposes. I'm sure its the type of thing where you could find out in a few phone calls where people get this stuff. My phone time allotted to this project during work hours is very limited though. One issue is that the guys making these things are used to "big money"... Telecom, Military, Test.... Will they sell us parts... Who knows.
If, in fact, the price can't come down much more than your $64 I think that custom sheet metal is more attractive. I have not done a full analysis including card guides and fastening hardware however.
The commercial offerings seem to be all aimed at deep cards and not to our application. I have found 2.5" card guides for $.15 each in qty. they snap in drilled or punched holes. It should be cheap and easy to bend a simple channel that takes the backplane and guides and cards and mounts in the enclosure of your choice. Any hvac shop could do this. But the drilling would be a problem for those without a shop. I can buy a simple brake to bend this for $30 or so. I can get 12" wide rolls of galvanized steel economically as "flashing tin" at a big box store. So there are things that could be done, but it would be nice not to be in the sheet metal business. I would like for anyone to be able to put this together with local sourcing or internet sources. I may buy the brake anyway as this gives me an excuse :^)
You can't compete with a sheet metal shop that has a CNC punch machine and press brakes. They load up a machine and load the CAD/CAM file and it punches all of your holes and profiles unattended. I'm pretty sure the metal will be under $20. I'd rather target a market where someone buys the backplane and cage from multiple sources who have invested in the quantities to make it a reality (since its open). IF someone has the machines to do it themselves, that is fine too. I just don't think it does the project justice to think that people will be out there hacking together units with saws and drill presses and wondering why cards don't line up. If we can get the smaller backplanes/cages to under $50 this would be a good price point for companies and hobbyists needing a lot of IO in an "industrial" package. I have access to a full shop and could donate a prototype cage to you once the design settles out.
I forgot to mention this, but the pluggable 3.5mm connectors I like are made by Weidmuller and are available from Digikey. I think the Right angle board header is about $5 and the removable spring cage plug is a bit more. I would not mind finding something that is cheaper in a very similar package (yeah, I think I could live with 0.2" (5.08mm) pitch for 16 contacts).
> You can't compete with a sheet metal shop that has a CNC punch machine and press brakes. They load up a machine and load the CAD/CAM file and it punches all of your holes and profiles unattended. I'm pretty sure the metal will be under $20. <
No, I can't compete for a qty order, and I'm not all that fond of sheet metal work anyway. But, it would be good to settle on something that could be fabbed locally for people in East Borneo or ? I found card guides that would work for sheet metal, also at Digikey. I can post the number. I will need to decide on a card spacing soon. I have 1.25" and I think probably the best compromise is 1". That allows space for leds and a double stack connector and would save on board cost for the backplane.
> I forgot to mention this, but the pluggable 3.5mm connectors I like are made by Weidmuller and are available from Digikey. I think the Right angle board header is about $5 and the removable spring cage plug is a bit more. I would not mind finding something that is cheaper in a very similar package (yeah, I think I could live with 0.2" (5.08mm) pitch for 16 contacts). <
I don't see how to use 3.5mm without a bigger board or less points. The 2.08mm are an Onshore Tech. part, There are several varieties but I want to use at least tin plated grade. They are wire clamps with a screwdriver slot. I like spring clamps, but I think they are bigger.
I'm happy to leave packaging to others, but we want to settle the parts that affect the board layout soon. I will set some mounting holes on the backplane as these would affect the package.
I sent a concept drawing to Bill. It is done in QCad which is free on Linux and of nominal cost on Windows. I sent a .png and a .dxf. The .dxf is supposed to be in AutoCad 2000 format for those who have AutoCad. The drawing is to scale and can be modified to show other ideas or ? I don't know how well the interchange with AutoCad works, so QCad is preferred. This drawing is for the 1.25" slots. I will do another with 1.00" slots when I get the 1" backplane done.
Curt said: "in my view isolated inputs that share a common are not isolated. So when I do that card, it will have to have 32 terminals or less inputs."
I agree that few PLC's have isolation from channel to channel, like an Opto 22 rack. But I think most have isolation from the I/O circuitry to the logic circuitry. I think this is what Ken was referring to. That style of isolation only requires 2 extra terminals. Otherwise, how would we use sourcing outputs > 5 volts? And I am not saying that we absolutely need any isolation, but that it might be a good idea.
Yes, the finding is the big problem. A Google search for card racks turns up thousands of hits and sorting through the mess would take a lot of time. I'm not too worried about looks at this time, PLCs tend to be ugly and get more ugly once you have the real world attached. If there is any substantial volume, more solutions become possible. It will substantially complicate things if we have to have things made for the project. Volumes are extremely unpredictable, who knows, I might end up having the only one, or someone might want dozens for a special project. The only part that needs to be unique for the hardware is the front plate. I still have some places to look for an OTS box at least, and that would leave only the front plates. It would be easy enough to just saw slots in a slab of nylon or HDPE for the card guides, but those slabs come pretty dear these days. If a person can come by a source of the snap in card guides used in PCs, they would probably be cost effective. One good thing on the connector front is that a standard .200" layout will work for both pluggable and non pluggable connectors of several types and the choice can be made on need or cost. Where did you see spring clamps reasonably? I'm going to call around and see if I can get a sample of the two types of wire duct to at least judge how that works. The connectors will also impact the front panels somewhat. I have a milldrill and can make presentable front panels, but that isn't a universal solution.
In reply to Curt:
> One good thing on the connector front is that a standard .200" layout will work for both pluggable and non pluggable connectors of several types and the choice can be made on need or cost. Where did you see spring clamps reasonably? I'm <
I'd like to get the package to under 4" if possible. I also would like opto isolation as an option (different card design). Perhaps if we bring the IO power in separately on the backplane we can use 16 conductor 0.2" pitch connectors on the front and still have room for all the hardware for the option of a fully enclosed unit. Maybe I'll have some time this weekend to do a CAD layout to see what kind of room we need once card guides, front plates, and card cage retention is all factored in.
is that an RC network on your inputs. I see some spaces labeled R1-R16?, but I'm not sure what 17-32 is. I think series resistors are an obvious choice for current limiting, then maybe some zeners or Transzorbs in parallel to ground for OVP. Also, should we use pins 7 and 10 for an earth ground to the boards, primarily to be used to sink voltage spikes, so they don't have to go to the supply common?
Those are voltage dividers to scale 24V inputs to the chip level. All 32 are resistors. The inputs have clamping diodes and the high resistance of the dividers will limit the current. You can socket the chip and replace it for a buck or so. 16 Transorbs or zeners would be expensive overkill. And the chip can be destroyed before they begin conducting. In actual testing, having "stiff" supply rails for the clamp diodes to conduct to has provided better protection. In this design, the backplane and case will be grounded to earth ground and two pins are tied to the backplane ground. The inductance of a separate wired earth ground would make it less effective. I did ESD testing for Control Data for a few years. The chips have gotten a lot better, even hand held devices have very few ESD failures and for extreme abuse, you would probably want to replace the chip anyway.
While on the subject of power, I could use some opinions. I have opted for linear 3 terminal regulators for the cards. This is reasonable, I think, because the 5V requirement is very small, around 10ma., less for an input card. I would like the whole unit to run on a single 24V supply for convenience. But, when you add a CPU card, things get a little more complicated. The CPU cards I have been looking at are wonders of low power, 2 or 3 watts. But at 5V that means we should allow as much as 1 A or even more because we don't know that the CPU chosen will be that low. The problem comes in because we have 19 V dropped across the regulator. If we use the simple approach of another three terminal linear regulator, it would dissipate just over 19 watts. Not a huge amount of power, but the regulator would require a fairly large heat sink to operate over our temperature range. And its kind of a waste to have a 20 watt heater in a low power PLC. I could design in a switcher with reasonable efficiency, but that would involve magnetics and the potential for noise, emissions, etc.
The chickens way out would be to leave it to the user to power their CPU card. Another would be to use two supplies. I don't like these much either, but it would get the heat outside the case. So, I thought I would see what the potential users might think:^). It's a very novel approach in automation.
I think it is very reasonable to use an off the shelf switching PS for the computer. Having said that, it would be nice if the rack had a 5 volt supply (or 3.3 Volt) specifically for a host processor.
This may be a good solution: http://www.dimensionengineering.com/DE-SW050.htm Have you seen these? With this idea, we do not have to develop a switcher of our own. It is not super low cost, but probably cheaper and smaller than any external supply.
I feel that 24V should be supplied to the backplane, either through the CPU or a connector on the backplane that someone can get at in the field. From this Backplane supply, the CPU card would feed 5V logic supply to the daughter IO cards through separate traces.
- Supplying 24V to the front panel of the CPU card makes it easy to wire, but limits the amount of connectors you can have on the front of the CPU.
- Supplying 24V to the backplane makes more requirements (potentially) on the mechanical layout since you have to leave room for a screwdriver to get into the end of the backplane. Depending on the path chosen this might not be a bad thing.
Something like that TO-220 switcher would be great to get started, and then something cheaper could be developed out of discretes. At this point we should probably just pick Backplane supply vs CPU "feed through" design. I guess I'm leaning toward the backplane to provide connections for 24VDC. If we lay it out and it is ridiculous this might change! :o) I guess it could be specified both ways, its just extra pins on the CPU connector.
Ken said "I feel that 24V should be supplied to the backplane"
I believe that this is exactly what Curt has in mind. Here is my interpretation: We will have terminals to supply 24VDC to the backplane. The 24VDC will get bussed to each card, where it will be regulated to 5VDC for the logic power. If I understand correctly, the backplane may have an extra 5 volt regulator with enough current to drive a processor board. (add it to the board layout, it can be optionally populated) This is where I suggested the TO-220 packaged switching power supply. So we will have 24VDC in and 5 VDC out on the backplane. Is this correct?
Exactly right, Bill, except a switcher there gives me pause for noise considerations. I'm looking at it though. I hate to generate extra
> I feel that 24V should be supplied to the backplane, either through the CPU or a connector on the backplane that someone can get at in the field. From this Backplane supply, the CPU card would feed 5V logic supply to the daughter IO cards through separate traces. <
The backplane has a connection for the 24VDC bulk power. These are currently for large wires, but would accept terminals of some sort. I don't bus 5V through the backplane because we learned in 70s that with the low voltage and relatively high currents and switching transients, you have much cleaner power with local regulators and minimal interaction. Since the output current will dwarf the CPU current, the plan is to power the backplane and run the CPU from that. The local regulation also means that the bulk power, the 24V bus, is not very critical and we can confidently use any OTS 24V supply with an adequate current rating.
The CPU power, we have to be a bit careful with. Although the input voltage is specified as 5V for convenience, the board is full of logic that is running at 3.3 V or even less. So the noise margins are low. It is important that the CPU common be run directly to the "one point ground" in the system at the bus ground plane. And if we do obtain the CPU power from the backplane, a high quality regulator and filtering should be used. Fortunately, PLC speeds are so low that noise from the IO shouldn't be a problem. Noise from a switching regulator might be, due to proximity. The ultra low power electronics means high impedance and we would want to shield a switcher if we build it in.
> - Supplying 24V to the front panel of the CPU card makes it easy to wire, but limits the amount of connectors you can have on the front of the CPU. <
The way I have planned it so far, is that the CPU card will mount horizontally ( that is in the same plane as the backplane)in it's own 4" X 4" bay at the left side of the housing. None of the CPUs I've seen are set up to plug in to a BP and they have connectors around the edges for the various interfaces. So it wouldn't have a front panel as such, There would be a cover over this bay which would provide a convenient place for status LEDs, switches, LCD display, etc. I should have made a rough drawing at least, as is was many words ago that I described that. I will make a concept sketch and ask Bill to post it. But, it will look like almost every other rack type PLC. Which isn't a bad thing.
> - Supplying 24V to the backplane makes more requirements (potentially) on the mechanical layout since you have to leave room for a screwdriver to get into the end of the backplane. Depending on the path chosen this might not be a bad thing. <
Access to the CPU end of the backplane is easy through the CPU bay.
> Something like that TO-220 switcher would be great to get started, and then something cheaper could be developed out of discretes. <
----- snip -----
I'm still pondering. Even though it wastes power, a simple linear regulator is attractive from cost and noise standpoints. And if we have a metal housing we can thermally couple the regulator to that for heat sinking.
I'll post a sketch tonight if possible.
The output card as designed has sourcing outputs at 24 volts. That's to work with the sinking 24V input card. The chip +5V is generated from the rack +24 which only supplies the actual output devices on chip. One dilemma was between internal power or external power. External power has the virtue of simplifying power distribution. but has the issues of ground loops and I've seen many cases of latchup and weird problems when it's done that way. Internal power means high currents on the bus, but ensures that the internal clamping diodes and protections are effective. Since many people don't bother with diodes on inductive loads these days I have empted for internal power for reliability. I could make it a jumper option I suppose, but folks would need to be careful when using external +24V. For sinking outputs it's not such a problem but it's still good to have things returned to the same point. There are a lot of things that must be carefully considered, especially for use by the general automation public.
"In my view isolated inputs that share a common are not isolated."
While not trying to get into a discussion on the definition of "isolated" I don't see value in individually isolated inputs. I definitely see the value of isolation from the logic, but input from input?
Most inputs have a common, uh, common anyway, so having two terminals per channel just makes more wiring. For me, individual channel isolation would create a lot more extra work (in wiring) than the commomed ones would create when I occasionally (think once a year) have to install a relay or optocoupler because they aren't isolated. You could have a specialty input card for people who need a lot of isolated inputs.
I do like the idea of internal power for the I/O, I guess. It is certainly seems simpler to use for many applications.
I do not like the idea of a wire duct for a rack enclose, they are way too flimsy. We need a better idea here, IMHO.
What about a bracket that holds the cards solidly to the backplane, who needs an enclosure? We could ultimately use a beefier circuit board (~.125") for the backplane and just bolt everything to it. Maybe???
In reply to Bill Sturm:
> I do like the idea of internal power for the I/O, I guess. It is certainly seems simpler to use for many applications. <
I mostly agree, but I go back and forth. You might want to limit the current so you don't pop your backplane or connectors. The power required for output cards is rather huge (even at 100mA per channel) though and you would need some kind of reasonable power budget. Nowadays with 1Watt valves being very common you don't need 250ma per output.
At a minimum, Power supplied through the backplane should have Logic and IO Power separate!!!
> I do not like the idea of a wire duct for a rack enclose, they are way too flimsy. We need a better idea here, IMHO. <
> What about a bracket that holds the cards solidly to the backplane, who needs an enclosure? We could ultimately use a <
Some folks make a card guide that bolts to your backplane. These would have to be relatively cheap to compete with a sheet metal enclosure IMHO. For the 8 slot chassis you would have to be probably under $2 a piece to keep it competitive with cheap card guides and simple sheet metal. I had only really considered this for OEM (and hobby) types of applications where cost was king. For professional life I'd spend the extra $20-$30 and get an enclosed sheet metal box to help prevent stray wire strands and screwdrivers from landing on my boards. This is a personal/professional choice and really there is room for both approaches in the spec as long as the boards stay the same for both.
How would you accomplish board retention with simple card guides bolting to the backplane? This was what stumped me on this idea.
Ken asked: "How would you accomplish board retention with simple card guides bolting to the backplane?"
I was thinking of something like this... http://www.rabbit.com/products/SmartStar/
I think this would be a good option for an "embedded only" kind of approach. The fact that you have to screw into the card guides from the side make it difficult for single board field replacement. What is the price for that kind of card support? Another approach would be to buy the card guides that mount to the backplane, and use long standoffs on each end of the backplane and run a piece of sheet metal strip, or bar stock, that attaches to the standoffs and runs along the top of the boards to keep them in. This would accomplish retention and card support as well as field replacements by simple removing the retention bar with two screws. Again, how cheap are the card guides for this?
In reply to Ken E:
Vector also sells self-standing card supports. They are die cast zinc or aluminum. Each support is individually mounted (i.e. two supports per board) via a screw down through the base of the support into the mounting surface. The support curves away at the base to provide clearance for a backplane. The I/O board would then slide into guide slots just like with the conventional plastic guides.
I don't recall the price, but they were a good deal more expensive than the plastic ones. This is probably something you would only want to consider if space was very tight and you only had a few boards.
> I do like the idea of internal power for the I/O, I guess. It is certainly seems simpler to use for many applications.
I do not like the idea of a wire duct for a rack enclose, they are way too flimsy. We need a better idea here, IMHO. <
It's a field expedient.
> What about a bracket that holds the cards solidly to the backplane, who needs an enclosure? We could ultimately use a beefier circuit board (~.125") for the backplane and just bolt everything to it. Maybe??? <
If we give up the concept of plug in cards, I might as well make it on one monster board. I did find card guides for a 2.5" board for about 15 cents each in qty. 1k, but they want a drilled panel to mount to. Back to sheet metal. I also found a killer deal on wire duct, but it's .4"(9.2mm) pitch and thats a really odd number. Looks like about $200 for 3 protos of the 3 boards. Plus parts. Less than $10 each in qty., plus parts.
Advanced circuits has much better pricing, check out their "bare board" special. 2 layers, no solder mask, no silkscreen.... Very cheap.
I'll second Advanced Circuits, they are very good. They have great deals, such as Barebones, 33 each...
I was using their "Bare Bones" quote. They seem to want to get about $60 an order, In other words 1,2 or 3 boards all cost about 50 or 60 bucks. I could panelize and try that way, but I was just looking for ballpark numbers. 3, 3.5" X 2.5" are $21.04 each. 1 is $54.38. A 10" X 1.5" backplane is $57.50 for one or $24.17 each for 3. So I figured roughly $200 for 3 input, 3 output, and 3 BP. The price does get very reasonable for 10 or so, but you would want to try one first. In checking, I also noted an error. The Allegro chip should be a 2981 rather than the 2982, higher voltage rating. If someone wants to fund the protos, I'll get the artwork done soon. Otherwise there's no hurry, I don't have the cash in the kitty for protos anytime soon. I would like a set though.
I agree that they aren't needed vary often. But the more common type with common terminals aren't often needed in a properly wired system either. With even reasonable ground bonding it's not a problem. But, what I have seen a need for, particularly when interfacing several boxes, is a mix of sourcing and sinking inputs in the proportion I need and the shared common units aren't very good that way. I seem to always have the type I don't need and need the type I don't have. One solution would be to have say three commons and an internal jumper select, but that would be pretty confusing after the fact. But for now, a simple card will suffice. The burden to add cards is not very high once the other issues are sorted out. One thing I probably won't do are line power inputs. Not difficult, but that opens a regulatory can of worms.
In reply to M. Griffin regarding plug computers:
I am aware of the facts you stated, I just wanted to clarify on this list that you can't actually buy a plug computer for $50, and to my knowledge there is not a $50-$100 "system on module" that breaks out SPI, UART, Ethernet, etc for this chip. If anyone knows of one it would be useful.
some of the boards I posted will do those at less than $100. And they will run on a wall wart.
It does fall into a ugly gray area, with even states getting into the act as well as insurers. Don't get me wrong, I don't scoff well founded safety concerns and I have been severely criticized for Not doing things that I saw as dangerous. But, despite the lofty ideals and stated purpose, much of this impresses me as more about IBEW et.al. than about safety. And I do recognize the right of companies to build their own solutions, after all, they know what they need. A trade school graduate with a license, who has been wiring mobile homes for a year is held as far more qualified than someone who has been designing control systems for 20 years. But this design does reflect some degree of compliance, it is all low voltage DC for that reason. And I think computer gear is generally held as exempt in most places. So get out the labeler and call it a Linux computer system. An interesting example is that the products of two institutions in the printing industry, with worldwide presence and sterling reputations, had to get the OK of some local guy before they could be installed. Millions at stake.....
> Here is what I feels strongly about: <
> - Develop an SPI based rack with electrical and mechanical specifications.
> - The rack can be used with a CPU or a communications module (i.e. remoteIO).
> * Lets not get too detailed on what these are *Yet* There will undoubtedly be many options here.
> * Using SPI as the [rack] bus will allow many options, from completely embedded AVR/Arduino to Marvell processors.
> - The rack should be as small as we can make it (This is to compete with the bloated solutions that already exist).
Tentatively 3" high, 3" deep and about 14" long.
----- snip -----
> I think that developing the IO rack in itself is enough of a project for now. I don't think looking at embedded linux computers is a bad idea at this point because that is where we want to go, but lets not get bogged down with the exact System on Module right now. I think I prefer the modules that are more "stamp"-like since they let you dictate where the front panel connectors (USB, ethernet) will be located on the "carrier" module. We don't want to design a rack based system around one CPU module. The "linux stamp" is such a device, but so far it seems limited to a 200MHz ARM, which should be fine for most things, but not for everything. <
I am providing for the rack to use the processor of your choice. You can make it anything that needs Industrial IO.
> I have developed IO boards based on a backplane before and I know some of the problems in doing it on your own. I was able to get it down to roughly a 3" x 3" board size while still using 16 IO points and 24VDC feed. I'd like to do some of the mechanical layout and board design if my "home time" allows for it (I have to young sons, so time is not that available). I've found that DIP devices are very much hard to find in some areas, so working with SMD is almost required. If we keep with 0.050" pitch SMD devices you can still hand solder them and use a 2 layer design. <
I would prefer that if you did, you use PCB which is free and runs on Linux for sure and I think Windows. But I have had no trouble sourcing through hole components and they make the boards much easier to build and repair. So far all I've needed are the Microchip MCP23S17 and Allegro 2982, both full production items available from the usual suspects or direct. I have first pass artwork for an input and output card and am starting on the backplane. I have a lot of time.
> Bill: I've not used a lot of free schematic/PCB packages, have you considered the Advanced Circuits free PCB tool? It is one of those deals where it is free software if you order the boards from them, but they are one of the cheapest in the USA for prototypes. I know a lot of folks use Eagle, but their board size limitation (for the free version) is limiting. I'll check out the software packages you mentioned. <
As above, I would prefer PCB because it's free no matter where you get your boards fabbed. I have used Advanced before and they had no problem with PCB Gerbers and drill charts. For any collaborative work, we need a common format and one that is totally unencumbered. All the other freebies seem to want DOS or Windows exclusively. And their libraries don't compare with PCB.
> BTW, the plug computer keeps saying it will be released for $50, but this seems to be a marketing thing for them to demonstrate that you could build a Marvell based "PC" for $50 in quantity. So far I don't know of anyone that is offering anything based on that chip for $50.
> BTW, what do you guys think about bussing out the 24V on the backplane as an option? I've seen some of the slice IO guys doing this and it can shave down the front panel connector requirements (and wiring). We could limit the amount of current that the "bussed" 24V backplane could supply for power budget reasons, and anybody requiring more power would have to supply it to the front of the board. Just an option, and I don't think it is critical, but it would be nice to consider up front. <
I have bulk 24V on the backplane, but so far have only brought out the rail the inputs or outputs work against +24 for sinking input and DC Gnd for the sourcing outputs. The wireclamp terminals are on .2" centers and 17 are all that would fit without bumping the height. I could maybe add some by setting them behind the input row, but that would make it hard to get to the screws. I need to get some samples to see if I can make the terminal strips pluggable. That's handy if you need to change cards.
I have also located a local outfit that makes enclosures and panels and such by "no tooling" forming. Once I have dimensions, I'm gonna see what they say for the card slot panels and a box.
In reply to KEJR:
Marvel makes the chips, not the finished plug computer. They provide a reference design which other people can modify, load a Linux OS (Marvell pay for developing the Linux support for their hardware), add their own software to, and sell as a complete product. Marvell is stating that if you get the hardware made in quantity you can get it for $50.
Your own mark-up would typically be %100 (software development, advertising, cost of sales, etc.) which would result in a final price of $100. That is in fact what companies that are selling "plug" devices are charging for them (the development kits from Marvell are similarly priced). Keep in mind that they aren't selling them as bare plugs. They are selling them as personal Internet file servers, media hubs, and other such consumer goods. You could however simply wipe their software and install your own. Even at $100, that is very cheap, considering that it is a complete packaged system, not just a bare motherboard.
Whether or not this is what you want for this sort of application, it is a good example of what I would call "opportunistic hardware". It is cheap, readily available hardware that uses bog standard interfaces and can be adapted to a lot of applications.
>BTW, the plug computer keeps saying it will be released for $50, but this seems to be a marketing thing for them to demonstrate that you could build a Marvell based "PC" for $50 in quantity. So far I don't know of anyone that is offering anything based on that chip for $50. <
Catching up a bit, I looked at the Sheeva stuff. This is ARM 7. I'm not sure if 7 has a MMU and would run a "standard" OS. I really want to run a standard OS as much as possible. The ARM path is one divergence, but it's necessary because the US is _years_ behind because everything has to run Windows. And even when shown the light with the netbook fad, consumers did an about face and regressed to something that will run Windows. Fortunately, running Linux, I can take advantage of the tremendous progress driven by the cellphome/netbook/mobile market and use an inexpensive, low power, high function CPU and use reasonable resources. The Sheeva is an early example of what can be done by leaving the MS mess behind. I can make an _extremely_ powerful, high function, PAC for the cost of a low end PLC. And it's extremely simple.
There is more than one type of "plug computer", and there are at least two different CPUs involved. For the most common one, standard Debian ARM seems to be the most recommended OS. However, they recommend that you use the "dev" version of the plug as that gives you a debug port.
I also agree that an SPI backplane with DC I/O would be a great start. I could test it with some PIC's that I have laying around. I wonder if a desktop PC running Linux could do SPI through the parallel port?
I like the idea of bussing 24V on the backplane, anything that makes the end users life easier is good.
I have used tinyCAD and freePCB with great success, but they are Windows only and have a bit of a learning curve. FreePCB is especially good at board layouts and it makes Gerber files that can be sent to any board shop. I will look at PCB, as Curt suggested. FreePCB uses some defacto standard netlists from a CAD package, so we may be able to interoperate with various packages. Time will tell...
Open fashion may mean continued poverty, but creating a traditional PLC company would probably make you even poorer these days :) Anyone make money building boards and providing support, if they choose. Much like Linux distributions sell CD's (remember that?) and provide support.
Curt, you mentioned Virtual mylar, Rubylith and tape. Are you planning to make your own PCB's at home? I have usually had some proto boards made, but the $$$ add up.
I have hosted your pictures under the pictures tab on my website. Keep 'em coming... I'll start adding some too, soon as I can.
Thank you, Bill
Got some preliminary costs, the connectors will be about $7, the chips about $1 each and the resistors $2 for the bunch, metal film, less for 2% carbon film. Boards will be $15-$20 in proto quantities. So figure a couple bucks a point, less in qty. I may have to change to 16 pins on the backplane connector, 14 doesn't seem to be a very common number. And I need to add some bypass caps, etc. But they are still very simple cards because the expander does everything. I may fuse the output card, but the drivers do have current limiting, so it may not be essential. The analog cards will be a little more complicated to add buffering and the standard voltage or current capability.
No hurry on them.
> I think it is great that you are jumping into this project. I do feel is far too soon to be jumping into FR4 and "virtual mylar" before a signal specification is drafted. Although the SPI bus isn't that demanding why would you layout boards before deciding on what the features were first? <
Because I don't have to specify anything. The SPI is defined in the expander spec. :^) But I will document the bus layout, and I may juggle things to improve shielding.
> Here are some thoughts I had along those lines, some of which you had mentioned previously: <
> - Each "IO" slot gets the following signals:
> * SPI clock and data lines
> * Its own unique SPI chip select (Slot select?).
> * 5V, Ground (Need to decide a power budget).
> * 24V and Ground (Need to decide a beefier power budget to support driving valves, etc.) <
Yep, See, you really didn't need a spec :^) I am not going to bus 5V though, I'll generate that on the board with a 3 terminal regulator. The high line regulation will isolate input boards from output boards that can actually use substantial power. The current needed on each card at 5V is very low so a TO-66 type regulator cane be used. This also accommodates chips that may want 3.3V or ? I will bus 24V on heavy traces as the output cards can source 120mA continuously on all outs. and up to 350 mA individually limited by dissipation.
> - CPU slot will need similar, but probably wants to pass through the power supplies to the backplane, and needs enough pins for all of the SPI chip selects. I would vote for having at least 24 slot addressing because if the IO slots are small enough you can fit a lot of them into a 18" - 22" long backplane (Anything more is unreasonable in size to fab). We could all argue on the limit of the backplane size, but my point is that lets not limit the addressing capability at an early stage. <
The CPU will not be a plug in card as these are not at all standardized. And others have expressed a desire for processors that won't necessarily meet my needs. There can be slots for board mounting posts. Most of the CPU cards I've seen have peripheral connectors on all four sides so they need to mount flat. Connections to power and the SPI bus will be wired to accommodate any layout.
> * The question is: do we bring out 5 bits of GPIO from the CPU card and have some decoder chips on the backplane, or bring all 20-24 chip selects out through the CPU card's connector? I don't exactly like having silicon on the backplane. <
I will probably bring out 8 chip selects from GPIO. I did want to use the clever addressing on the expander but not all SPI chips support addressing. So, we need a chip select for each slot as you need to be able to plug any card in any slot. I have arbitrarily decided to do 8 slots, that's 128 points. Beyond that, power and scan time begin to be more problematic. You can add a second rack with a dedicated processor acting as a bus coupler speaking any of the comms supported by the main processor. This is the interest of some parties anyway, so by the time we need it they may have a bus coupler figured out:^). By keeping the CPU card unspecified the rack can economically be either a main or remote.
> * Alternatively, could we just buss the 5 chip [slot] select "address" lines to each card, and fabricate the backplane in such a way that each IO slot gets its own unique address via "jumper" traces? This imparts some more complexity on the IO card since it needs to compare the two addresses, but for 5 bits this can be done in a PAL or even 74 series without a lot of pain or cost. <
I am going to bring a chip select to each slot. I'm not going to bring an address bus as that would be redundant. And the address comparison is done against the data sent on the ones that have addressing so an external decoder won't really help much unless we don't have enough GPIO lines available. Then using 3 lines and a decoder would help. But the drivers would need to understand the sequencing. I think the drivers are written to use GPIO one line at a time.
> I don't think we should worry much about the more complicated IO cards. Reading a 16 channel A/D card will be as simple as addressing that chip select [slot] and reading in 16*16bit words. The controller software will need to have a file (or data structure) describing each slot's buffer size and how many bits [bytes? Words?] to read off of each one. Logically, in software the IO could look like a data structure, and, like MODBUS, it would be up to the program to interpret what the data means. I think its too early to get into this in detail, I just wanted to mention that ADC and DAC cards should be no problem as SPI doesn't define data size going into an out of chips [slots]. <
I will be thinking about the analog cards as the driver work needs to accommodate them. But I'm not in any hurry for them. Many of the CPU boards have A/D that can be used in the meantime.
All these points are subject to change for any good reason, but I'm going to shape up the bus in the next few days. The bus connectors on the cards are subject to change to optimize the layout, which is why I haven't generated Gerbers yet. And soon the progress will depend on getting boards made which will cost money that's hard to come by at the moment. But I want to press ahead so this actually happens. I'd rather change things based on a prototype than debate until everyone loses interest:^). The cost to change anything in this modular design will be low.
Is everyone aware that to put any of this hardware into use in for instance the US, that it must be "listed". That is tested and certified example UL in order to meet Nat Electric code. Europe is even better, as unit.
Oops a little more cost, unless you know of an " open" certified listing org.
As I said this gets much deeper as you go, hurdle number 50.
Control Systems Engineer
Sent from my iPhone
> I would imagine that if you want community support that some common standards might want to be addressed, <
I agree with Ken
I propose that we open a wiki page on control.com (http://controlwiki.com). It would contain all ideas/issues we agree upon.
I propose M. Griffin as a secretary.
Dave Ferguson said: "Is everyone aware that to put any of this hardware into use in for instance the US, that it must be "listed". "
I have always thought that only certain cities and locales required UL listing. Maybe that has changed...
Sounds good to me. I honestly don't know much about wiki's, but I get the concept. Is the secretary the person that decides if a wiki page should be amended by a persons modification?
In reply to Gilles Allard and Ken E: With a wiki, you don't have a "secretary". That goes against the whole concept of it. You would have an "administrator" for the wiki, but that would just be whoever controls the server. If it was hosted on ControlWiki, then the administrator would be whoever it is that controls that server. The administrator would hand out passwords, but have no further involvement.
One of the direct participants would tell the administrator who to add or who to remove, and the administrator would just ignore everyone else. Since Ken E seems to be the direct participant with the most interest in this, I think he should be the one in charge of that. As for me, I'm just a bystander who is offering a bit of advice that can be taken or ignored as you wish.
Those people who have passwords would then just edit the contents of the wiki however they wanted to. The idea of a wiki is that you have a group of people who trust each other not to vandalize the contents. Then you just go in and write something and say to the rest of the people "what do you think about this"? Someone else could write an alternate version and that could be debated.
I used this process with several other people to develop a communications protocol. If all you do is send disjointed e-mails back and forth, then things can get very confusing. Instead, you just use the wiki to write what you mean, and let the others edit it or write alternative passages. You can then use e-mails to ask things like "do you agree with section 4 now?". It's rather like having a meeting where you are drawing on a blackboard. Things change continuously, but everyone is working from the same version. It sounds chaotic, but it works quite well in practise.
Another way of doing this is Google Docs. That isn't a wiki, but it does allow collaborative editing of documents. If you're really interested in that, just go and sign up (it's free) and start doing it.
The way the Free/Open Source Software world works is that while you do talk about things, it's the people who come up with the actual code (or drawings) that get the final say on things. It's a lot easier to debate the merits of a design once there is something actually down on paper to talk about. A lot of problems only show up once you start to design the details. So, Curt draws something and says "this is what I think", and Ken draws something else and says "this shows why my idea is better". And since I didn't come up with anything, you can pretty much ignore what I said if you don't agree with it. If the peanut gallery doesn't like the way things are being run, then they're welcome to take what is there and go out and come up with their own design. There's no vendor lock-in, so time will tell in the end who was right.
You can think of it as the ultimate free market in ideas versus the sort of top down political control that prevails in monopolised markets. You compete and cooperate simultaneously, but the best ideas are supposed to win on their own merits rather than through market manipulation and legal trickery.
So, what I think you are looking for is:
1) Collaborative document editing - either a wiki or Google Docs. You probably only need this during the period of the most intensive development though.
2) Some place to host files such as drawings, etc. while you are working on them. You want to make sure that you are using the most recent version as opposed to hoping that what you found in your mailbox is up to date.
3) You're going to need someplace that people can eventually download the drawings and documentation *from* when you are done.
4) You are going to need a web site to promote the project. That would be a page that explains what the project is and what it offers people. If someone takes one of your designs and does a Google search for it, they should be able to come up with that web site.
5) You will need some means where people whom you have never heard of can contact you if they have questions or problems.
6) All of the above should be free, as I don't think there is a budget for this.
The above is how a software project is operated. However, I don't see why a hardware design project couldn't operate the same way. In the end, it's all just digital files. There are lots of free code hosting services, but Sourceforge is the only one that I know of that also provides a web site.
To clear up what I intend to do since it _is_ a little muddy, the board will take the address of the slot if the board does addressing. In other words the address pins in the first slot will all be tied low, second slot LLH, third slot LHL, etc. This addressing can be turned off in the expander chip with IOCON.HAEN. The chip selects will be redundant if all the boards handle addressing. The expander specified uses the address to compare to the address sent in the control word. It would not be easy to implement this for a chip that does not, as we would have to look at the data then conditionally pass the chip select. It could be done, but since it seems to be particular to _only_ that particular chip, it's probably better to ignore it. It's just a little too clever this time. But it costs nothing to provide the address pins at this stage. With only those chips in the machine (possible, since I use them for both inputs and outputs) you could tie the chip selects together and drive them all with one GPIO. Or use the scheme for the digital IO and separate GPIO selects for boards that don't grok. Another way to save GPIO pins would be to use three to drive a one of eight decoder and use the outputs for the eight slots. It wouldn't be hard to add that in a later rev. But the driver code would have to reflect these other schemes, and I don't know how many people want to mess with that. So I think I'll assume 8 hard selects and that way you're covered, kinda. I'm eager to get to the software end of this as it should be even more interesting. Of course, I could get a job at any time and that would slow things down a lot.
How about this one?
OK, I have a complete, except for capacitors, backplane. And I'm thinking of starting over. Why, you might ask? I took a perfunctory look at standard enclosures and boxes to make an enclosure. The results were not promising. I need an enclosure about 14x4x3. I am hoping to find something OTS. The closest I've found is a Hammond 1441-20 which is 17x4x3. That would be pretty long for a 8 slot chassis. So, I mused on shrinking the backplane to 1" card spacing rather than 1.25". Then I could use a 12x4x3. But, I turned up nothing close for that either. Ideas? The local place that does forming is not real interested. And they hinted that I couldn't afford it, which isn't that surprising. Next to consider would be to have the local HVAC shop make something. But something available to all would be much better. I even thought of using steel channel used for steel framing, but, again that's not OTS. Has anybody seen anything that might work?
I can host files for the time being, it is not a problem at all, but a Wiki site or maybe SourceForge would be a better long range plan. The controlWiki has been mentioned, is that appropriate? Can SF be used for hardware designs?
Ken, I also thought of optocouplers. There are many applications that have no need for them, but some OVP might be a nice idea. Curt has series resistors, some zeners or Transzorbs might be a good idea for extra reliability. Maybe we will eventually need boards with and without optocouplers. Optical coupling doesn't affect the rest of the design at this time, it just adds cost. For larger installations with multiple power sources, optocouplers may become mandatory.
If we can raise the cost of a CPU and proto fab, it'll become reality real soon. I should have the backplane artwork done this weekend. A couple days checking hole sizes and design rules for the three boards and it'll be ready for fab. I will check with the proto shops for Gerber and drill chart requirements as part of the checking. But I can't handle the costs till tax time unless fate smiles on me.
Curt said: "I will probably bring out 8 chip selects from GPIO. I did want to use the clever addressing on the expander but not all SPI chips support addressing. So, we need a chip select for each slot as you need to be able to plug any card in any slot."
I have been pondering some of these design decisions myself. If we have 8 chip selects, the cards are simpler, but we have each slot addressed. We also neen a little more I/O from the control board and larger bus connectors. We also need to be careful to plug the cards into the correct slot. If we multiplex the chip selects, then we add decoding logic on each board (address jumpers, TTL logic or 8 pin PIC?). We can use then smaller connectors and the backplane is truly parallel. We could then plug any card into any slot, but the cards must be setup correctly. There is also a chance of collisions due to improper setup. I don't know which is better, I was leaning towards multiplexed address lines but maybe the slot addressing scheme is easier to implement.
I am fine with 8 slots, it keeps the cost low and in the future, I'm sure we will be able to address multiple racks.
This is experimental gear, I don't think anybody would actually use it in a UL shop. It should fit in as power limited anyway. If you use a UL approved power supply.
This has been an interesting and thought provoking discussion. It would be fantastic if this could develop to the point where a commercial sponsor was involved, who would be able to offer assembled backplanes and I/O cards.
>Got some preliminary costs, the connectors will be about $7, <
While not a rigid as commercial products with a chassis, perhaps something like a 30-pin SIMM socket would work here. This approach would offer both a low-cost socket for electrical connections, plus a right-angle placement of the I/O board to the backplane. Pins are on 0.1" centers, which is easy for through-hole soldering. A casual search shows that they're available for about $2, though they're old technology and availability may be a concern.
> This has been an interesting and thought provoking discussion. It would be fantastic if this could develop to the point where a commercial sponsor was involved, who would be able to offer assembled backplanes and I/O cards. <
How commercial do you want? I am going to actually produce the hardware. There are local shops that will assemble them if there is any volume. I can probably assemble a few, if needed. They won't be very hard to assemble as low component count is a goal and they will be hand solderable. Once you have the artwork you can make one or one hundred. I'm going to probably make two or three of each to start. Getting a large company involved might be more of a problem than a solution as Open tends to go out the window. I may make a run or two if there are people who don't want to get them fabbed locally.
> While not a rigid as commercial products with a chassis, perhaps something like a 30-pin SIMM socket would work here. <
----- snip -----
They are awfully fragile; I am planning on pin headers as they are robust, cheap, and well proven in automation. I am thinking of a more or less regular rack with card guides and covers. The lion's share of that cost is the wire clamp connectors for the world end of the board.
Paul said: "It would be fantastic if this could develop to the point where a commercial sponsor was involved, who would be able to offer assembled backplanes and I/O cards."
I have a small business which is primarily a hobby business at this time. I may consider building and selling these boards in small qtys for the cost of my time and material. Others are free to do the same. I would offer just the PC boards also, to amortize the cost. This could easily become reality.
What would you like to see, Ken? Hit me with an outline and I'll fill it in.
I have given a fairly complete description along with connector information, slot spacing, address provisions, devices used, power distribution, just about everything I know at this stage. Some is subject to change. I'm using .020 traces on .062 nominal FR10 over a ground plane for the active pins, which should provide a fairly low impedance with equal length lines to prevent timing skew. I will be bussing 6 lines. They are SI, SO, SCK, !reset, VSS and VDD. VSS will be tied to the ground plane and both VSS and VDD will be very wide traces. Provisions will be made for a bypass cap near each connector. Connections at the processor end of the bus will be PTH to accept 22 Ga. stranded wire. The address pins will be hardwired to the slot address on the backplane even though I'm not relying on the cards using the addressing scheme. Chip selects will be eight individual lines from each slot to the CPU end of the bus. The cards will be attached to the backplane with right angle .1" 2X8 Pin header connectors although I'm still considering whether the card should be male or female. Convention wisdom is that the powered half should be female, but male pins would be better protected on backplane than on the board. All of this is very much conventional. I suppose I could formalize it, but email isn't conducive to formal documentation. And there really isn't any other way to do what I'm doing, so it probably is what you would expect. The backplane is very simple, pretty much a hard ribbon cable except for the address jumpers. The CPU is TBD.
INT A and INT B will be brought to the backplane connector but not used at this time. They may be useful or not depending on software.
I'm not being trying to be difficult.
Curt said: "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"
I don't see how we are straying from this idea. USB has been suggested instead of SPI. I say lets start with SPI, it is simpler. (although USB enabled microcontrollers are everywhere these days) I have suggested a local microcontroller based processor board, but that is a completely optional component. I am actually leaning more towards the Linux SBC concept, as we speak. Have you seen the boards from Technologic Systems, they have some under 100 USD and they look pretty robust. I'm not sure how to do a backplane and chassis, but ideas will come.
Something I forgot to emphasize, (I was tired). The "big problem" with shop made gear is how to mount and enclose it so you don't just have a pile of boards. That is not derogatory as I have many "piles of boards":^). Here you will have a box the contains inexpensive industrial IO and is usable and presentable to customers, etc. It will be (sounding more committed) using SPI I/O chips from the company that makes PICs. They would be absolutely proud, if instead of a full blown Linux computer, you were to mount a PIC board in the box, and SPI is the native tongue. And so, this would then make a remote rack or whatever you care to do with the PIC. Other personal favorites would also fit, needing only SPI capability, and almost anything can do SPI. Of course, there might be those who would seek to cram in x86 hardware and run Windows, but that can't be helped, people do drive screws with a hammer. This would thus take care of the part of automation hacking that isn't fun. Other backplanes could be done as well, but that would mean all new card designs too. When I think about it, there are a lot of people who could use this as the world end of their special projects. Doing it in an Open fashion will probably mean continued poverty, but it should stand the best chance of making it popular. It's beginning to sound like something that needs to be done :^). When I get a chance I'll see how a sourcing output card would look and post that. Virtual mylar, Rubylith and tape are very inexpensive.
I apologize for the commercial nature of this post, but thought I'd mention that the company I work for makes a low cost micro-PLC that is based upon the open-source Free-RTOS, comes in an enclosure, and already has the regulatory certifications needed for a lot of industrial installations. We can provide all the hardware libraries needed as modifiable C source code and let you write your own control application in C, giving you a lot more control than just standard Ladder.
There is a 4-line or 2-line LCD, with a knob and 4 buttons to create a user interface. Modifiable libraries are supplied for a generic menuing system or you can roll your own.
I/O is somewhat limited at only 4 DI and 2 DO on-board, but there are 2 RS-232 and 2 RS-485 ports and both Modbus master and slave communication libraries making I/O expansion extremely simple, and for those who don't want to do it themselves we are working on an I/O expansion board that accepts any of the standard Grayhill plug-in modules.
The more the merrier! Ours is aimed at a different segment of the market. And it ties into my software plans quite a bit better, but it's good to know of other Open efforts.
Here's what I think I'm gonna do for the CPU power. The little switcher module Bill found will should work. I have a little heartburn about a single source and it is kinda spendy. It's fairly clear what they did, they simply bundled one of the many packaged switchmode chips with the inductor and caps, etc and heatshrinked the whole blob. Its pretty much what I had in mind if I built in a switcher. Only I'd do it on the board. A 7805 or better, heatsinked to the case would also work, but it would make more heat than the rest of the PLC. And, for all we know, the ultimate user may well want 12V or 3.3V or ?
What I can do is site two TO220 outlines on the backplane. One will be oriented so that a regulator could be screwed to the case, and one will be oriented perpendicular to the backplane long axis. I will provide for brute force cap filtering. This way you can use a linear, the module, or if worse comes to worst, I can draw up a small regulator board that will plug in the TO220 space. Holes can be drilled to mount a magnetic or Faraday shield between the regulator and the CPU. After all, this is Open Hardware, and choice is consistent with the goals.
Ok, tonight I did the 1" card spacing backplane. It's 8.5" X 1.5" with the extra .5" on the CPU end. Because the space is more limited, this is arranged for the 90 degree connector on the component side of the cards. It has the two TO220 spaces to use either a linear (7805 or better) or the switcher which shouldn't require a heatsink. I did move the connectors up to gain more space for the CS lines. I'll do a .png and adjust the box drawing and send them to Bill in the AM. I have a little more checking to do with hole sizes and the like. I am leaning towards the male connector being on the card as male pins should be the non powered half and it would be easier to repair on the card.
Yes, male pins on the card sounds right. 1" spacing sounds reasonable. If the regulator doesn't dissipate much, we should screw it to the board and maybe a plated area to soak up the heat (shouldn't be much). One thing I would suggest, we should start with a smaller rack, like 4 slots max to keep the cost down while we are developing our ideas.
It didn't look like the module had a screw hole anymore! For industrial use, I would like to see some way of supporting it so vibration doesn't fatigue the leads off. The cost comes in in some strange places. I was looking at the simple and ubiquitous .100" headers and receptacles. Just looking at Digikey's selection the cost varies from about $3 a card to over $10 at qty 100. Since there are often several on a $10 card, they aren't paying anything like that. But unless you have to throw away a few revs, it really wouldn't save much if you know you need to do a full compliment once you are satisfied. We can simply not populate the entire card until it works. I am pretty confident in the cards as drawn as they are really simple cards. Getting a full set to test with will be a stretch, but, if an input card and an output card work, chances are good that they'll work in any combination. I don't expect to make more than 1 fixup rev at the most. One of the few good things about my situation is that I can take all the time I want to check. There's no one pushing.
Curt said: "One of the few good things about my situation is that I can take all the time I want to check. There's no one pushing."
And that is one of the main reasons that free, open source, and public domain products frequently are designed so well, there is no unrealistic deadline set by some manager or marketing department...
If we are looking at spending $3 a connector we should consider the 2 row DIN connectors as they were about $3-$4 for a 20 pin version from Hirose, also at Digikey. They are probably overkill, but they do offer more chamfer lead-in distance than a standard header, which will allow for looser mechanical tolerances. I'm not sure what target application uses a 20 pin DIN connector, so I can't say how standard it is, but it would be interesting to find out.
Would it be possible to put holes on the board and either use the screw down headers or "non screw down" headers as the application requires? We have to be careful with headers as there are several types with different dimensions. We will have to pick some standard connector since the mechanical spec would vary if we have different height connectors, etc. There is probably some de facto standard.
As Michael suggested, I'm looking at licensing. Considering the TAPR Open Hardware License, which see.
In reply to Curt Wuollet: I've looked at the TAPR license, and I'm not sure I would recommend it as it stands. I see a few problems with it.
1) There are two versions - the OHL (Open Hardware License) and the NCL (Non-Commercial License). You definitely don't want to use the NCL version, as it it says you can only distribute hardware on a non-profit basis. That is a big can of worms you don't want to open for an industrial control system.
2) The OHL version states you must "Attempt to send the modified documentation by email to any of the developers who have provided their email address. This is a good faith obligation -- if the email fails, you need do nothing more and may go on with your distribution."
That is a very wishy-washy statement, and really has no point. What's more, it ends up being like a chain letter with e-mails going all over the place. The GPL by contrast doesn't bother with a requirement like this (deliberately).
3) The OHL version states that "You may include files in proprietary formats, but you must also include open format versions (such as Gerber, ASCII, Postscript, or PDF) if your tools can create them."
The phrase "open format" is left undefined. That pretty much defeats the whole point, as pretty much every vendor these days calls their proprietary product "open". The phrase "if your tools can create them" then waters down that requirement to the point of meaninglessness.
4) It is not clear to me where the boundaries on the license are. That is, when you include a licensed board in a product, where is the limit on the "assembled or partially assembled units" which are "based in whole or in part on the Documentation". It's not clear to me whether someone can draw a black box in the middle of an existing board design and then say that it's "documented". On the other hand, you obviously don't want the license to try to apply to the circuits inside the chips you use (if you did that, you wouldn't be able to use chips).
5) The copyright notice on the circuit boards sounds like the old style BSD "advertising clause". This sounds like it could be a problem if a design goes through multiple revisions by different parties over time.
A lot of interest in open hardware has developed in the past year or so. Someone like the SFLC or the FSF might be willing to put together a better license based on something like the GPL. TAPR have based their own license on the GPL, but they've added some points of their own that I think are problematical and I'm not sure they've properly addressed the differences between how software copyright and hardware designs.
I don't know if you agree with me on the above points, but I think they need to be considered. On the other hand, I definitely wouldn't recommend trying to write your own license. If you decide that you can't be bothered with the whole issue, then you would probably be better off with the TAPR OHL than with nothing.
I have been thinking of contacting the FSF and/or SFLC with a question of my own. I can ask them about this issue as well if you like. This is the sort of thing they do (for free), so I can't think of a better party to ask. However, you will need to be prepared to answer questions about things like data formats.
I agree that it's got problems, the whole business of trying to accomplish for hardware what the GPL does for software has many problems. You don't have to even think very hard to find them. Even the phrase, "So it stays free and Open", is a legal nightmare to define. So yes, if you could get the EFF, etal. current thought on the matter it would be great. I did like their clause that the customer gets the stuff to make his own. That would mitigate most of the extortion that happens now. No one license will please everyone and the whole idea seem to displease some, but we go on. Any license will disclaim any liability for stuff beyond our control.
I didn't get to work on anything this weekend as we had a terrible storm in New England that caused major power outages for several days. So I was running around for Groceries and Gas for the generator, etc. Things have stabilized now.
The data formats are tricky. Some hardware projects may require high end PCB tools that are definitely not GPL. The GPL tools are starting to get there, but they still can't compete with the likes of Mentor Graphics and Altium (formerly Protel). CPLDs and FPGAs tools have their own issues as well, although Verilog and VHDL is easier to distribute.
At this point, with this project, I think we want to *at least* mandate the inclusion of GERBER outputs and PDFs of schematics in a license. This way anyone can use their own tool to do their designs, but allow others to recreate the boards at the Fab of their choosing. Unfortunately this will not inspire people to alter/enhance schematics and netlist the design changes to the PCB program because GERBERs are not *that* editable, and sufficiently complex designs mandate Schematic/Netlist/PCB/(maybe)AutoRouter. I think the lack of a standard schematic format and netlist will hinder the community effort.
Bill Suggested a couple schematic/PCB packages for windows, and Curt suggested using "PCB" for linux. Is there a defacto standard out there in the GPL world? If it is "PCB", what is the program used to do schematics? Are these tools able to migrate to more complicated designs as [hopefully] someday we will have CPU cards designed specifically for plugging into the backplane? I know this is a long ways off, I'm just looking toward the future. Maybe its worth contacting some of the guys doing "open" CPU cards for linux as they have probably already solved some of these issues. I'll work in whatever program as long as it is decent.
As Curt already mentioned, Mechanical designs can be exported to DXF, which is an editable format and most packages support it for import/export. I don't think the simple nature of this project warrants the complexity of a 3D CAD package.
There is a standard for the Open Source world and that is The GEDA Project. It includes an attribute editor and a schematic editor and a gerber viewer and PCB. Your humble correspondent unfortunately learned PCB layout before integrated tools and I did not generate netlists, etc. for this project. For 1 or 3 chip boards, I didn't think it very handy, but it would be valuable if you have a whole board of logic. Developing a competitive CPU board would be such a case, but for now, I think the market offerings with their board support packages are more cost effective, even with volunteer labor. I have done a microcomputer before, but today you almost need automated equipment to build a board that compares in space efficiency and the like. But, the tools are there if it should become a burning desire for someone. On a related note, the 4x4 space I am allowing for a CPU board may be a hindrance, limiting the selection of boards, but I hate to make things much bigger. I did try some samples of terminals, and while I need the current capability of the .200" wide terminals on the BP, we could use .150" spaced terminals on the cards and gain 5 extra spaces. I can't conveniently do 3.5 mm without metricating the whole board. Perhaps the 3.8mm, .150" spacing would be a good compromise? I still have to see if the variety of terminals in the .150" spacing would meet foreseeable needs.
I have upgraded the 1" spacing backplane +24V bus to carry 15A conservatively which should be enough. And I added terminals for the power connections. I'll send Bill the .png. The 1" BP is getting close to doing a DFM check and release. I have redrawn the input card for the .150" connectors. And I've found headers and receptacles for reasonable cost at Jameco. They are .25 and .65 respectively at qty 100. The screw clamp terminals are still spendy, but I'm looking around.
Curt says: "The screw clamp terminals are still spendy, but I'm looking around."
I presume you've tried Mouser, they have decent prices and a wide selection.
Even with 16 chip selects (slot selects) the CPU connector is under 26 pins which is still really cheap to acquire. Keep in mind that the Slot connectors can be the smaller 10 pin or whatever we choose in the end. I really would encourage a completely passive backplane for simplicity.
I don't mind using GEDA if it is becoming a defacto standard for the open world. For needing a schematic I wasn't necessarily considering a CPU design just yet [ maybe an AVR version of CPU], but more likely a board that has optical isolation. Having the rubber bands on an opto isolated card is nice because the interconnects get a lot more involved.
I don't have a problem with 3.81mm field wiring connectors. If they are more common it would actually be better. Lets just make sure they have front entry pluggable versions. I personally like being able to wire to the connectors without removing the pluggable portion to be able to access the cage clamp or screw terminal.
I have a virtual PC running Ubuntu so I am sure I can install the GEDA fairly painlessly and give it a try at home.
It sounds as if the answer to data formats should be:
1) Always include a PDF version.
2) Mechanical designs must be in DXF format.
3) For the PCB files, there is another way of looking at this question. You guys should be setting a policy for the project itself as to what formats these designs will be in. That is, you don't want to have Curt Wuollet's files in one format, Ken E's files in another incompatible format, etc. If I download the files, they should be in some consistent format, you should be able to read and work with each other's files, and I shouldn't need to use several different programs which all do the same thing.
For the particular boards you are designing, you could then have the license state that any derivatives of these designs must retain the existing formats (or newer versions of those same formats). That pretty much solves the whole issue (except of course the arguing amongst yourselves as to what those formats should be).
Now if someone else designs a board that is not a derivative of one of your designs, he could use whatever format he desires. To use the same license however, he must include all the files used in the design and manufacture of it. In addition, he must include PDF versions.
I am assuming in this that anyone can interface a board of their own (or someone else's) design to the backplane without using the same license. That's how for example you would use off the shelf CPU boards, or interface off the shelf third party assemblies. This is analogous to how if you modify a GPL licensed program the changes must be GPL also (or compatible with GPL), but simply communicating with a GPL program over a network does not cause the same terms to apply.
So, I think the file format question is best solved by setting a policy for the project, and then having the license require the same policy for derivatives. That will also help when you get other people interested in this. If anyone else wants to contribute designs then you will want them to be in the same consistent format that you are already using. Once you get enough people using a format, it becomes the "defacto" standard for this particular field (open PLC hardware).
I have an idea for the backplane. Could we have an 8 output SPI digital I/O chip on the backplane for the 8 chip selects? With that, the number of wires from the host computer can be reduced by 7. We would need only 4 wires plus power. We would simply send an address followed by data, all in SPI. We would have one chip select from the host CPU for address select. I guess we would also need a logic chip to gate the address bits from the data bus. Does this make sense or is it better to keep the backplane purely passive?
Well it would probably work, but it would cut your speed in half, doubling the number of serial read/writes. And you would need the "native" CS to go to that chip. A better way, if you want to include some hardware, would be a 1 of 8 decoder chip using 3 GPIO lines to drive it. A write to GPIO should be much less expensive in terms of time. Most simple would be to use the software select built into the expander chips, but we need the hardware select anyway for cards that don't use that particular chip. If 8 GPIO lines are not available on the CPU selected, then we might have to go with one of these routes. We can certainly add length to the backplane on the CPU end and have it run under the CPU. I suppose I should pick a CPU card and see how hard it will be to use 8 GPIO. 3 should be available on most any card. But, I hate to design to any one board as they are coming out at a rapid pace and who knows how long a particular board will be available. If the need for 8 selects will be a problem perhaps I could include copper for the decoder. Otherwise, the BP is very close to being ready for fab. PCB's design rules checking has a field day with the bus routing, but the issues are minor. Perhaps another version with the decoder for those who have a shortage of IO would be better?
Curt said: "Perhaps another version with the decoder for those who have a shortage of IO would be better?"
Ken said: "I really would encourage a completely passive backplane for simplicity"
OK, then that is what it will be, at least at this point in time. Simplicity wins, I was just thinking of ways to minimize the number of interconnects.
The 1" backplane just passed the Advance DFM check and is ready for fab after my final check.
I'll work on the cards in the morning after chores. I'll send Bill the .png to post.
The gEDA suite is the only contender here, I'd much rather spend money on the prototype than on tools or especially Windows. It is also the only choice where you don't have to pay to play. Combined with QCad, a poor student or itinerant automation guy can contribute. It's quite doable to put the whole works on a USB thumb drive and use it with any PC.
Curt said: "The gEDA suite is the only contender here, I'd much rather spend money on the prototype than on tools or especially Windows"
I would personally rather use TinyCAD and FreePCB. They cost nothing (if you run MS Windows) and are very good. They are both GPL'd also. I do agree that a nice open file format would solve these kind of issues, I am not aware of any however. TinyCAD uses XML as it's file format, FWIW. It also can export PNG files. FreePCB uses a Pads-PCB format for it's netlist input/output. It's output files are in Gerber format, of course.
I suggest that we all use what we want, as long as we output RS274X Gerber files for board artwork and any open image format for schematics, such as PDF or PNG. Sure, there will be some duplicated effort, but so is learning new software and installing multiple operating systems.
I suppose you can design boards with whatever you want. But, besides the issue with duplication of effort, there are a few problems that are analogous to Open Software. Gerbers are not "source code". Yes, you can make boards from them, but that's about it. So they are analogous to binaries. The "source code" in this case is the file format the layout software uses. The end user should be able to use this without restrictions, now and down the line. That means the layout tools need to be Open and not just free. And although this may seem to be splitting hairs at the moment, I have dozens of board designs that were made mostly with free tools that are now useless, because the tools have gone away. Some were DOS based, on old versions that are no longer available. Some were tools from board vendors that are no longer with us. Some even date back to my last regular use of Windows, (3.11) because there was no choice. Some could probably be resurrected, but not easily. And not without my involvement. So as soon as PCB would make artwork that was acceptable to the proto houses, I switched to that. All of those designs are still loadable and editable and I can legally send you the artwork, PCB and the OS it runs on. Because I _own_ them, and you can too. In fact, I'm obligated to make them available. This is one of the least recognized problems with shrink wrapped commercial software, but a problem that causes a great deal of trouble in automation and any of the arts that produce durable goods. Can you use any of the Windows tools that you were using 10 years ago?, 15?, and can you legally provide them to others? Maybe, but probably not. So, yes, at the moment, I am glad for free tools. But, for the future, I need Open tools. The GPL can't be retracted. And PCB will not go away. Please don't read this as nagging at you, there is a point to be made as to what Open really means. And it's one of the special problems with Open Hardware that we heed to consider.
Well, I worked over the input board to use .150" connectors which will allow for 23 connections, enough to do the usual sort of "isolated strap to either sink or source" board. But in the meantime I submitted the input card to a DFM check at Advanced, and it threw all sorts of defects. I was shocked, and then I looked at what it found. It doesn't like the lettering on the board that shows the pinout.:^) Is this desirable enough to try to find a workaround? I like having it on the board, but may have problems if their check barfs. Also, I am trying to find available alternatives to the Beagleboard. In my search, it seems to have the best bang for the buck even if $150 is more than I want to spend, and it has all sorts of bells and whistles that seem pretty unnecessary for this application. But it's the right size, has good support and an active community. And it will probably be around for a long time. Glomation apparently doesn't want to sell me anything. I've emailed them twice for information with no response. Using a CPU board you can get at DigiKey would have it's advantages. I would prefer on board ethernet, but still...... I could use some eyeballs.
Technologic or EMAC come to mind for embedded Linux boards at a reasonable price point. Or just use a mini-ITX...
Nearing the end of what I can do for free, so I took some time out from hardware to look at software. Taking the Beagleboard as the default unless or until something more suitable comes along, I joined the community mailing list and _after_ reading the manuals, I mentioned what I want to do as the muxing and default pin setups were a bit confusing. There are people using the SPI ports and GPIO for similar tasks. The standard kernel SPI driver will work and there is a driver to access the port from userland (spidev) and the GPIO pins can be accessed through sysfs. It looks reasonably easy to do once you get in the zone. I think this will be the first pass approach as this should achieve <1mS scans with "normal" (Bonehead C tm.) programming. I need to look again to see if the expander chips actually need full duplex. I'm kinda eager to get a board and play, but it's not likely soon unless I hold a bake sale or something:^). Retaped both cards to use .150" pitch connectors and both pass the DFM check with the text on the silk layer. I'm gonna call Monday and find out if having it on the top copper is really a problem. I'll try to get some .pngs to Bill tonight or in the morning. The Beagleboard most commonly runs the Angstrom distribution of Linux which I have to investigate. If I get bored, I'll do an optoisolated input card.
Curt says: "Nearing the end of what I can do for free, so I took some time out from hardware to look at software."
Curt, get some prices together and I'll try to help out...
I thought I'd summarize what the system looks like so far for those that don't want to try to pick through the thread.
This is in essence, a do it yourself PLC, remote I/O, or all in one, automation kit. It will provide, with the SBC of your choice, a platform with PLC type I/O. Everything will be provided for you to procure, make and assemble locally, but I or someone will probably sell boards if that's easier.
The SBC is not a part of the project, This will allow any to be used that will fit in the space. The only requirement is that it be SPI capable. Depending on the intended application, it could be anything from a simple hardware state machine, a PIC, A BASIC Stamp, a Rabbit, on up to a full blown Linux Server class machine capable of running SCADA and web services, etc.,in addition to the logic process. Thus it can economically be a simple I/O rack for serial (CAN for example) or ethernet (ModbusTCP) or whatever else you might need, or a complete Industrial Computer system. I will be doing the development with a Linux SBC, because that's where my interest lies. I will publish the code for this, but for the others, you're on your own. I will do best effort on other SBCs if you supply what is necessary. I don't do Windows. My R&D budget is about $500, which I don't have right now. $200 for boards, $200 for a Beagleboard with the doodads needed to bring it up, and $100 for supplies and misc. That's probably low due to shipping, etc. Individual sets will be much cheaper with even qty. 10 because of part and board volume discounts. Budget for $2 a point for IO and whatever you want for the CPU. Analog TBD, but probably not much more. Just building a full set of cards will lower the cost per point quite a bit.
The backplane is extremely simple, basically a SPI bus and chip select lines and power for the cards. Since we aren't mandating a SBC, the SPI lines, chip selects and power will be wired to one end of the BP There are 8 slots in this version, each will accommodate one SPI slave device. Each slot has a hardware address feature for chips that support it and a hardware chip select for chips that don't. Any card will plug into any slot and acquire the address for that slot. The cards are attached with a standard 16 pin header receptacle. The slots are on 1" centers. +24V and GND are supplied to each slot through redundant pins 2 power, 2 GND, and fed by high current bussing. The current limit is around 15ADC average. CPU power will be provided by 2 locations for a three terminal regulator from the 24V bus. BP size is 1.5" X 8.5" with a full ground plane and provisions for bypass caps and termination resistors, if needed. All are OTS through hole devices. Power to be supplied by a single external OTS 24V power supply.
The card form factor is 3.5" high X 2.5" deep. All are connected to the backplane with a right angle .100" 2X8 16 way pin header.
Initial card types are:
16 24VDC sinking inputs (High = True) with a common ground. This card is extremely simple as well, with 16 voltage dividers, the MCP23S17 chip and a 78L05 local regulator to power the chip. There are 18 terminal pads on .150" (3.81mm) centers that will accept several types of modular terminals, both fixed and pluggable. They are +24VDC, GND, and the 16 inputs.
16 24VDC sourcing outputs (ON = 24V) with a common GND. This card is also extremely simple, with the same MCP23S17 chip, two Allegro UDN2981 driver chips, and a 78L05 regulator for the MCP chip. The Allegro drivers switch directly from the +24 bus and will source at least 120mADC continuously, all outputs on, and up to 350 mADC limited by the number of outputs on and thermal considerations. Again 18 .150" pitch terminals are provided for and they are +24V, GND, and the 16 outputs.
Together these give 128 points of digital IO. I have an isolated input card in the works and I can do a sinking output card and/or isolated output cards if there is interest. There are many SPI D/A and A/D chips available and these will form the basis for additional cards. The engineering is free, but offering to pay for the proto fab will get any of these done in short order. It's not much, much less than an analog card for what you are using now:^)
I did a BOM for the cards with real numbers, I sent it to Bill but I will post it if I can figure out a way where the formatting is not destroyed. I will do one for the backplane tonight, when I can deal with the tedium. I found another very attractive board called a HawkBoard. While it isn't as fast as the BeagleBoard, it has a number of improvements from my perspective, like ethernet on board and VGA video rather than DVI-D. It also costs quite a bit less, like $89. The big problem is that it's very new and doesn't have anything like the community or community development that the BeagleBoard has. So the cost of a dev environment would be much less, but there could be much more work to get all the drivers. etc. working. But, software aside it's a better mix for a PLC. I guess that I'll have to stick to the old engineering axiom, "First make it work, then make it elegant". Software should port over easily once the early adopters do the heavy lifting:^). But if I have $89 and can't scrounge up another $60..................
The Beagleboard and the Hawkboard seem to be aimed at slightly different applications. The Beagleboard is more like an embedded PC replacement, while the Hawkboard is more of a traditional embedded design. The Beagleboard will run Debian ARM, while the Hawkboard requires a custom Linux image. The trade-off seems to be that the Hawkboard is cheaper, but would require more development effort, while the Beagleboard is cheaper, but can use many of the standard Debian ARM packages.
The Hawkboard might make a good communications interface board for the rack. You could write a Modbus/TCP server for it that would let it be used as remote I/O for PC or PLC applications. That would give you a complete working system relatively quickly that can act as a showcase for the hardware design. Turning it into a full fledged PLC could then be a follow-on project (possibly using a different CPU board).
The Beagleboard and the Hawkboard seem to be aimed at slightly different applications. The Beagleboard is more like an embedded PC replacement, while the Hawkboard is more of a traditional embedded design. The Beagleboard will run Debian ARM, while the Hawkboard requires a custom Linux image. The trade-off seems to be that the Hawkboard is cheaper, but would require more development effort, while the Beagleboard is cheaper, but can use many of the standard Debian ARM packages. <
Using something like Angstrom really doesn't trouble me because I don't, for what I need to do, need much more than an embedded distro. All I need is a working SPI driver, ethernet, and working toolchain. What troubles me is the "youth" of the Hawkboard community. Can I get the help I need?. Can I avoid "heavy duty" hacking? The whole point is to have a platform. Once the distro, kernel and drivers are stable, I can port my original PLC demo and self host for the small applications. Then we have the stone for the stone soup. This might be easier on the Beagleboard. The Beagle would also be better for "all in one" type stuff where the HP would be more important.
The Hawkboard might make a good communications interface board for the rack. You could write a Modbus/TCP server for it that would let it be used as remote I/O for PC or PLC applications. That would give you a complete working system relatively quickly that can act as a showcase for the hardware design. Turning it into a full fledged PLC could then be a follow-on project (possibly using a different CPU board). <
What I think should be in a PLC will fit on either. But, just by virtue of having on board ethernet, the Hawk is better suited for Linux automation. I can't see having dongles and the like on the factory floor. But doing it by myself, it would be nice if the Hawk were farther along. Mebbe we have some kernel hackers within the sound of my voice who will reassure me:^) I just want for it to be doable while I can commit the time. Then maybe I can get back to PLC tools. For now, I have boards ready for fab and I'm not sure how and when to release them.
Here's another $90 contender, already set up as a network gateway. For the many folks that have wanted a web controlled PLC, this would do it with little effort. I need to look at this one a little more, but they've got a cool demo. And this board is available from DigiKey also. Would make a nice ModbusTCP slave at the least.
The AVR board looks like it would do the job for a Modbus/TCP interface, provided it works with the I/O rack (I'm assuming you've already looked into that). The web server would also be useful for configuring the rack and for troubleshooting and commissioning I/O. SSH/SCP and/or FTP could be used to upload new software ("firmware upgrades"). All of those "extra" features are actually quite important to make a system usable.
Here are the BOM with real numbers.
Sorry about the formatting, Windows is different than Linux and the rest of the world. I screwed up my config trying to match.
$63.12 to get 3 proto boards. Advanced Circuits Bare Bones service. It's not much cheaper to get 1, $54.38
1 Board blank Advanced Circ. $21.04
1 78L05 regulator Jameco 51182 $ .25
1 Right angle male header Jameco 203967 $ .39
9 RA header Jameco 2094661 @.25 $ 2.25
9 Top Screw terminal Jameco 2094602 @ 65 $ 5.85
1 MCP23S17-E/SP Microchip.com $ 1.05
1 capacitor 50V .33 uF Jameco 138237 $ .14
2 capacitor 50V .1 uF Jameco 25523 @.08 $ .16
16 4.99k R 1% MF res.1/4W Digikey 4.99KXBK-ND $ 1.70
16 19.6k ohm " Digikey 19.6KXBK-ND $ 1.70
Same card price as above
1 Board blank Advanced Circ. $21.04
1 Right angle male header Jameco 203967 $ .39
1 MCP23S17-E/SP Microchip.com $ 1.05
9 RA header Jameco 2094661 @.25 $ 2.25
9 Top Screw terminal Jameco 2094602 @.65 $ 5.85
1 capacitor mono 50V .33 uF Jameco 138237 $ .14
4 capacitor mono 50V .1 uF Jameco 25523 @.08 $ .32
2 UDN2981 driver Newark 31K7841 @1.95 $ 3.90
1 78L05 regulator Jameco 51182 $ .25
1 board blank Advanced $23.04
8 F header recept. Jameco 70721@.85 $ 6.80
4 capacitor mono 50V .1 uF Jameco 25523 @.08 $ .32
connectors and regulators for your app $ TBD
Note: the extra cost built into the R&D budget reflects the fact that some parts must be purchased in multiples especially the boards.
What i find really interesting is the low threshold to being in the embedded Linux game. Even though I don't have the $90 at the moment, that's cheaper than most of the "Low Cost" alternatives that I might otherwise use. I did download the AVR32studio software to take a look, since the price was right, but it's java on eclipse and wants Windows type resources to run and didn't like my Fedora 10 setup. They did say they wanted RHE or Fed 9 or .........
But, I wasn't that impressed by what I saw anyways. I think I'll grab the toolchain and c library to look over. VI and make are fine by me. They do mention that they pin out 1 SPI port but I haven't discovered any SPI driver work or threads to encourage a longer look. It does seem that there will be a "beagleboard class" of SBCs to choose from. From what I can tell, it might be cheaper to write to Linux than to compile to the machine language. Of course, I'm not interested in doing that for anything large anyway, but I was amazed that these powerful SBCs are $100 and many "deeply embedded" class boards cost many times more plus big bux for the emulators, etc. etc, to actually use them. But there is a growing trend to provide tools free to sell chips. I wonder where that came from:^) I even saw one piercing flash of brilliance, simply dazzling. Someone had a link to a live, boot CD with the whole hosting and cross compiling setup installed on Linux and ready to go. Unfortunately the link was broken, sigh....
With regards to compilers: gcc-avr is in the Ubuntu (and therefore I imagine Debian) repositories - I could install it with two mouse clicks right now. I would assume that it's in Fedora as well. I would be very surprised if what's in the repositories is any different from the packages on Atmel's web site (although they may have some library bug fixes).
According to Atmel's web site, it includes:
* Runs on Microsoft Windows and Linux platforms
* Cross compiler for AVR32 devices
* Assembler and linker for AVR32 devices
* Debugger for AVR32 devices
* Flash programming tools for AVR32 devices
* C-libraries for development of C/C++ programs
As for Fedora 10, that's kind of old, but they do have updated RPMs for it. They list packages for multiple versions of Fedora, Red Hat Enterprise, Suse, and Ubuntu (and MS Windows as well).
I wouldn't bother with Eclipse. If you are going to re-distribute source code then I imagine the recipients would much rather have a make file than some sort of Eclipse configuration that may or may not work with whatever version of Eclipse they have installed.
For this sort of project developing on and targeting anything other than Linux is not very practical. You really want to develop on your PC and debug it there and then port it to the target board once you have all the logic errors fixed so you only have to deal with the platform specific issues at that poin. I think that AVR recognizes this which is why they (and other embedded OEMs) are doing things this way.
> According to Atmel's web site, it includes:
> * Runs on Microsoft Windows and Linux platforms
> * Cross compiler for AVR32 devices
> * Assembler and linker for AVR32 devices
> * Debugger for AVR32 devices
> * Flash programming tools for AVR32 devices
> * C-libraries for development of C/C++ programs <
I see now that ARM has a similar IDE for the Beagle et al.
Too bad the simulator will be available "real soon now".
I like these trends, before you almost had pledge and be initiated to be allowed to join the elite. Somehow they've grasped that making it approachable will attract developers.
> As for Fedora 10, that's kind of old, but they do have updated RPMs for it. They list packages for multiple versions of Fedora, Red Hat Enterprise, Suse, and Ubuntu (and MS Windows as well). <
I will probably dedicate a box to whatever distro is convenient, but I really like the idea of a bootable CD with all the right stuff on it. I could go the VM route, but embedded devel is quite complicated enough without adding more layers to debug. A CD and "standard" setup would make it much easier to support. This is all quite dynamic though, and people might well want to _use_ all the nifty features. This makes a large, diverse community very important as I wouldn't be vary good at supporting HDTV or DSP noise cancellation algorithms. But I can see where having a fast, floating point DSP would be extremely useful for some apps. And _I_ would like the composite video stuff for a PLC with built in machine vision which has required a Linux PC before. It would be _way_ cool to be able to deliver a "packaged" MV system.
> I wouldn't bother with Eclipse. If you are going to re-distribute source code then I imagine the recipients would much rather have a make file than some sort of Eclipse configuration that may or may not work with whatever version of Eclipse they have installed. <
Well, as I said, I'm fine with VI for development. I was thinking of our command line challenged brethren. At some point, though, if all you can deal with is Windows, point and click, embedded development is probably not for you. The fact that it was drain bamaged for me on an extremely common distribution does not bode well for adopting it. There should only be a limited amount of low level work though. My thought is to write a daemon? that would do the scanning and expose the IO as virtual registers in a shm structure with semaphores or just flags to synchronize the solve phase, thus providing an api to write "normal" programs to. That way folks would not have to deal with sending the right sequence of words to manipulate the IO. If you want to set a bit you just set it in the map and mark it changed and either wait on the flag or simply go on your way. A read could look for a "consistent" flag and set a "solving" flag, write the results and set the changed, flag, etc. The problem is making it friendly to folks that don't have a "normal" way of writing programs for *nix. The good part of being broke is that all this "window shopping" is good research to decide on the best board and tools. For me, the best OS is not an issue. I'm leaning towards the Hawkboard and the OpenEmbedded way of doing things. But, I'm still looking.
> For this sort of project developing on and targeting anything other than Linux is not very practical. You really want to develop on your PC and debug it there and then port it to the target board once you have all the logic errors fixed so you only have to deal with the platform specific issues at that poin. I think that AVR recognizes this which is why they (and other embedded OEMs) are doing things this way. <
I quite agree, but there are some.......
In my continuing examination of the SBC field, it has come to my attention that there is a fly in the ointment. I was going to leave level shifting for the SPI bus and extra chip selects up to the selector of the SBC. This simplifies the backplane, and the level shifter should really be close to the driving pins. Perhaps on the plug where it connects to the SBC. I was thinking some may not need level shifting at all. Actually they would be best on board on the SBC.
Unfortunately, it seems no one does this. And there are 3.3V, 1.8V, 5V and all manner of drive capabilities. I see an application headache there.
So, I guess the thing to do is put them on the backplane. Obviously, this is an industry wide headache in mixed systems, so there are chips available for the purpose. The problem, is that since this is an ugly necessity, they put the function in as small a package as possible. The largest I've seen so far has .65mm (about .025") pin centers. This is maybe OK from the board fab side (I have to check) but would be a PITA to ever replace in the field.
The chips I'm considering are fairly universal and would connect anything to anything, at speed, but I'd like to find some that are reasonable to handle, solder and replace, if need be. They also want power for reference from the levels to and from. At least they don't take up much space. Reference the MAXIM MAX3378 and MAX3390 and you'll see what I mean. It may be that there aren't any good alternatives.
Yes, you can, but getting nanosecond switching times out of them is non trivial and uses more board space. And you would have to use FETs
because with 1.8V logic VCE(sat) of most BJTs isn't a guaranteed low. So, I took a look at what you would have to do to add level shifters to the backplane.
About the time I got it figured out, it was done. I'll send the .png. Power is an issue, not because they use any real power, but because the backplane has only 24V. So, I hooked the high side to the CPU regulator so that will have to be populated. The rather problematic low side voltage will come from the SBC, or worst case, I added yet another spot for a regulator. I haven't seen a 1.8V fixed regulator at the usual vendors, but I'm sure someone makes one.
While I may not have this entirely correct (I am a controls engineer, not a combustion engineer), my recollection is that naphtha is a difficult liquid fuel - it has low lubricity (compared to distillate or kerosene) and is corrosive. I believe that it was preferable to leave the better fuel in the system while running on gas or when the unit is shutdown. Then, when either changing from gas to liquid or starting up, you begin with the kerosene or distillate, get a stable flame established on the liquid system and then transfer to naphtha.
Report on progress, or lack of it:^) The original backplane layout with level shifters fails the DFM check. I had staggered holes on 50 mil centers that would make it possible to solder ribbon cable to the board. with the holes at .020" the runs between the holes don't make spacing. So, I decided to drop two 8 pin headers onto the board and jiggle things to hook up to them. This went well until I noticed that I was treating the SMDs as through hole, when there is no actual connection through the board. This is a headache You can't just drop vias on the pins because the min hole size on APC's barebones service is .015". The alternatives are: Reverse the layers with the wiring on top and the ground plane on the backside. This I don't like because you depend too much on the pth. Or you can drop vias for every pin. That's really ugly. Or you can move the chips to the solder side. I think this last is going to be the approach I take. Opinions?
Can't you just add some 10 pin thru hole headers? I don't like the idea of soldering ribbon cables directly to the board. I also would prefer to see thru hole for connectors because they are mechanically stronger. Then, of course your via problems go away :)
Once again, I have not explained as I should. I did solve the problem with spacing with 2 standard 8 pin (2x4) headers. There simply wasn't room for a single longer header. One header has the /reset and SPI signals along with 1.8V from the SBC and ground. These last two are redundant pins. The second has the 8 chip selects. Through hole headers do not solve the SMD problem though. On this board the ground plane is on the component side, no exposed voltage, and 99% of the wiring is on the solder side. These signals are all bussed and need to work opposite the ground plane. Dropping an SMD (TSSOP14 in this case) on the component side gives you pads only on the component side so they would have to go through the board to the actual bus lines on the solder side. Due to the fact that these are tiny devices and added late in the game there isn't enough room for vias that meet fab limits. So the most practical thing to do was move the chips to the solder side. I did this and the board passes the DFM check. Since all the other soldering will be done on the solder side (duh) this presents no problems other than breaking tradition that chips go on top. I'll send the .png. I need to check the hole sizes and that nothing got messed up in the process, but the board should be ready for fab. The new headers use ribbon cable numbering since they will likely be used with ribbon cables. I am not a fan of IDCs and ribbon cable for high reliability gear, but they are easily replaced. The scrambling will be on the SBC end.
7. Low side reference voltage from SBC (VL)
8. Low side reference voltage from SBC (VL)
No progress on the funding front.
Request for comments on releasing the design under a Creative Commons license.
Arduino is released under a CC license. Software would of course be GPL.
There are several different Creative Commons licenses. For all of them however, I don't think there would be any obligation for someone to distribute the documentation if they distributed the hardware. That makes it more like a BSD type license rather than a GPL type license. Whether that is what you want, is of course up to you.
If you are going to release the docs, then a CC type license is far from the worst. Just make sure that you include a warranty disclaimer (as with GPL).
Just a small progress report. I drew the schematic for the input card and sent Bill a copy. Still looking at boards, but I wanted to show how the community can be a huge factor in making things work. This kind of information would save many, many hours of frustration. Rooting it out from the docs, etc. would be a long and tedious task, and you might well not even succeed.
With that working, the project with a beagleboard would be feature complete. I'd like to see something like that for the other contenders. If I get a chance tonight, I'll start on the isolated input card.
I just finished laying out the isolated input card. It has 16 DC inputs that can be either source or sink. The inputs are in groups of 4 with a common so you can have 4, 8, 12, or 16, source and the rest sink or vice versa. 5000 V isolation. There is a full guard trace between ins and outs on the isolators to intercept leakage. Cost will be about $6 more for the isolators. I will add an option for back to back Zener diodes to set the logic threshold tomorrow. The isolators are the double LED type to accept either polarity.
I sent the .png to Bill to put up, but I haven't done rigorous checking yet.
Progress, Isolated Input Card.
Well. the back to back Zener idea I had at 2 AM didn't survive the first cup of coffee, so I had to come up with another way to get a reasonable logic threshold with the dual LED isolators. What I ended up doing was using a 10 to 1 voltage divider ahead of the LEDs. Most 24V inputs switch at 10-14 V. With the Vf of the LEDs in the range of 1.0-1.4V they should begin to conduct at 10-14V applied. The LED will clamp the divider voltage so the increase in current as the input goes from the threshold to 24V will go through the LED. The current transfer ratio on these isolators is spec'd rather broadly, from 20-300%. Fortunately the expander has a max input current of 1uA. So, setting the output current of the isolator at 100uA to swamp out all the variables, we want a LED current of at least .5 mA. A total resistance for the divider of say 10k Ohms will supply 2.5ma without the LED and clamped with the LED will supply 2.51mA. 1.4 will go through the resistor and 1.11 through the LED. So preliminary values are 9k and 1k for the divider and 50k for the emitter output of the isolator. I sent Bill a .png of the new layout and will follow with a schematic, probably tomorrow.
OK, here's the last in the digital series cards.
I finished a 16 output 24VDC sinking card and sent Bill the .png. Continued hard times in the woods, on the Rum. I'm entertaining any and all thoughts on how to get this built and tested. I don't want to make a general release until it works:^), but if anyone's interested in finding out soon... I'll provide the labor.
Saw a first today, guy sent a job offer to go pull Cat5 locally for $20/hr. But, only if you have a $5000 Fluke DTX tester. If I had the tester, I'd rent it out and he could go pull wire. I'm thinking of an analog card, but, there's no hurry with little prospect of getting it built anytime soon. Still, it helps to keep busy. I was looking at some of the other OMAP series from TI. There's one with quadrature inputs, etc. specifically aimed at industrial control. Doesn't look like it will run Linux though:^( I suppose I could write a PLC executive, but that would be regressive.
I've been scoping out ADCs for an analog card.
First, the good news, the interface is dead simple and the layout should be easy to do.
The bad news is that appropriately priced ADCs top out at about 200k samples per second and 12 bits. What's that you say? That's more than fast enough and 12 bits is more real resolution than you will get in a noisy industrial environment? True, on both counts. But it's a side effect that rains on the parade. Since these are SPI parts, everything runs off the SPI clock. And for 200ksps that is about 3.6 MHz max. This limits the whole bus speed to less than half of the max capability. These would give 4 channels quasi-differential (common low side) or 8 channels single ended. I need to take a look at the commercial offerings to see if this would be adequate as far as accuracy is concerned. To keep the SPI speed high, we wander into more complex ADC with FIFOs and asynchronous conversion. They get spendy fast. Instead of $2.50 they go to $30 to $50 a chip. Time to do more digging. The more esoteric chips are also not commonly stocked so I lean towards the commodity items. I would like a little more speed though. We don't need it for most PLC tasks, but I want to achieve fast scans.
What chips are you looking at? Do they have an option for a second clock input? If so, could we add an on-board oscillator? If not, do we really need or even want our SPI bus running at greater than 3.6 MHz? High frequencies can cause their own issues, as you are well aware.
I've looked at TI, Maxim, Microchip and National Semi. I'm concentrating on popular chips that most distributors carry. Best overall so far seems to be MCP3008. But, I need to look at Linear Technology, BB, Analog Devices, Motorola, etc. I'd like 400ksps, 12bits, 4 diff or 8 single ended option, DIP, internal reference would be nice. And of course SPI. At less than $10, if possible. Then it comes down to designing a front end with buffering, wide common mode voltage range, 250 Ohm resistor for 4-20 ma. input, etc. And industrial protection. Fortunately, good op amps are cheap. 0-10V is pretty standard, I'd like a 100mV range for current sensing etc. An active front end is pretty much a necessity to adequately charge a fast SAR convertor. And the need for speed isn't _just_ because I can:^) It enables many good things like averaging samples and software debounce for the digital side, fast PID loops, vibration analysis, fast servos, "real time" machine vision, etc. a lot of the reasons you might use this instead of a "regular" PLC. There are many jobs that want a _computer_ with industrial IO and if you can serve that need as well as the PLC and remote IO facets by design without raising costs too much, it's a win. Then you can have a PLC with PLC software or a platform for advanced automation with only a software change. Most PLCs kinda suck at analog, accurate but too slow for anything but "meter work" because they are content with one sample per scan, (at best, some don't always make it.) But with a multitasking OS, you could do a lot with analog between logic scans or? If you can have faster analog along with all the other things that regular PLCs don't have, it's worth a little effort. Michael asked, why I am doing this? To make a mediocre PLC is not on that list. You get a good idea what folks could use watching this list :^). There are many folks that are reading this that could do wonders with a capable platform.
What is the worst and best case scan rates that you calculate for the current design? I have a hard time believing that 3.6 MHz is a problem considering that the old Siemens S5-100U series (including the 95U) had a serial shift register backplane that operated at 9.6 kHz (375 times slower) without having serious problems with digital and analogue I/O.
Here's some example estimates (assuming no overhead):
A) 8 analogue input cards with 8 channels per card. That is (8 cards) * (16 bytes per card) * (8 bits per byte) = 1024 bits. At 3.6 MHz that is 284 microseconds.
B) 8 digital cards with 16 bits per card. That totals 36 microseconds per rack.
C) 1 analogue input card, 1 analogue output card, and 6 digital I/O cards. That is 98 microseconds per rack. That would be a 10 kHz scan rate.
Let's put some perspective on this. To actually make use of data at this speed in a PC application you would need to provide buffered I/O with triggers. The only things that I can think of that operate at comparable speeds are low end data acquisition systems. A factor of 2 faster won't make much difference.
I don't know enough about the hardware to say what other overhead factors might come into effect, but raw backplane speed doesn't seem to be a problem. Perhaps you could provide some estimates that take into account whatever factors that I've overlooked.
> What is the worst and best case scan rates that you calculate for the current design? I have a hard time believing that 3.6 MHz is a problem considering that the old Siemens S5-100U series (including the 95U) had a serial shift register backplane that operated at 9.6 kHz (375 times slower) without having serious problems with digital and analogue I/O. <
Digital is no problem, perhaps 40 clock cycles even refreshing the control registers. That would be worst case. And it will run at up to 10 MHz. About 4 uSec a card. + switching TBD. Twice that if the linear stuff slows the clock to 5MHz. > Here's some example estimates (assuming no overhead):
> A) 8 analogue input cards with 8 channels per card. That is (8 cards) * (16 bytes per card) * (8 bits per byte) = 1024 bits. At 3.6 MHz that is 284 microseconds. <
Here's where it gets more sticky. 10 bits or 12 bits are read as two reads with most hardware. Some ADCs want a setup write to change channels. Minimum 24 bits X 4 or 8 channels. I lean towards 8 channels to provide best bang/buck. Lets say 200 clock cycles with start bits and channel switching. IFF I can run at 5 MHz that's 40uSec for the rack, worst case could be higher if I have to run the clock slower and I'm sure there's some setup with the GPIO and the SPI hardware. Then there's the elephant in the room, one sample on a signal doesn't mean much. For 10 _effective_ bits, I'd like to average at least 5. I know others may well use a single sample, but ..
> B) 8 digital cards with 16 bits per card. That totals 36 microseconds per rack. <
> ----- snip ----
> I don't know enough about the hardware to say what other overhead factors might come into effect, but raw backplane speed doesn't seem to be a problem. Perhaps you could provide some estimates that take into account whatever factors that I've overlooked. <
Now, a PLC cycle involves a read, solving, and a write. Logic solving with optimized C won't take long, but there are scheduling uncertainties etc. It will be faster than most PLCs but you can see how you want to aim high. A mostly digital rack should be great, but if you want to debounce in software you would probably want to look for 3 consecutive states. etc. Of course, every other PLC has many of the same issues, but they get to hide theirs under a big black shrinkwrap tarp. It's not a detailed analysis, but you can see why I want everything I can get before we account for Murphy and Nyquist. I can always slow it down if it's too fast:^) I'm taking state of the art as a 1mSec scan. That doesn't mean much if you have 15mSec filters, but it is a goal I'd like to beat comfortably. And if you aren't using the cyclic model, I'd like to be able to handle those low end DAQ and motion solutions. This PLC will have the compute resources to do so. I'd like to fill the backplane pipe at 10MHz or whatever the OMAP will do. If it doesn't raise the cost much, it's better to have it and not need it than to need it and not have it. I would like to have it unconditionally software limited. Then the hardware guy has done his job. It gets back to your question of: Why do it? Just to have a PLC that runs Linux is OK for me, but if I can build a better PLC that runs Linux, that's a better reason. So far, it hasn't been very hard to move into PAC territory and I can't see any downside. I would be very disappointed if it doesn't outdo a S5. I'd like to be sure that even with tradeoffs down the line, it'll be more than competitive.
24 bits per channel at 5MHz doesn't change the numbers much from my previous post on this which used 16 bits per channel at 3.6 MHz. With a rack full of I/O, that is 64 channels at a rate of 3.2 ksamples/sec per channel. Or, to put that into DAQ board terms, that's like buying a 200 ksps DAQ board (3.2k * 64 = 208k).
64 channels is a lot of channels. A realistic typical application might have 4 analogue inputs, 2 analogue outputs, 48 digital inputs, and 24 digital outputs. Let's estimate the following:
1) AI = 4 * 24 = 96 bits.
2) AO = 2 * 24 = 48 bits.
3) DI = 48.
4) DO = 24.
Total is 216 bits. At 5 MHz that is 43 usec (that is close to the number in your example). That can be sampled at 23 ksamples/sec.
For "PLC" type applications, your problem is going to be how to make use of this data. A you said, you could have the "firmware" (libraries) in the "PLC" board do averaging or other filtering. There is a limit to how useful that is however.
For PC applications connected over Ethernet, you would probably want to buffer the analogue channels and let the end user do his own filtering, since he may want to do something other than simple time domain averaging. This is going to need something more than a simple Modbus/TCP interface however. The user would need to be able to start and stop sampling, configure buffer sizes, etc.
My opinion is that this is fast enough. I suspect your bottleneck is going to be finding some effective way to make use of this I/O bandwidth on the CPU board.
Yes, on paper, it should be fast enough. I'm thinking there will be some slippage as there is in almost every engineering project with this many variables. As far as what to do with the data to use it, I am thinking of breaking the ties to the application. That is, putting all the reading, writing, debounce, averaging, etc. in a subsystem that writes to a map and runs at I/O cycle speed. That way applications don't have to deal with all that detail. They just read the map.
This seems to be one way to get less than + or - 1 scan uncertainty, provided the map is updated faster than the application scan. I do need to think it through more, but it should also make more programming models usable than just cyclic execution.
I also have to see just how much CPU that would consume. I hope I can justify the choice of serial rather than parallel, but it seems practical so far.
In related news, I did check with SourceForge and they said it would be OK to host the files there. And I also checked into a website if people want to obtain boards, etc.
Sorry for jumping in on this thread, but I'm interested in efforts leading to "Open source PLC Hardware". Can someone direct me to the best location on this forum (or another forum) to get up to speed on what is underway?
This is it currently, if you use the web version you can follow the thread. Where it is at, is that I have an 8 slot backplane, 16 input DC sinking card, DC output cards in sinking and sourcing and a 16 DC input card that is isolated and can be strapped either sinking or sourcing in groups of 4. The boards are ready to be fabricated. The backplane interfaces to the SBC of your choice with a SPI bus. 8 chip selects are needed, can be GPIO. Bill has some of the pics on his website. My intent is to have a Linux based PLC, but the hardware could be used with any setup that can communicate with SPI. Fab, build, and test are awaiting funds (I'm unemployed). Once working, I will release the PCB files, gerbers, schematics, BOM, etc. under an Open License. Boards may be available from me or others, but can be fabbed locally.
BeagleBoard.org has a contest for projects using the BB. If your project is approved, they provide a BeagleBoard to help get the project going. They award two every week on Friday. Maybe this is interesting enough to get some help.
Otherwise not much is going on. The boards are ready to go to fab and the packaging can wait for hardware. Getting a BeagleBoard would let me get started on the drivers and software. My tentative endpoint is to get the hardware and drivers working and port the small PLC program in C and ncurses that I published here long ago. That would be enough to show how to use the hardware.
The BeagleBoard contest sounds like a good idea. As well as getting you a free BeagleBoard, it will provide publicity for the project by bringing it to the awareness of people who encounter it via the BeagleBoard.
I just had a look at the BeagleBoard web site, and I see that you've registered the "BeaglePLC" project there on Monday. I'm not sure however that someone will understand your project from the description you have given unless they are already familiar with the project. In fact, I'm not sure I understand the scope of the BeaglePLC project. You might want to re-word that, I'm sure we could provide some suggestions if you are interested.
You also said earlier that you had investigated using Sourceforge to host the project. I would suggest that you register it, put up preliminary files for download, set up the project web site, etc. That will let you link the BeaglePLC listing to the project web site home page which in turn will help a lot with explaining the project and in making it look more serious (which should help with the BeagleBoard contest). I can help with the project web site if you need help with that.
Before you can register the project you will need a name. It should be something that will show up on Google pretty easily ("Open PLC Hardware" won't do well in that respect). Have you thought about this?
I have registered with SourceForge, but haven't done anything with it, as I don't have anything yet:^). I can see releasing alpha or beta code, but I don't think I want to release hardware without building and testing it. If you download something free and it doesn't compile or segfaults, that's one thing, but if you build boards and buy components and a BB, etc. and it doesn't work, I think you would have justification to be a bit more irate. It is extremely frustrating to me to be hung up on the filthy lucre to get it done, but it's hard to attract sponsors for something you plan on giving away. I even played a bit with SeaMonkey and started a web page with pictures and descriptions, but the cheap hosting outfits want 6 months or a year in advance to be cheap, and I can't mail that away right now. I could drop a PayPal donation box on it though ":^). Just keeping the effort alive is hard and I don't think tax time is going to help. The good part is that I have the time sinks done, so if I get a job, I can still proceed. And I was going to start accumulating the parts, little by little, but the shipping eats you alive that way. Everyone can feel free to send suggestions on the project description. I've been deep in the techie end and while the folks playing with BeagleBoards seem pretty deep there also, anything to help people understand what it's about would help. I guess my world view has become fairly narrow:^).
I found your project page on Sourceforge. As for the cost of a web site, Sourceforge gives you free web hosting (for static pages) with the project. Right now your project just has the default web page up.
If you replaced the default page with your own, then you could link your BeagleBoard.org description to that so that people who find it via the BeagleBoard site could get more information about it. As it is, the only way that anyone can find out about this project is to find this thread on Control.com and try to follow the discussion.
My own project web site on Sourceforge has over 1000 files totalling about 20 - 25 MB in size. Anything that anyone wants to know about it is right there.
As I said before, if you want help with the web site, let me know.
Part of the reason for a separate site would be to offer boards, which might upset SF, but it would probably do for now. I need to dig through how to do stuff on SF, I may take you up on that kind offer.
Trying amid many other non related issues to keep things moving, at least a little. Dug back in the archives and pulled out the Demo PLC code that I wrote years ago. I guess I shouldn't really refer to it as a demo, it was code written to do a specific job. It was the go between for three robots and a machine vision fixture. But anyway, I was curious if the changes to Linux would require changes to get it to run on the hardware. It was originally written in two parts, one was to run the hardware, which was a ComputerBoards DIO48 card with the level translators I built, and the second part which was to display the registers and allow modification, forcing, if you will, for testing and monitoring. I don't have a DIO card and that would be replaced with the SPI code anyway, but I did check out the display portion. It mmaps /dev/kmem in an area declared outside the Linux memory management. To use it, I give the Linux kernel a boot argument that limits the memory to 1M less than what is in the machine and this gives an area that is safe from conflict. Once I adjusted the addresses to the much larger memory on this machine and remembered what the compile options were, it came right up and ran overnight with no errors or leaks.
Since I still don't have any hardware, I will write an emulator to modify the shared memory to make sure it really works. The original reason for this mapping was that mapped this way, the memory is accessible to a RTLinux task and thus could work around delays, etc. I'm not sure this is important anymore, and it raises some security issues, but it works. The display app is tiny by today's standards and uses ncurses on the console or a terminal emulator. If Angstrom includes ncurses, it should fit just fine on an embedded host.
I have been a little disappointed on the BeagleBoard contest front, it seems there has been no action since I added the project. Not wanting to jinx it, I have been reluctant to ask what the deal is, after all, they are giving the hardware away. I could really use for something to happen to keep the momentum up.
Have a look at this: http://lwn.net/Kernel/LDD3/
Linux Device Drivers, Third Edition. It's a free download and the authors are well known kernel developers.
The following is a summary of SPI driver development:
It does mention that there is support for user space SPI drivers, but it doesn't go into details (it's just a summary).
Wouldn't the Beagleboard come with SPI drivers and wouldn't there be an "official" way of accessing it? For example, I've got a "/sys/bus/spi" directory (but no SPI devices however).
As for the contest, they say they give away 2 boards every week. However, not all the details for your project are filled out on the contest wiki. The "beagleboard.org project" and the "homepage" are still "TBD".
I would suggest filling out the details, and PUT UP A HOME PAGE SOMEWHERE. As far as most people are concerned these days, if it doesn't have a web page, it doesn't exist. You have to explain the project to people who don't know what a PLC is. They're not going to give you a free board if they can't figure out what you are trying to do. If you need help with the web page, let me know.
You've registered a Sourceforge project, so you have a free host for static pages. That would be the home page for *the project itself*. If you decide you need a more elaborate web site later (e.g. so people could order boards, etc.), then you can point the home page somewhere else later, link to it, or whatever makes sense at the time.
The Beagleboard site has a mailing list. Subscribe to it and participate in some of the discussions. They've got an IRC channel. Log into there sometimes and get to know some of the people. Take the questions you've just posted here and discuss them there. Find out who knows what they are talking about, and ask them about your application. Look like you're an active community member.
P.S. It looks like someone else is working on a Beagleboard based PLC as well. See PupLC for details.
> Have a look at this: http://lwn.net/Kernel/LDD3/
> Linux Device Drivers, Third Edition. It's a free download and the authors are well known kernel developers. <
I have Russini's book around here someplace.
> The following is a summary of SPI driver development:
> It does mention that there is support for user space SPI drivers, but it doesn't go into details (it's just a summary). <
Yes, there is a spidev userspace driver. And a kernel space driver. And I've got examples. Just waiting on hardware. That's what's so frustrating.
> Wouldn't the Beagleboard come with SPI drivers and wouldn't there be an "official" way of accessing it? For example, I've got a "/sys/bus/spi" directory (but no SPI devices however). <
Well, kinda. There are issues on how to get the muxed pins set up right for SPI and some churn because new versions are coming fast and furious. But, I can see that it's all doable. Most of it's noise until you actually do it and get in the zone. Hard to do until you've got a target.
> As for the contest, they say they give away 2 boards every week. However, not all the details for your project are filled out on the contest wiki. The "beagleboard.org project" and the "homepage" are still "TBD".
> I would suggest filling out the details, and PUT UP A HOME PAGE SOMEWHERE. ----- snip ---
If you need help with the web page, let me know. <
I'll have to figure out how to show you what I've got. I'm not a web monkey, but I've got a start.
> You've registered a Sourceforge project, so you have a free host for static pages. That would be the home page for *the project itself*. If you decide you need a more elaborate web site later (e.g. so people could order boards, etc.), then you can point the home page somewhere else later, link to it, or whatever makes sense at the time. <
Yeah I can start working on that again.
> The Beagleboard site has a mailing list. Subscribe to it and participate in some of the discussions. They've got an IRC channel. Log into there sometimes and get to know some of the people. Take the questions you've just posted here and discuss them there. Find out who knows what they are talking about, and ask them about your application. Look like you're an active community member. <
I'm on the mailing list. I don't do IRC, but I suppose I can learn:^). The problem is I'm just a wannabe and don't have much to talk about yet.
> P.S. It looks like someone else is working on a Beagleboard based PLC as well. See PupLC for details. <
If it's the one I saw, he's more at interfacing the BB with PLCs that is, more like SCADA. But I should drop him a line. You have to remember, I don't "get" social networking :^) Just like I've been invited to get "Linked In". OK, so now what? I guess what I've been doing is close to blogging, but I'm not much on idle chit chat. Lately I've been burning a lot of time on job hunting but I don't want to let the project slide. More at home with C than HTML. I guess I'll have to reinvent myself _again_:^).
>I'll have to figure out how to show you
>what I've got. I'm not a web monkey, but
>I've got a start.
Send me a private message via the Sourceforge accounts, or else just download one of my MBLogic packages and look in the source code copyright headers for the e-mail address. I have a dedicated e-mail account set up for open source projects. I don't want to post it here because it would get spammed to death.
>OK, so now what? I guess what I've been
>doing is close to blogging, but I'm not
>much on idle chit chat. Lately I've been
>burning a lot of time on job hunting but
>I don't want to let the project slide.
>More at home with C than HTML. I guess
>I'll have to reinvent myself
If you're running an open source project you have to be prepared to do "management work". It may not be as much fun as writing code (or designing circuits), but it's part of the job you take on.
As for HTML, it's not hard once you get the basic ideas. I'm not an artist, but I can make a passable web page using proper modern techniques. I think it's an essential skill these days, so it's well worth learning for its own sake. I'm willing to explain whatever I do, so if I help you with the page(s), you will understand exactly what I did and why I did it that way.
Not much happening, but for a good reason. After a year and a month of sending resumes to the dead letter office, this week I got 3 calls. Went to one interview. I have a phone interview Wednesday and I was asked to show up for testing tomorrow. I may skip that as the outfits that do the testing are scamming. Aptitude, OK. Ability, Ok. General knowledge, OK. Personality profiling or psychological testing, not OK. The relevant stuff would be fine if they post the results in public and hire by those results. Otherwise, it's just a scam to legitimize discrimination. As long as nobody sees the results, you can reject anybody by telling them they didn't meet the criteria, with no recourse.
And you're free to use any criteria if it's challenged. I won't play. If you ask to see the results, they hang up. It's a scam. Don't play. But anyways, that's what's holding up progress. If I get a job I can probably afford to fab the cards and move it along. No progress noted on the BeagleBoard Contest. I wonder if it's dead.