Ladder Editor For Linux.

Hello,

In reply to KEJR.

DACHSview-SDL doesn't support SFC ... it supports function block display (as done by other newer standards - e.g. IEC61499). Besides the FBD is also supported a subset of elements of Petri Nets .... used for the lamp ON/OFF example.

The thread concept used for FBD includes blocking/non-blocking threads scheduled by the RTOS. These threads can be assigned to individual cores of multi-core CPUs. That's provides any kind of parallelism.

> You mention your system can develop an outline for overall top level structure using graphical language (lets say SFC), but can you have parallel execution of SFC elements that are coded in text code and happen to contain "blocking" code? <

Yes, blocking function blocks are allowed.

> In the case of automation I'll define blocking as waiting on an external resource such as an input bit from a sensor. i.e. code equivalent to:

> While(Mysensor == OFF); <

Bad example ... waiting could be done on semaphores, mutexes, messages and software/hardware interrupts

> What I'm getting at is that I have seen systems that allow you to define a system structure in SFC, and to have the internals of the SFC blocks consist of a text language (usually Structured text, or ST). The problem with a lot of IEC implementations, especially related to ST code is that the internal ST code must not block or else the system will watchdog. <

Yes, this a one of the most disadvantages of the polling operation of IEC61131-3. Blocking function blocks/calls are not allowed in that environment.
Distributed application are also not allowed.

> Does your system allow parallel execution when one or more of the executing SFC elements are blocking? <

Yes, the threads of the DACHSview target are not scheduled by an internal proprietary co-operative scheduler of the target ... they are scheduled as system processes (or threads) by the RTOS scheduler.

> Is this accomplished via multiple RTOS threads, or do you do the technique of skipping to the next parallel element once a blocking condition is encountered on the current element? <

We are using multiple RTOS threads coded with function blocks. This allows us e.g. to run parallel execution of these threads on different CPU cores ....
We use function block display as a general purpose development language ... without the restrictions of IEC61131-3.

Best Regards
Armin Steinhoff
 
D

Dave Ferguson

In my opinion the only way you have any chance of doing this is browser based. Otherwise you will not compete.

You will not reverse engineer a major player. After Icom days they will see to that, where is Icom, Taylor etc, AB will not make that mistake again.

Liability will be your next major roadblock. I know many a company who will not take a small or unproven app because they want someone with deep pockets to go after if things go wrong.

Next would come the challenge of making hardware or getting buy in for soft control. Since you will not succeed at reversing a major.

Lastly IMHO would be the lawyers and insurance. We are not talking about "What would Google do" here, we are talking machines that move and KILL people. BIG difference than an App that tells you stock prices etc.

Much bigger hurdles to overcome than just writing the code....

PS: I lived the Icom experience as Wintegrator #1 wish it could happen again but much, much tougher.

Dave Ferguson
Control Systems Engineer

Sent from my iPhone
 
In reply to curt wuollet:
> I propose to look at their DL06 and friends first as this is a sort of generic PLC and can be found used inexpensively. <

From a cursory look, that one has good potential for reverse engineering. However, it looks as if the DL series will soon become a "legacy" product, with the Click and Productivity3000 series being the new basis for their product line.

On the other hand, just getting the experience of reverse engineering *any* popular PLC will be worth while. Once you have that working you could then decide if you wanted to re-target the effort to another model.

I think what you would want to start with as a first target is to just be able to:

1) Take a text file of IL and compile it to whatever format the PLC uses,

2) Download it to the PLC.

3) Upload the program from the PLC.

4) Decompile it back to IL.

Those would be four individual command line programs. I would suggest not even thinking about a GUI or ladder, or anything like that until you had those basic functions working. Siemens launched their S7-300 series with not much more than that (although the distributors were absolutely livid over it).

I started off addressing your other points, but quite frankly I don't think they're really relevant at this stage. The upload, download, compile, and decompile capabilities are the targets that should be aimed at first.
 
As I think about this some more, I have a few other suggestions about an implementation.

As I mentioned in a previous reply, you would want to start with a basic uploader, downloader, compiler, and decompiler. I guess you would want a 'Y' cable so you could listen in on the conversation between the programming software and the PLC. That will let you work on developing an uploader and downloader.

When you get the upload/download protocol worked out, you would probably want to also write a version that acts in place of the PLC. That would let you "download" programs from the programming software to your development PC (Linux PC) and capture them to files without having the PLC plugged in. That should make the next stage (decoding the instructions) easier.

