10-13-2008 03:51 AM
Here is my test vi.
I used the hardware timed counter from DEV1/CTR1 to control a timed loop.
Inside the timed loop, I use a Digital 1D Bool and a True/False case statement to write the data.
The fastest I can seem to go is 5000Hz. Anything above this and I start to lose counts.
I put the Channel Creation outside the loop so all the function inside the loop needs to do is write True or False to a Line -> should be very fast.
Is this the best performance labview can do in software or am I doing something wrong? Is this a problem with my computer, my DAQ card or Labview?
If I wrote this using calls directly to the NIDAQ Api, will I see much improved performance?
It seems to process 5000events/second max is pretty bad...
10-13-2008 03:52 AM
Sorry forgot to attach the VI.
How do I get an image out of labview so it'd be easier for people to see it without downloading?
10-13-2008 05:07 AM - edited 10-13-2008 05:09 AM
Here's an improvement of your Modulo 2 calculation, it should be way faster:

But you will never get to 80 MHz with this approach, I advice sending trains of boolean lines:

Here you write every 10000 ticks 10000 samples to thedigital output.
Ton
henry99 wrote:How do I get an image out of labview so it'd be easier for people to see it without downloading?
Havea look at the 'Code Capture Tool:To create images of a part of code you could use the code Capture Tool it is great for this purpose, you select the part you want to capture, start the tool (Tools->Code Capture Tool), review your setting (FP-none, BD-selected, Clipboard-FileName), finish the capture.
Then you switch over to your internet browser, in the file dialog you past the file name from the clipboard and the file is attached.
To download
10-13-2008 06:29 AM
10-13-2008 11:51 AM
I will try it with the AND and see if I can get it up faster.
I only need 1-10MHz output.
Do you think that is acheivable?
I don't think the modulus function should be a big deal. I'm running a quad core 3 ghz machine so it should only take 1 or 2 clock cycles which is 1000x faster than 1 mhz. Writing to a port should be done in 1 clock cycle.
I think my problem might be the indicator display as it takes time to write the windows display so will delete that and try to locate a scope to figure out how fast I'm outputing...
Thanks for all the help. Any other suggestions besides buffered writes to speed it up?
10-13-2008 01:01 PM
Hi Henry,
LabView isn't C or handcrafted Assembler... So I doubt a port write will be just one cycle: you're using VISA, so LV has to translate VISA address to "port address", has to call drivers, and so on. And you try to call these steps 10million times a second...
And even the Q&R will be slower than 1 clock cycle in LV...
Why don't you try buffered writes? That's the way to go!
10-13-2008 03:26 PM
Buffered writes would work for controlling the stepper in this application but I'm thinking sometime later I'm going to need to 1) read in input 2) do some processing 3) output to ports so I can't build up a buffer of data if it is changing every 1-10us.
Doing a PID loop for example to control a stepper motor...
10-13-2008 04:33 PM - edited 10-13-2008 04:33 PM
I remember a NI presentation comparing achievable PID loop rates, depending on the hardware/software used. (Plain LabVIEW, LabVIEW RT, LabVIEW FPGA, etc.).
Unfortunately, I cannot find a reference, but I think a 1us loop time is not realistic except for FPGA.
Look at the paragraph from here:
One of the first options to improve the performance of your PID controllers is to increase the loop rate at which they perform. This is now possible thanks to advances in computer technology. With current technology, you can run PID loops up to 20 kHz using NI Compact FieldPoint controllers, 40 kHz with NI PXI technology, and up to 1 MHz with NI CompactRIO hardware when using PID functions based on field-programmable gate arrays (FPGAs). You can find an FPGA-ready version of the NI LabVIEW PID Control Toolkit in the LabVIEW Real-Time Module.
Sorry, I don't know what the newest numbers are. 😉
10-13-2008 05:08 PM
I think I can live with 40khz loop. However it seems my max is around 5khz with my current program. After I delete the screen indictator, hopefully it will go up. Is there a way to figure out how many counts I am outputting?
I was thinking of creating the timed loop on CTR0 and hooking it back into CTR1 and reading the pulse width but maybe it's easier (like inspection of a watch variable?).
10-14-2008 10:36 AM
The timed loop has a node, 'Finished late' if this booelan goes true you know you are too late, remember the while loop doesn't control the counter, it is the other way around.
Optimizing your code can give you great performance, what is the algorithm you need.
Remember you still work on Windows so you might get jither on the loop performance although the timed limed has a quite high priority.
Ton