NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Deploy TestStand System and Override Module Settings

Solved!
Go to solution

Hi Community,

 

I have the opportunity to finnaly use the Override Module settings and I'm trying to deploy my code. I'm a little bit surprised of my understanding of this function.

 

I have set a Code module with a project in source and a project in PPL. I can set and override my code withtout problem. It's works and I understand well the behavior.

 

MaximeR_0-1686318880904.png

 

For Deployment, my understanding was that I can use only the PPL version of my code but I never came to this situation.

If I choose to include Packed Library Source File Specified in Steps it Includes sources and my specified PPL in files that I can deploy :

MaximeR_2-1686319294099.png

 

but If I uncheck this option, I only have the sources that I can check.

 

MaximeR_3-1686319350391.png

 

I was thinking the behavior will the total opposit. If I uncheck the Include source I only have the PPL.

 

I can choose to put my modules in a packed Library but it's another PPL that is build specifically for that distribution. So it takes my sources and build a new PPL used for distribution.

MaximeR_1-1686319079826.png

This option was available before the "Override Module Settings" but in this case i don't understand why I will spend some time to set a PPL specific for a project, and create another project to use it for each code Module...

 

Can someone explain If I'm doing somehting wrong or it's just the functionnality that working in this way ?

 

If it's the second case, I'm very surprised and don't crealy understand the interest of the Override Module Settings option.

 

Best regards

Maxime R.  

  CLA - Certified LabVIEW Architect / Architecte LabVIEW Certifié
  CTA - Certified TestStand Architect / Architecte TestStand Certifié

0 Kudos
Message 1 of 18
(1,810 Views)

Hi Maxime,

 

I wasn't aware of this feature at all. Since we are also using PPLs a lot, it could be of intrest for us as well.

Docuementation is kinda sparse though...

 

Hope someone can help!

 

Oli

Message 2 of 18
(1,735 Views)

It seems that's I'm the only one to try to use it !

I have to start my project and trying t choose the right way to manage my code module. If using this option doen't give any advatnage for distribution, I don't understand the benefits.

 

I will scincerly appreciate any help or feedback on that point.

 

nobody from NI can answer this question?

 

Best regards

Maxime R.  

  CLA - Certified LabVIEW Architect / Architecte LabVIEW Certifié
  CTA - Certified TestStand Architect / Architecte TestStand Certifié

Message 3 of 18
(1,684 Views)

I have the same issue, can some body from NI explain this?

Message 4 of 18
(1,609 Views)

So, I have to continue to work without any help from NI.

My understanding is that this option is only bringing advantages when you want to deploy code with source code control and you want to be able to run application in RTE but continue working on sources at the same place (meaning in the same folder hierarchy on disk)

 

I'm explaining my point of view.

Since few LV version, VIs have "Separate Compile Code from source" by default activated. On development computer, you have everything set and it can work easily in LV Dev and RTE after all the used VIs are compile at least one time in your local LabVIEW databse. Configuring PPL, force LabVIEW to compile and embedded inside each PPL what they need to have to execute. In this case, if you are running your code in the same location on a deployment station, it can work in RTE without LV and any missing dependencies.

 

If you want to use distribution to differenciate Development and Deployed station, you have to embed everything at the distribution building time. In this case, it builds a new PPL that will use the sources. You can select to keep sources in the deployed code to facilitate debug on deployed system, but the switch is not straightforward. It seem's to be mainly to fix deployed code that is not working and you can rebuild deployed PPL without regenrating distribution. By having this strict separation between sources and deployed code, using Override Module settings is a non sence because you will never deploy these PPL and the switch doesn't bring you a lot of advantages except maybe loading time if you force RTE and you don't have modification.

What do you think about this ?

Maxime R.  

  CLA - Certified LabVIEW Architect / Architecte LabVIEW Certifié
  CTA - Certified TestStand Architect / Architecte TestStand Certifié

0 Kudos
Message 5 of 18
(1,523 Views)

Hi Maxime,

 

I understand that the "Include Packed Library Source Files Specified in Steps" option is confusing and the behavior when it is unchecked is not what the user might expect to see.

 

When the option is unchecked, the behavior we would want to support is to only deploy the PPL without including the source files. However, the Override Module feature in the LV adapter doesn't support this very well.

 