There will be hundreds of instruction combinations to deal with once you take the op code plus address type into account. You will probably want to auto-generate test PLC programs in IL to create these combinations (using Python, Perl, or something like that).

Once you have the upload and download process worked out, and you have captured a complete selection of instruction samples you won't have a lot of use for the original programming software. You will need to haul it out from time to time as you think of new things to test, but at this point you are mainly working from a known set of test data.

The basic boolean logic instructions should be a small proportion of the total work. The bulk of the work will be the word instructions, simply because there are so many of them once you take address combinations into account.

You would also want to keep track of the results for each instruction in a big spreadsheet. The spreadsheet format will depend on what you eventually do with the data, so that is something that will change quite a bit as you design the compiler and decompiler. However, it is really the only practical way to keep track of all the data plus whatever tests you have done. I know the DL205 has over 200 instructions, and I don't think the DL06 is much different in that respect.

What I did for my soft logic system was to export the spreadsheet to a CSV file and then run that through an small AWK program to auto-generate the Python data structure (a big dictionary) which controlled the IL compiler. That way as the program design evolved I could update the data structure automatically. That is a much faster and less error prone way of doing things then updating the code for each instruction by hand. Your spreadsheet columns and data will be totally different from mine, but the principle should be the same.

When you have the instruction format worked out, then you can upload programs directly from your Linux PC to the PLC and test them. What you would need to do is to write a series of PLC programs that test themselves and report the results in the data table. You would then read the data table (probably using Modbus) to verify that the tests are working correctly. I do something similar, although I my case I am testing what the instructions do, rather than testing whether I have the correct instruction. You will want to automate this testing because you will do it over and over again with each new version to make sure that you haven't introduced any new errors.

Another suggestion from my own experience on this is that when you design the IL compiler (to convert IL to the binary format) it will be tempting to do it all in a single stage. However, you may want to break it up into multiple passes so that the different levels of analysis are available to the editor when you get to that point. That is, in one pass you break it up into rungs and subroutines. In another pass you analyse each instruction to see that it is syntactically correct. In another pass you convert it all to the final format (whatever that is). That way you can do things like check to see that if a subroutine call is made, that the subroutine actually exists somewhere, etc. It's not something to get too hung up on, but if you don't take care of it at the start, then be prepared to rewrite it all later (which is what I had to do).

I think at this point the whole project is starting to look a lot more practical. At this point however as I said before, don't worry about how to do a GUI or how to edit ladder. Worry about how to convert from a text file with IL to an executable PLC program and then download it to the PLC. Once you have that done you can sit back and evaluate where the project would go from there.
 
C

curt wuollet

Hi Dave

> In my opinion the only way you have any chance of doing this is browser based. Otherwise you will not compete. <

There is no need to compete. I'm obviously not in it for the money, and if the folks that want to use Linux and I can do so, that's good enough.

> You will not reverse engineer a major player. After Icom days they will see to that, where is Icom, Taylor etc, AB will not make that mistake again. <

Perhaps, but they would have to prove damages and sue their customers. That is fairly poor CRM and I doubt that we would do any substantial harm, after all, you'll still buy from them, and the people using the project would still buy hardware. Unless the project got extremely popular, I don't think it would be worth their while to take my 1998 Sunfire or 95 Buick. I submit that going along with the project would do them more good with their customer base than stomping on it.

> Liability will be your next major roadblock. I know many a company who will not take a small or unproven app because they want someone with deep pockets to go after if things go wrong. <

If it compiles and runs correctly, it should be fine. The biggest liability would still be the person writing the ladder code. That's one of a kind and a lot more likely to have unfound errors than an often used programming tool.

> Next would come the challenge of making hardware or getting buy in for soft control. Since you will not succeed at reversing a major. <

Lot's of other people are working on that, as I have. It's not in the scope of this project, at least initially.

> Lastly IMHO would be the lawyers and insurance. We are not talking about "What would Google do" here, we are talking machines that move and KILL people. BIG difference than an App that tells you stock prices etc. <

Somehow factory people manage to do a lot of things without legal counsel. Are those replacement bolts certified? Will those weld repairs hold? Is that the very finest duct tape? Life is full of risks.

> Much bigger hurdles to overcome than just writing the code.... <

