What VI Changes force a Step to need Reloaded

[ShockHouse]

We have a PPL based architecture that heavily uses TestStand. When updating PPLs we try to take care to keep the VI's the same so TestStand does not need to reload the steps. There are certain things you can change without forcing a reload, and certain things you can not. I'm wondering if there is a list saying what is breaking, and what isn't. From our findings

Breaking Changes:

Different Type

Label Change

Connector Pane Change

Label of the control/indicator inside of an array change (even if array itself keeps the same label)

Non-Breaking Changes:

Caption Change

Control Type (System, Silver, etc...)

VI Documentation

VI Icon

Enum additions

Label/Caption Visible Change

[richjoh]

I don't have a list of breaking items but a comment. You use PPL to make all your VIs parameters stay the same so TS never reloads is my guess.

IMHO PPL based architecture the only benefit is locking out other from your source code.  Too many times you lock yourself out or other co-workers which requires a recompile of the source project.  Furthermore, you use to need the same year/version to compile source, ouch, if its earlier than 2019 or so.   Are there other options/tradeoff of using PPL, not enough for me to use it.  

Any change to VI parameters controls or indicators in the connector pane will definitely cause TS to reload.  Broken VI caused my TestStand 2020 32bit too crash upon loading.  I have to mass compile and fix the broken VIs to temporarily fix.

[ShockHouse]

Using PPLs has some extreme benefits, and PPLs are forward compatible. If I make a PPL in LabVIEW 2019, it works up to LabVIEW 2023 Q1 no problem without recompiling (development and runtime). This allows us to give a PPL to Customer X using Y, and Customer B using A and it's the exact same PPL and performs the same.

Our large use for this is a HAL. If someone needs a DCPowerSupply for their TestStand, we can just hand them a few PPLs and they are good to go. It's been a pretty powerful system. I just want further information on what is breaking so when we push updates for bugs, sequences will just accept it instead of needing the Seq Editor to update.

To note, we've been doing this for about 6 years without issue. There's just some times a developer will change a label without changing anything else, and I'd like to have a better list of what to watch out for that might cause sequences to break.

[richjoh]

PPL Labview has been around since 2010, so from 2010 to 2018 what a pain to anyone using PPL.  It's a tool waiting to become a solution to a problem. From 2019 on, agreed it is much easier w/o the restriction of compiling with matching version year, forward compatible as you say.  

It is now 4 years from 2019, you may have been forced to match a Labview PPL, version 2018 or earlier, code back then or so.  Hey, I have, it wasn't my code of course.  It was someone using the wrong PPL tools just to enforce no change in code for the next Labview co-worker/developer.  A better tool for that is a source code repo but that was misused too, lol. 

Good Luck with that PPL.

[bienieck]

If it was possible, I would give richjoh an antikudo.

Regarding the main question. I don't think there is an explicit list. However, in general we could safely state that the interface (from the adapter perspective) change will require reload. That is why e.g. labels are also on your list - they are used for the interface mapping.