From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bug in the project template? Continuous measurement and logging

Solved!
Go to solution

Hi,

 

I'm using the "Continuous Measurement and Logging" project template.

In the Main.vi, the error message case seems wrong.

In default, error out from "variant to data" is connected to the "Error Handler.vi". However, "variant to data.vi" does not output error unless the non-error data type is fed to the "variant to data.vi" so that error occurred in other loops never be correctly handled.

In my opinion, "data" output from "variant to data.vi" should be connected to the "Error Handler.vi"

 

Thanks!

Download All
0 Kudos
Message 1 of 7
(2,415 Views)

Based on the two pictures you attached, I completely disagree.

 

Is that subVI at the end of the pictures the Error Handler that is talked about in the yellow comment box?

 

If so, you've created and endless cycle.  Some loop somewhere has an error and puts it in the error handler function as a message.  It goes to this VI which then displays the error.  But your modification would put that message back into the error handler subVI again causing the whole cycle to repeat.  As future errors get generated, they get added to the queue creating an ever longer list of error messages to be displayed over and over again.

 

Have you run your code with your modification?  What have you observed?

Message 2 of 7
(2,386 Views)

Thank you RavensFan for the reply.
 
I should have explained the whole structure of the template.
 The "main.vi" in the "Continuous Measurement and Logging" has some subloops such as "Acquisition Message Loop".
 
Errors in the subloops are handled up to the "UI Message Loop". "Error handler.vi" in the "UI Message loop" is supposed to judge exit or continue with the error.
 
However, in the original configuration, handled up errors are not passed to the "Error handler.vi" so the vi cannot be shut down.
  
Please check the attached project. I added a simulated error in the acquisition subloop. Nothing else is modified. The acquisition subloop continues to work so that the same error is continuously generated.

Download All
0 Kudos
Message 3 of 7
(2,214 Views)

I've not yet installed 2019 so I can't open your code. In looking at the sample project in 2018 the original code appears to be correct. You enter the error handler which decides whether to send a message (go to the Error case) or exit (Go to the Exit case). Changing this would seem to get to an endless loop where it's constantly going to the Error case. Of course if you have not changed code inside the Error Handler you will never get to the Error case as the default is to Exit on error.

0 Kudos
Message 4 of 7
(2,186 Views)

Thank you johntrich1971 for the comment.

As you pointed, "error handler.vi" in the "UI Message Loop" can handle the error correctly to exit if the error occurred in the "UI Message Loop".

The problem is error occurred in other Loops such as Acquisition Loop. The default setting in "error handler.vi" in other subloops chooses the error case on error, not to the exit case.

 

"Error handler.vi" in the "UI Message loop" is supposed to handle the forwarded errors from subloops, but errors from subloops never arrive the "Error handler.vi" in the default wiring.

0 Kudos
Message 5 of 7
(2,180 Views)
Solution
Accepted by topic author oxalis

It appears that the code is structured so that it does not exit on the subloop. If you want to always exit on error then you should change that in the subloop. Otherwise you are going to be displaying the error message twice.

Message 6 of 7
(2,178 Views)

Thank you, I got the structure concept!

0 Kudos
Message 7 of 7
(2,101 Views)