Most are irrelevant to a community owned project that operates in the public interest.

> PS: I lived the Icom experience as Wintegrator #1 wish it could happen again but much, much tougher. <

You see, there is some value in trying to change things, Regular old people trying to make things better for themselves and others is a force that's time has come.

Regards

cww Itinerant Automation Guy.
 
C

curt wuollet

> As I think about this some more, I have a few other suggestions about an implementation. <

> As I mentioned in a previous reply, you would want to start with a basic uploader, downloader, compiler, and decompiler. I guess you would want a 'Y' cable so you could listen in on the conversation between the programming software and the PLC. That will let you work on developing an uploader and downloader. <

Yes, I am looking for a linux datascope program so I don't have to write one first :^) Host also offers a free download/upload program. I have thought of looking at using the save format as an intermediate if it's not too bizarre. This would have meta data the IL wouldn't. Of course, it will not be generic at all but, I may look at it anyway. It would buy file compatibility with the original tools. That would be handy.

> When you get the upload/download protocol worked out, you would probably want to also write a version that acts in place of the PLC. That would let you "download" programs from the programming software to your development PC (Linux PC) and capture them to files without having the PLC plugged in. That should make the next stage (decoding the instructions) easier. <

First step is to get the thing to talk at all.

> There will be hundreds of instruction combinations to deal with once you take the op code plus address type into account. You will probably want to auto-generate test PLC programs in IL to create these combinations (using Python, Perl, or something like that). <

Yes, I am hoping that there is some regularity based on the fact that they can't be sparing much code on the target for up/download. Whatever they do has to be dealt with in a fairly straightforward manner. They don't have a Cray onboard and they worry a lot about kbytes. I'm thinking static addressing and storage.

> Once you have the upload and download process worked out, and you have captured a complete selection of instruction samples you won't have a lot of use for the original programming software. You will need to haul it out from time to time as you think of new things to test, but at this point you are mainly working from a known set of test data. <

> The basic boolean logic instructions should be a small proportion of the total work. The bulk of the work will be the word instructions, simply because there are so many of them once you take address combinations into account. <

---- snip ----

> I think at this point the whole project is starting to look a lot more practical. At this point however as I said before, don't worry about how to do a GUI or how to edit ladder. Worry about how to convert from a text file with IL to an executable PLC program and then download it to the PLC. Once you have that done you can sit back and evaluate where the project would go from there. <

Yes, the encouraging part is that these are currently, very small and simple computers and there are only so many ways to do the job. And for example, I expect all the "V"addresses to be contiguous, along with counter regs, etc. After a certain point it will become more predictable. The newer generations will have the hp to do much more clever things.

Regards
cww
 
I have to re-iterate that I think reverse engineering a PLC download is ill advised. Doing what ICOM did was [in my opinion] only possible because in the old days the PLCs were ROM based. Now that just about everyone is using flash you are really "asking for it" in terms of needing to keep up with their neverending upgrade path. I think an open source project needing to keep up with [potentially] dozens of firmware revisions is going to fail. Can you require firmware "downgrades" to run the alternate uploader.... Maybe. But usually you are limiting capability of new products when you do this. Koyo may be better than some, but I doubt they will open up their doors to the community or keep their design static.

In reply to M. Griffin, my comments about web browser editor was in regard to a completely open source CPU running some kind of softlogic. Contrary to what some have said, I believe that a common open source hardware project would help with software design because there is a defined target that people can program around and not have to try and be everything to every piece of hardware. I found myself looking at the sheeva plug computers, and I don't think they are that useable by themselves (you could argue with this, but hear me out...), but the internal System on Chip (SOC) device by Marvell is incredible. It has two ethernet ports, digital IO, I2C, etc.

My goal for any linux based "PLC" device is to have the following:

- Modern processor to handle softlogic, web server, X server (can be remote), program compilation, etc. GHz class ARM/Atom machine will suffice.

- Dual Ethernet to separate optional remote IO from corporate LAN and/or HMI.

- Cost under $200 to purchase the complete board (Qty 1).

- Can be offered in two types of physical packages:
* light version is a tiny brick PLC with small amount of built-in IO and remote IO....
* Rack version that can be used on a rack, also with remote IO

- Fanless....

- Any built-in IO will have removable screw terminal blocks

