LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Application Broken with error 6208 on a particular PC

Solved!
Go to solution

@Fedor wrote:

Ben,

 

Thanks for quick reply. I have the source code. The number 6208 does not appear to be an error code, but an error type number, whatever it could mean. I do not think is is a custom error code either since exact same behavior was reported on the forum by others before.

 

I would like to re-iterate that the application runs fine from within the LabVIEW development environment in all versions of LabVIEW tested.The application compiles into executable.The executable runs fine in all versions of runtime engine but the 2019 SP1.

 

I do not have tools to identify the reason for this run-time engine behavior. I'm wondering if NI might have them in house.


Did you try searching the code as Ben suggested? There is no "Error Type Number" in LabVIEW other than the Error Code. 6208 is definitely in the Custom Error Code range. Are you using some third party drivers? If so perhaps you and the previous poster(s) are using these same third party drivers. If these drivers are not accessible then you would need to contact the driver manufacturer about the error.

0 Kudos
Message 11 of 23
(1,925 Views)

I was able to reproduce the problem with a simple example, using just Labview built-in Xcontrol and Actor Framework tools. 

 

The problem pops up when I include a reference to Xcontrol into class data. Please see attached code.

0 Kudos
Message 12 of 23
(1,906 Views)

There is a part of my brain that says "XControls and Classes do not mix" but that may be dated.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 13 of 23
(1,898 Views)

Thanks for looking into it Ben.

 

I would like to note that application with this mix of Actor Framework and Xcontrols has been working fine for the past  5-6 years through all the LabVIEW versions. It still works fine in 2019 SP1 IDE, but is broken when opened  in run-time engine with undocumented and untraceable error type. 

 

It might be possible to reproduce the problem without using LabVIEW classes if only I had all the time in world to try and figure it out. 

 

Most of the older posts with similar error behavior point to missing or outdated dlls. I wonder if NI own runtime engine developers could look into it.  

0 Kudos
Message 14 of 23
(1,879 Views)

I can offer only a bit of a guess.

 

There was an issue going back to about 2017 where under some unknown condition, LV would loose track of Class constants. In LV 2017, LV would not be able to detect the issue until the class was actually used in running code. But if you chased down into "every crook and nanny" you would eventually find a class constant that appeared to be "grayed out". Replacing that instance of the constant fixed the problem.

 

Latter "someone in another private forum" figured out how to find those constants programmatically. That "work-around" was then integrated into latter versions of LV such that LV will now break when that grayed out class constant was detected to help us notice and fix the problem.

 

So...

 

Since it seems you have the source code, chase down the broken VIs looking for a funky class constant.

 

If that does not help you, maybe it will help others.

 

Doing what I can,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 15 of 23
(1,853 Views)

Hi Ben,

 

I would like to re-iterate that the source code is not broken. Would you have a minute to take a look at the source code attached to this post and the resulting application, if you have LabVIEW 2019 SP1 installed?  The attached source code consist of a single class and a method. Storing a reference to a control in class data breaks compiled app in SP1, but not in earlier runtime engines.

 

 

0 Kudos
Message 16 of 23
(1,842 Views)

In 372 days, yes.

 

Until then I am under restrictions.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 17 of 23
(1,837 Views)

I tested the bug with March 2020 patch: LabVIEW 2019 SP1 f1 Patch.

 

The bug is still there:

sp1fp1.png

 

How can I bring it to LabVIEW bug fixing team to have it addressed in the next patch? I know there's a list of known issues floating arround somewhere. How the issues become known to National Instruments? I've emailed it to our representative last year, was redirected and the issue killed I guess(?)

 

0 Kudos
Message 18 of 23
(1,789 Views)

We had the similar error in our application (type 4E7E8, LabVIEW 2017 64bit, Win10) when we enabled the setting "allow future versions of the labview runtime to run this application" in the build specification. Disabling solved the problem.
allow future versions of the labview runtime to run this application.png

--
Certified LabVIEW Architect
www.merecs.de
Message 19 of 23
(1,736 Views)

I just tested the suggestion to disable "allow future versions ..." option in the build settings, but the resulting application remains broken. 

 

I also note that the only LabVIEW runtime engine version that have this bug is 2019 SP1. Every other version, including 2017, worked fine.

0 Kudos
Message 20 of 23
(1,718 Views)