Buffer Problems using NI PCIe-6353

[mary_mun]

Hello,

I am actually working with LV2017 to control an UV laser and to galvanic mirrors to perform nanodissection. The main VI is a queued state machine, where the user can chose different options. The most important one is the Cutting SubVI (Name). The user can chose the Laser Frequency, the Point Distance, the Diameter of the circle that should be cut and many other things. Using this information a (Sub)SubVI calculates the frequncy of the sine-waves which are generated for the mirrors as well as the Sampling-Info for the function generator. At the moment, the only point distance, that doesn't leads to an error is 0,1µm. In this case there are bubbles because of heat. To avoid this, I want to increase the point distance. Every time I am trying the program displays error 200015 and says that the buffer isn't big enough and that the program is mixing the old and new generated values. I suspect that the problem is that the function generator generates the signal faster than the Writing from DAQmx that I am using to communicate with the mirrors through an analog output. I already tried to increase the buffer using one of the DAQmx functions with configures the buffer. Also I tried to decrease the sample-rate of the function generator but the problem still occurs. I uploaded the SubVI (CuttingControl_Circles.vi) and the related (Sub)SubVI (CalculationSkill.vi) of the version before I tried to change buffer size and sample-rate. Is there anything I can still try to avoid the bufferproblems?

Hoping that somebody has an effective solution.

Marion

[Kevin_Price]

There's probably gonna be a better way to code this that will avoid these errors.  I would need to see your DAQmx code too, plus I for one would need *any* code saved back to LV 2016 or earlier.

-Kevin P

[mary_mun]

I hope that it is now saved as LV2012. The version withoutDAQmx is the original version that I posted yesterday. The version DAQmx is the newest version with the buffer configurator. The other VIs are just the SubVI for the calculation and the Laser Trigger (the Laser Trigger isn't important in this case). Thanks for your answer.

[Kevin_Price]

Nope, all are still saved as LV2017 and I can't open them.  Use "Save for Previous Version..." from the File menu.

-Kevin P

[mary_mun]

Sorry for the late answer. I hope that it works now, I just don't understand why it didn't worked last time. If not can you just tell me how it is possible to see the version in the saved file. Thanks.

[Kevin_Price]

Worked fine this time, I can see the code.  

It appears you are using Finite Sampling for AO and CO while using Continuous Sampling for DO.  That *seems* unusual, though there can be good reasons for such discrepancies depending on the finer details of a given app.

For AO, the call to DAQmx Timing defines a different # of Finite Samples than what you wired into an earlier explicit call to DAQmx Config Output Buffer.vi    When I've used that buffer function, it's only been for Continuous Sampling tasks and I always call it *after* calling DAQmx Timing.  In that mode, the explicit call always "wins" at setting the exact buffer size.   I'm not sure which setting "wins" in the sequence you've used.  

    In the explicit buffer sizing call, you're setting a buffer size that's 2x the # samples you ever write to the task.  If that sizing call "wins", then  I would pretty strongly suspect this to be the main source of the -200015 error -- the task gets 1/2 way into the buffer and has no more new samples available to generate. 

    Try dropping the explicit buffer sizing call.

Note also: the CO task is configured to be retriggerable but there's no trigger configuration to define a trigger signal.  That's gonna be a problem too.  It probably isn't pulsing which in turn means you won't have a sample clock signal for your DO task.

-Kevin P

[mary_mun]

Hello Kevin,

I hope that I've understood you right. You think that the error only arises because of the DAQmx ConfigOutputBuffer.vi. I didn't used the VI when I started programming and when error 200015 occured for the first time I searched for a way to avoid this size problem and so I found the Configuration VI. I already tried to place the buffer function *after* the Timing but the error occured every time. I suspect that the FunctionGenerator for the Sine-Function generates the values faster than the DAQmxWrite.vi is sending them. By using the Buffer function I was hoping that I can save the values longer so that the Writing can call the generated values. So I am confused now what to do. I just tested it using Finite Samples for all, the CO, DO and AO but then a new error arised (error 200288 which corresponds to the DO function). Is there any possibility what I can still try to avoid the 200015 error? The trigger configuration is implemented with the SubVI.

Marion

[Kevin_Price]

Ok, if you had errors before adding the explicit buffer config, my last guess must be wrong.

What are typical values for the front panel control inputs?  I just did a trial run here where I have a similar 6341 X-series board and was able to run without any DAQmx errors.  Everything but the software timed AO ran on the real device, but had to use a simulated device for the seemingly innocuous software timed AO at the bottom of the diagram because I only have 2 AO channels on my device.

My wild guess input values were:

Laser Pulse Freq = 50 kHz

Point Distance = 1 um

Diameter = 500 um

AOM Voltage = 1 V

# Rotations = 2

Objective = Leica 40x

Pulses/Point = 4

Phase = 0 deg

I suspect the -200288 error comes in the last sequence frame.  It *might* be sufficient to call DAQmx Stop first and *then* DAQmx Write with auto-start, but you'd also need to defer stopping/clearing the CO task until *after* you've set your final DO state.  (It also may turn out you need to write multiple samples to the DO task, enough to correspond to the unknown # of additional CO pulses that'll happen before you can stop the task.)

As to triggering CO, I don't see any calls to DAQmx Trigger.vi.   The only "subvi" is one that assembles a DO waveform for the DO task, but has no access to *any* of the DAQmx tasks to configure them.

The code runs as-is, but there is no trigger based synchronization going on.  The CO task simply free runs in an untriggered mode.

-Kevin P

[mary_mun]

Hello Kevin,

the single AO at the bottom is not important for the buffering problem I think. 

The typical values are:

Laser Pulse Freq:  100-1000 Hz

Point Distance: 0,1 µm

Diameter: 70 µm

AOM Voltage: 5 V

Rotations: 1-3

Objective: get the similar error for both possibilities

Pulses/Point: 1

Phase: 90 deg

The horrible thing is that I never get an error with the values I wrote and when I increase the point distance the error occurs. Furthermore I think that it depends also on the card because I normally do the programming thing outside the lab using NI PCIe-6259, looking at the oscilloscope to see the signal, and it worked with every possible point distance. Afterwards I tested it with the NI PCIe-6353 in the lab and the error arises using point distances higher than 0,1µm. 

I' m going to try to change the trigger thing.

Marion

[Kevin_Price]

I tried again with your input values.  After a couple successful trials, I too started to see the -200015 *warning*.  It occurred in the DO task in the last sequence frame,  seemingly for reasons related to my previous speculations about the other DO error you saw when switching to Finite sampling.

I got rid of it by stopping the task before doing the write with auto-start.  I *also* inserted an explicit config step to put the task in software-timed "on demand" mode (instead of hardware sample clock mode) before writing.  Doing things this way meant there was no need to be careful about sequencing when to Stop/Clear the CO task.  Here's a snippet showing that change:

What I noticed with a little more experimenting with your original sequence is that the -200015 warning happened sometimes but not always.   I could often turn it on and off by changing the # Pulses/Point.   It make take a pretty deep dive to understand exactly *why*, and I'm doubtful that'll be the most productive thing to do first.  Instead, my advice would be:

- work on fully configuring your CO triggering so that it retriggers correctly.  Based on my understanding of your app, CO should remain a Finite Sampling task.

- change the last sequence frame for DO as I illustrated above.  It should be ok to leave it as a Continuous Sampling task, though Finite ought to be able to work as well.

-Kevin P