What is missing is someone to design the CPU guts of the board. Dealing [and most importantly troubleshooting) 400MHz memory busses is not trivial. I've done a fair amount of PCB design work, but this is outside of my personal experience level (I'm an EE who has done automation my whole career). Im almost wondering if there is a hardware group that we could collaborate with at least to develop an open module that would include CPU, RAM, FLASH, and provide headers to break out the CPU signals to a carrier break-out board that will be specific to the design (I know I could handle the latter on my own). There already exists a project called the "linux Stamp" which is really cool, but it is somewhat limited in capability of the processor and memory (at least compared to the Sheeva CPU).

I have a comment with regard to programming environment executing on the embedded computer. Would we not be better off using a specially packaged X windows client that could be made to easily install and run on windows, Mac, Linux? This already exists and is well supported. It has (almost) all of the requirements as a web based approach without getting into coding a new "web" based front end for any package we team up with (MAT, ClassicLadder, etc). That is to say that program software living on the device will be free of the upgrade nightmare, and one installation of (just about any) X client will cover many different versions of the PLC that the user might have. The user also need not know they are running an X client, just ask them for an IP address upon startup and they are hooked up to the system viewing the PLC editor. Just an idea, what do you all think? I think it gets us much closer as we will be hooked up to a lot of software already designed for Linux.

KEJR
 
In reply to Ken E: You said: "My goal for any linux based "PLC" device is to have the following:"

Like the following? "http://www.logicsupply.com/products" There is lots of off the shelf hardware there that meets your criteria. There is no need to design boards. If there is anything that you want to design, then you might want to design a case that mounts at right angles in a panel rather than flat.


As for using 'X' for programming, that's fine for on-line programming or troubleshooting on a system that is already installed. How would you handle a project however where you were working on the PLC program but hadn't installed the "PLC" yet, or where the PLC is not accessible to you via the network? You need to be able to install and run the software anywhere.

I don't want to give the impression by the way that a web interface is the answer for everything. I don't even want to swear that it is the solution to this problem until I actually have it working. Even if it does work the server will still need to be cross platform because you will always need to have the ability to do stand alone programming. In fact, when you are creating a new project you would normally do it using a server (soft logic system) running on your desktop (or laptop) PC.
 
In reply to M. Griffin:

**** In reply to embedded PC for PLC application: *********

I have to admit that the pico ITX from www.logicsupply.com is very attractive from the aspect of a miniature computing platform and this is the type of thing I would probably use on a medium sized system when you have the real estate for remote IO. I've also looked at Advantech and the like, but they are usually more money.

I think what I had hoped is that there would be interest in developing a PLC brick that could have remote IO and/or developing an open card cage design. Having a open source hardware computing platform with built in 24V IO (that you could expand) seems like a good thing to me. Let me ask you though, if there were a completely open platform that packaged a fanless linux processor and sat on a PLC looking rack with IO that could be accessed at bus speed wouldn't you use it? I'm not talking about a PC with miniature PCI boards, but a full blown PLC rack system with field wiring on the front, like a Koyo Click or Contrologix.

Realistically is it worth the effort? Probably not. As I have said before a small PC with ethernet fieldbus is probably sufficient for even 1ms updates given its own segment. I still would like to see someone say "I've tested Wago slice IO with modbus/TCP at 500us rate for 256 IO bits and 16 analog IO words." So far I don't know of anything stated as tested at these speeds, and I don't have a modbus/TCP "slice IO" setup handy. And yes, as I have stated in the past, I do need 1ms update rates for our equipment.

I do often run into the scenario where there is a "small" project that needs to be automated. This is where I thought an embedded linux "PLC" with built in IO (call it a brick PLC) would be handy. For small projects I've always used Keyence brick PLCs which are archaic in their programming, but they work fine. The saving grace is that these small automation projects often do lend themselves to these simple ladder programming PLCs. I guess I'm growing tired of dishing out company money for such limited devices.

********* In reply to using X server/client for PLC programming: *************

I agree with you about "offline" programming. This is a big downside in the idea that "you don't have to install any software to use it" concept. Whether it is web based or X server based you will need a piece of hardware (or emulator software) to host the development environment. I have seen more and more systems that require you to plug in to program them and it is strange when you come from the days of editing on a PC "in buffer memory" and then compiling/uploading to your device. Most devices requiring you to plug in to program have a way to back them up to a file, but it is somewhat backward from what traditional editors do. Usually it's a device like a smart servo amplifier or a vision system. So yes, I agree with your point.

