DDK under CVI RT and changing pulse specs

[rjrowe]

Hi there,

Has anyone used the DDK under CVI RT? 

I am struggling to work out what to use, the only NI RT OS files I can find are for labview RT - is this the same as CVI RT?

Basically I have been trying to get a function to work using daqmx under CVI RT, for the PXI-6608 counter/timer module, but I don't think it is supported so turned to the register level programming manual and am sure that this can be easily implemented in the hardware.  I am using a counter to generate a retriggerable single pulse, which works fine, but I need to update the delay/width values between triggers every so often.  I don't have much time to do this.

I found that I could use a write function to change values when the counter is set up in continuous pulse train mode, and this only takes a few microseconds, however to update the settings for single pulse mode in daqmx seems to require stopping/starting the task, and takes in the order of 30 milliseconds!!

Looking at the RLP manual and 660x examples, it seems fairly straightforward to update the A and B registers (once I work out what all the other register settings need to be for the retriggerable trigger mode), and I really can't work out why this functionality isn't in daqmx (if only the source code was available!).  I don't think I even need to worry about using the shadowed A and B registers (i.e. the 'y' ones) as i'm not worried about timing glitches whilst it updates (presumably that is why they are there).

The only problem is I have no idea how to implement the PCI stuff (osibus) under CVI RT - is it just the Labview RT (which seems to be VISA based) osibus stuff or do I have to work out how to implement a custom one?  Does anyone have a bit more of a 'step-by-step' guide as to how to get this into my project?  Also, in using register level calls for this device, can you confirm that I can still use the daqmx library calls for all the other NI PXI devices in my rack?

Many, many thanks in advance,

Rob

[stilly32]

Hey Rob,

I can't help you on the DDK part, but before you give up on DAQmx have you tried the setting the pulse properties directly rather than using the write?

I'm thinking:

DAQmxErrChk (DAQmxSetChanAttribute (taskHandle, "", DAQmx_CO_Pulse_HighTime, hightime));
DAQmxErrChk (DAQmxSetChanAttribute (taskHandle, "", DAQmx_CO_Pulse_LowTime, lowtime));

to update the pulse specs. I haven't scoped out the signal yet on a 660x to see if it works the way I expect but I didn't get errors when I ran this on my M-series. 

Thanks, 

Andrew S

[rjrowe]

Hi Andrew,

I have tried that now (some of these channel attributes are nigh on impossible to find the correct identifier - I trawled the help before and couldn't find that).  Whereas it is marginally better than before (when I had to start and stop the task, it still takes 15ms to update - I know it can be done faster, as you can write the settings when in continuous mode in a matter of microseconds.  I can stop a PXI-5421 AWG task, download a 2048pt waveform and start it up again in a third of the time as writing these two 16-bit words to the 6608!

I took a look in the MHDDK download for Labview RT under the "Step 2: Download OS Specific Bus Interface Component" section, it gives the same link as for the windows OS.  I don't really know what to do with this then.  1: it seems to be the same as for windows, not sure if it works for ETS (CVI RT).  2.  It has c++ files, whereas CVI/RT uses ANSI C only.

Any ideas?

Ta

Rob

[Tom_W_[DE]]

Hi Rob-

The Windows-based MHDDK uses NI-VISA as its kernel driver.  According to the NI-VISA readme (current version as of March 2009 is NI-VISA 4.4.1), CVI RT is supported.  However, if CVI/RT is ANSI C only then you will need to backport some of the MHDDK material from C++.  You should be able to use the MHDDK material as a reference to get started.

From the "OS Specific Bus Interface Component," see osiUserCode.cpp.  This file implements some important functionality using the NI-VISA "C" API.  Look at acquireBoard() for instructions on how to open and map the two device BARs using NI-VISA.  Similarly, check releaseBoard() for the steps necessary to release those resources.

You should also check the initMite() function from any of the 660x-specific examples.  This step is necessary to properly initialize the TIO registers that live at BAR1.  Once the TIO is initialized, you should be able to use the 660x RLP Manual to find the necessary steps to program the counter settings.

Still, I am interested to know why NI-DAQmx isn't working up to your expectations.  You should know that any delays introduced by the "on the fly" update that Andrew suggested are most likely due to attempts by NI-DAQmx to avoid glitching or unintended behavior in your generation.  What type of pulse durations are you programming for the counter (high time/low time) before and after the 15mSec update delay is noticed?  How small of a delay during update do you require for your application?

[rjrowe]

Hi Tom,

Thanks for the response - I don't really understand why there isn't an "OS Specific Bus Interface Component" for NI CVI RT - it is after all an NI product (based on ETS of course), and the constructs must already exist from developing the daqmx libraries for CVI RT (which only expose C function calls, no classes, etc).

The sort of values we are programming in are ~2us delay, ~0.2us width, then keeping the width the same , but changing the delay by a small amount.  The application requires alternating between updating the PXI device settings (~50ms) and then letting the hardware triggers take over for ~50ms (pulse gens will get triggered 1000+ times), then updating the PXI device settings ~50ms, then hardware triggering ~50ms, and so on.  When the hardware triggers are going off, we do not want to touch the settings, similarly when we want to update the settings there shouldn't be any triggers coming in.

The 50ms may sound like a lot of time, but we have a lot to do within that time - some ethernet traffic, 4 sets of GPIB commands, up to 12 AWG waveform downloads, 8 counter channels, plus a bunch of digital I/O.  We have characterised the AWGs (PXI-5421) and it only takes about 1.5ms to do each of the 12 devices using FGEN lib, and that is 2048 points each!  Similarly, the digital I/O (using PXI-6509) doesn't seem to be a problem using daqmx.

30ms to update a couple of registers in the 6608 just doesn't seem right to me, and certainly stuffs us for using this in our application - unless I can get around the problem by either doing something else with daqmx, or just writing to the registers direct.  I reckon I can work out the 6608 register settings for repeat HW triggered single pulse generation, but if I can't work out how to set them under CVI RT i'm not sure what else to do.

Do you know what daqmx is actually doing when you call the functions to update the pulse parameters, and why this takes so long?

Many thanks,

Rob