pre-triggered scanning
RJS
Fri, 05/31/2013 - 01:56 pm
I am trying to find a way to (pre-) trigger scanning of diff. channel AI 0 (68 and 67 on my board) using the analogue signal coming into this channel itself. To be precise, I am trying to periodically record 10-30 seconds of EMG (electromyography) signals only when they reach a certain threshold voltage, over an undetermined amount of time (and save them into different waves, but that's not important right now).
Sofar I have been trying to use the Scan Control panel (NIDAQmx) settings but without much success, as its not letting me set the input channel AI 0 as the trigger channel.
Other than splitting my data cable and feeding one half into the AI 0/AI GND and the other into another analogue trigger channel, is there any way this can be done?
Cheers,
Ruud
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
May 31, 2013 at 02:10 pm - Permalink
Did anyone respond to this thread prior to the server issue?
It is now apparent that my NI board does not allow for analog triggering, but it seems to me that there should be a programmatical way of triggering data acquisition of an AI once it hits a certain value? Ideally, I would record several seconds prior to the actual "trigger" event, so that I would have a baseline to compare against.
I'd be interested to know if anyone has a suggestion.
Thanks
Ruud
June 4, 2013 at 01:51 pm - Permalink
I suggested that you might be able to come up with something using DAQmx_AI_SetupReader and fDAQmx_AI_GetReader. But I think it might be difficult to make it work right.
I also suggested that if you can find a bit of money, it would be a lot easier just to buy a DAQ device that supports analog triggering.
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
June 4, 2013 at 03:15 pm - Permalink
and whoever was the other source of suggestions.
I will give it a go.
Cheers
Ruud
June 5, 2013 at 06:33 am - Permalink
I managed to get a very reasonably priced DAQ device (6052e) that should allow analog triggering.
Two questions:
1. Can I add channels to the list of channels in the NIDAQmx WaveScanProcs panel start trigger/trigger source menu item (i.e. the one that by default shows PFIO, ctr0internaloutput, ctr1internaloutput, and ao/starttrigger)? I would like AI0, AI1 or whichever AI input channel I like to be the trigger source, and still use (a slightly modified version of) the panel.
2. If 1. cannot be done, would it be possible to execute a scheme such as this (excused for the rough sketch):
a) setup AI0, AI1, AI2, AI3 channels for analog data acquisition and a counter
b) perform a Do/while using the Daqmx_scan operation.
Something like this:
Do
Daqmx_scan/dev/"dev1"/RTRG={AI0, pretriggersamples[,2, 1, level1, level2]} ;
When an acquisition is triggered, save 30 seconds of total data (including pretrigger samples) into wave X, Y, Z, etc ;
While
my counter value is less than 10 minutes.
Next, I would want to repeat this process for the next AI channel, i.e. AI1.
After all four of my AI channels have been scanned for 10 minutes each (and for some hopefully some data has been collected into waves) I would want to repeat the entire loop so its starts at AI0 again.
Thanks for any insight/suggestions.
Ruud
June 10, 2013 at 01:53 pm - Permalink
Remember that the trigger channel must be the first channel in the list of analog input channels being scanned, or it must be /Dev1/apfi0 (I think, I'm working from memory).
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
June 10, 2013 at 05:14 pm - Permalink
well its not working yet. When I tick the start trigger option, and type in "dev1/AI0" as the trigger source, its giving me this error:
"NI-DAQmx driver error while calling function DAQmxTaskControl with DAQmx_Val_Task_Commit; device Dev2:-200265: An attempt has been made to use an invalid analog trigger source"
I can't find much on this error number online.
However, I can use PFI0 as the analog trigger (although I am not sure to which board address I need to connect the ground wire for the PFI0 signal (as its the same signal that I want to record).
Do I need to go into the procedure file for the scan control panel and add "AI0" to the options for the panel item in question, so that it will recognize it?
I tried this before but was denied access to this file (i.e. its a read only file).
Any more help is most appreciated.
Ruud
June 11, 2013 at 03:14 pm - Permalink
Is that exactly what you entered? It needs a leading slash: "/dev1/ai0". I'm still not sure I have it right, but I know the leading slash is required.
Are you using single-ended input mode? If you are, then you shouldn't need another ground connection. If you are using differential input mode, then I think you may be out of luck. It looks to me like the PFI0 input is single-ended. That might be a problem even using ai0 as the trigger source.
If you mean that you would add it to the menu, then no, that isn't necessary. The menu is just a convenient way to enter some commonly-used connections. I did that to help eliminate spelling errors that result in tech support calls. You can also manually type in a signal path.
Right- if you use the
#include <filename>style to load the file, it is opened in a protected state. If you want to modify those files you should really make your own copy and modify the copy.John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
June 11, 2013 at 04:21 pm - Permalink
Is that exactly what you entered? It needs a leading slash: "/dev1/ai0". I'm still not sure I have it right, but I know the leading slash is required.
Yes I did enter with the leading slash "/dev1/ai0" and am using the RSE input mode. Doesn't work sofar.
I have also tried using the PFI0 as the analog trigger by just splitting my analog signal across two leads (one into ai0 and one into PFI0), this doesnt work either. Perhaps I am missing something simple here.
daq board seems fine, I can use basic scan protocol fine (e.g. 5 secs of scanning Channel 0 RSE) works, its just the triggering that seems to cause problems.
Do you have much experience with the repeated scan proc panel? This seems to be able to do what I need (provided the triggering issue is resolved), i.e. repeated scanning and data output into waves. There is not much information on this panel available.
June 12, 2013 at 08:06 am - Permalink
Seems I was wrong about the leading slash. NI requires the leading slash for certain uses and requires that it not be present for other uses. I have trouble remembering which is which. I don't presently have a setup that I can conveniently use for testing if this sort, so I used a simulated PCI-6052e. It doesn't actually work (the trigger never arrives) but the driver still reports the errors. If it works, it just hangs without actually doing anything.
To simplify things, I used the bare DAQmx_scan command on Igor's command line. Here are some results (pardon the huge amount of text I'm posting!):
First, I made a couple of waves
Then I started trying various commands:
•print fDAQmx_ErrorString()
NI-DAQmx driver error while calling function DAQmxTaskControl with DAQmx_Val_Task_Commit; device 6052e:-200265: An attempt has been made to use an invalid analog trigger source.
Ensure that the trigger source you specify matches the name of the virtual channel in the task or matches the name of a non-scannable terminal that the device can use as an analog trigger source.
Extended info:
An attempt has been made to use an invalid analog trigger source.
Ensure that the trigger source you specify matches the name of the virtual channel in the task or matches the name of a non-scannable terminal that the device can use as an analog trigger source.
Property: DAQmx_AnlgEdge_RefTrig_Src
Corresponding Value: /6052e/ai0
Valid Choices: 6052e/ai0, PFI0
That was how I figured out that the leading slash is wrong. Here is another attempt, but with the leading slash removed:
•print fDAQmx_ErrorString()
NI-DAQmx driver error while calling function DAQmxTaskControl with DAQmx_Val_Task_Commit;
device 6052e:-200264: Device supports an analog channel as the source of an analog reference trigger only when it is the only channel in the task.
Remove all of the channels currently in the task except the channel that will be used as the analog trigger source, or change the analog trigger source to a terminal.
Extended info:
Device supports an analog channel as the source of an analog reference trigger only when it is the only channel in the task.
Remove all of the channels currently in the task except the channel that will be used as the analog trigger source, or change the analog trigger source to a terminal.
Property: DAQmx_AnlgEdge_RefTrig_Src
Corresponding Value: 6052e/ai0
Number of Channels in Task: 2
This says that you can't scan more than one channel and still use the scanned channel as the trigger source. This was news to me! So I removed one channel from the channel list:
This one "worked". That is, it didn't cause any error reported by the driver. I had to click Igor's Abort button to make it stop waiting for the trigger. To get around the requirement to scan only one channel, I tried PFI0:
•print fDAQmx_ErrorString()
NI-DAQmx driver error while calling function DAQmxTaskControl with DAQmx_Val_Task_Commit; device 6052e:-200265: An attempt has been made to use an invalid analog trigger source.
Ensure that the trigger source you specify matches the name of the virtual channel in the task or matches the name of a non-scannable terminal that the device can use as an analog trigger source.
Extended info:
An attempt has been made to use an invalid analog trigger source.
Ensure that the trigger source you specify matches the name of the virtual channel in the task or matches the name of a non-scannable terminal that the device can use as an analog trigger source.
Property: DAQmx_AnlgEdge_RefTrig_Src
Corresponding Value: apfi0
Valid Choices: 6052e/ai0, PFI0
This tells me that the name of the signal is just "PFI0", not "6052e/PFI0". I don't know why!
This "worked":
So, now that I figured out what the signal names should be, you should be able to enter "dev1/ai0" as the reference trigger source in the panel, but you can only select channel 0 to scan from. Or you can enter "PFI0" as the trigger source.
I have a recollection of reading somewhere that the resolution of the analog trigger using PFI0 is low. I can't remember where I read it; it seems like the kind of thing that should be in the manual for the device.
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
June 12, 2013 at 09:56 am - Permalink
Ah progress! I am now at least able to trigger acquisition of ai0 using ai0 either as a start trigger or a reference trigger.
Although I must say that the consistency with which the panel correctly executes is a bit iffy. It will hang now and then, by making small changes to settings in the panel before initiating a new scanning protocol (start button). I need to close and reopen the panel to make it work again. I have run into this issue before I think with a much older version of Igor and nidaq tools..
I am going to try it your way, i.e. coding the data acquisition myself.
Also, using the scan proc panel, I cannot do pre-triggered scanning using "repeated" scanning option. Only "oneshot" allows pre-triggering. Is this technically not possible or just a idiosyncrasy of the panel code?
Thanks
Ruud
June 12, 2013 at 11:38 am - Permalink
Doing repeated scan mode, if you turn on the Use Continuous Acquisition checkbox, then you get only one trigger at the very start. You must turn off that checkbox if you want a trigger on every scan. Do understand why, read the help for DAQmx_Scan, RPT vs RPTC flags.
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
June 12, 2013 at 01:08 pm - Permalink
I think the buggy behavior has to do with me tampering with settings in the panel while scanning is ongoing.
I shouldn't do that :)
On a bright note: the "Repeated Scan Control" panel does exactly what I need given the change in channel designation from '/DevX/ai' to 'DevX/ai0'. I have attached a screen capture of settings I used. If only there was a quick way to collect all these settings into procedure code so I could customize it further if I needed to.
One more question: do you happen to know if the "DAQmx_Scan WAVES=..." function allows for a "$" operator in the wave designation? I tried to code whatever the repeated scan control panel does and tried to use "... WAVES=" $destinationwave, channelX;" to be able to change the destinationwave name every trigger cycle (i.e. by using some string+counter combination to have the procedure dump data into wave0, wave1, wave2 etc for each trigger cycle/counter value increase), but it gives me either an error that the wave name has to have single quotes (since it has a $ character in it), and when I put it between single quotes, it says that "one of the waves listed does not exist". There is probably a workaround but I was wondering if $ is allowed in general in the scan commands.
Thanks for your help.
Ruud
June 13, 2013 at 11:33 am - Permalink
$ works when Igor expects a name. It converts a string to a name.
In this case Igor is expecting a string, not a name, so $ is not appropriate.
Here is what you can do:
sprintf wavesStr, "%s, channelX;", destinationwave // Assuming destinationwave is a string containing a wave name
Print wavesStr // For debugging only
DAQmx_Scan WAVES=wavesStr
June 13, 2013 at 01:36 pm - Permalink
That's an eyeopener and caused some progress.
I am still having difficulties actually getting the data in, but that's another problem
It is scanning at least from code.
Ruud
June 13, 2013 at 04:29 pm - Permalink
Sorry to keep bugging you, but I am finding rather odd behavior of the "Repeated Scan Control" panel. I have attached a screen shot of some data I collected from a live animal's muscles, and the settings in the panel. Notice that the baseline data all three graphs is higher than the set Analog level 1, yet it doesn't trigger data acquisition until it reaches a much higher level.
It seems that the Analog Level 1 value is irrelevant because the only voltage that will trigger acquisition is 1V.
In all three traces you can see that at exactly half the period of acquisition (5 secs in this case) there is a signal through ai0 that exceeds 1.0V and triggers the retrieval of 10000 samples, with 5000 samples post-trigger.
I have tried many Analog Level 1 settings and it doesn't seem to matter what value you put there (below 1.0 at least is what I have tried). I'd like to trigger acquisition at much lover voltage levels, say 0.05 Volts.
Is Analog Level 1 scaled somehow by the Min/Max V settings of the channel, or by some other setting?
The same does appears to be true for the regular scan control panel, set to repeated scanning, with the same analog trigger settings.
Any thoughts, ideas? It seems crazy that one would only be able to trigger with +1Volts..
Thanks for any (continued) help
Ruud
June 14, 2013 at 11:18 am - Permalink
Added July 8, 2013: It turned out that the problem was caused by a malfunctioning DAQ device. See the end of this thread.
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
June 17, 2013 at 10:45 am - Permalink
yes that would explain it :)
Can you tell me what I could change in the panel procedure file to let me pick the right analog level (I do need it to trigger while on a rising slope, so that seems fine)?
Thanks.
Ruud
June 19, 2013 at 07:22 am - Permalink
I see also that your signal has lots of high-frequency stuff in it. It's possible that the triggering algorithm has some sort of filtering that would require that the signal cross the threshold for more than one or two samples. You might try feeding the analog input with one of the analog outputs. Run a waveform from the analog output so that you can control the characteristics of the waveform. That would allow you to try out various signal characteristics.
If that is the problem, you may need to increase the sampling rate so that your spikes are sampled more accurately.
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
June 19, 2013 at 09:22 am - Permalink
Ok, I understand. So I don't mind that its hard-coded to trigger on a rising slope. I will try some even higher sampling freqs and see if that changes things, but I still wonder why it would trigger only at 1V with my current settings. If what you are saying is true, wouldn't you expect the triggering to occur at more random (yet high) voltages that would cross the threshold longer than a couple of samples? Anyway, I will give it a go and report back.
Ruud
June 19, 2013 at 10:47 am - Permalink
Just FYI, I am scanning at 20KHz at the moment, and it seems (see attached closeup of trace) that signals are covered pretty well.
Here, data acquisition triggering occurred at x-value 0.25.
I will try doubling the scanning rate and get back to you.
Ruud
June 19, 2013 at 10:57 am - Permalink
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
June 19, 2013 at 11:13 am - Permalink
John, that can't be it, can it? Didn't you just say that trigger is hardcoded to be on a positive slope? In general, the base level of my signals vary tightly around 0, its just that what you see in the figure (i.e. the acquired data after the trigger) shows a lot of peaks that reach 0.25. This is why I am confused as I set the trigger level lower than that, with 50000 post-trigger (i.e. pre-trigger) samples to be taken. There are many more spikes that go higher than the 0.1 value, and those that do also typically go below 0.1. Yet, when I look around datapoint 10000 in the acquired waves, there is always that value of 1.0 that is being breached (i.e. it does seem to take about 2-3 samples around 1.0V to trigger).
I am not getting any different behavior by acquiring at higher scanning rates, or any variations on the trigger level. Strange no?
The other thing I just noticed is that there seems to be some scaling going on between the minV/maxV settings and the trigger level for say Analog Level 1. The screenshots I sent you were from scans where I set my "Channel 0" to "RSE" and +-2V. When I let the wave generator run infinite loops providing one of the acquired waves (I renamed them first) to AI0, there is triggering of acquisition at the same levels (i.e. again around 1V, instead of the set 0.1V), but when I change "Channel 0" to +-10V, there is NO triggering whatsoever using that same input wave (by the wave generator panel).
any thoughts?
Ruud
June 19, 2013 at 11:28 am - Permalink
That somehow rings a bell, but I'm having trouble making a sensible story out of it. Unfortunately I don't have a device that supports analog triggering.
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
June 19, 2013 at 02:48 pm - Permalink
If we are out of options with the repeated scan control panel, I will give coding from scratch another try.
Please let me know if you come up with any new insights?
Cheers,
Ruud
June 19, 2013 at 05:52 pm - Permalink
If you could give up your 6052e for a month, I could take a look at the issues myself. I have the advantage of having access to the source code for NIDAQ Tools MX :)
It would actually most likely be on the order of two weeks, but I couldn't promise that.
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
June 20, 2013 at 01:01 pm - Permalink
Hi John,
Sure, I can do that and send it to you. How do you suggest we proceed?
Cheers,
Ruud
June 24, 2013 at 09:27 am - Permalink
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
June 24, 2013 at 09:56 am - Permalink
This problem turned out to be a hardware related issue. I solved my issue by getting a replacement board (after having it properly tested by John Weeks during which self calibration failed indicating a faulty board) and using the "Repeated Scan Control" panel, I am now perfectly able to trigger data acquisition from AI0 using the signal coming in from AI0.
Cheers,
Ruud
July 8, 2013 at 10:13 am - Permalink