Labview for Control

Anybody use it? Do you need special hardware for real-time control?
Tam

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Real time control is relative concept. My world real time is less than a cycle. Computers running WINDOZE work in seconds or 10's of seconds depending on what your doing and how it is routed.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
SQLit wrote:

Real-time control is not a relative concept. Real-time is real-time.

If you describe it that way, then yes it becomes relative, because we don't know what kind of cycle you're talking about. A wash cycle? A lunar cycle? A bicycle? Sorry, that wasn't very funny....

As far as I know, Windows XP time slicing occurs at something like 10ms intervals.
Strictly speaking, anything running on Windows cannot be considered real-time because there is no guarantee of when processes will be scheduled. Although, for many applications, a desktop PC running Windows is going to be way faster than necessary, so you could count on it with a reasonable degree of confidence to get something done within a set amount of time.
Anyway, to address the original poster's questions:
Yes, I use LabVIEW for real-time control.
Essentially, National Instruments offers three products for R/T applications. There is a PCI card you can get that has a real-time computer on it (I didn't have much success with this product). There is the ruggedized PXI hardware, which might be more than you're looking for. And then there is the LabVIEW R/T ETS for desktop operating system that you can install on a regular desktop PC (there are a few requirements, I think it has to be a Pentium 4 and have a specific kind of NIC, maybe a couple other things). This is what I've been using for my application, and it works quite well.
As for special hardware, it depends on the requirements of your project. I'm using an FPGA card in the R/T computer for doing I/O.
Hopefully that helps.
--
Colby


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Colby wrote:

having seen the NI guys at my place of work during theweek I was interested in the CompactRIO systems that they are now producing. The whole aim of this product is to remove the "Real Time" requirements from the software running on the PC and move it into specialised hardware able to cope with and meet the scheduling demands of the application. With a programmable FPGA on-board the unit as well there is a lot of scope for tailoring the device to ones needs. The only thing that let's the product down is that you will still need additional signal conditioning hardware as the units are not robust enough in some of the application areas we have in mind for them. The main reason I stick with bespoke embedded systems I suppose.
--
********************************************************************
Paul E. Bennett ....................<email:// snipped-for-privacy@amleth.demon.co.uk>
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Paul E. Bennett wrote:
How did you make out with the recalcitrant stepper?
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Colby wrote:

That's not entirely true. I've designed a real-time control systems on Windows XP with no problem. You simply have to make the control loop (or whichever loop in your application needs to be realtime) the highest priority in the application, and then run the executable with a windows priority of "real time". This will force EVERYTHING running on Windows to take a back-seat to your application.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Loban wrote:

So, does that hold for sub-millisecond events requiring context switching latency in the few usec region? I think not. There are some control problems that can only be solved by carefuly designed embedded hardware solutions specific to the task. The Windowy environments for user interfaces in such systems only adjust the control parameters and do not take part in the inner control loop.
--
********************************************************************
Paul E. Bennett ....................<email:// snipped-for-privacy@amleth.demon.co.uk>
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

This is only true if you are writing in kernel mode. For user mode programming, this doesn't hold. Even if you assign a user-mode process & thread REALTIME priority, if you move the mouse or press a key, or write to the disk, these hardware devices still take priority.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.