03-13-2025 01:05 PM
Windows 10 Enterprise
TestStand 2021
LabVIEW 2022.3.1f8 configured in developer mode
I have a vi that runs fine when I open it in LabVIEW, but when I get to the step that runs the VI in TestStand I get this error:
I have mass compiled the project and run the sequence analyzer. The analyzer RULE just says Code modules must be able to load. I do not know why this is unable to load when the vi runs fine when I open it in LabVIEW. I am migrating working code from NI2013/TS2013 and have done the mass compile and am looking for the inevitable problems that I know will be in here. But nothing tells me what this problem is.
What else can I look for?
be well,
DLC
03-13-2025 05:01 PM
Additional information. When I removed the vi from the sequence and added it back, two things I have never seen before happened.
When loading the vi after I showed TS where the file was, TS complained it could not find:
Trim Whitespace One-Sided.vi
and
LVPointTypeDef.ctl
I located them both deep within the bowels of LV in
LabVIEW 2022/vi.lib/utility/error.llb and miscctls.llb.
Why did it not know this? I am not calling those VIs, so they must be buried within other VIs.
But it didn't matter. The same vi failed in the same way. Again, the vi says it isn't broken, and it runs fine in LabVIEW, so for some reason it does not work in LV when called from TestStand.
I found a debug file SeqEdit_BrokenVILog.<timestamp>.txt that says this VI is broken because of the above things.This is what the ctl "looks" like:
It set the origin of my front panel
If I remove this property node from my VI, the problem goes away. Is it no longer possible to set the origin of a control panel?
I do lots of "trim white space" in this VI.
If I remove the trim, the error goes away. Why are these broken? Is it not possible to set the origin of a control panel and trim white space in LV 2022?
be well,
DLC
03-13-2025 10:07 PM
Hi,
Does your sequence execute if you change the LabVIEW adapter to use LV development system instead of the LV Runtime engine?
If so, I would suggest shutting down both LV and TestStand and mass compiling your VIs again.
Can you check the option for giving a warning for read-only VIs before mass compiling and can you post any messages that show up in the mass compile log.
Regards,
Anand Jain
NI
03-14-2025 11:03 AM - edited 03-14-2025 11:06 AM
@Anand_Jain wrote:
Hi,
Does your sequence execute if you change the LabVIEW adapter to use LV development system instead of the LV Runtime engine?
If so, I would suggest shutting down both LV and TestStand and mass compiling your VIs again.
Can you check the option for giving a warning for read-only VIs before mass compiling and can you post any messages that show up in the mass compile log.
Regards,
Anand Jain
NI
Anand,
I have done a few mass compiles with this project.
I have not even tried the run-time engine, I have been in dev mode the whole time. The MC log didn't mention the VI at all. It complained about several other VIs for a variety of reasons. Not unexpected since 9 years have passed since this project was written. The sequence analyzer just said it couldn't load the VI.
As I noted, the TestStand debug error file pointed to these two dependencies as a problem. LabVIEW itself had no problems, only TestStand complained. But even when I provided the locations for the VI and the ctl, TestStand would not load the VI. The only way to make it work was to remove those two dependencies.
I have gotten the code to work, but the question remains, why is this happening?
This NI2013 project uses many of the same named VIs that a prior NI2010/TS 4.2.1 project that I have already migrated to LV2022/TS202. I noticed that this TS project has taken dependencies from that other project to use without telling me. So, my feeling is there there are dependency conflicts that may be causing issues. So I am merging the two projects together to use the same code base (which I wanted to anyway to maximize code reuse and minimize support issues).
I have a feeling that NI has been "helping" me behind the scenes and gotten confused about where things are - which does not surprise me.
I knew this migration task was going to be complex and would be a journey of discovery.
Learning = 70% doing, 20% mentoring, 10% class instruction. SO true.
be well,
DLC