Hi, please feel free to respond as if talking to a 5 year old, for such is my experience with this kind of thing to date.

I am developing a small system which will be using a pc as the controller. However, the pc will have to "read" and display an incoming analogue voltage (0-10V) and an incoming pressure signal (the feedback from the device being controlled by the analogue signal). In addition, I also need to operate a couple of rotary valves (On/Off only, so digital I/O is good). Am I correct in thinking that a pc with an additional PCI card (http://www.eurotech-ltd.co.uk/en/products.aspx?pg=APCI-ADADIO&pid=10147) and running Windows XP Pro embedded will be somewhere near what I need? I am looking for some hardware advice here, and I'd rather deal with a company with a UK branch if possible.

Notes;
I'm not sure if I need real-time capability or not.
I will be controlling either a proportional valve or a servo motor. If it is a servo-motor then I will be using a proprietry servo control card and my pc will simply tell it what to do or interrogate it via RS485 or RS232 (what's the difference?)
I need to have a decent display resolution, no blocky graphics.
This is a one-off system for development and R&D purposes at the moment, but hopefully it will lead to approx 50 a year being built.
Touch screens are not an option as it is a very dirty environment (physically, not electronically), I must use a mouse and/or keyboard.
It is likely in future I will have to link in to a bus system such as profibus or interbus-S.

I'm happy to put more details up if anyone can help, but I'm trying not to make this introductory posting too tedious. Many thanks in advance for your help.

Gordon

 

You need to define what sampling rate you need for the analogue signal. That is, will you will be taking individual readings and then acting on them or will you be reading at high speed in hardware and then doing signal processing on large buffers of data?

If it's just single sample, then I would suggest looking at some Ethernet connected industrial I/O instead of a PCI card.

It's hard to give good advice on the servo without knowing a lot of detail about the application. However, I would suggest looking at using a stand alone servo controller (controller and drive amplifier in one box) that can be controlled via Ethernet from the PC. That is, the PC would tell the servo controller where to move to next, and the servo controller would move and let the PC know when it got there.

I would suggest staying away from PCI cards unless you really need the performance. Network connected I/O is easier to install and service and is good enough for a lot of applications. Ethernet is probably also a better bet for hardware compatibility over the long run. Plug-in boards are for when you are dealing with large volumes of data at high speed.

I would also suggest avoiding RS-232 or RS-485 if you have an Ethernet option available. Both technologies are clearly on their way out, and Ethernet is usually a lot easier to deal with.

For an Ethernet control protocol, I would suggest using Modbus/TCP. It is one of the very few open industrial protocols and there is lots of hardware available for it from a large number of vendors. Most of the other industrial protocols are proprietary to one vendor (or to one large vendor and a "club" of smaller associated licensees).

As for your choice of MS Windows XP for an OS, I think you will find that it will be difficult or impossible to get by the end of the year (it is already very difficult to find). If you are fixed on using an OS from Microsoft's product line up, then you should be looking at MS Vista. When MS Windows 7 comes out at the end of this year, MS is expected kill off the "XP downgrade" option. MS Windows 7 is basically MS Windows Vista with a few minor changes, so those are your product options from Microsoft.

If you want to consider other software alternatives, then some sort of Linux distro is your best bet. Debian or Ubuntu would probably be good choices.

 

I would have to agree with Michael on this. The programming for a PCI solution will make you dependent on drivers and possibly firmware that are dependent on a particular Windows version and you will have all sorts of issues starting on XP as it is a dead product. These are considerations that folks consistently ignore up front, to their peril down the road. An external servo controller would be much safer as you could conceivably talk to it with pretty much anything if you need to change. VB is becoming a liability for much the same
reasons.

There is a middle ground though, The EMC project (now LinuxCNC or something like that) supports a few servo cards that would get you the servo control with OSS drivers that will not become obsolete. At least one of the cards also offers analog and digital I/O for an all in one solution. If you are at all familiar with Linux programming this could be a much cheaper option for say, 50 units a year than an external controller. If you are not, then the external controller is probably your safest bet. And this is from someone who has used the cards and is an unabashed advocate of roll your own.

With the murky future and overall (un)desirability of Windows versions going forward for this sort of work, I would strongly consider Linux even if you intend to use an external controller. The Vista model will make programming close to the machine really interesting.

You wanted advice:^)

Regards
cww

 

Sounds absolutely perfect for a small PLC. for little more than the cost of PC interface cards you could buy a PLC. As for touch screens, the industrial models are much more robust than a standard keyboard and mouse. Connection to a servo would be via a serial or Ethernet port. Connection to external field-bus like PROFIBUS or PROFINET would be trivial with a PLC. As for using windows, it is still not intended for critical applications, (read the licence agreement).
You could use a pc connected to the PLC to gather data into a spreadsheet while you test your prototype, at a push you could use SCADA on your pc, but let a PLC do the dirty work, it's what they were invented for!

Marc Sinclair
http://www.germainesystems.eu

 

I'm amazed by how quickly you get to the same point that it has taken me weeks to reach already. I plan to use a servo controller and amplifier from a proprietary brand, but wasn't sure how to link it best to my control pc. What I want to do is display the movement of the servo motor on a graph in something close to real time, at the same time showing the incoming analogue signal in comparison.


>Ethernet is probably also a better bet for hardware compatibility over the long run. Plug-in boards are for when you are dealing with large volumes of data at high speed.

I'll definitely take that on board, thank you. Network I/O seems straightforward enough, I think. That would then talk to the pc via the Ethernet, I guess?

>I would also suggest avoiding RS-232 or RS-485 if you have an Ethernet option available. Both technologies are clearly on their way out, and Ethernet is usually a lot easier to deal with.

Ok, thanks.

>For an Ethernet control protocol, I would suggest using Modbus/TCP. It is one of the very few open industrial protocols and there is lots of hardware available for it from a large number of vendors. Most of the other industrial protocols are proprietary to one vendor (or to one large vendor and a "club" of smaller associated licensees).

I'm starting to see exactly that with Profibus and Interbus-S. You really do know your stuff, huh?

>If you want to consider other software alternatives, then some sort of Linux distro is your best bet. Debian or Ubuntu would probably be good choices.

I think I am starting to get to the limits of my abilities here, my only programming experience was with an Object Oriented training language a couple of years ago, so I think I may need to buy in some advice. Thanks again for your help with this, it's incredible how well you've been able to sum up the application from so little information. I may be back for more another time, but this has given me plenty to work on. Just have to go and find a good manufacturer of ditributed I/O stuff now.

Gordon

 

>An external servo controller would be much safer as you could conceivably talk to it with pretty much anything if you need to change. VB is becoming a liability for much the same reasons.

This is really the sort of advice I was looking for, thank you. I am designing an OEM system which I will want to offer (with various sub-options) for the next 5-7 years, so I absolutely don't want to start with something which will be outdated in a year.

>There is a middle ground though, The EMC project (now LinuxCNC or something like that) supports a few servo cards that would get you the servo control with OSS drivers that will not become obsolete.

(What does OSS stand for?)

I am going to plump for a good servo driver and amp from a good manufacturer, then I don't have to try to reinvent the wheel. Trust me when I say that my app is fairly simple but I am quite capable of messing it up with bad software, so I want to use good components where possible to minimise my bad influence. However, does that mean I can use LinuxCNC to talk to and display feedback from something like a Yaskawa servo card?

>With the murky future and overall (un)desirability of Windows versions going forward for this sort of work, I would strongly consider Linux even if you intend to use an external controller. The Vista model will make programming close to the machine really interesting.

Why does interesting sound like a euphemism for "dangerous, and a whole world of pain and problems..."?

>You wanted advice:^)

