Acquire N scans on multiple channels using daqmx and Visual Basic .NET

[Ryan_V[DE]]

Colin,

Another, perhaps easier, way of synchronizing DAQ cards is to use the SyncTask class which extends the Task class to include automatic synchronization. This class is available in both C# and VB .NET. The VB example is installed to C:\Program Files\National Instruments\MeasurementStudioVS2003\DotNET\Examples\DAQmx\Synchronization\Multi-Device\AIFiniteAcquisition\vb by default. It should be very close to what you are trying to accomplish.

Good luck,
Ryan

[Colin hughes]

Hi Ryan

I needed a re-triggered delayed single pulse so I played with one of the examples for the counter timers.
I managed to find out how to re-trigger but had problems as there seems no function for doing a single delayed pulse which is pretty standard for counter timers.

The sample expected three values start-delay/ down-time and up time (something like that).
Three values instead two values (delay and pulse width)

If I chose rising edge trigger, it would trigger on both edges but if I chose falling edge it would work as expected.
Seem like a bug on the rising edge selection?
If I use the RTSI bus I would need to set it up in software and not MAX as I would have problems later installing the software on other machines.

I am still playing.

Thanks again
Colin

[Colin hughes]

Hi Ryan

I have looked but I do not have that example code.
There are two examples under Synchronization\Multi-Device, both end with DSA. (AIShaedTimeBaseAnd Trig_DSA)
I don't no what DSA is but my cards do are not supported.
The cards are PCI-6143.

I will try to re-write the Sample to see if I can get it to work with my card.

Off subject now, I have altered the counter timer sample "GenDigPulse" to display a delayed re_trig pulse.
I found that it would work OK with start delay of "0.0" so as to have a normal delayed pulse.

If the delay+pulse-width is smaller than the width of the trigger pulse then if set to trigger on rising edge it triggers on both edges.
Seems like a bug to me but in pratice my delays would normally be longer than the trigger pulse.

All I need to do is find out how to change delay+pulse-width (on the fly )without stopping the task.

Thanks Ryan, I will play with the Synchronization code now.

Colin

[Ryan_V[DE]]

Colin,

I have attached the example that you need.

Unfortunately, programmatically setting up a RTSI cable between devices is not supported. Perhaps you could file a product suggestion.

I will see if I can find any information on the behavior you are seeing with the pulse generation. That ceratinly isn't expected. Are you sure that there are no glitches on your trigger? As for setting the initial delay while running (I'm assuming that that is what you want to do), I will double-check, but I am fairly certain that that is not supported.

Hope this helps,
Ryan

[Colin hughes]

Hi Ryan

Odd that I do not have that example.
I found that all I needed to do was set up the RTSI cable in max as you say and just change where the trigger comes from for the second card.
I don't like the lack of RTSI control leaving it to the driver.
I found that even starting the second task first there is still a delay before the second card is triggered (about 30us )and sometimes big delays of a few hundred micro seconds. (Not good)
This is a problem we had last year with Labview even using the old daq driver.

I have the task setup in button event and the start task and rest of code in a counter timer event with a stop button to stop and kill the task.
So far so good.

I think, what I done in my old software of putting a counter timer output on the bus and using that as the trigger is more reliable and I have no problems with delays that way.
This is not a big problem for this project as I have to extract the required info from the returned data but no timing measurements (for now).

>>you sure that there are no glitches on your trigger?
Trigger pulse is a clean TTL pulse.
I have played with the CreatePulseChanneltime.

I think the hole driver code for this is buggy as I have an inverted pulse even when I selected idle to be low.
Switching to high screwed things up good and proper.
As this is a small app just to trigger some hardware I might redo it in Borland with the old DAQ driver as I am finding the MX way of doing it pretty useless and very bugger (counter timers) considering the simple task required.

>>(I'm assuming that that is what you want to do), I will double-check, but I am fairly certain that that is not >>supported.

Ok leaving initial delay at 0.0 but not the other two (low value, high value).
I tried it with a value for initial delay just in case but no luck and I am still stuck with an inverted pulse even with idle set to low.
I don't think this is a pull.

Thanks for your help

Colin