12-19-2023 05:50 AM
I have a PCIe 6738 that I want to use to generate a train of pulses with varying amplitude. A PCI 6225 will then measure the average response of a connected device.
Example
Start generating a pulse train with amplitude 1V for some amount of time until the measurement has completed. Change the amplitude to 2V and measure again. Etc.
The idea to output a pulse train was to simply output an array of [1,0] and allow regeneration. Then I just want to change the amplitude in the following way:
However, this generates
Warning 200015 occurred at Test Low Level Output Train.vi
Possible reason(s):
While writing to the buffer during a regeneration, the actual data generated might have alternated between old data and new data. That is, while the driver was replacing the old pattern in the buffer with the new pattern, the device might have generated a portion of new data, then a portion of old data, and then a portion of new data again.
Reduce the sample rate, use a larger buffer, or refer to documentation about DAQmx Write for information about other ways to avoid this warning.
I don't really care about this since I average a lot. But the thing is that the ouput voltage doesn't change at all. I measured it with an oscilloscope and the voltage always remains 1V. Any suggestions?
12-19-2023 06:08 AM
Hi Basjong,
@Basjong53 wrote:
But the thing is that the ouput voltage doesn't change at all. I measured it with an oscilloscope and the voltage always remains 1V. Any suggestions?
Because you place the error wire into a shift register.
When that error happens at the very first DAQmxWrite operation (writing the "1" sample) all following DAQmxWrite operations will not do anything useful… DAQmx uses "default error handling"!
12-19-2023 06:22 AM
It's not an error though, it's a warning. Indeed, replacing the shift register with tunnels doesn't solve it. The output always remains a pulse with amplitude 1.
12-19-2023 07:41 AM
Theory (b/c not around h/w to test):
Your buffer size is set to 2 samples b/c that's how many samples you wrote to the task prior to starting it. That doesn't leave much wiggle room for DAQmx to manage your subsequent writes and also the process of transferring data repeatedly to your device.
At least in this example, you could easily write the entire pattern before starting the task [1,0,2,0,3,0,4,0,5,0]. Try that out, verify that it works better, then come on back if such an approach won't be suitable for the real app you have in mind.
-Kevin P
12-19-2023 07:43 AM
Hi Basjong,
@Basjong53 wrote:
It's not an error though, it's a warning.
Sorry, just focussed on that error code (number)…
@Basjong53 wrote:
The output always remains a pulse with amplitude 1.
You set a sample rate of 1000 S/s and output just two samples: this just takes 2ms before your DAQ device starts to re-use the buffer. I guess you aren't fast enough to refresh the buffer before the next cycle starts…
02-02-2024 07:27 AM
I have come back to this project after a while. I want to clarify the situation. Basically, the final application will be a PID-like control system where a current output is the setpoint and the voltage output the process variable (basically make a software version of a galvanostat). The output has to be pulsed (between 0 and set current). I therefore need to continuously update the write buffer based on the response of the DUT.
But I am unable to update the output voltage. I have made a sample VI that more closely resembles the situation:
I cannot create the entire waveform from the start as I know only the first value with subsequent values being dependent on the DUT. I tried to follow the suggestion of @GerdW by making the buffer larger, but the output voltage still doesn't change even though I do not get the warning from my first message anymore.
What can I do to allow updating the output voltage of a buffered write setup? Am I going in the completely wrong direction here? Or am I missing something obvious?
02-02-2024 11:12 AM
IMHO, you aren't going to get there from here without some additional hardware. This is not meant to discourage, just to save you from some time-wasting dead ends.
What I see are some circular dependencies that are incompatible.
1. You plan to pulse your output with a 2000 Hz sample rate where, for each pair of samples, one is 0 and the other is >0.
2. This sample rate calls for sample timing with a hardware clock.
3. Hardware-clocked tasks at 2000 Hz need a buffer.
4. A buffer adds latency between updating your desired output value and seeing it become a real-world signal.
5. The amount of latency will probably be variable.
6. But the output is also part of a PID control loop.
7. PID control isn't particularly tolerant of latency, even moreso when the latency varies.
What you probably need is a fairly simple external circuit that performs PWM on a variable voltage output. You can supply the on/off PWM with a 2000 Hz counter output from your 6738. And you can change the voltage output with an unclocked, unbuffered, software-timed on-demand AO task which will have minimal latency (though also limited and variable update rate).
Something like that.
-Kevin Price
02-05-2024 06:11 AM
Thank you very much for the detailed reply. The 6738 is actually already connected to an external operational amplifier that has an enable/disable function. As the idea is to control multiple channels in parallel, each output port is connected to one of these operational amplifiers. The enable pin of each op-amp is also connected to a digital line of the PCI 6225. I could use these digital lines to generate the pulsing behaviour as you suggested.
I ran into problems implementing it however. A counter output seems to be the simplest for generating a PWM signal. Unfortunately it can not be routed to the digital outputs it seems.
Can you maybe point me to a tutorial on digital outputs with DAQmx? I have been trying it but wasn't succesful. Applying my experience with analog output, I thought digital write would work the same and this should toggle between 0 and 1 with a rate of 10 (for testing purposes). But it remains 1. When I swap the elements in the array, the output remains 0. Any suggestions?
I have tried to run the "Digital - Continuous Output.vi" from the examples, but it times out at the DAQmx Write vi...
02-05-2024 07:14 AM
From your description, it sounds like you're literally running the exact code you posted where execution ends immediately after you write data to the task. When execution ends, LabVIEW & DAQmx do garbage collection on allocated resources and your task gets cleared almost immediately after you auto-start it, leaving your DO lines in whatever was their last state when the task is stopped & cleared. I don't think I would count on it *always* ending with the last value in the buffer, but it could be the case that having such a tiny buffer makes it more likely. You could always experiment if you were curious by writing a 5 second buffer of alternating values that you stop abruptly.
A counter would be an easier way to generate PWM, but you'll be limited by the # counters (4) on your device. There are examples to illustrate counter output. Probably the key thing is to know that many lines do double duty as both DIO and PFI functionality. When routing timing-related signals, including all counter outputs & inputs, you need to reference the pin by its PFI designation, not as "port x / line y".
Dunno why your example times out. Are you sure it's at DAQmx Write? What specific error # and text? What config settings did you change?
-Kevin P
02-05-2024 07:33 AM
Ah, no no, the full code I ran is this:
I then run this code in parallel to check the signal:
I would need to pulse 32 channels in the final product. If I can route the counter to multiple digital outputs, that would be acceptable, the PWM signal do not have to be independent on all channels. If this is the case, how can I know which digital pins are connect to which PFI? It is not reported in the Device Routes in NI MAX.
Regarding the time-out in the example, yes, it happens at DAQmx Write. Enabling "Highlight execution" shows that it's blocked there. I only changed the Sample Clock Source to OnboardClock, since I don't use an external clock. All else default. No trigger. Here's the error:
Error -200292 occurred at Digital - Continuous Output.vi
Possible reason(s):
Some or all of the samples to write could not be written to the buffer yet. More space will free up as samples currently in the buffer are generated.
To wait for more space to become available, use a longer write timeout. To make the space available sooner, increase the sample rate.
Property: RelativeTo
Requested Value: Current Write Position
Property: Offset
Requested Value: 0
Task Name: _unnamedTask<13F>