Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Analogue output with double or circular buffer

I would like to identify hardware and LabVIEW code to implement a continuous Digital-to-Analog conversion that occurs on a trigger. It's a continuous process, so I cannot pause to re-load the buffer at any time.
I'm machining a grid pattern line-by-line, each analogue value is clocked-out of the DAC when an in-position trigger is received from a motion system.

To make the problem slightly more tricky, the motion system occasionally produces an extra unwanted pulse at the end of a Scan Line. To compensate for this, each line is zero padded at the end (zero equates to no mark on the workpiece).

 

e.g. DAC values might be:

Line0: 8 2 2 4 4 4 2 2 8 0 (9 pulses received, zero goes unused)
Line1: 7 3 3 5 5 5 3 3 7 0 (10 pulses received, the extra unwanted pulse clocks out a zero)
Line2: 9 1 1 2 2 4 1 1 9 0 (9 pulses received, zero goes unused)

 

LabVIEW can interrogate the motion system to find out when each line has completed, or a separate digital trigger pulse could be created to signal the end of a Scan Line. End-of-line signal could trigger a flipper over to a second buffer, or in the case of a circular buffer, the end-of-line signal could move a pointer to the start of the next line. e.g. Line0 end-of-line signal could move the memory location pointer from "8" to "7". Line1 end-of-line signal could move the memory location pointer from "0" to "9".
The whole time the system is running, we can write more data to the buffer and the process will continue indefinitely. The actual line length may be up to 16,000 points.
At present I have a PCIe-6341 with a buffer of 8192 elements. I re-load the complete buffer by pausing the process at the end of the Scan Line, it's way too slow and I'm limited to 8192 elements per line.

0 Kudos
Message 1 of 8
(2,082 Views)

I'm pretty sure I don't *completely* understand your situation, but here's an assortment of thoughts:

 

1. The occasional unwanted pulse seems like the biggest obstacle to a clean hardware-signal-based solution.

2. I would get in the habit of thinking about the motion system's pulse as an "external sample clock" rather than a trigger.  It matches the DAQmx task terminology better.

3. It isn't clear what the timing might be between "in-position" pulses.

4. It also isn't clear what timing you'd need to meet between end-of-scan-line and start-of-next-scan-line.  The more time you have, the more likely a decent solution can be found.

5. In general, you won't be able to directly manipulate pointers into the AO buffer based on hw signals the way you seem to be describing.

6. The 8191 sample buffer refers only to the *onboard* FIFO.  There's also a PC memory *task* buffer whose size can be much larger.

7. An end-of-scan-line pulse could be a helpful addition.

8. An alternate approach that could also be helpful is to add a "scanning active" signal for use as a DAQmx Pause Trigger.

9. I recently did my first dabbling with DAQmx Events for buffered AO to get low latency between writing new data to my task and having it show up as a physical output signal.  The point is, there are ways to feed new data to the task pretty much just in time for it to generate.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 8
(2,050 Views)

reworded to make it a bit clearer:

 

Analogue output with double or circular buffer.

I would like to identify hardware and LabVIEW-code to implement a continuous Digital-to-Analog conversion that occurs on an external sample clock. It's a continuous process, so I cannot pause to re-load the buffer at any time.
I'm machining a grid pattern line-by-line, each analogue value is clocked-out of the DAC when an in-position trigger is received from a motion system.

To make the problem slightly more tricky, the motion system occasionally produces an extra unwanted pulse at the end of a Scan Line. To compensate for this, each line is zero padded at the end (zero equates to no mark on the work-piece). Being 1 pulse short is also possible, if there is an extra pulse or 1 pulse short, come the next line, the DAC must output the first value for the new line.

 

e.g. DAC values might be:

Line0: 8 2 2 4 4 4 2 2 8 0 (9 pulses received, zero goes unused)
Line1: 7 3 3 5 5 5 3 3 7 0 (10 pulses received, the extra unwanted pulse clocks out a zero)
Line2: 9 1 1 2 2 4 1 1 9 0 (9 pulses received, zero goes unused)

 

LabVIEW can interrogate the motion system to find out when each line has completed, or a separate digital trigger pulse could be created to signal the Start or end of a Scan Line. End-of-line signal could trigger a flipper over to a second buffer, or in the case of a circular buffer, the end-of-line signal could move a pointer to the start of the next line. e.g. Line0 end-of-line signal could move the memory location pointer from "8" to "7". Line1 end-of-line signal could move the memory location pointer from "0" to "9".
The whole time the system is running, we can write more data to the buffer and the process will continue indefinitely. The actual line length may be up to 16,000 points but we can continue writing to the buffer mid-ScanLine.
At present I have a PCIe-6341 with a buffer of 8192 elements. I re-load the complete buffer by pausing the process at the end of the Scan Line, it's way too slow and I'm limited to 8192 elements per line. I also have a counter-timer function that counts the number of pulses received from the motion system.
The frequency of the external sample clock will be 0.5 to 4kHz. The accel/decel region between scanlines where no pulses are received is approximately 500 time periods of the 0.5 to 4kHz external sample clock (position trigger). An end of Scan Line pulse could be generated by the motion system.

 

If you imagine we have a linear FIFO buffer for the example above:

Index 0  1  2  3  4  5  6  7  8  9  10 11 12 13 15 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Volts  8  2  2  4  4  4  2  2  8  0   7   3   3   5   5   5   3   3   7   0   9   1   1   2   2   4   1   1   9   0

At the end of Line0 we've clocked out 8volts(Buffer Index8), the end-of-line signal arrives, so buffer pointer jumps to Buffer Index10, the start of Line1. The program will be loaded with Buffer Index 0, 10, 20 to correspond with Line 0, 1, 2. In other words, you must be able to manipulate a pointer that determines which value from memory is clocked out next, or switch to Index0 of a separate buffer.