Yes, and I really appreciate you taking the time to offer it, thank you. This is invaluable, because even if I don't do the job myself then at least I can have some idea of what I'm looking for in a programmer, and what he should be capable of.

I may be back for more help, you have been warned. Thanks again to you both.

 

I think Marc has hit this nail on the head. With a PLC you get IO, servo, and HMI/SCADA support (And most have communications libraries if you want to write your own HMI/Datalogging code). You do your critical stuff in PLC and use your HMI or PC for display and data logging.

I would just add that you could use a Mitsubishi FX or Siemens brick PLC (Maybe Automation Direct and/or OMRON has some too...) PLC that has motion control (via pulse and direction) built in. IT would be more than adequate for a medium performance servo application to go this route.

Depending on what you are trying to display, and log, a commercial HMI panel could display the data and do minimal logging. Beyond that I would pick the PLC depending on its communication support, motion step control ease of setup, communication options, and of course your other project parameters.

Just about Any Servo system (Amp and Motor) will plug into pulse and direction interface, Yaskawa being a good safe choice.

KEJR

 

Hi Gordon

>(What does OSS stand for?)

Open Source Software. If you aren't acquainted with this, it's often like having someone code a working example and give you the source code. And often they are available and willing to help with the sticky bits. Since you have the source code, they can never be obsoleted and leave you in the lurch or force you to move to a different version. Your work is safe and the OSS can be maintained indefinitely and modified if you need something a bit different. In short, OSS solves a lot of the problems with doing automation work on platforms someone else controls, which is why big automation has been studiously avoiding it.

