COsiecki

Some things I noticed: 1. The only flow control on that loop is waiting for the read. You could use an event structure and a DAQmx event to potentially improve your response. A good one to use is EveryNSamplesAcqIntoBuffer. 2. You are doing some unknown amount of processing in that state. You might try using a producer/consumer architecture so that the processing and database access don't potentially slow your loop down. 3. What is that DataQ and what is putting data in there? That state won't run if the queue is empty. 4. You have the task set up for 100 samples per channel, yet your read is for 1 sample per channel. Try checking some of those things. If you narrow down the delay to the actual DAQ read, then I think a call to NI would be a good bet. There are cases where the hardware acts weird, but you have to eliminate the software first.

I don't know how your program is set up, but I would use a DAQ event for timing and then read the mouse position when the event fires. See my attached VI. Read Mouse.vi

You can either create the mesh manually by using Create Mesh.vi and then adding the array of 3D coordinates using a property node. The other option is to use something like this: http://decibel.ni.co...t/docs/DOC-5242 I like the second option for complex things, though it can take a bit of getting used to for scaling and position. All of the tools are free, which is nice.

I have a similar project, and I wanted to have it run faster as well. I don't know if it will work for your system, but the system we have lets you create movement programs that you can run without having to send individual commands. To deal with the timing issue, I just run the data acquisition continuously and watch for "flat" spots in my data, since that corresponds to where the motor pauses between moves. I can put very small delays in between my moves and pull that out of the data. It still takes a while to copy the programs to the controller, but once its sent, I can rerun it as many times as I want. This may help speed things up. If your particular task doesn't have data that would easily let you determine where the motor stopped, you could use the status bytes from the motor controllers to read when they change state from moving to stopped. If you aren't having to send individual commands, polling status should be fairly quick. Some controllers even have digital outputs that indicate when the motor is moving. You could use this as a trigger for your acquisition.

I am trying to map hardware that is currently in use. Is there a daqMX property that will let you know if the device or physical channel is reserved? I know that if you try to run two tasks on the same hardware you get error 50103 and you could capture that, but I'd like to not need to create and run a task on every channel in my system. Another option would be to assume that nothing else is running (probably a fair assumption on our systems) and then flag them as "in use" in my software. Has anyone come up with any other methods for this type of thing if there isn't something in daqMX?

I use DAQmx quite a lot in my day to day work. The only way you can get to the 16bit data from the acquisition device is to use the Analog>Unscaled option on the DAQmx Read vi. When you read the waveform datatype, the unscaled data it converted to DBL values by the DAQmx driver using a polynomial evaluation. You can get the polynomial coefficients for converting to voltage from the driver by using a DAQmx Property Node: DAQmx Channel>>AI.DevScalingCoeff. What you would want to do then, is to set up your read as unscaled, use the unscaled data for your TDMS file, and convert to volts, or whatever scaling at that point. Stay away from the Raw read options. The Unscaled will still return your data in a 2D array of [channels x samples]. Raw returns a 1D array that you have to parse manually. One other note: don't assume the nominal voltage ranges on your device are acceptable for rescaling. Just because you have a 16bit ADC with +-10V range, it doesn't mean you can use 20 / 2^16 as your dV. The actual output from the device probably goes from -10.214 to + 10.173. This will make your data very messy. Always use the device scaling coefficients from the driver. I use a polynomial composition to combine my unscaled to voltage conversion and my voltage to engineering units conversion. This reduces my CPU load quite a bit. If you are using a custom scale in MAX, I don't know how that works, so you may not see a difference. Another thing I do it build my tasks programatically from config files (you could use xml). I have found that for situations where people are changing acquisition settings frequently, MAX can be a pain. Also, you can't (as far as I know) dynamically retarget a MAX task to new hardware so that you can run multiple instances of it. Another good thing about not using MAX is that you can control what configuration settings your users do and don't have access to. You don't have to give them AC/DC coupling options if they are only reading DC levels, for example. One nice thing about MAX is, well, um, oh, it already has custom scaling options. Though they can be a little cumbersome. I usually avoid MAX as much as I can since its portability is practically nonexistent and the interface is straight out of the early 90s.

That was fun to watch and listen to! Thanks for sharing