I am writing an FPGA application where I acquire data from a unit under test (UUT). The PXI-7842R digitizes 3 groups of signals:
1. an analog voltage monitor
2. 5 digital signals connected to the analog inputs (connector pinout limitation) and converted to Boolean values
3. 11 digital signals connected to digital inputs
That's a total of 1 analog input and 16 digital inputs. I want to show them on the same graph, so I used a mixed signal graph.
To avoid reconfiguring the mixed signal graph every time I open the application, I wrote a subVI to programmatically format the graph. I pass in a reference to the Mixed Signal Graph indicator and try to adjust it to look how I would like. The indicator was built up as a cluster of 1 analog waveform, 2 digital waveform busses of 5 signals, 1 digital waveform bus 3 signals, and 3 individual digital waveforms. The subVI is called inside the Host VI using a case statement controlled by the "First Call" function. Then the Host vi reads out a U32 from the Target-to-Host DMA FIFO, formats the data in the proper order, and bundles everything into a Mixed Signal indicator. When trying to format the graph programmatically I am getting some invalid property errors that seem to depend on state. Unfortunately, the properties documentation seems to be pretty spotty for the errors I'm getting. The attached subVI goes through the following sequence:
1. Configure the shared x-axis and shared properties (IgnoreAttributes, ShowBusseswithLines)
2. Configure the analog plot area Y-scale (top plot, area 0? documentation is spotty on this point)
3. Configure the digital plot area Y-scale (area 1?)
4. Name the digital busses (3 total, should be numbered 0-2).
5. Name the plots
Steps 1-3 complete correctly, but I get an error when trying to set the Active Bus to 0 --> "Error #1077, Invalid Property (Active Bus)".
I tried setting the Active Plot to 1 before configuring the bus, and I get the same error.
But then sometimes if I rerun the Host VI without changing anything, the subVI completes correctly (although the Y-scale area becomes huge and blank). The only way I can remove the errors is to set the for loops to iterate 0 times, let the host VI run a couple of cycles, stop the host VI, remove the 0 constants, and rerun. Then there are no property errors.
I then tried creating an Mixed Signal constant with the correct sequence of empty plots and used it to set the MixedGraph::Value property at the beginning of the subVI. Now Error #1077 occurs at the Active Plot node before the Active Bus node. The trick before about setting the iteration constants to 0 doesn't help when the value property gets an initial value.
Here are my questions:
1. Does the ActivePlotArea property need to be set to use ActivePlots or ActiveBusses, or is that property only for sizing and moving the plot areas?
2. Does the ActiveBus property need ActivePlot to be set first? i.e., if I have ActivePlot=0 (for the analog plot), will the ActiveBus property always fail?
3. What else is required for the ActiveBus property call to function?
4. Why does the subVI fail the first time but succeed on subsequent calls without being initialized yet fails every time after being initialized (unless for loops are set to 0 and subVI finishes once)?
5. Since I am showing a plot legend, I don't want the digital signal names to show up again in the Y-scale area. How do I hide the names but allow the plot area to extend all the way to the plot legend instead of leaving a huge area of wasted white space?
Solved! Go to Solution.
The reason your subVI doesn't work is that the busses you are trying to modify don't exist when you are running it.
If you want to run that subVI as an initializer, you need to first initialize all of the plots you will be modifying.
I included a quick example of how to do this by bundling together an analog waveform constant with some digital waveform constants and feeding that bundle into the "value" property of the Mixed Signal Graph.
Thanks Jim -- that's getting me much closer. I figured it had to be initialization, but I couldn't figure it out.
Now I'm having a new problem - the graph gets formatted correctly during the first loop iteration, but then the formatting gets overwritten during the next iteration. If I stop the Host vi and restart it, the formatting is maintained the entire time.
The call stack looks something like this:
1. The Host VI has the graph indicator to be formatted and a reference that is passed to the Acquisition subVI.
2. The Acquisition subVI passes the reference into a case statement. The case statement calls the Format subVI on First Call and does nothing on the second call.
3. The Format subVI properly formats the graph on the first run of the first execution of the Host. Then the formatting gets wiped. Subsequent executions of the Host VI (stop and re-start) work correctly.
How many levels down can the reference be passed before it stops working?
I atteched the other 2 VIs (Host and Acquire).
Sounds like a shift register might help, running through your states in a state machine. You could keep your settings constant until you change them when you move intentionally to a fork in the program.
It's already functionally a 2-state state machine - initialize the graph, and then populate it with acquired data. My problem is that the initialization doesn't stick after the initialization subVI finishes execution, at least for the first execution of the Host VI. After I stop it and restart it, the format changes are re-applied and hold correctly.
OK, I found out why my careful formatting was getting blanked. I'm doing my data acquisition in a subVI that uses a case statement. It waits for a DMA FIFO to gather enough samples to display.
1. If there are enough samples to update the display (True case), the subVI reads the samples and updates the Mixed Signal Graph indicator.
(see attached image for "Acquire (New Data).png")
2. If there are NOT enough samples (False case), I need some way to avoid blanking the indicator. I was using a feedback node, but that destroys the formatting I just performed! I replaced this with a Read from the RefNum, but the LabVIEW help section on programmatically controlling controls specifically warns against doing this. It does solve my problem, however. (see attached image for "Acquire (Hold Data).png")
Is there an elegant way to hold the current indicator value? I know I could add a control to the connector pane and wire it through, but I don't have a Mixed Signal Graph control anywhere on the top level. (see attached image for "Host.png"; don't know why the RefNum constant in the top left of the while loop changed to a RefNum Control when making a VI snippet; it's still correct on my VI.)