Hi vietwave,
Welcome to the NI discussion
forums. I have two suggestions.
First suggestion:
The first is that you have both the
read and the write in the same while loop. Because your digital write is executing
in a stacked sequence structure, for each loop iteration your program is going
to write two values and read only one value of the digital input. You can run
your program with Highlight Execution to see this behavior. You can put the digital read in a separate
while loop. This will allow the read to
truly execute in parallel.
Second suggestion:
Because this application relies on
software timing, Windows is controlling the execution order of each process.
For example, if your Anti-virus or other program comes on while you are running
your VI, there is no guarantee when Windows will let each program run. You will never get a really accurate 50 ms
digital pulse using software timing. For
some applications, the accuracy from software timing is good enough. You may be
able to get something that is accurate enough for your needs.
A similar issue may be that LabVIEW
creates a separate thread for the user interface and the code running on the
block diagram and I believe assigns a lower priority to the user
interface. When running really fast loop
rates LabVIEW will give more priority to executing your code then updating the
buttons on the front panel.
I have attached a simple example
program (a modification of yours) written in LabVIEW 8.0. To make sure it was
working correctly, I ran the VI using a 1 second timing and could clearly see
that the input was reading the output correctly on the front panel.
Jared T.
