In Teststand 2021 set adapter to use my 2022 Labview, it insists on using LV 2013

[DLMC]

I have a NI 2013 Teststand project that I opened in Teststand 2021 and configured the adapter to use my Labview 2022.

When I execute using  "Test UUTs" or just run the MainSequence on this project it says this:

TestStand cannot locate a LabVIEW Run-Time Engine of version '13.0' and bitness '32-bit'.

I configured teststand to use my development LV 2022.  But this is being ignored.  Where else could vi's be told which runtime or developer engine to use?

be well,

DLC

[Oli_Wachno]

Does your project use a custom ProcessModel?

[ShockHouse]

Per each step, you can set the step to use the LabVIEW Run-Time Engine regardless of the adapter settings.

If that is the case, you can select the little tool on the top right of the Module tab for the step to disable it.

[DLMC]

Does your project use a custom ProcessModel?

It doesn't look like it uses a custom Process Model.

be well,

DLC

[DLMC]

Does your project use a custom ProcessModel?

It doesn't look like it uses a custom Process Model.

be well,

DLC

[DLMC]

Per each step, you can set the step to use the LabVIEW Run-Time Engine regardless of the adapter settings.

If that is the case, you can select the little tool on the top right of the Module tab for the step to disable it.

In this case if that was set then it would run the LV 2022 run-time engine, I don't have any other installed on my development machine.

In the case of the custom process model (from the responder above), how would I tell if this was the case?  I am not very familiar with changing the process models.

be well,

DLC

[ShockHouse]

In this case if that was set then it would run the LV 2022 run-time engine, I don't have any other installed on my development machine.

It will try to use whatever version the LabVIEW VI's it calls were written in, it doesn't matter what version you have installed. If the VI's are saved in 2013, it will try to use the 2013 runtime engine. (Note that this behavior changes if you check the "Enable version independent runtime engine" checkbox in the adapter settings, but that only applies to LabVIEW 2017+ so 2013 would still look for 2013 even in that case).

[DLMC]

It will try to use whatever version the LabVIEW VI's it calls were written in, it doesn't matter what version you have installed. If the VI's are saved in 2013, it will try to use the 2013 runtime engine. (Note that this behavior changes if you check the "Enable version independent runtime engine" checkbox in the adapter settings, but that only applies to LabVIEW 2017+ so 2013 would still look for 2013 even in that case).

That is interesting.  I migrated vi's written in LV 2010 directly to LV 2022 without any issues, other than having to update deprecated, changed, or new NI vi's.  So this directive must come from TestStand rather than the vi's.

Here is where I show my ignorance...

I used custom process models developed by another group, long gone, that were done on the NI 2017 environment.  This kind of indicates to me that development work must have set the version independent runtime engine checkbox. 

Because checking those options with my TS2021 version does nothing, I assume that LV 2013 lock can't be changed in my TS 2021 configuration.  Is there some way to change that in whatever file it is stored from the NI 2013 environment or must I make that change in the NI2013 environment and try again.  This is assuming I can find that NI2013 development environment, it has been quite a few years since that team left and well, mistakes were made...

be well,

DLC

[ShockHouse]

You would need to find the VI's written in LabVIEW 2013 and recompile them to a newer version.There must be some LabVIEW call, in some sequence that is calling into a 2013 VI/PPL, etc...

If you can't find them in your direct sequences, then I would look at the process models, report plugins, or other types of plugins like station callbacks, front end callbacks that run, but are not as obvious. You should just be able to open up the sequence, do a sequence analyzer and see which one errors for the 2013 issue. Then you will be able to find that step.

[Oli_Wachno]

Does the error also occur, if you are running your project without any ProcessModel?

Just to determine where the offending VI(s) are situated

[DLMC]

You would need to find the VI's written in LabVIEW 2013 and recompile them to a newer version.There must be some LabVIEW call, in some sequence that is calling into a 2013 VI/PPL, etc...

If you can't find them in your direct sequences, then I would look at the process models, report plugins, or other types of plugins like station callbacks, front end callbacks that run, but are not as obvious. You should just be able to open up the sequence, do a sequence analyzer and see which one errors for the 2013 issue. Then you will be able to find that step.

Hmm.  Would a mass compile handle this?  I kind of doubt it because I can open the vi's with LV 2022, no issue.  Only when I run in the TestStand sequences do I get the error, so it looks like I have to find a process model or something that causes it.

be well,

DLC