LabVIEW
Control LPT using Labview
Hi abhi,
your VI refuses to obey any LabVIEW standard or style guide...
- You use too much local variables and sequences.
- You use wrong datatypes.
- You use functions in wrong places...
See cleaned up attachment (just cleaning up the locals and removing the sequence structure).
There still is a big bug in: In each iteration you close the VISA port, but you never open the port again!
You only need to open the port once before the loop and you only need to close the port once after the loop!
Then I think your VI will never run fast enough nor will the underlying hardware driver be fast enough to support sending data to the LPT port with 1000Hz or so. Atleast when trying to send single byte command. Also windows task scheduler will make your life much harder as it will steal away the CPU from your task sooner or later...
Hi abi,
The VISA writes again inside each loop doesnt it. This should again affect the timing right.
What do you mean by "doesn't it"?
And why do we need another VISA write outside the for loop ?
Well, it has been there before in your original VI too. You should know why it has been there...
Each VISA-Write sends out those 8bit data as a single byte.
The last VISA-Write sends out a zero, in your original VI you used a boolean array constant for this purpose.
Did you remove those silly VISA-Close in the loop?
Even if you control the parallel port direclty through Port IO functions will you be limited in speed. 1000 Hz on average should be possible, BUT there is no guarantee under Windows. When a Windows network driver or other kernel device driver decides it needs the CPU and/or memory bus to transfer a package of memory it gets that resource assigned and whatever user space application is running has to wait for whatever time the driver feels appropriate. This means that your application can get randomly suspended for several milliseconds without any chance to do a single CPU cycle.
With VISA there are several more layers of userspace drivers atop the kernel port IO driver and that makes it significantly slower. It probably is able to do 1000 single byte writes per second on a modern computer, but the timing will be way off from a regular 1ms interval. But even with direct Port IO VIs it won't be really a clean 1ms interval at all. Also direct Port IO is not available for Windows 64 Bit systems so if you run on that or plan to move to that in the future it's not an option.
Since your loop timing directly seems to control the motor speed, I'm afraid you will never be able to get the motor to operate at a constant speed under normal Windows. These kinds of things call for either a realtime operating system or dedicated hardware that takes care of the faster timing signals all on its own and only needs to be controlled by the computer through commands to change the parameters and start and stop the motor.
