LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

code skipping steps: local variable initialisation failure

Solved!
Go to solution

Hi all,

I am upgrading some LabVIEW RT software that I inherited from LabVIEW 2011 to LabVIEW 2015 (32 bit) on a Windows 7 Professional host PC. The target is a PXIe-8135. The software ran well when compiled under LabVIEW 2011.

 

I have modified the code to permit tracking what is going on by looking at display output on the target. The initial error that led me here was that a cluster local variable initialised in the first window of the flat sequence described below were showing up as uninitialised in subsequent windows.

 

The code begins by initialising local variables in the first window of a flat sequence and outputs a quick line of text to the target display (let's call this text #1) (using RT Debug String.vi) I send two lines of text so that a new line is created and subsequent text does not overwrite it. . In the next window of the flat sequence it then writes two groups of text output to the target display monitor. The second text output  in window 2 (text  #3)has an input wire running from  the error out from the first text output in the second window (text #2). I.e. the second output has to wait for the first output to complete before being sent to the display.

 

I am now seeing some weird symptoms:

1. When I connect to the target under a remote debugging session I see the expected display outputs. When not remotely connected, text #2 does not display. The code proceeds to the third window in the flat sequence so everything in window two should have executed.

2. Text #1 appears on the target display *before* I get the message "Welcome to LabVIEW Real-Time 15.0". Is this normal? Where is this message coming from? I searched my vis and subvis for this text and it is not there so it mucst come from LabVIEW vis somehow.

 

This all began with local variables not initialising in the first window, so I apparently have a data flow issue. Since the problem goes away under remote debugging I am at a bit of a loss.

Thank you in advance for any assistance,

Eamonn McKernan

 

 

0 Kudos
Message 1 of 7
(3,699 Views)

Wow, that's amazing code.  Thank you for supplying a VI that fits in a very small space (smaller than a period ...)

 

Why are you telling us this?  What do you think we can do to help?

 

Bob Schor

0 Kudos
Message 2 of 7
(3,686 Views)

You were a bit all over the place.  Without code, that makes it rather difficult to give you any strong advice.

 

You say you were responsible for Text #1.  Later, you say you can't find Text #1.  (Or were you trying to say you didn't add the welcome to RT message, which of course would be something added by NI. It's part of the OS and has nothing to do with your VI).

 

You bring up local variables and suggest you have a dataflow problem.  That's often the case with local variables as they break dataflow.  But, I'm not sure I'd agree with that problem without having a better idea of what's going on in your code.

 

What do you mean by initialized?  What do you mean by windows? 

 

When you say you're not remotely connected, how are you running the VI?  Do you have it set to run as startup?

0 Kudos
Message 3 of 7
(3,680 Views)

I've had similar behaviours with code that had several Locals and thus race conditions, when upgrading. What seems to have happened is that the recompile changed in which order some things happen causing this. That's pretty typical of race conditions, you dont know when they'll hit ... This is ofcourse assumptions as there's no code to look at, but i believe that working away race conditions will solve the problem.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 7
(3,649 Views)

Thank you for all of the replies. Please excuse a newbie for not providing enough information.

 

I have attached two screenshots from the code. It is a large piece of software so I have grabbed the relevant elements. The Text 1 image shows the code initialising local variables. This happens in the first window of a flat sequence. Text 2and3  shows the next window in the flat sequence writing text 2 and 3. It is a bit messy because of the debugging code I have added. The VIS Cam image Server parameters are showing up as empty when passed forward to the second window.  Text 2 only displays when remotely connected It does not show up when run at startup. This is very odd. I even tried adding a 10 second delay before the first window of the sequence and text 2 still does not print except when remotely connected.

 

When I remotely debug I stop and restart the code. Then I try probes and highlighting execution. Since the behaviour is not consitent however, these usual debugging techniques are not applicable.

 

Since the initialisation occurs in a flat sequence race conditions should not be an issue.

 

Thank you again in advance for any help you can offer.

Download All
0 Kudos
Message 5 of 7
(3,612 Views)
Solution
Accepted by RavensFan

@EamonnMcKernan wrote:

Text 2 only displays when remotely connected It does not show up when run at startup.


Your "Text 2" appears to be fed by a feedback node set for "initialize on compile or load".  This will return an empty string the first time and so shouldn't be displaying anything until the code i run a second time.  What is this feedback node for?

0 Kudos
Message 6 of 7
(3,604 Views)

Boy that is unexpected. This was not in the original code so it was somehow added by LabVIEW during the upgrade. I have removed the feedback node and with the delay on startup it is now working.

Thank you!

0 Kudos
Message 7 of 7
(3,566 Views)