LabVIEW
DAQmx Digital Input and Output and monitoring a specific channel
Solved!
Ok, so I'm not sure this will solve your problem but let's start with some simpler points - maybe from there we can work this out.
- You're passing (via a Shift Register (SR)) the Check/Put/Exit state to the "Count Samples Acquired and ... .vi"
- This VI contains a While loop that in each case exits on the first iteration
- Firstly, if you always want to exit on the first iteration, put the True constant outside of the case structure - it will be easier to read for yourself later or others now
- This looks a lot like a "FGV" or Functional Global Variable, but for that to work, you must have an "Uninitialized Shift Register" - i.e. disconnect the control for "State". By connecting it in the caller (NCh RT v2.0.vi) you prevent the SR in the subVI doing anything at all.
- When you trigger the Exit case in the caller, the While loop also finishes. As a result, it never calls the Exit state in the "Count Samples.." VI.
Moving to less certain things:
- In the Count Samples VI, it looks like you're checking if the sum of a bunch of values is greater than 5. Are you sure that
- a) you have the set of values you want
- b) it ever exceeds 5V?
- See edit at end of bullet points
- How many samples are you expecting in the While loop (from the AI tasks)? I can see you're writing 1 value at the bottom of the While loop, and that the sampling on that channel is driven by the AI task, but you didn't wire a number of samples to acquire to the top task, and probably you'll hit an error at some point with the non-regenerated AO if you're acquiring lots of samples (which you might be, since your loop might be slower than your sample rate and you could be acquiring multiple samples at AI when you don't specify size
- My guess (without running) is that you might be exiting with the lower error state, but it appears as though that would prompt you at the end of the program execution, and I guess you'd have mentioned that (it would probably be the message prompt in Error case, not the Error Handler at the end, because you're clearing all errors.
- Edit: Actually, I guess the intention is for the loop to detect the 5V before it reaches the end, and so you'd possibly not get an error. Maybe you're going into the "Next Trial" case too quickly after correctly detecting, or maybe the 5V doesn't exceed the 5 value (you used Greater Than). Consider checking x > 4.5 perhaps?
As an additional point, if you have the same code for the predictable and unpredictable cases except for the number of samples of 0 to generate for the AO, consider generating that value then moving the rest of the code into a separate state that actually runs the experiment. This will reduce a lot of duplicate (and possibly complicated) code, and simplify both maintenance and reading (for example, you in 3 months or me right now 😉 )
Here's a picture that might describe what I mean a little better.
If you create a simple system with two VIs, one as a "FGV" and the other calling that function, you should be able to see that if you pass the "data" (not enum controlling action) into the FGV, it loses its ability to have memory. This is described more here: Building Single-Execution Uninitialized Shift Registers. Figure 2 and 3 in the basic concepts for SRs (http://www.ni.com/getting-started/labview-basics/shift-registers) also demonstrate this functionality/issue.
@atrinh wrote:How many samples are you expecting in the While loop (from the AI tasks)? I can see you're writing 1 value at the bottom of the While loop, and that the sampling on that channel is driven by the AI task, but you didn't wire a number of samples to acquire to the top task, and probably you'll hit an error at some point with the non-regenerated AO if you're acquiring lots of samples (which you might be, since your loop might be slower than your sample rate and you could be acquiring multiple samples at AI when you don't specify size.
- This is one concept I have always seem to have difficulty with. In the example vi, I would imagine it is a multiple of 2048 x 3 (SampleRate x duration). This number could change depending on the what the user inputs for SampleRate or duration. Do you have any suggestions for making the input for samples to acquire dynamic and appropriate to the user input?
I usually find that the simplest thing for me to do is decide on a loop rate (in your description quoted here, it sounds like you want this to be one second, which probably isn't true because you're also modifying the Visible property in the same loop.
Your task configuration VI, "3Ch Config DAQmx Logging RT v1.0.vi", has a sample rate output. You can use that (along with an appropriate divider, maybe 100 or 50?) to work out how many samples you want per loop. Wire that to the blue "number of samples per channel" input to your Read to specify how large the output array should be (you'll need an integer, so consider rounding up/down).
If you want to have (random*2*sample rate) zeros, followed by a 5V output on your DO, consider just appending 5 to the array you write before starting, and removing the Write inside the loop. I *think* that would have the same functionality. The sample clocking is controlled by the AI.
