C code on a PLC

W

Thread Starter

Wim

Hi,

For a project that will start within a few months, we will be re-implementing the motion control of an astronomical telescope. Currently the control system is based on transputers, but we want to replace them by a modern, industrial controller. The encoders we'd like to keep, but the motor controllers can be replaced. I think the position control loop will have to be implemented on a PLC (or similar) because we have a large number of redundant Heidenhain encoders per axis which all need to be read simultaneously.

A particularity of this motion control problem is that we need to include a large number of complex calculations into the position control loop (e.g. coordinate transformations, effects of atmospheric refraction, etc.). To simplify this we want to use a standard package of C code which is used by many major observatories in the world. I have not obtained this C code yet, but I expect this to be a few hundred kilobyte large. I don't know how to estimate the CPU and memory requirements for the main calculations, but I've seen them running on a normal PC (say 2 GHz) at a rate of a few 100 times per second. It is however not necessary to run the calculations at each cycle of the position loop: if the calculations are run once or twice per second, the position loop can simply interpolate between the results and run much faster.

Hence my question: what are your thoughts on how to implement this control system? What are the possibilities to run C code on a PLC?

What I know so far:
- B & R PLCs can be programmed in C

- a solution would be to add an industrial PC and let it calculate the trajectory, while sending set points to the PLC. But I'm not very fond of distributing the control system on a PC + PLC.

- I've read about PLCs with co-processors, but can't find anything useful

- we're also seriously looking for a National Instruments PXI solution (which can easily embed C code into LabVIEW)... but we have our doubts about long-term robustness and availability of these "semi-industrial" solutions.

Any thoughts would be very welcome!
Thanks.
Wim
 