The LV Adapter expects the source files configured in the Override Module step to be present and uses it for validation and rebuilding of the PPL even when the Module override option is set to run the PPL and not the source. If the source files are absent, as of today, you will see some unexpected behavior like errors or very slow module load times.

 

We do have a feature request in the backlog to better support this behavior which would require changes in the LV adapter as well as Deployment Utility.

As part of this feature these are the changes you can expect:

  • The "Include Packed Library Source Files Specified in Steps" option is checked: No changes in behavior, will deploy the PPL as well as the source files.
  • The "Include Packed Library Source Files Specified in Steps" option is unchecked: Only the PPL is deployed and the steps are set to call the overridden PPL.
  • The LV adapter is tolerant of the source files for an override steps missing and will continue to execute the PPL that is available. Now this affects the overall behavior of the feature and not just deployment case so we might have to possibly put this behind an option in the adapter.

 

Do let me know if this satisfies your use cases.

 

Regards,

Tinu

Message 6 of 18
(1,503 Views)
Solution
Accepted by topic author MaximeR

Hi Tinu,

 

Thanks for your reply. I defintely doesn't understand well the behavior of the deployment tool in different cases. I did a lot of test by my own in the last weeks tryng to understand it.

My post is open for almost 1 month and I still missing some answer. I'm already happy that some people from NI are still working...

About my problem, If you are going to fix behavior it's a good news, but today, I want to be able to use my software. So let's try to have a discussion about how it works today and how to use this functionnality or not. It seems that i'm not the only to not understand.

 

If I choose to have source (default behavior), it deploy sources and packed library and override module settings is not change ! Is that right ?

 

If I Uncheck source, you build a new ppl from the source and you replace the source lvlib inside the source project and relink with a ppl the step and the override module is disabled. each project or maybe each lvlib have is one lvlipb In this case, the lvlip configured inside override module is not used ! override code module is disabled for each steps that have this option. Is it a bug ? why not used the already builded ppl ? 

 

If I choose to deploy inside PPL, I don't have the choice to select or not sources. But at the end you build a PPL per project like without sources.
For the module that don't have a project, code is place inside a seperate ppl.

 

In the end it's not possible to use the override module settings and deploy only the already builded PPL ?

 

If it's the case, what is the interest of this functionnality except my understanding to have a deployment process with Source Code Control and be able to run sequences with the RTE only ?

 

Don't hesitate to share more details, explantion or examples of the current expected behavior.

Don't hesitate to review, comment and set status on different topics of the TestStand idea Exchange and NI Package Management Idea Exchange

Best regards

Maxime R.  

  CLA - Certified LabVIEW Architect / Architecte LabVIEW Certifié
  CTA - Certified TestStand Architect / Architecte TestStand Certifié

0 Kudos
Message 7 of 18
(1,475 Views)

@TRJ wrote:

Hi Maxime,

 

[...]

 

When the option is unchecked, the behavior we would want to support is to only deploy the PPL without including the source files. However, the Override Module feature in the LV adapter doesn't support this very well.

 

[...]

Do let me know if this satisfies your use cases.

 

Regards,

Tinu


Tinu,

 

do I understand correctly, that the source files need to be available in the deployed code though the code is actually using the PPL?

 

Cheers

Oli

0 Kudos
Message 8 of 18
(1,426 Views)
Solution
Accepted by topic author MaximeR

"do I understand correctly, that the source files need to be available in the deployed code though the code is actually using the PPL?"

 

Yes, that's correct.

 

The PPL Override feature was meant to be used in a way where the LV steps has both the source VIs and the PPL configured and execution can easily switch between the two.

 

The LV source files are the source of truth for the step, since that is where the user can make changes. When the step is set to execute the overridden PPL, the LV adapter has to validate if the code in the PPL is up-to-date and reflects all the changes to the source VIs. If not, it rebuilds the PPL to include those changes before execution. So having a Module override step with only a PPL and no source files does not make much sense. If you only need a call PPL, you can simply configure a step to directly call the PPL and needn't use the Module Override feature.

 

So even in deployment scenarios, we would want to keep the source files for Module override steps which is the behavior when "Include Packed Library Source Files.." is checked (by default).

 

