DAQmx Trigger

[DriesM]

Hi Thierry,

I hope you enjoyed your vacation.

I managed to get the adapted Trigger and Gate vi working.

The 'save to a .mat file' also works properly.

The only thing which I'm still stuck at are the numbers on my x-axis. They keep changing from 0 to a very large number every time I start the program.

I was already given to understand that this has to do with the sort of data type that I'm acquiring from the DAQmx system. This would also include 'time'.

To get rid of it I should convert the data or something like that? But I haven't really figured that out yet...

Best regards,

Dries

[ThiCop]

Hello Dries,

Great you have been able to do so much during my absence!

Can you share the last VI with me?

Maybe I can just fix that last visualization issue with a simple work-around.

[DriesM]

Hello again Thierry,

In attachment you will find the latest version.

I've cleared the spaghetti code a little bit, as you suggested.

I will not take the credit for myself, as some of your colleges helped me a little bit while you were absent 🙂

The trigger and gate vi works almost properly and so does the 'save to a .mat file' thingy. I haven't used your suggestion regarding the save to a .mat file so I did it true some other way.

I do have two remarks:

- I still have the problem with the x-axis.

- Eventhough I ask for 'only' 60.000 samples per channel, I get more than that.

If I run the program once ( at 60.000 samples per channel) and I save the measurement, then the matlab file will contain more than 60.000 samples. The first test I did resulted in 78121 samples, the second one resulted in 80652 and the third one in another number ( also higher than 60.000).

Any idea what is going on?

Thank you again for your help 🙂

Best regards,

Dries

[ThiCop]

Hello Dries,

Can you also add you "Trigger.VI"?

It is missing...

[DriesM]

I know it's probably not the 'right' way to make this program, but it worked and I'm happy it did 🙂

Best regards,

Dries

[ThiCop]

Hellp Dries,

The issue with the 60000 samples is logical.

It's the same issue we saw before:

You are putting more than 60000 samples in the array, so it's normal that you have more than 60000 samples.

You still have to implement something that acts like a circular buffer that contains 60000 samples.

You can either do this while running (with an actual circular buffer) or through some post-processing.

If the trigger and gating (without the circular buffer is working correctly at your side, then the latter will be very easy to implement.

Just take the first 60000 samples of each measurement/channel.

Regarding the axis, the problem is still the same as before.

You see it because you are writing a waveform to your chart that contains the "real time" from during the measurement.

- Either you change that t0 of all the waveforms you're using

- Or you write simple double arrays to your charts. Then the index of your measurement should be on the X-axis.

Seeing that your indexes should go from 0 to 60000, this directly corresponds to the amount of milliseconds.

If you want to change this, then you can apply an offset and a multiplier to your charts by using the corresponding property nodes.

[DriesM]

Hello,

I have fixed the '60,000' samples problem using a little matscript code. It seemed easier to me to do it that way.

Also I converted the data type to 'double' using a 'Convert from Dynamic data ( to 1D Array of Scalar). Is this what you meant?

I also added the multiplier property node and now the x-axis problem seems to be fixed 🙂

I've added the changes in the attachment.

I'll do some more tests to see if there aren't any more problems and I'll keep you posted 🙂

One question: you said this in your previous post:

"You are putting more than 60000 samples in the array, so it's normal that you have more than 60000 samples."

Is there a logical explanation for that? I mean, if put the Samples per channel at 60.000, then how come more samples are put in the array?

Best regards,

Dries

[ThiCop]

Hello Dries,

I think there might have been a misunderstanding before, but let me first come back to your solution.
Your code to get rid of the redundancy could be easier implemented by a simple "Array Subset" VI, but of course you don't have to change it if it works according to your needs.

Regarding the 60.000 Samples per second input there might have been some confusion.

If you look at help of the DAQmx Timing VI, then they state:

"samples per channel specifies the number of samples to acquire or generate for each channel in the task if sample mode is Finite Samples. If sample mode is Continuous Samples, NI-DAQmx uses this value to determine the buffer size."

In this case we're using Continuous samples so tat this VI we are just using it as a sort of guideline to determine the buffer size:
http://zone.ni.com/reference/en-XX/help/370466W-01/mxcncpts/buffersize/

The next part where we use this is in how many iterations we have of the Acqusition Loop.
Please note that we have a wire called >Max. Iterations> that is equal to samples per channel (60000) divided by sampling frequency (10000).

I would expect this to give us a value equal to 6. (If rounding goes not as I expect it to go, then this could also be 7 because of the round towards infinity function)

Let us take the case with the value equal to 6.

This means we have 7 iterations of the acquisition loop.

In the first iteration of  the loop when the trigger occurs we have our trigger VI which should output something between 1 and 10000 samples (if it's triggered).

Afterwards we'll have 6 more iterations that will output 10000 samples.
So you'll always have more than 60000 samples. (that was also why I was always talking about the circular buffers etc..)

However, I would expect between 60001 and 70000 samples and not more than 70000.

To know where your error is coming from I would like to know what the exact value of you >Max. iterations> wire is. (placing an indicator there will show it)

[DriesM]

Hi Thierry,

Thank you very much for this clarification.

I didn't expect the loop to be executed 7 times ( and not 6) but it makes sense.

There is one thing I don't fully understand. In your post above you said the following:

"In the first iteration of  the loop when the trigger occurs we have our trigger VI which should output something between 1 and 10000 samples (if it's triggered).

Afterwards we'll have 6 more iterations that will output 10000 samples."

Why doesn't the first iteration output 10,000 samples? Does this have anything to do with the amount of pretriggered samples?

Best regards,

Dries

[ThiCop]

Yes that pretriggering link is there!

Normally, you should only add the samples that occur after your trigger level is reached to your actual measurement data.

So the first iteration (when the trigger occurs) should show a variable amount of samples between 1 and 10000 that happened after your trigger.