KEJR
 
In reply to Ken E: The speed of the I/O is more closely related to how fast the software in the field device can turn around a message than it is to the actual protocol. It therefore tends to be very product and model specific. I haven't looked at sub-millisecond I/O because I've never needed it so far (except for wave form data acquisition, which needs a different class of hardware altogether).

Fairly often the slowest part of an I/O update cycle is getting the data between the communications module and the actual I/O points. This is often a serial bus and is much slower than the actual network speed (although the overhead can be much less). If the communications module has to address each I/O module in the rack one at a time, then a large rack can be slow to update. The result can be a trade-off between high speed stand alone modules with low I/O count and low cost (per point) racks with high I/O count.

When it comes to a small, low cost, shoebox PLC however, you are going to find it very hard to beat companies like Koyo on cost alone if you use a custom hardware design. They are buying enough components to get very good discounts, and they are amortizing their moulds and assembly tooling over larger production volumes. The way to match their costs is use commodity hardware and to use I/O from companies that specialise in it. For some niche applications a specialised hardware vendor like Keyance is always going to be better.

What I am looking for in an open system is the ability to do things that you simply can't do with a cheap (or even an expensive) PLC. I would like a better integrated HMI, integrated recipe management, built-in reporting of status and production statistics, better management of program versions, etc. In other words, I am looking for things which are in addition to just making the machine go, and that is what I am working towards. That is the additional value that the proprietary systems don't offer today.
 
C

curt wuollet

There are suitable systems that would require only a port of Linux and drivers. I think AD has one that could use an H20 port. But they are really expensive. But they do have the whole PLC ball of wax> I have done a little design work on adding a backplane bus to a PC104 processor. With a little money I could generate the Gerbers and have the boards made and package them. But that's the problem with Open Hardware. Hardware costs money and you end up with a business rather than a project. And then it's not Free anymore. And you can publish the plans, but very few people want to build their own.

Regards
cww
 
C

curt wuollet

As I mentioned earlier, I sent a note to AD and CCd Host Engineering. Both sent courteous replies which I'll paraphrase out of courtesy, not having asked if I could publish the replies.

Host Engineering:

They corrected my impression (from the AD site) that they weren't doing Vista or W7 yet, they are. Host explained that some folks had run DirectSoft on Linux using Wine and that they had never pursued a Linux version because: It's relatively not popular.

My response: Except among millions of Linux users. Neither is DOS, but I run it if that's what the software runs on.

There is not a guaranteed standard version.

My response: Pick a version or make your own and ship it with the product.

It's free.

My response: I can't see where that is a problem.

They went on to tell me the protocols are not public and Koyo would want an NDA. No surprise there.

Not a word whether they would encourage or discourage or help such a project.

Automation Direct:
A Mr Jeff Payne Product Manager PLCs, etc.
He said they've talked about a Linux version and he thought it had merit. And perhaps it was time to reopen the discussion with Host about it. He did say he would get back to me. He also said it they did a version it would be with Host and he'd leave it up to them if they would involve the community.

Of course, if they did come up with a Linux version, it would move them to the top of My preferred vendor list, free or not.

But the response so far doesn't encourage a community owned version.

I should CC: Koyo and see what they say. It would be their IP.

Regards
cww
 
Curt:

I looked back at your idea a while back when you were heading down the PC104/backplane path. I thought this had merit at the time because I too agree that ISA is simple, fast, and built in to many boards. I do somewhat think that PC104 is a bit large for a piggyback design. I can't help but think once you add room for the cardcage rails, front panel, and connectors you will be looking at a form factor that is about the size of a 3U rack computer, which may be too large. What rough size was your initial design? Was it Euro rack based (VME)? Did you find any cost effective PC104 modules? These always seemed to be in the $400-$800 range when I bought them, probably because of demand. I do really think ISA is a perfect bus for automation, I just wish there were more choice besides PC104.

It is true that someone would have to take some risk and dish out the cash to make some prototypes. Given the interest I've seen so far from this list, I don't think I would bank-roll the project. I think that sometimes open source projects need momentum though before people start to buy into it. I know I might be able to scrounge/beg/ebay a PC104 module and some rack hardware, but there would be a few bucks on misc items and interface boards. You would have to gamble that you could sell enough "kits" to make the initial investment worth designing.

