Ladder Editor For Linux.

C
Electronics with microsecond resolution are certainly doable, in fact, outside automation even trivial electronics operate much faster. But because you can't just casually wire things together and expect them to work at high kHz or Mhz speeds, PLCs are _deliberately_ held to speeds where you can. And sensors, etc, take this into account as well. My crude original Linux PLC with a commodity DIO card would work far above the speeds you need. But not with 10 feet of #16 run through a wiring trough with the ground maybe in another trough. And if it doesn't work that way, the average automation guy will tell you it doesn't work. That's why "high speed" stuff is treated specially and not widely produced. Getting signals 10 feet at mHz speeds is non-trivial. Of course, it's doable, but not with common wiring practices. I can send you the code and the gerbers for the level translators, add a PC and a DIO48 card and you have the timing you need. But keep your scope handy and look into line termination and back matching.

Regards
cww
 
C
I quite agree, and I did forward the inquiry and responses to Koyo. And it's certainly not above common courtesy to ask politely before you RE someone's stuff. You might just catch the right person or the right time or mood. And there are very good business reasons to do a Linux product when you are in a market with so little differentiation. There will be a first commercial Linux toolset, I would like to accelerate that timeline a little. After all, you would be hard put to hire an embedded engineer that doesn't know all about Linux and I'll bet at least one of the three has application people that could do it. Right now, they could hire me and I'd do it, we'd have to talk about licensing, but I still program what the customer wants, within reason. I spent hours last night wrestling with XP to get a stable environment to run their free demo version. I have not missed the Windows mess at all. But that's another story. I'll putz with it some more once I regain some patience.

Regards
cww
 
Armin:

See Curt's reply. If you have a local bus attached to the CPU you can have the CPU carrier decode the ISA address space into 8 or 16 divisions, which will end up being your rack IO address limits. Each IO card will get a decoded "card select" from the rack based CPU carrier board, so no jumpers will be necessary. In this way you can develop cheap and simple IO cards with a simple PLD or 74 series chips.

PCI is somewhat more difficult for a rack based "simple IO" interface because of its high speed and need for interface chips. I think you can do a PCI interface in a $5 Altera chip, but I haven't confirmed this. In real life the PCI board still needs a physical address, so you will have to have your backplane have some kind of additional jumper or slot ID anyway.

KEJR
 
Hi Bill,

Oh yeah, I've seen A LOT of STD bus boards! Just last year I had to have some legacy boards scanned and converted to GERBERs so I could have more made for spares. That is the good thing about those old boards that were DIP based, you can actually work on them. We have a lot of legacy systems running z80 embedded control from the days when PLCs were way too slow to do the job. Occasionally we have to reseat a card or replace a ribbon cable connection, but that's about it. I'm waiting for some electrolytic capacitors on our old obsolete PMAC STD boards to start popping. Some of them are approaching 15-20 years of service.

I know you can buy Pentium class CPUs for STD bus, but I can't help but think it is still dated. I was also wondering about 3U VME since it has a rugged mechanical spec. I've never used it and it seems like it would be expensive, but I don't know this. Maybe a version that is VME in mechanical but electrically simpler.

KEJR
 
In reply to Ken E: The problem with the older bus standards is that the supply of interface chips is dwindling and will disappear.

As for VME, I believe that it is much more expensive than STD. The reason that STD bus existed was that it was cheaper than VME while still being good enough for many applications. VME seemed to be for applications where cost was no object.

Although STD bus was a "rack" that was superficially like a PLC, it wasn't as easy to work with as a PLC. The cards were exposed and you had to be very careful not to drop anything into them. The wiring connectors were on the edge of the PC boards without any mechanical support and could be damaged if you were not careful. The wiring usually had to be tie-wrapped to the card cage to avoid putting any mechanical stress on the cards or the connectors. If you had an electrician who liked to use his "big" screwdriver on everything, you needed to keep him away from any STD bus equipment.

The companies that I know of that used STD bus used it as a hardware platform for their own soft logic system. PLCs didn't do what they needed from a software perspective, and they also needed to avoid vendor lock-in so they could guaranty the availability of parts to their customers based on their own product lifespan plans rather than the product schedule of a PLC vendor. All of the companies that I know of that used STD bus no longer use it and have switched to networked I/O with a single board computer or passive backplane PC.

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.
 