When "Include Packed Library Source Files.." is unchecked there are two options we could support:

  1. Only deploy the PPL and don't include the source files. The steps will retain all the Module Override settings and will reference both the source files and the PPL. So if needed users can copy the source files to the deployed machine manually and switch to executing the source for debugging. By doing this users would like to avoid copying their large source files to deployed machines by default. This requires changes in the LV adapter to prevent it from trying to access the source files which will be absent.
  2. Build and deploy the PPL but update the step to directly call the PPL itself and remove any module override settings. In this case, the steps knowledge of the source files is lost.

The current behavior when "Include Packed Library Source Files.." is unchecked is that the source files are deployed but not the PPL. The user can still execute the deployed sequence file and it should build the PPL on the fly and execute it (provided the LV adapter option, "Automatically Build PPLs at Start of Execution" is enabled). However, there is not much of a difference in behavior when compared to "Include Packed Library Source Files.." being checked, which is what we plan to fix.

 

Regards,

Tinu

Message 9 of 18
(1,410 Views)
Solution
Accepted by topic author MaximeR

If I choose to have source (default behavior), it deploy sources and packed library and override module settings is not change ! Is that right ?

Yes, that's correct and that's the intended default behavior for the Module override steps.

 

If I choose to deploy inside PPL, I don't have the choice to select or not sources. But at the end you build a PPL per project like without sources.
For the module that don't have a project, code is place inside a seperate ppl.

 

By this i think you are referring to the option shown below:

TRJ_0-1689075893660.png

 

This particular deployment option existed much before the Module Override feature was added in LV adapter (which was in TS 2017/2019). So even prior to having the Module Override feature, users could choose to output all the VIs in their deployment to (one or more) PPLs. Along with this option, they could also choose to include the project, source files and build spec that was used to create that PPL in their deployment, in case they needed to rebuild it. When this option is chosen, every LV step is updated to call the VIs from the deployed PPL. This option works exclusive of the Module Override feature. If you have Module override steps, even their source files will get pulled into a PPL and the deployed steps will be updated to directly call the PPL, just like a regular step.

 

If I Uncheck source, you build a new ppl from the source and you replace the source lvlib inside the source project and relink with a ppl the step and the override module is disabled. each project or maybe each lvlib have is one lvlipb In this case, the lvlip configured inside override module is not used ! override code module is disabled for each steps that have this option. Is it a bug ? why not used the already builded ppl ? 

I think even here, based on the behavior you're describing, you're referring to the "Output VIs to a Packed Project Library" option. Like i mentioned, this option pre-dates the Override Module feature and if you choose this option, the Module Override settings as ignored. The source VIs in a step and pulled into a PPL that TS creates on the fly and the steps are relinked to call the PPL directly. The deployed steps will no longer use the Module override option since the step is now configured to call a PPL directly (the concept of overriding the "source" VIs to call a PPL is not applicable here since the step is directly calls a PPL).

 

 

In the end it's not possible to use the override module settings and deploy only the already builded PPL ?

It is currently not possible to to deploy only the PPL from a module override step, with the PPL being built from the build spec that was configured in the step and for the step to retain the override module settings. This is what we are trying to address as a feature request.

If you only want the PPL in the deployed scenario, you can always use the "Output VIs to a Packed Project Library" option i mentioned above. The downsides to this are:

  • The PPL is not built using the build spec configured in the step but a generic build spec that TS creates on the fly.
  • The deployed LV steps will now directly reference the PPL and will not include any reference to the source files (module override settings).

This option might be good enough for your requirements, since it doesn't seem like you need the source files of the module override steps in the deployed machines.

 

Another clarification that will probably help is that the "Include Packed Library Source Files Specified in Steps" option is specifically meant for Module Override steps. The "Output VIs to a Packed Project Library" option is applicable to any LV VIs in the deployment and pre-dates the Module Override feature. If you enable "Output VIs to a Packed Project Library", that takes precedence over "Include Packed Library Source Files Specified in Steps" and this is also indicated in the UI by the latter option becoming greyed out and disabled.

 

If it's the case, what is the interest of this functionnality except my understanding to have a deployment process with Source Code Control and be able to run sequences with the RTE only ?

I did not fully understand this question.

Message 10 of 18
(1,402 Views)