There is some hope with System on module (SOM) standards (much like PC104, but more like a credit card package) but over the last ten years I have seen these things come and go like the wind. PC104 seems to be the only true standard (that I am aware of) that has lasted in the embedded arena. I tried to get a price on a new SOM from ADLink but I think they blew me off once I gave them my personal home address and quantities. (pricing for 1,10,100). You know that when it is hard to get a price that they don't intend to sell it to end users, which is a bad sign already.

KEJR
 
M. Griffin:

I wanted to explain my position of needing low IO latency. I don't think you are questioning me, just wanted to give an example where fast IO can add up even for a non DAQ or signal processing application. I do a lot of high speed pneumatic and servo actuated assembly equipment. The servos get actuated by a motion controller and have little latency. For the pneumatics, the IO speed is critical in not needlessly increasing cycle time. I'll give you a brief analysis based on 50ms pneumatic actuations. 30ms-50ms is typical for small cylinders and high flow valves mounted close to the actuator and moving small masses, of which we do a lot of, confirmed by oscilloscope and high speed camera. Also assume that every action has a sensor on the end stroke, which at these speeds you really need to do to get maximum performance without compromising reliability:

50ms * 10 actuations = 500ms cycle (assuming no latency on IO).

Also, assume that the IO latency adds up both ways, as it will when you have a networked bus on both inputs and outputs. (You know, read input, process logic, set outputs) For the following we get these added delays simply due to latency of IO:

For 0.5ms IO latency:
Added cycle time = 0.5ms * 10 operations * 2 (for input and outputs) = 10ms
Latency added to cycle: 2%

For 1ms IO latency:
Added cycle time = 1ms * 10 operations * 2 (for input and outputs) = 20ms
Latency added to cycle: 4%

For 2ms IO latency:
Added cycle time = 2ms * 10 operations * 2 (for input and outputs) = 40ms
Latency added to cycle: 8%

For 5ms IO latency (Modbus TCP default for some devices):
Added cycle time = 5ms * 10 operations * 2 (for input and outputs) = 100ms
Latency added to cycle: 20%

So as you can see, even a 2ms latency is getting up to 8% theoretical latency for this application, which is typical for these classes of machine I deal with. This of course is the worst case latency, and there are probably statistical analysis that says you can expect some fraction of this to be a real average (I bet its more than half the theoretical...).

So this is the reason I keep inquiring about field IO that is tested to respond to 0.5ms polling rates. For packaging, service, and reliability I'd like to stick with something that is packaged for the field, like the slice IO from Wago, B&R, Moxa, etc. In the end, I can't help but think that a backplane system would be better for these types of applications. The beauty of the remote IO is that it leverages the availability of multiple ethernet ports.

I agree with your points about brick PLCs. They kind of have their niche and it is probably hard to beat the price and reliability. Effort here might be wasted.

I also agree with your points about needing more than anybody offers in the PLC world. I think I am in the same boat here, its just that I also need the performance stated above as well. I don't think this is unique to us. I also don't like having separate boxes and programming environments for control, HMI, motion, and database. Its a lot to manage. There are times where you are putting a lot of time into interfaces that pass data around. I am encouraged that RTOS like Xenomai can have an application with mixed RTOS and "conventional" linux threads in one memory space. Picture HMI and control threads sharing the same global data structures without having to resort to a RTOS shared memory interface (yes, you probably need to use Mutex or Semaphores here...). Imagine RT threads writing to some data logging queue that a non RT thread is interfacing to database, etc. I know you can write shared memory interfaces to separate these (and in some cases you WANT to do this) but sometimes it is better to do it under one hood. Xenomai can supposedly switch in and out of realtime automatically, although I don't claim to know how this works. Current commercially available HMI/SCADA systems seem to piece together database functionality with slow complicated OPC mess running on a separate windows PC which I can not stand. I think we are preaching the same thing on this front.

I respect your experience and contributions here. I just want to stress that realtime and low latencies are not just for niche applications. Certainly for process and slow automation its not required. Unfortunately the tools to make things flexible are not always RTOS friendly. I'm hoping to find one popular fieldbus vendor that offers a fast slice IO. Maybe if I end up going down that road I'll try and give the manufacturers the third degree on their internal "slice IO" serial bus speed. This is usually like pulling teeth.

KEJR
 