Some of your details are a bit vague, but it sounds like you want to skip the PLC and go with a real motion controller. Delta Tau has a new product called the Power PMAC that allows you to program just about anything in C language. Its based off of a realtime linux, so you have some high level features available to you (Don't expect it to be a desktop linux, but the linux distro is based on debian so you can install some additional packages). I would consider them a hardened Industrial product similar to a PLC because the flash disk is mounted readonly at bootup.

There is also an SD card if you want to add your own data storage. You can even re-define the servo algorithm if you want to, but it sounds like you probably don't need to do that if you are just positioning multiple axes. It sounds like you would have one task that calculates position and pass it to a motion control program that just follows the position. I don't know if this is appropriate, but they have a drive network system called MACRO, and Copley Controls has amplifiers to interface to the motors/encoders. I think they have some level of EnDat support if you need absolute capability (you mentioned Heidenhain encoders...). If you are interested I would call them because the product is new, but there is some description on the website.

KEJR
 
Hello,

We have customers which are using PLCs from Siemens together with QNX PCs for running SCADA systems on oil platforms.

The computing intensive tasks are done by the PC systems which are linked via the fieldbus PROFIBUS-DP with the PLCs. In that case the PLCs are just used as intelligent I/O sub systems. The application cycle time is in the range of 1ms.

Similar configurations are also possible with other fieldbus systems which are supported by the PLCs.

Best Regards

Armin Steinhoff
http://www.steinhoff-automation.com
 
W

William Sturm

This sounds like a good application for a Delta Tau PMAC controller. The processing speed and motion capabilities would be a non-issue. Their latest Power PMAC runs on an embedded Linux system, and can be programmed in C. Their older established system uses a Basic type language with 64 bit floating point, you might be able to port the C algorithms to the older system. The PMAC can be used with virtually any type of motor, which could be useful. You would probably want to attend their training class, as the PMAC takes a while to learn.

Bill Sturm
 
C

curt wuollet

<b>Moderator's Note:</b> post corrected to remove name at beginning of post.

Once again, it's much easier to do PLC functions on a PC than to do PC functions on a PLC. As for robustness, that shouldn't be a problem in an observatory environment as far as hardware goes. The key to robustness on a PC is simply to use robust software that isn't obsolete whenever revenue is needed. I would use a Servos To Go, or other encoder card in a PC and run Linux, which should be well accepted by the science lab types and will probably run the position package without much putzing around. The IO can be handled with a DAQ card and the drives can be selected for non-proprietary communications. This will IMHO, give the most robust and "time proof" implementation and can be implemented and maintained by any competent C programmer without any expensive or short lived tools whatsoever. Code for the technical bits should be freely available from the various Linux CNC and Linux lab sites and won't cost you anything. Most Science types love Linux and OSS and you'll make them happy. You can do this on Windows, but it will cost a lot more and the robustness is laughable.

Regards,
cww
 
C
Hello Wim:

Our controllers have been used for many years now on many of the large telescopes around the world. Our newest controller, the Power PMAC, which we are rolling out now, allows the user to insert custom routines written in C at many points and priority levels in the overall control, including the servo loop. Running a custom algorithm one place still permits you to use all of the standard built-in algorithms elsewhere. Everything is run on a single processor, so it is very easy to share data between custom and standard algorithms.

You can contact me by e-mail with questions at:
cwilson [at] deltatau [dot] com.

Curt Wilson
Delta Tau Data Systems
 
Depending on the time involved and the performance requirements with regards to positioning, rolling your own motion controller is not something to be taken lightly. To me, doing your own motion controller is really only affordable for a company/institution that has lots of time, but not a lot of money (i.e. colleges and hobbyists). If you do decide to build your own I would at least recommend the RTOS for linux or at least the Preempt_rt patches to close your feedback loops. Depending on your performance required you won't be able to tolerate the latency issues with vanilla linux when handling your loop gains.

It is also possible to run linux as a host and communicate position to CanOpen enabled drives. Using a smart amp like a Copley or Elmo will allow you to just send position information to the drive and have the drive close the feedback loops. Again, there are performance limitations to this as well.

I still agree with Bill to look into the Power PMAC. You won't regret your decision, at least with regards to servo performance.

KEJR
 
C

curt wuollet

> Bill Sturm, Once again, it's much easier to do PLC functions on a <

I don't know how Bill's name got on the front end of this, I was addressing the original poster. I wouldn't want Bill to think I was arguing with him :^)

Regards,
cww
 
The first thing I would do would be to ask the other observatories how they are running this package. If they are using it now, they will have a lot better idea of the various pros and cons than will a bunch of people who've never even seen it. If I had to guess though, I would guess that a lot of them are doing something like what Curt Wuollet described.

I would recommend trying to run it all on one system rather than interfacing a PLC and a PC. The handshaking between the two systems will be a lot more work than you expect, and the latencies may be a problem as well. This isn't really something that PLCs do well. For that matter, motion control isn't a strong point for most PLCs either (although there may be some exceptions).

I would suspect that *somebody* out there is running a telescope that isn't too different from yours, and that they have a software and hardware design that they would be happy to share with you. It is usually a lot easier to start with something that you know already works than it is to start from scratch.

I'm not an astronomer, but I was under the impression that observatories are normally all computer controlled. Older ones tend to use Unix (e.g. Solaris), while newer ones use Linux (because they can port their existing software easily, and because that is what astronomers are familiar with).

I am also going to take a guess that whatever control system you end up using, it is going to need to integrate well with the rest of the observatory including the observational instruments. I think you really need to be approaching this problem from the other end, and figure out how the motion control system will need to interface with everything else.
 
Hi,

Thank you very much for all the answers.

It is true that telescopes are mainly controlled by custom software on industrial PCs. Actually our telescope will be too, we have already implemented a large fraction of the control system (e.g. the dome, all CCD detectors, our spectrograph, ...) on a small network of linux PCs. However for the control of hardware similar to "industrial" applications, we are reluctant to replace everything by custom software because:

- you have a limited hardware choice because everything needs to be interfaced to linux

- you need a lot of low level coding to get all hardware interface cards to work

- you need tons of lines of code to get the same features (e.g. diagnostics) a standard PLC has

- it's not trivial to create (semi-) real time applications (e.g. for a position loop)

- it probably won't work more reliable than an industrial solution.

So, for the telescope pointing (= 3 axis motion control problem) and the hydraulic system, it would be nice to have a dedicated industrial controller connected to all I/O and motor controllers, while the rest of our Linux control system can interface with this controller (e.g. for SCADA purposes).

Other observatories I know of use VME boards, software on Linux as described above, and a few recent ones use LabVIEW. But I'll try to find out more information.

Anyway many thanks for the help. We'll study the alternatives and make a decision in a few months!

Cheers.
Wim
 
For each axis you will have a servo motor and drive. The motor will have its own encoder which will go back to the drive (not the controller). This will be for feedback and motor commutation control. I have said "servo", but that could possibly be some sort of AC vector drive with encoder feedback.

You will then also have a controller which takes readings from the Heidenhein scales and sends commands to the servo drives to coordinate them. The commands from the controller to the drives may be analogue (+/- 10V) or digital (some form of network communications). The controller could be either an "industrial" packaged product, or it could be a purely software solution running on a PC.

Above all this will be a PC which is coordinating all this with whatever else the telescope has to do. I believe you've said this part of it is already laid out.

There is nothing exceptionally robust about modern "industrial" controls. You can basically think of them as consumer electronics for factories. What they offer is they allow someone with relatively little knowledge to apply them out of the box to a narrow range of targeted applications.

The negative side to them is that most industrial control systems only work with components from the same manufacturer (or one of their licensed partners). Once that particular product is discontinued and parts are no long available, you can be faced with having to scrap the whole works. That's not a problem in a lot of typical industrial applications because the rest of the machine is probably at the end of its economic life anyway.

I would imagine though that telescopes tend to go on more or less forever. I think the thing you really have to be careful of in this application is getting tied into a situation where your design gets locked into hardware from a single vendor, where that vendor may discontinue the product, go out of business, or get bought by a competitor (who then discontinues the product).

At some point the higher level controls of your observatory need to communicate to the motion control system. That communication needs to be via some sort of genuinely open means. I said "genuinely open" because industry is full of "open" protocols that are secret, patented, and guarded by an army of lawyers. You will find legions of posters here who are asking "how can I make X talk with Y", only to be told that it can't be done. There are open protocols where you can download the specs without being a licensed OEM partner, but most of the big vendors will try to sell you their own proprietary solution.

To address some of your points directly:

You said: "I've read about PLCs with co-processors, but can't find anything useful"

I wouldn't recommend a PLC for this application. Their motion control abilities tend to be very limited. They are fine for stacking up boxes on a pallet or rotating a small table, but that's about it. I don't have anything against PLCs in general, and I have used a lot of them myself. They just aren't what I would recommend for this particular application.

You said: "we're also seriously looking for a National Instruments PXI solution (which can easily embed C code into LabVIEW)... but we have our doubts about long-term robustness and availability of these "semi-industrial" solutions."

NI makes really nice hardware and software, but I'm not sure what they can really offer you in this situation. You have to deal with a bunch of C code anyway, and then on top of that you will be faced with trying to duct-tape the NI stuff to the rest of your system.

My experience with Labview is that it's nice if your problem fits exactly what Labview does. If your problem doesn't fit the way that Labview works then you are in for a lot of pain trying to make it do what you want, or trying to change your problem so that it fits Labview. You also have the problem of what to do 10 years from now when the old development software won't run on any PC you have at the time, and the control program you have now won't work in whatever system NI is selling 10 years from now.

If you are looking for robustness in a PC, the things that tend to fail are hard drives, power supplies, keyboards (and mice), and monitors.

For keyboards and mice, just buy some inexpensive USB versions and replace them as they wear out or break. LCD monitors are cheap now, and they last for years. "Industrial" versions of these are just the same components in sealed packaging for very dirty or wet (oily) environments. If you are operating optical instruments under those conditions, you have much bigger problems to worry about than a bad keyboard.

For hard drives use a solid state drive. There are lots of those available now and a typical Linux distro will fit on even the smaller ones.

For power supplies, what tends to go on them is the fans (the fan seizes, and then the power supply overheats). Use a good power supply with ball bearing fans (which is what a good "industrial" version would do). Alternatively, look at the mini-itx packages, many of which use fanless "brick" style power supplies.

You said: "B & R PLCs can be programmed in C".

If you are going to program it in C, then why would you use a PLC?

You said: "a solution would be to add an industrial PC and let it calculate the trajectory, while sending set points to the PLC. But I'm not very fond of distributing the control system on a PC + PLC."

What would the PLC be doing in this situation though? Why not just download the set points directly to the drives? Many modern drives will communicate directly with a PC over Ethernet.

You said: "you have a limited hardware choice because everything needs to be interfaced to linux".

The stuff that will interface with Linux is the stuff that both has open specs and which is widely used. The stuff that doesn't is probably stuff that you want to avoid anyway (whether you use Linux or not) if you are concerned about longevity. For data aquisition boards look at COMEDI. They don't have everything, but what they do have is the stuff that most people actually use.

You said: "you need a lot of low level coding to get all hardware interface cards to work".

Again, see COMEDI. They make vendor independent drivers, and some of the hardware vendors recommend using their drivers rather than their own. However, what hardware interfacing are you talking about? I'm talking about plugging an Ethernet cable into the back of the PC, and there's no special hardware interface cards involved in that. If you have something else in mind, then you haven't told us what that is.

You said: "you need tons of lines of code to get the same features (e.g. diagnostics) a standard PLC has".

PLCs work great in a lot of applications. I've used lots of them myself. However, I can't imagine a bunch of astronomers sitting around a laptop trying to debug a ladder diagram. If you are talking about "user friendly" as opposed to "electrician oriented" diagnostics, then that is something that PLCs do rather poorly. I have written a *lot* of diagnostics for PLC programs, and doing a good job with that is usually more work than making the machine run. I don't think PLCs have any advantage there. Doing really good diagnostics with a PLC usually involves adding a PC to do the diagnostics and then figuring out how to make the PLC talk to the PC.

You said: "it's not trivial to create (semi-) real time applications (e.g. for a position loop)"

You should be talking to the people at EMC2 (http://www.linuxcnc.org/). This is the sort of stuff they do.

You said: "it probably won't work more reliable than an industrial solution".

It probably won't be any less reliable either if done properly.

Having said all this, take the above with a grain of salt. The correct answer to this problem depends on application details that I don't know about and which probably aren't practical to talk about here. However, what I can say is that I don't think there is anything in the industrial market which does what you want in a off the shelf manner. There just aren't a lot of things in a typical factory which resemble a large telescope. I think the biggest thing you need to worry about is to avoid painting yourself into a corner by picking something that *almost* does just what you need.

Something that I would do is to talk to other observatories about what they've done or are working on. I know that some telescopes have implemented things like vibration damping algorithms. That isn't something you'll get in a typical industrial package.

I don't want to give the impression that industrial controls are somehow "bad". However, they are products sold by companies that want to make money. They therefore design their products with a particular market focus. Once you step outside of their focus you are on your own and your problems become much more "interesting".
 
Thank you very much for spending your time and efforts... your views are most interesting, and very much appreciated.

I think our whole point is to try to separate the "industrial" control parts from the telescope a bit from the "astronomical" control parts.

Maybe it's interesting to tell you about one of the axes (apologies, should have done that a lot sooner):

- the "azimuth" axis has 2 motors, which both provide a torque in a different sense so that the gears are under "strain" and there is no play

- one of these motors has a resolver on the shaft

- each motor is controlled by a motor controller. One of them is in torque control mode (so that it renders a constant torque for the strain), the other one is in velocity control mode (using the signal from the resolver).

- for the position control loop, a precise Heidenhain linear incremental encoder encircles the telescope. This encoder is read by 4 "encoder heads", which all need to be read out simultaneously (buffered), averaged, and used as a position feedback.

- an absolute encoder is used for the homing.

- many safety and final travel switches are used to electrically safeguard the telescope using relays. The status of them should also be read by I/O. If easily feasible, also a bunch of Pt100s spread out over the telescope should be read.

The other axes are similar.

Because we have so many encoders, I think it's difficult to connect them directly to a motor controller. So I had in mind that we need to close the position loop on something else:
1) on a PLC: can read all encoders and I/O and talk to the motor controllers deterministically. However the trajectory (involving coordinate transformations etc.) needs to be calculated by a PC. These predictive setpoints need to be given periodically (e.g. once per second) to the PLC so that the PLC can interpolate, and close the position loop fast. The status of the system could be polled once per second or so for SCADA purposes with a simple ethernet protocol.

2) on a LabVIEW PXI system: can read all encoders and I/O and talk to the drives deterministically, and can calculate the trajectory all-in-one. The status of the system can be polled once per second or so by simple TCP/IP.