In reply to curt wuollet: I agree that it probably wouldn't hurt to ask. So far though, all they know about you is that you are interested in their PLCs. It might not get anyone's attention there.

If you contact them again later and tell them that you are already compiling/decompiling programs and uploading/downloading them, then that is something that is more likely to get their attention. They'll know at that point that you can go ahead with or without them.

Ultimately, it would be to Koyo's advantage (although Host Engineering might perhaps feel differently about it) for you to succeed. At this point however, they don't know if you *can* do it or if anything will come of it. Having something which actually works (even in a limited fashion) answers those questions.
 
C
Or if you can tear yourself loose from the wide bus thing and go thoroughly modern, you could now implement with a serial bus ([email protected]) and the plethora of I/O expanders from Microchip,etal. and have a very low cost backplane and still make very respectable scan rates with cool stuff like interrupt on change at the cost of software complexity. That would require a library to hide the nasty serial details. I've just been looking at that as part of a search for suitable IO port chips. That would open a large variety of non PC104 options. Sadly, it's getting very difficult to find through hole components. But there are a lot of inexpensive processor boards that can do SPI. I would lament the loss of nostalgia and the easy repair and interfacing the traditional approach provides, but the cost advantages would be fairly large.

Regards
cww
 
In reply to M. Griffin and CWW:

I thought about a serial bus, and although the hardware is arguably more complicated, it is within our grasp, especially if we can use one of these SOM devices (Linux Stamp, ICOP, etc). 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 (as Curt suggests).

I did a study on our typical machines and found that although we benefit from a fast scan rate that we weren't moving much data at all during any given millisecond (Maybe one or two changes of state per ms). I don't think this is unique and probably represents a typical machine. Analog will still probably want to be polled, but we could offer a choice of a data averaged analog value or the instantaneous value and let the little microcontroller do the work there.

Event driven or not, I think 1.5MHZ bus with a very simple protocol would be fine for most people. I belive SPI has an addressing scheme already (I have to check this).

I know VME cards are expensive, but why couldn't we use the Euro-card *hardware* to make our own simplified system with these available components? I've worked on these systems before and they aren't much more than off the shelf rails cut to length with sheetmetal endplates and covers. Sheetmetal can be REALLY cheap in any kinds of quantity, and even cheaper for prototypes if you have a shop (I do...). We could customize the package to be close to PLC sizes. Developing a backplane for a serial bus is rather easy once the mechanicals are taken care of.

KEJR
 
C
> I thought about a serial bus, and although the hardware is arguably more complicated, it is within our grasp, especially if we can use one of these SOM devices (Linux Stamp, ICOP, etc). 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 (as Curt suggests). <

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. And since they are programmable as either inputs or outputs, the cards would be the same except for the interface stuff. And SPI D/A and A/D are widely available. If you find an embedded processor that already has the SPI work done and a Linux port, you could be in business in the time it takes to layout and fab cards. The only kink I can see is enough chip selects, but if the processor card chosen has utility outputs, these could be used as high order address and preselect a bank for the provided cs lines. One might want to do some sort of an output enable for the interface to keep the outputs defined while you initialize them, I forgot this on the board I did as they default to inputs on power up. Even better might be the chips that can be programmed in a shutdown mode, then brought up all at once.

> I did a study on our typical machines and found that although we benefit from a fast scan rate that we weren't moving much data at all during any given millisecond (Maybe one or two changes of state per ms). I don't think this is unique and probably represents a typical machine. Analog will still probably want to be polled, but we could offer a choice of a data averaged analog value or the instantaneous value and let the little microcontroller do the work there. <

> Event driven or not, I think 1.5MHZ bus with a very simple protocol would be fine for most people. I belive SPI has an addressing scheme already (I have to check this). <

You don't really need to design a protocol, in fact you can't. You do what the target chip wants. Once programmed, there is very little overhead and read and write should be symmetrical. An extra line per slot for the interrupt would let you skip input regs with no change. And you can do the same in software for the outputs since you know if you changed them. > I know VME cards are expensive, but why couldn't we use the Euro-card *hardware* to make our own simplified system with these available components? I've worked on these systems before and they aren't much more than off the shelf rails cut to length with sheetmetal endplates and covers. Sheetmetal can be REALLY cheap in any kinds of quantity, and even cheaper for prototypes if you have a shop (I do...). We could customize the package to be close to PLC sizes. Developing a backplane for a serial bus is rather easy once the mechanicals are taken care of.