> I looked back at your idea a while back when you were heading down the PC104/backplane path. I thought this had merit at the time because I too agree that ISA is simple, <

No, no ... the ISA bus isn't simple because you have to handle all resources manually by jumper settings a.s.o. That means you have to know all hardware details about ROM, RAM. IO addresses and interrupts. PC/104plus is much better ... it works also on Compact PCI carrier boards. There is also PC104plus based on PCIexpress ...

> fast, and built in to many boards. I do somewhat think that PC104 is a bit large for a piggyback design. <

PC/104 isn't designed for the use only as piggy backs. It allows to build small ans stable PC systems for the harsh environments.

> I can't help but think once you add room for the cardcage rails, front panel, and connectors you will be looking at a form factor that is about the size of a 3U rack computer, which may be too large. What rough size was your initial design? Was it Euro rack based (VME)? Did you find any cost effective PC104 modules? <

Yes ... I have seen professional CPU boards (800Mhz CPU clock) for less than 200 Euro. ( e.g. http://www.icop.com.tw/pddetail.aspx?id=127&pid=4 )

> These always seemed to be in the $400-$800 range when I bought them, probably because of demand. I do really think ISA is a perfect bus for automation, I just wish there were more choice besides PC104. <

No problem ... there are other format available e.g PMC.

> It is true that someone would have to take some risk and dish out the cash to make some prototypes. Given the interest I've seen so far from this list, I don't think I would bank-roll the project. I think that sometimes open source projects need momentum though before people start to buy into it. I know I might be able to scrounge/beg/ebay a PC104 module and some rack hardware, but there would be a few bucks on misc items and interface boards. You would have to gamble that you could sell enough "kits" to make the initial investment worth designing. <

> There is some hope with System on module (SOM) standards (much like PC104, but more like a credit card package) <

Also available: http://www.icop.com.tw/pddetail.aspx?id=135&pid=4

> but over the last ten years I have seen these things come and go like the wind. PC104 seems to be the only true standard (that I am aware of) that has lasted in the embedded arena. I tried to get a price on a new SOM from ADLink but I think they blew me off once I gave them my personal home address and quantities. (pricing for 1,10,100). You know that when it is hard to get a price that they don't intend to sell it to end users, which is a bad sign already.<

Well, I'm not sales guy from icop .... this hardware is just one selection of other possibilities and is available since years.

Regards
Armin Steinhoff
 
C
Hi Ken

> I looked back at your idea a while back when you were heading down the PC104/backplane path. I thought this had merit at the time because I too agree that ISA is simple, fast, and built in to many boards. I do somewhat think that PC104 is a bit large for a piggyback design. I can't help but think once you add room for the cardcage rails, <
----- snip ----

It's a bit off topic here, but the height (width?) would be controlled by thePC104 stack and the bus width. It would not be any standard, as most require specific connectors, some of which cost more than I would hope for a whole module. The lowest cost, suitable, connector would be a .100" pin header. These are cheap and if the better grades are used, reliable. Using the whole ISA bus would be overkill and require high pin counts. By decoding and using hard card selects, you could keep the address bus size down to the number of registers expected on a card and make the cards much simpler and cheaper. Of course a narrow bus means longer scan times, but not out of the range of popular PLCs. The cards could be pretty simple as they would need few glue chips and little decoding. The PC104 processor is too expensive, but would have the advantage that you could stack special functions and make for a very versatile PLC. It would also give a measure of protection against single sourcing and to a lesser extent, obsolescence. The PC104 bus is on pin headers already so, you aren't going to find something much smaller to be of advantage.

> It is true that someone would have to take some risk and dish out the cash to make some prototypes. Given the interest I've seen so far from this list, I don't think I would bank-roll the project. I think that sometimes open source projects need momentum though before people start to buy into it. I know I might be able to scrounge/beg/ebay a PC104 module and some rack hardware, but there would be a few bucks on misc items and interface boards. You would have to gamble that you could sell enough "kits" to make the initial investment worth designing. <

Yes, the big question mark would be getting a stable, quiet. backplane, but at ISA speeds, this is feasible without extensive R&D or special fab. But. it's beyond my current means, or my former means, for that matter, but I felt it had to be done. At least far enough to show people that it could be done, and that there is no real magic behind PLCs. I also think it lends a little credibility to the issues with "Free Hardware". But they are not insurmountable.

> There is some hope with System on module (SOM) standards (much like PC104, but more like a credit card package) but over the last ten years I have seen these things come <
----- snip ----

Once again, smaller is not necessarily better, cheaper would be better. But the whole point is that a good PLC could be done with OTS components, 20th century technology, by an old electronics guy who is not even employable by today's standards :^) and maybe 25 individuals or companies willing to risk the price of a commercial PLC. And you could run whatever your heart desires on it, including full blown DAQ cards, video frame grabbers, and whatever else is available for PC104 from a variety of vendors. And would network with whatever you have a mind to talk to, and using the tools of your choice. This is the antithesis of the current PLC offerings and the advantage should escape no one.

As I've mentioned before, things don't have to be the way they are. So, if I'm not wowed by new systems whose features are quite overwhelmed by anti-features like lock-in, single sourcing, and marriage to a predatory monopoly, it's probably because I have a clear vision of how we could have the good without the bad. Suppose there was a Foundation for Open Industrial Automation? Very modest projects and cooperation with the many authors waiting for a platform could greatly change the slope of the playing field.

Regards
cww
 
In reply to Ken E: I am quite familiar with these types of I/O scan delay. However, in between high speed packaging and low speed process industry is a very broad middle where the sort of times you are talking about don't make a significant difference. 50 ms cylinder strokes will often either damage the product being worked on, or else catapult it through the air.

You might also want to compare those times to factors such as MRS positioning accuracy and cylinder charging time which make such high speeds impossible for anything other than the very smallest of pneumatic cylinders. Also consider that a small (20 amp) motor contactor can take close to 100 ms to close. In most applications these things matter much more than the I/O scan time. This is why you don't find customers scrambling to "upgrade" their PLCs whenever the vendor comes out with a faster version.

There are however applications where this does make a difference. For those sorts of things you might want to look at the I/O that Beckhoff offers. A lot of their I/O is designed specifically for high speed. You might have to adjust your designs to their packaging however.

It sounds as if what you want is the sort of thing that Armin Steinhoff is doing (his latest systems run on Linux), except you want the actual logic engine to be open source and program using a type of textual language. He doesn't have very much detail about his products on his web site, but you may wish to have a look at it for ideas.
 
In reply to curt wuollet: I think you will find that Automation Direct (and Koyo) have a contract with Host Engineering for programming software, and for some hardware designs. The relationship will go both ways, so AD can't afford to antagonise Host Engineering (HE), and HE really has no incentive to make their position redundant by providing you with information on how to write your own PLC.

I am not quite sure what the actual business relationship between Koyo and AD is - whether AD is a subsidiary of Koyo, or whether they are a distributor. AD's newest PLCs (Click and Productivity) aren't listed on Koyo's own web site. The AD brand only covers certain countries, with other countries have different distribution channels. I have to wonder what is going on there. You might have better luck contacting Koyo directly.

As for a Linux version of the software from Host Engineering, I doubt they would be interested. It would probably be very difficult for them to make an existing MS Windows program run on any other OS. Unix and C (and C++) were joined at the hip from birth, and unix has very consistent designed principles throughout. Porting a typical unix/BSD/Linux program to MS Windows usually isn't too hard (provided you stick to GCC). Going the other way however is usually really difficult. MS Windows is a rag bag of ideas copied from VMS, CP/M and Unix all mixed together. It doesn't have any consistent design principles, so making an MS Windows program "fit" anywhere else is usually almost impossible. Even if you are using something like Mono, it is almost always a port with a good deal of effort.

What the above all means is that if you can get the AD software to work satisfactorily on WINE, then all find an dandy. However, I doubt that HE will think the economics of coming out with an actual native Linux version are worth while. To get what you want will I think require you to write it, with or without Koyo's cooperation.
 
W
KEJR Said: "I do really think ISA is a perfect bus for automation, I just wish there were more choice besides PC104."

Have you ever seen an STD bus system? They are fairly obsolete now, but they were designed for embedded computers. The cards plugged into a rack similar to a PLC and had an eight bit bus, which was similar to the 8 bit ISA bus. Some companies adapted a 16 bit bus, but it was not as popular. The STD systems were tough as nails and fairly compact. Early systems used 8 bit micros, later x86 chips and became popular. The narrow bus was the downfall of the STD bus, AFAIK. A Linux based STD system would be very nice today.

Bill Sturm
 
Top