3) on a PC: i.e. implement everything with a PC and linux compatible hardware. This was our original plan, but we got stuck at some point because we had trouble reading out the counter cards for the encoders (buffered reading was not well supported for our card by the official driver nor by the comedi driver). Other people have managed to get it to work by using a very old driver for 2.4 kernels and modifying it, but it's exactly this kind of stuff we want to avoid.

4) perhaps this Delta Tau system mentioned above

Above is pretty much what I had in mind from before (maybe not in the same order), but of course we need to study it more in detail and finally make a "best fit" decision. Also I need to re-read your post (and this whole thread) a couple of times more and let it sink in... but your points seem genuine and they are very well taken.

Thanks for all the efforts and the enlightening views.

Wim
 
C
Sounds like a switch to a better supported card would get you going and preserve the work you've already done. I agree, a one-shot driver fix isn't that bad, but to keep it current you need to know a lot about what the kernel folks are doing. And it is non trivial programming. But if you can find a card that is well supported, I still think a Linux solution is probably the best. Not just because I _always_ think a Linux solution is the best :^), but because it sounds like a lot of the solution is already there and the acceptance factor is high. The difference between a PC selected for the task and the flashy new PACs is not that much in reliability terms, and I think you are overestimating the value of a PLC in the mix. It brings it's own set of problems and you have very limited means to deal with them.

