If you update a graph on the main vi in a subvi by wiring a reference, the graph on the main vi lags behind one reading

[SegmentationFault]

Sorry about the long title, but it was the most concise way of summarizing I could think of. Anyways, I am having the above problem. The user can select a device and then the subvi corresponding to the device is executed. This subvi takes power readings and plots them on the graph. However, the graph on the main panel is always lagging behind one reading. I know this is happening because I placed a graph on the panel of the subvi too, and that graph was working fine, while the one on the main panel lagged behind. 

This seems to cause a problem with auto-scaling too, as the graph on the main panel will not auto-scale until it receives the last reading, but it never receives that unless you run another power meter test, in which case the first value received completes the older graph, which seems very strange to me. I did notice, however, that if you go to plot properties after the subvi has finished executing and you select different axes (without changing anything), the graph will automatically scale correctly. 

Does anyone know how to fix this issue?

[RavensFan]

While updating something by way of references and properties nodes will take a bit longer than if you updated the indicator by directly wiring to its terminal, you really shouldn't see a "lag by one" type situation.

My guess it has something to do with the way you programmed your subVI.  Please post your main VI and subVI so we can see.  If you can, try to simplify things to give us the most concise VI's that demonstrate the problem without giving us your entire application.

[SegmentationFault]

I am positive it is something I am doing, I am just not sure what it is. Anyways, attached is part of an application that has this problem. The VIs in this application are pretty straightforward, so it shouldn't be too hard to understand. I put comments in too. Thanks for your help! 

[RavensFan]

I can't run your VI because you are missing some VI's, and also, I don't have your instrumentation.

One recommendation I have is to abandon those ancient serial port functions and use VISA read and write functions.

Nothing jumps out at me as to explain why things are lagging like you say. But perhaps it has something to do with using a special LabVIEW class of that 3-D graph indicator.  When I started reading this thread, I thought you were dealing with a normal XY graph.  Perhaps someone who is more familiar with how that special 3-D indicator works can look into this.

[SegmentationFault]

Yeah, I didn't supply the other VIs because you can't run the program anyway without the equipment I am using. =/ As far as the serial port functions go, I remember there was a reason I was using them, but for the life of me I can't remember what it was...

Anyways, it is not just this graph that has this problem. I am doing a similar thing in another application and the same thing happens, although it is with another 3D graph. 

[Sarci1]

Hi SegmentationFault, I created a VI which replicates this and am still looking into a possible setting that might need to be changed or another method we could use to perform this operation. May I ask why you are not performing this operation within the main VI or using the output of the subVI? Best, Lynn

[SegmentationFault]

I am not performing this operation in the main VI due to request. I am also not using the output of the VI because I want the graph to update with each value, rather than waiting until the test is finished to see an updated graph.

[Sarci1]

Hi SegmentationFault,

I believe I have found the issue.  The 3D Stem plot will update in the main VI until execution stops. If execution stops prior to the final data acquisition you have the potential to miss the last data set. 

In order to get around this we can use execution flow to ensure that the last set of points gets plotted. To do this, output the last data set from your subVI to your main VI and plot it on your 3D Stem graph.  

I am including the three VIs I used to demonstrate this.  Feel free to run both main VIs with the same subVI to observe the differences.

[SegmentationFault]

Are you sure about that? My subvi should not stop executing before final data acquisition because it takes the arrays and outputs them to a data file.

Furthermore, this behaviour is reflected even at the very first reading. The first reading doesn't actually appear until the second reading is done, so the explanation seems wrong to me. But perhaps I am misunderstanding something fundamental. 

Although instead of doing what you did, I just used the purple wire as output and wired it to a property node (I have to do it this way because of scope issues. I need to put it outside of an event structure, but not all events will print to the graph and I don't a default value going to the graph in those cases). 

[Sarci1]

Hi SegmentationFault,

I looked into this issue a bit further and compared it to the response of an XY graph and you are correct the behavior is faulty.  I am going to file a Corrective Action Request on this issue.  For now, however, I would suggest using the workaround of output the last data set from your subVI to your main VI.

Thanks!

Lynn