Problems synchronizing 5124 with 6110

[DAQ_nubee]

Hey all,

I am trying to control some motors using a signal generated by 6110 card's ao0, ao1 outputs. But I need these signals to be synchronized with the data acquisition done by the E series 5124 digitizer. So what I tried doing, was use the 'end of record event' and other trigger events (seperately) to start the generation of motor control signals, but it seems like the 'end of record event' is being missed for every other data acquisition (sometime more are missed).

The 2 cards are connected via an RTSI cable, which seems to be working fine. It should not be a hardware speed issue since the 'end of record event' should be generated at about once every 20ms. I am not sure how could I change my code to improve performance. Could someone please suggest anything I might be doing wrong or how I could improve the synchronization?

Thanks

[Kenn_N]

Hey DAQ_nubee,

Thanks for contacting National Instruments support.  You should be able to accomplish this.  I am curious how you are attempting to do this in code.  Are you using LabVIEW, or some other programming language.  Are you using a counter to do a re-triggerable generation or are you using software-timed generation?  More details would help greatly.

Regards,

[DAQ_nubee]

Hey Kenn,

I am curious how you are attempting to do this in code. 

>Yes we are using LabVIEW

We have 3 triggers in the program. One external trigger is used to acquire data from digitizer. This is generated at 20us and is seen without any problem by the program. This trigger is used to acquire a 2D array of 990x1024 I16 points. The second trigger is generated after every 1D part of the array (1024 points) is acquired. It is the internal trigger event 'end of records event', which is transported from the scope digitizer to the DAQ 6110. This second trigger is used to generate some signals points on ao0 of the NI6110. These points have a minimum at 0,1024 and the maximum value at 990,1024 (a ramp signal). So the signal spans 990x1024 points (ie: one data acquisition cycle). The data acquisition runs within a while loop continuously without any reconfiguration of hardware. Now there is another third trigger event called 'start trigger', which occurs after a set value of five data acquisitions (five times the second trigger). This trigger is supposed to be used to generate a control signal at ao1 on the NI6110. with a minimum value at first acquisition and maximum value at the fifth acquisition.

Now what is happening is that after every acquisition, there is a wait cycle (I am not sure if it is due to external trigger or some data transfer latency), which causes a delay after every data acquisition of 990x1024 points of data. So at the outputs ao0, we see the expected control signals for as long as one data acquisition cycle, but after that we do not see any signal for about 2-3 data acquisition cycle durations. This cause the ao1 signals (also a ramp waveform) to be broken up. This is causing the problem in instrumentation controls. We would ideally want absolutely no wait between acquisitions.

Currently the data acquisition happens within a for loop (with an NIscope initiate and NIscope fetch VIs) without any configuration. Every time the loop stops, there is a wait, whose source we are unable to figure out. I could try and e-mail the code if required.

Any help would be greatly appreciated.

Thanks a lot

Best Regards

Priyesh Jain

[Kenn_N]

Hey Priyesh

So if I understand you correctly you have one trigger to start the scope, and at the end of it acquiring the data you trigger the ao0 on the 6110, and every fifth trigger you trigger ao1 on the 6110.

I'm a bit confused about how you are specifying your ramp, as you can't output a 2D array to one channel, but I think that is a typo or I am still misunderstanding something. 

So ao0 has a ramp and ao1 is a square wave basically with a period of 5 times the time between the 2nd trigger?  Is that right.

I think the delay may be from calling start in each loop iteration.  You should only call this once.  There is a time in which the scope must use to rearm it's trigger as well, but your triggers are being seen so you must be accounting for that.

I think the code may be helpful, is this a large vi?  If you can send the simplest code possible that would help.

Regards,

[DAQ_nubee]

Hey Kenn,

>You are pretty close : at the end of it acquiring the data you trigger the ao0 on the 6110, and every fifth trigger you trigger ao1 on the 6110.

I have 2 seperate signal ramps on ao0 and ao1. The initial value of ao0 is its assigned minimum, and at each trigger2, it is incremented by a value "max-min/1024", whereas the ao1 signal is incremented by a value "(max-min)/(1024x5)", and then they are reset.

I am just adding the values to the previous values of signals at each trigger on both ao0 and ao1

> I could not really understand which start call are you talking about? (I think the delay may be from calling start in each loop iteration. You should only call this once.) 

Is this the initiate VI you are talking about before the fetch VI? I am configuring the hardware only once, and then after that I have a while loop with initiate VI and the fetch VI, to acquire data.

>There is a time in which the scope must use to rearm it's trigger as well, but your triggers are being seen so you must be accounting for that.

I believe you are right. We either see all triggers or we see none for 2-3 data acquisition durations. Which seems to imply that it is a problem with the restart/rearm of data acquisition rather than tiggers.

I will post the VI in a bit.

Thanks a lot

Best Regards

Priyesh Jain

[Kenn_N]

Hey Priyesh,

Yes I am talking about the Initiate vi in front of the fetch you should only need to initiate once, and then it will fetch the data based on the triggers.  It is a multi-record acquisition so this should work.

The rearm time for the 5124 is at most 10us, so as long as you account for that you should be fine.

Regards,

[DAQ_nubee]

Hey Kenn,

Here is the code attachment.

I have labelled the data acquisition and the Galvo signal generation portions. I just feel the hardware has been designed to perform much better than I am able to get it to work.

Thanks a lot for you help.

Priyesh

[DAQ_nubee]

Hey Kenn,

I think you have a pretty good idea of whats going on, but I fail to understand why there is absolutely no data acquisition if I do not use the initiate VI inside the while loop. It seems like the trigger is seen only once if I use the initiate VI outside (before) the while loop. Am I doing something else wrong here?

And since the external trigger is expected only about every 20us, the rearm time for the 5124 of 10us should not be a problem at all. We would not really care if we are off by 20us, but here we are skipping 20usx990, which is just bad.

Regards,


Priyesh

[Kenn_N]

Hey Priyesh,

I've been looking at your vi, and I would suggest decreasing the number of Local Variables to as few as possible, these circumvent dataflow, and are considerably more overhead for your PC to process.  Also the use of sequence structures is not needed since LabVIEW follows the rules of dataflow.  You can easily force sequence with error clusters or other means. 

Onto the application.  Your Analog Output situation seems impossible unless I am mistaken about your requirements.  There is only 1 timing engine on the 6110 and thus you are not able to trigger ao1 and ao0 at different times.  It doesn't look as though you are attempting to in code anyway, but it's not possible how you are explaining it.  Also you are sending the AO task a 2D array with data so it is going to write that data on both lines every clock cycle.  Lastly if you want to re-trigger than you would need to specify a counter that you can re-trigger to accomplish this, but you would still only be able to trigger both lines at the same time. 

Your scope should acquire and receive triggers for as many records as you specify to acquire.  Calling the Start vi outside of the loop should allow this.  It's true that some of our examples place the vi in the loop, and it will work, but for more accurate timing it should be outside the loop.

Let me know if you have further questions.

Regards,