Regards,
cww
 
> ==> Automation List post by M Griffin...
> [ clip ]
> I don't want to give the impression that industrial controls are somehow "bad". However, they are products sold by companies that want to make money. They therefore design their products with a particular market focus. Once you step outside of their focus you are on your own and your problems become much more "interesting". <
---------------------------------------------------------------

I can only support that statement. It's really the best way not to use specialized features of PLC systems because of the are mostly designed for a special type of application or market. One of our customer connects intelligent drives from Baldor with IPCs working with QNX6 and the fieldbus Ethernet PowerLink. This hardware configuration is used for automated car park systems.

Best Regards,
Armin Steinhoff
 
> [clip]
> 3) on a PC: i.e. implement everything with a PC and linux compatible hardware. This was our original plan, but we got stuck at some point because we had trouble reading out the counter cards for the encoders (buffered reading was not well supported for our card by the official driver nor by the comedi driver). Other people have managed to get it to work by using a very old driver for 2.4 kernels and modifying it, but it's exactly this kind of stuff we want to avoid. <
-------------------------------------------------

PROFIBUS and other fieldbus systems are also available for LINUX.

IMHO
... your application has a lot of distributes I/Os which are at best
handled by a fieldbus I/O system.

Best Regards,
Armin Steinhoff
 
