timing on Labview with Linux vs. Windows

[Andy_something-or-other]

Hello,

I am looking at purchasing a copy of Labview, but I want to be able to use the parallel port with repeatable timing (on the order of ~+/- 10usec, e.g. 50Khz) .

I have ran into problems using Windows for timing on older versions (7.0), and have been told this is a windows problem that still exists on 8.6-- is timing with a Linux version more repeatable?  

Thanks in advance!

[Dennis_Knutson]

Neither windows or linux is a real time and deterministic OS. For that sort of timing accuracy, you would need to move to LabVIEW RT.

I don't know what sort of operations you want to do with the parallel port but since it is essentially digital I/O, you can get a DAQ board with much better timing and use that instead of switching LabVIEW versions and the os.

Message Edited by Dennis Knutson on 06-05-2009 02:22 PM

[Andy_something-or-other]

Okay, thanks for the response!

I guess the reason I struggle with this concept is that I run my CNC mill from a windows based application [mach3] written in VB; I can get repeatable signals to 100Khz. It is hard for me to justify spending $400-600 (on top of the $2-5K software license) on external hardware every time I want to obtain repeatable timing for a project. I mentioned the parallel port simply because that is a cost effective way to obtain TTL signals.

[rolfk]

---

Andy_something-or-other wrote:
Okay, thanks for the response!

I guess the reason I struggle with this concept is that I run my CNC mill from a windows based application [mach3] written in VB; I can get repeatable signals to 100Khz. It is hard for me to justify spending $400-600 (on top of the $2-5K software license) on external hardware every time I want to obtain repeatable timing for a project. I mentioned the parallel port simply because that is a cost effective way to obtain TTL signals.

---

Well the software license is only once necessary since you hardly will let the application run in the development environment at the customer site (unless you like customers to call you for support since they did something stupid in the development environment because they thought to be smart).

Stable software controlled timing under Windows in the range of <100ms is basically impossible without resorting to some kernel driver solution which last I was looking was certainly not the area you could work in VB.

Your Windows process can be preempted at any time for long periods of time by the OS to let execute other processes or handle driver requests such as network packet arrival etc. Those periods can easily be in the range of 10 to 100 ms. A user process has no way to prevent that, you can just give your application a higher foreground priority to tell Windows that you would like it to minimize those preemptive interrupts.

What you probably do in your VB application is controlling theparallel port with register access. This is possible in LabVIEW too. it can be fast too in the range of a few us per call but as I just explained there is no way you can guarantee that your pulse trains generated in such a way may not at some point pause for 10ths of ms and that is true for VB just as much as for LabVIEW.

Rolf Kalbermatter

 

[Andy_something-or-other]

Thank you agains again for the replies!

It would probably help to clarify my application;

I build commonly build automated test fixtures.   Labview could greatly expedite this process (rather than programming an mcu in "C").  However, the cost builds up quickly for additional hardware-- I mentioned the software cost simply because even though it is a one time thing, it is still a significant investment that makes it even harder to say, "oh yeah, and we will also need an M-xxx DAQ device for $600"... for [i]every[/i] new fixture.

The computers I am putting the applications on are always decommisioned PCs-- meaning I can strip ALL unneccassry software (which in fairness is what I have to do to run Mach3 for my CNC mill).

I am not a VB programmer, but from what I have gathered, is you do have to go into kernel development to make this work-- basically windows only gives 'timing rights' to drivers, so in effect you have to write a driver for the external application.  But this is why I was referring to Linux, because I know you do [i]not[/i] have to go into substantial work arounds to build a simple stepper motor controll [for a timing example].   I am not worried about other applications 'taking over' because  I will remove any & all applications from working computer.

How does "Register Access" function?  E.g., can you only send signal bursts, or can you send dynamic streams of data?

I think I will just download a demo version of Labview for Linux, and see how it compares;  are there any significant differences between Labview on Windows and Linux that I should be aware of?

Thanks again!!

[rolfk]

Not sure I can give you more information about the other topics but about the parallel port you have bascially two possibilities under Windows to access it.

The first is through the COMM API (or VISA if you use LabVIEW) since the parallel port is considered a serial port (byte serial) under Windows. This is very limited in what you can do, basically you can only send out 8 bit data streams but that is not very high speed and definitely not in a strict timing.

The other one is programming the registers of the parallel port directly. For every pattern on the port you write a value directly in the hardware register, possibly interchanged with writes to and reads from other registers to handle handshaking or other requirements of the port handling. This is all happening under software control and therefore highly undeterministic in its timing although possibly faster than what the COMM API can stream data out.

Not sure if you have any experience with kernel driver development but in old days the only way to do that was to use (partly) assembly language. For newer Windows versions such as from Windows 2000 on it is possible to do that without assembly in C alone but it is very involved, difficult and nasty to program, debug and maintain.

Rolf Kalbermatter

[Smootastic]

Hi Andy,

Here's a pretty useful link for using the Parallel Port in LabVIEW.  It describes to get register-level access for your application.