Using LabVIEW Packed Library within TestStand Deployment Tool

[Jean-Louis]

I am wondering what could be the interest of generating Packed Library within the TestStand Deployment Tool since the sequences using these VIs will not be able to find the dependant VIs included into the build Packed Library on the deployment target.

Any experience using Packed Library within TestStand Deployment Tool ?

[~jiggawax~]

I've tried it out on several builds.  I like it.  The deployment utility will redirect your sequence file to call into the packed project library for you automatically.

My only problem so far....

If your VIs are calling nonLabVIEW dependencies then you need to include those in the same folder as the packed project library.  For instance we were using some XML parsing code modules that were built on top of some dlls.  Until we put them in the same folder as the packed project library it wouldn't work.  I don't know why the PPL couldn't pull them into itself.  But it doesn't with the TS deployment utility.

here are some interesting reads:

http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/caveats_recommend_packed/

https://decibel.ni.com/content/docs/DOC-20274

Regards,

[Romain_Duval]

Hi Jean-Louis,

I checked in on my side and indeed the deployment utility automatically update the sequence file to point to the right location inside the lvlibp.

regards

[Jean-Louis]

Thanks for your reply.

I did the test again and I agree that TestStand Deployment Tool is able to update VI calls into the created Packed Library.

May be I did something wrong...

I tried to do the same with Custom Step Types.

The TestStand Deployment Tool could not modify the PostStep and EditStep definition referenced within my sequence.

Did you also use Packed Library for Custom Step Types which are using normal VIs out of .lvlibp for PostStep and EditStep ?

Regards,

[~jiggawax~]

Custom Step Types are a whole different cat.

Here is my opinion on the matter.

A custom step type should be a standalone entity.  In other words, a custom step type's substeps and dependencies should all be packaged up into a nice neat llb or dll before developing with it.  It would all be packaged up and put in the TestStand public folders in Components>>StepTypes folder.  Then you just deploy the public folder contents.

You can reference the NI Step Types in the TestStand>>Components>>StepTypes folder to see how this is done.  Basically they have the source code and packaged up code in the same place.  In their step types they only ever call into the packaged up code.

Hope this helps,

[Jean-Louis]

jiggawax,

If I resume, the TestStand Deployment Tool is able to modify the VI calling path and include the Packed Library Name for standard Steps with specified VI module but it cannot do the same for Custom Step Type Definition with PreStep and EditStep.

We think of another way for using Packed Library for Custom Step Types : building an .lvlibp from our source VIs and then using this .lvlibp by our Custom Step Types (similar to your neat llb).

The only inconvenient is that you must have the same VI path for CST debug (generating a "debug" .lvlibp) which may include diagrams or debug option.

Thanks again for your help.

[~jiggawax~]

Maybe I'm confused about what you are asking for then.

Let me see if I understand you correctly.  Basically with any step in TestStand you have 2 types of code modules:

SubSteps

Main Module

If I throw down an Action step from the Insertion Palette I can modify the Main Module by pointing that step to a VI or Dll or whatever adapter I'm using.

The only time in the development environment that I see a substep is on 2 occasions: OnNewStep (or other custom substeps), or Edit Substep.  Pre and Post substeps only happen during execution.  All 4 types of substeps are configured when defining the step in the type palette.  Are you saying that you have different substeps depending on the mode they execute in?  All of the substep modules should be packaged up into the same package (whether it be lvlibp or llb or whatever). 

Then the Main Module is the one that gets packaged up in your lvlibp that the deployment utility creates.  The substep stuff should not be in that one.  It should be in the public folders like I talked about in my previous post and deployed as part of the public folders.

So I'm not sure what you mean by "same VI path for CST debug".  Are you trying to create 2 lvlibps?  Or are you trying to make the lvlibp be debuggable?

Regards,

[Jean-Louis]

Jiggawax,

Sorry for the confusion,

My question concerns the developement of Custom Step Types.

For example, within a project or as an independant product.

The best practices is to avoid using main module when developing CST in order to preserve evolutivity (main module calling paramters are copied within CST instances and could need prototype updating). I prefer using PostStep (as NI does for its own CST).

Thus, when creating the CST palette, I have to configure the EditStep and the PostStep and define each VI call.

If I want to distribute these VIs through a .lvlibp, then I need to build a .lvlibp very early and use it within my CST palette.

This .lvlibp will be used on deployed benches and may not contain VI diagrams and debug options (best performance).

But during the development of my CSTs, if I need to debug the VIs called when using CST whitin a sequence, and if I don't want to change the called VIs defined in my CST palette, then I need to regenerate this .lvlibp with debug option (different from the deployment .lvlibp) in order to allow debug.

May be it could be interesting that the TestStand deployment tool take into account SubSteps when selecting the Packed Library option. This tool is able to modify sequences, it could be able to change also palette configuration file.

This will allow to have only two levels :

 > Source and Debug (VIs)

 > Deployment (.lvlibp)

instead of three :

 > Source (VIs)

 > Debug (.lvlibp with debug option)

 > Deployment (.lvlibp)

[~jiggawax~]

That makes more sense.  Thank you for clarifying.

Personally I prefer the 3 level approach where you have your source, debug lvlibp and distribution lvlibp.  You should only need the debug lvlibp while creating the CST.  Once you are done creating it then you switch over to the distribution lvlibp.  If you did a good enough job testing your debug lvlibp then you shouldn't have to modify or even think about that code for a really long time.  Unless features came up.  In that case though you would go back to the creating stage for the CST.  Generally you never have more than 2 or 3 substeps so repointing those is simple enough.

Anyhow, you can always throw your idea up on the idea exchange and see if anything comes to fruition.

Regards,