Even the VME rack parts are really spendy, out of all proportion, and the connectors would be the major cost of your PLC. 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. Vector and others used to sell card racks, but I would look at the packaging AD and Optomation and other low cost folks are doing. One way to deal with this is to find extruded shapes that can be cut to length and the cards mounted, then a simple pair of slotted rails can be all you need. You might even be able to use a ribbon or flex bus to eliminate the connector strain issues. All of this could be done with little or no tooling cost. A guy with a mill/drill would suffice. I've been thinking about this while waiting for the funds to buy a used AD DL06 or similar. I need to be doing something.

Regards
cww
 
In reply to Ken E: 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.

It could be configured such that each rack is a USB hub. The backplane connectors to each card could be USB type A connectors.

Power to the electronics in each card could be provided via the connector (provided the current draw was low enough). I/O power would of course be provided conventionally (through the card's front connector).

Racks could be daisy-chained via USB cables. You could have a maximum of 127 USB devices (including rack hubs). That should be lots for most applications.

Off-rack expansion to a device which won't fit in a rack could be provided by USB cables. For example, you could have a dummy card which simply brings the USB connector out to the front of the rack.

This configuration means that all the electrical engineering issues of cables, connector designs, signal characteristics, etc. are already taken care of. You can also use off the shelf cables for making connections between racks.

If you can map the device characteristics to one of the common USB device classes, then the driver on the PC end is taken care of already. For example, a digital I/O card could appear as a USB mass storage device (the same is true for anything else whose I/O or data table could be memory mapped).

A single USB device can have multiple "pipes" for transferring data. There are 4 types of pipes: isochronous transfers, interrupt transfers, bulk transfers, and control transfers. Between these 4 types you ought to be able to find something which suits your applications.

As far as speed is concerned, USB has a lot of bandwidth. The current version (USB2) is 12 Mbps. USB3 will increase that to 4 Gbps. Actual throughput after overhead would be a lot lower than that, but either should give you all you can use (and perhaps more than a PC could handle). I don't know how that will translate into latency however.

Using USB would give you the following:

1) Electrical design is done. You just need to follow the specs,

2) Connectors are fairly robust, and should be quite cheap.

3) Cables are off the shelf.

4) Hub chips for rack interfaces are off the shelf and hub designs should be easy to find. You are just basically adding a mechanical rack mount to a (stretched out) hub.

5) USB device chips are quite common. For example I believe that AVR sells micro-controllers as USB devices. Things like A/D converters may not be available with USB interfaces on them (SPI has the advantage there), but you could interface those to a micro-controller that has one.

6) I/O cards could be hot-plugged.

7) Expansion racks can be daisy chained.

8) Up to 127 devices (including hubs). This is comparable to the capabilities of most mid range PLCs. You may be able to go beyond that by simple plugging any additional rack chain into another USB port on the PC (I'm not sure what the OS limits are however).

9) If you can map the I/O cards to a common existing USB device class (with existing drivers) then you can use existing drivers that are already installed.

10) A lot of the software interfacing issues are already handled in the OS. For example, if you plug in a new card, it shows up in the OS without having to scan for it (automatic discovery). You may be able to use existing desktop tools (e.g. Nautilus) to browse the device for testing and troubleshooting purposes.

Those are the pros for this idea. For the cons, I don't know if there is a USB patent pool which would demand royalties. It is quite possible however that any patents apply to the chips themselves and that you are OK so long as you are simply using those chips (you certainly aren't going into the chip making business).

The USB name will be trademarked, and you probably won't be able to use the "USB" name or logo anywhere on your hardware unless you were a member of the USB vendor's association. That probably wouldn't be a problem however as far as you are concerned.
 
Have a look at Proview developed by SSAB. It is a complete automation system running on Linux on standard PC hardware. For IO connection it supports for example Profibus and Modbus. It includes editors for PLC code in grafcet and fbd as well as inline C code blocks. There is also a complete HMI part in the package. A typical automation project can be divided in process nodes running PLC code (= compiled in to C code) and operator nodes for the HMI. Take a look at www.proview.se

/niroma
 
Top