Hi,

we are using LabVIEW too. Solar telescope, and "Pinocchio". Wi/Fi, Wi/Fi cameras, 3d motion control, industrial PC, the Lintel or Wintel platforms, remote control. PLC and SCADA are too obsolete technology and expensive solution for the task.

BTW, welcome to ACIT-ICT 2010: www.iasted.org/conferences/cfp-691.html.

I am sure the guys will take a part in the conference. See no problem to integrate any C-code in the program.

TA> Other observatories I know of use VME boards, software on Linux as
TA> described above, and a few recent ones use LabVIEW. But I'll try
TA> to find out more information.

--
Best regards,
Vladimir E. Zyubin
 
I think I see now how you ended up with a Transputer based solution on the old control system. What you are trying to do doesn't match a typical industrial application.

What I see as being the difficult point is averaging the 4 scales together for each axis. I haven't tried such a thing before with a servo system, and I don't know of one that does that (although I've never looked either). On a typical industrial system the relationship between the encoder input and the axis being controlled is fixed in firmware (and hardware). You can control things like scale factors, gains, and set points, but you don't get arbitrary control over all of the hardware. It is possible that something like a PMAC might let you do that, but someone who is more familiar with it would have to answer that question.

The big problems that I would see trying to do this with a PLC would be speed and latency. The backplanes are an I/O bottleneck on many PLCs, and the situation is worse for multi-axis servos because the data is often multiplexed over multiple scan cycles. Then you would have to do your calculations, which is something that PLCs are not very good at (they can be quite slow doing floating point math). I mentioned speed *and* latency, because there is the additional problem that readings from different cards will arrive out of phase with each other which can make coordinating actions difficult.

I have had to deal with these issues in PLCs even with normal industrial processes, and the PLC manufacturer typically can't even give you a good guess as to what sort of speeds you can expect. To get good coordination between motion control and digital I/O or analogue readings you typically have to use one of the more sophisticated servo systems where the controller is build directly into the drive (or at least very closely coupled with it).

I won't comment on the Labview solution because I haven't studied it in enough detail to know if it will work. As I've said before, my experience with Labview has been that if what you want to do fits with the way that Labview works, then it can be a nice system to develop (although long term support can be a bit of a pain). However, once you step even a little beyond the way that Labview was meant to work, you are in for a great deal of pain in getting it to do what you need. It's enough of a problem that Labview wouldn't be my first choice for things like automated production line test systems. So, what I can say about Labview is you would need to make sure that you have worked out all the details about how you are going to use it before making a commitment.

For the Delta Tau PMAC, I would suggest talking to Delta Tau and working out *exactly* how you would use it before making a commitment on that either. Don't rely on the salesman telling you "oh yes, we can do anything". Just like with Labview you would need to pretty much engineer a complete solution before concluding that it would work.

For the PC solution, I *think* (although I don't know as much about the problem as you do) that buffering the readings is the opposite of what you would want to do. I would think that what you would want to do is to run a time based cycle where you would get the most current servo readings directly from the input cards, update your position calculations, and then output the result. I *think* that for these types of readings you want to operate as close to the hardware as possible because you don't want latencies (delays between the readings and the reactions).

If you were looking at one of those nice National Instruments counter cards with a million features, well that's exactly the sort of thing that I would be trying to stay away from unless there was absolutely nothing else that would do the job.

I bought some very nice NI boards a while ago for a project that were perfect for the application. However, NI didn't update their Windows drivers, and they later dropped the product and there was nothing comparable to replace them available from them or from anyone else. Replacing the boards would have meant completely rewriting the software (because so many assumptions about the board were woven throughout the program). Oh and their drivers and libraries had some very interesting bugs (although they were quite good about fixing problems when I reported them).

One sort of solution that you might look at is a PC/104 system with either real-time Linux or QNX. That is probably the closest off the shelf thing to your existing Transputer system. Alternative hardware could be a mini-itx board, but the expansion options for those are limited (typically only 1 slot).

At one time there were lots of servo and stepper control boards that you could plug into PCs. Those seem to be a lot less common these days. What appears to have happened is that a lot of drives now have controllers built into them so the PC just has to send a set point target to the drive (via Ethernet) and the drive takes care of the rest. The stand alone controller/drives are more convenient for typical industrial applications, but it makes things a bit more difficult for unusual jobs.
 
W

William Sturm

I think the PMAC could work really well here, it is extremely flexible. A brief description might be in order. It is a motion computer, not an I/O card. It has inputs and outputs specifically for motion systems, encoder, analog, pwm... All of the I/O is memory mapped and you can set up a very sophisticated system once you understand how the system is configured. There are pointers to everything. I believe that you could easily average multiple encoders, for instance. It has built in routines for motion, such as jogging, position capture, multi-axis interpolation, translation and scaling, feed rate override...or you could write your own. You then write motion programs that execute in hard real time. You can have numerous coordinate systems and they can all run a motion program simultaneously. It also has numerous background PLC style program buffers for handling digital and analog I/O.

There are other system that could work also, such as Galil, Aerotech, Trio, or Baldor, they all sell real time multi-tasking motion computers. Based on your needs, you should probably be looking at motion controllers with built in real time programming capability. Other possible options are CTC and Giddings & Lewis, they are closer to a PLC but still have good motion capabilities. I'm sure there are others that I am missing. You want to pick a vendor with good tech support, as you will need some coaching with any of these systems.

A realtime network of positioning drives might be able to work, but you will need at least a soft RTOS to coordinate them. I agree that a PLC solution would probably be too slow and limiting, although a PAC system like an A-B ControlLogix could possibly work.

Please keep us posted with your findings...

Bill Sturm
 
Hi,

thanks once again everyone for the very valuable information!

> The big problems that I would see trying to do this with a PLC would be speed and latency. <

Indeed! We would need counter cards which store their value at a trigger, so all counters can be read buffered afterward. National Instruments has such cards (e.g. NI 6602) but I have no experience with PLC equivalents.

About the PLC performance (also Bills concern), I was guessing that it shouldn't be that critical, considering the system is currently controlled by transputers? The current position loop is running at 50 Hz.

> (...)
> For the Delta Tau PMAC, I would suggest talking to Delta Tau and working out *exactly* how you would use it before making a commitment on that either. Don't rely on the salesman telling you "oh yes, we can do anything". Just like with Labview you would need to pretty much engineer a complete solution before concluding that it would work. <

Absolutely!

> (...)
> If you were looking at one of those nice National Instruments counter cards with a million features, well that's exactly the sort of thing that I would be trying to stay away from unless there was absolutely nothing else that would do the job. <

Hmm I will look for alternatives but I'm a bit surprised, because the general NI-DAQmx LabVIEW driver seems like such a nice and well maintained piece of software (and I've heard lots of positive comments about it, also regarding future compability).

> (...)

Thanks again everyone (of course also Armin, Bill, Curt, ...) for all the efforts, it's really helping us!
 
The difference between the Transputer system and a PLC is that the Transputer system will have been designed for that specific task while the PLC is a general purpose device that carries a lot of extra baggage. A dedicated microprocessor wouldn't have to be exceptionally fast to do that job (not considering the atmospheric calculations), so long as it had direct hardware access and that is *all* it had to do.

A PLC offers you a very nice set of features for controlling *typical* industrial machinery. However, you have very little control over what additional tasks the PLC does and when it does them. Meanwhile, the Transputer board does exactly what you ask it to, when you ask it to, and nothing else.
 
Top