0 Kudos
Message 3 of 8
(1,968 Views)

I think the fact that you can also get too FEW external pulses paints you into a corner.  For buffered AO, you MUST define the possible AO sample values and write them to the buffer at least a little ahead of those pulses.  But then if not enough pulses arrive, it's too late to *remove* the extra value back out of the buffer.

 

There might be a glimmer of hope though I can't say for sure.  I've fairly recently learned of a new-ish (to me anyway) buffered AO option that didn't used to be supported -- the ability to regenerate for a while but then also update the values in the buffer without stopping.   I haven't experimented, but it's possible some other useful capabilities have started being supported through the DAQmx Write property node.

 

For AI tasks, there are DAQmx Read properties for "Offset" and "RelativeTo" that give you some options about what part of the task buffer to extract data from.  Similar DAQmx Write properties have tantalizingly existed for AO tasks, but the last time I tried dabbling (maybe about a decade ago?), they weren't actually supported and caused errors.  I won't have a chance to test them out anytime soon, but they *might* give you a chance to move the "write pointer" around.  Note that this is *only* the PC memory task buffer write pointer.  I'm almost certain there won't be support for direct manipulation of an onboard FIFO.

 

Among the complications however are that the DAQmx driver is in charge of moving samples from the task buffer down to the board's FIFO.  Even if you have some ability to move your task buffer write pointer, you still may not be able to coordinate sufficiently with DAQmx to make sure you get the behavior you want.  If the pre-written sample you'd like to *avoid* generating has already been transferred down to the board by the DAQmx driver, it'll be too late.

 

That leads me to suspect that you'd likely need to keep approaching this 1 line at a time.  Software will need to react to some signal that designates "end of scan line", stop the AO task, write new values to the buffer, and restart the task again.   You won't need to write 8192 samples all at once, just enough to buy time until you can write the next chunk.

 

Yeah, the more I'm working my way through this, the more I think you'll be needing to handle each line discretely, and restarting the AO task for the start of each line.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 8
(1,957 Views)

Thanks for the reply Kevin,

I have the system running at present on a line-at-a-time basis.  At the end of each line, I completely reload the buffer with the values for the next line, then send the motion system back along the line.  If I can design a system without the buffer reload pause at the end, we can manufacture 50% more product.

I'm also looking at various micro-processor options with a view to designing a dedicated control module for the task.  I will be a lot more work, but still economical due to the improved speed of machining.

0 Kudos
Message 5 of 8
(1,953 Views)

Maybe we should focus on your slow buffer reload.  It seems to me like that shouldn't slow the process down appreciably.  You said that your equipment presents you with roughly 100's of msec of non-generation time between lines due to motion accel / decel.  It also sounds like each scan line typically occupies multiple seconds worth of time. 

 

I find it surprsing that writing data to your task buffer should be a pacing item.  I would expect it to fit seamlessly in the 100's of msec between scan lines and not slow down your overall process at all.   Is it really taking multiple seconds?!?    That's highly unexpected unless there's a lot more going on than you've described (like retrieving the next scan line of data from a network-connected database or something?).

 

 

-Kevin P

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 8
(1,949 Views)

yes, your right.  the comms with the motion system is actually what takes most of the time, the PC waits for a motion complete flag before reloading the DAC buffer then commanding the target position for the next line.  The concept I'm working with at present, is removing the comms with the motion system by moving the whole raster scanning job to the motion controller DSP.  The problem I'm left with is synchronising the buffered DAC with the motion.  I can use the motion system to generate pulses for each grid position, and end of line pulses.  BUT it's prone to not producing the exact number of pulses required for each line.

if during the scan, the buffered value wrapped round due to incorrect number of pulses, the product would fail:

Line0 11111

Line1 22222

Line2 33333

perfect.

 

Line0 111110

Line1 2222

Line2 33333

is okay, the zero pad on Line0 saves it. 1 pulse short on Line1 is okay.  Line2 is correct.

 

111112

22223

3333

fail. Line0 has a value intended for Line1.

In summary, 1 pulse extra or short per line is okay.  Values on the wrong line, not okay.

 

I'm fairly sure I could implement what I need using an NI compactRIO product.  But, if I need to go to those lengths, for packaging reasons, I'd be better off designing a dedicated single-board solution based on a MicroController product.

You are right in pointing out, that once I've moved the raster scanning to the motion controller DSP, the time penalty of reloading the DAC buffer from LabVIEW might not be too severe in the overall scheme of time-taken.  If I generated a line complete flag during the deceleration phase, I could probably complete the reload of the DAC buffer during the turn-around.  I think I need to experiment with how long the buffer load actually takes.  Then figure out how to add to the buffer during the line scan.

0 Kudos
Message 7 of 8
(1,943 Views)

If you're going to move more of the smarts and control to the motion controller DSP as a throughput enhancement anyway, I think you could get pretty robust with a 2-way handshake between the DSP and your normal PC.  This assumes that you can configure or program the DSP to wait for a signal from your 6341 before it starts the next scan line and also generate a signal for your 6341 to receive when it finishes a scan line.

 

That way, even if there's a rare, occasional slow buffer reload, you won't get out of sync and make a ruined product.  The motor controller will wait until you give it the OK after having loaded up enough samples to the buffer. 

 

Note: you'll probably need to do explicit buffer sizing, possibly with a DAQmx Buffer property node.   One of the default behaviors is to auto-size based on the amount of samples you first write before starting the task.  You'll probably want to write to the buffer a little at a time for each scan line, but you'd want a buffer size that's much larger than the size of the chunks you write.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 8 of 8
(1,936 Views)