offset relative to most recent

[Kjell-E]

Hi,

I took two NI examples and combined them trying to brain-storm a solution path for an upcoming project. The problem I have is that I'm on "new ground" as far as my level of tinkering with the DAQmx tasks so I'm trying to prove or test my code to see if I'm doing it right, but without access to the hardware (which is coming).

The following is a copy-paste from a comment box in the VI (attached), so some of it may not make sense until you look at the code. (LabVIEW 2010):

Scenario:
At a rate of about 10Hz, a digital signal will go from low to high and then back to low. Digital pulse-width is ~couple of ms.
The digital signal is 24V industrial signal. I do not wish to wire this signal to the 4462 trigger line as it is out of spec for the trigger line and would damage the card. I also don't wish to "voltage divide" or level shift the signal as that would require adding external componenents.

Whenever I get a digital trigger, I wish to read out a fixed number of AI samples corresponding to about 4ms of data, Lets assume that is 400 samples for sake of argument.
The AI task is running continously with a large buffer set to "overwrite unread samples" and read "most recent sample".

I do not care about any data between the digital pulses.

My approach is that I will read in the samples (say 500 samples) starting at 100 samples before the current, most recent sample. My idea is that
the -100 offset will go back in time enough to make up for the software delay in registering the change-event and signalling the AI Loop to take a
frame of data. My plan is to modify the offset to a safe number once I get the hardware.

Here are my questions:
1) Using simulated devices, I never get a DAQmx Change Detection Event to fire, even though the simulated data is changing. I could understand that
this may not be supported using siumulated devices, but I have not found any text that explicitly states this, so at this point I'm not ruling out me doing
someting wrong?

2) I have not used "Relative to Most Recent Sample" and "Offset" before so I am not entierely sure how to use them. First, do I need to set the DAQmx Read
properties inside the loop immidiately prior to the read, or can I configure the read outside the loop?

3) With an offset of -100 and a "samples to read" of 600, I expect to get 100 "old" samples and 500 new samples. I expect the DAQmx Read to stop and wait for
the 500 new samples to become available. With the simulated data, again, I cannot think of a way to verify that this is indeed how it operates?

4) Is "Hardware Timed Single Point" a good choice for the DI task for this application? -I do not care to read or log the digital data. Also, since I only wired the
rising edge on the change detection, I already know all I need to know about the digital line.

Is this an okay way to approach the problem given that the analog events of interest are short relative to the repetition rate (10Hz, but only last 3-4mS)?
I only want to analyze and log the data frames occuring as the digital goes low to high. The analysis is fast enough to finish well inside of the remaining ~90ms before the next event.

[Kevin_Price]

1.  I suspect it's just that simulated devices don't support all the features of a board.  There's more than one way to "catch" and respond to a digital change detection event and the approach you took looks fine to me.

2.  I remember having the same question about those DAQmx Read properties, but I'm not sure I know the definitive answer.  I wouldn't just assume the settings would "stick" though until I tested it out pretty thoroughly.  Since that isn't necessarily a trivial task, I think I'd do just what you're doing -- set the properties inside the loop just prior to every read.

3. Read 600 with an offset of -100 from Most Recent should behave just like you expect.  No worries.

4. Re: HW-Timed Single Point - it *sounds* fine to me, but I don't have experience using change detection in that mode personally.

   There's just one other suggestion I'd offer:  Right now, your AI loop will burn all available CPU polling the 'DigEvent' control that's being set in your DI loop.  I would setup the AI loop to be event-driven so it'll sleep most of the time and be awakened as soon as a change detect event is recognized.

   One way might be to route your registered change detection event to the AI loop instead of the DI loop.  That'll accomplish your job more directly.  Another way might be to use a boolean Notifer instead of the boolean front panel control.

-Kevin P

[Kjell-E]

Kevin,

Thanks for your feedback. The code was a 15 minute mash-up of 2 or 3 NI examples. I refactored to code today such that the AI read is inside the digital change event in the event structure. I then use a queue to transfer the data to  an analysis sate-machine. This should allow the threads to sleep most of the time and only wake up to pass data as needed, much as you suggested.

I think about the best I can hope to do is get a reasonable level of confidence that my approach "should work" until I get the hardware. I should be able to test out on Friday and will try to remember to report back here, in particular if you need to set the properties ahead of every write. In my setup, it will be pretty trivial (I think) to see if the offset is working when set once, or not.

Thanks,

Kjell