> However, does that mean I can use LinuxCNC to talk to and display feedback from something like a Yaskawa servo card?

That would probably be gross overkill. But LinuxCNC would show you how to talk to the card and you could use something like Glade and Python to do fairly rapid development on your display functions. All of this is free with no royalties, so your cost per unit goes down rapidly as you amortize your development time. And you don't have the insane treadmill of keeping up with MS planned obsolescence. And you can strip the thing down to a headless low power module at your servo and displays at as many locations as you want for the hardware cost. And you can make your system boot up as your system and that's all it does, or you can pop it up as window in a fully featured GP desktop system. I've done this and it's much easier to maintain and support than running as just another app on Windows.

>Why does interesting sound like a euphemism for "dangerous, and a whole world of pain and problems..."?

MS has gotten extremely paranoid about low level programs lately, with good reason. And most of the new geewhiz stuff goes in the wrong direction as far as supporting industrial control. This is a strong trend and they want to own or control everything. Linux lets YOU control and own everything, and you can limit risk and mischief by simply removing everything you don't need. This makes it extremely secure and much faster in the bargain. So why doesn't automation flock to Linux? Big automation would lose their biggest moneymaker, Lock-in. And on the user side, most people want to simply run other people's software. If you are in the middle the opportunities are boundless.

Regards

cww

 

In my previous reply, I presented two different scenarios. Be sure that you consider both of them.

Scenario #1: You only need single data samples at a rate of 10 samples per second or less. External Ethernet connected IO is a good choice.

Scenario #2: You need large buffers of data at a rate in the kilohertz or faster. You need a data acquisition board.

In your most recent post you made oblique reference to a very critical point which you didn't mention earlier. You said you wanted to measure what appears to be displacement versus force ("the movement of the servo motor on a graph in something close to real time, at the same time showing the incoming analogue signal in comparison").

If this is a pressing or upset application, then you are probably dealing with sample rates in the kilohertz. You will want a data acquisition board for this.

You may also want to have an analogue displacement sensor instead of using the servo feedback encoder for position. This provides you with two things. One is that you can eliminate mechanical wind up from the reading (the mechanical parts of the drive system will be like a spring, so the real position will lad the encoder reading). The other is that you can use the data acquisition board to sample both signals together at the same time and at the same rate. Data acquisition boards do this directly in hardware because people need to do this in high speed applications.

Draw a sketch of what you think each of your signals will look like. Put time along the x axis and voltage on the y axis. Mark out points for where each reading would be to have a good signal. Now put some time numbers on the x axis. That will give you a good idea of how fast you need to collect readings. That in turn will tell you what sort of hardware solution you need.

If you are going to talk to someone about the software, then I suggest that you talk to them about the hardware as well (and if he doesn't know both then you are talking to the wrong guy).

The first thing you need to do though is to characterise your process. You may not know exactly what you will see, but draw some graphs for what you *expect* to see. Then do a few calculations on how fast the data is coming in and how much lag you can tolerate between the signals.

No doubt you have a wonderful idea for a machine and don't want to tell us what it is. However, unless you can either describe the application or give some detailed specs for the system, you are not going to get a good answer for how to do it. The best you will get is "if you want to do x, then you need y, if you want to do a, then you need b".

With what you've told us so far, I can't tell what you really need. I can just point out a few things to look into, and the pros and cons of each.

As for the software, think very hard where you want to be with this system 10 years from now and where the software you are basing this on is going to be in that time. If the answer is that you are going to be stuck with whatever Microsoft (or National Instruments, or whoever) wants to give you, then you have to think about whether that is an acceptable answer. There's always alternatives if you're willing to consider them. If you are planning on selling 50 systems a year, you can't afford to keep redesigning the system every time some marketing wiz at a software company gets a new brainstorm. Try to stick with something where you have control over what goes into the system and what the pace of change is.