Formbara VI:n i LabVIEW
Av Henrik Hjorth
Mallable VI:er introducerades i LabVIEW 2017 för att implementera generics och kan anpassa varje terminal till indatatypen. Detta gör att du kan skapa funktioner där datatypen inte definieras i själva funktionen utan bestäms under kompilerings- eller körtid.
Jag har funnit att denna funktion är mycket användbar för att öka återanvändningen av kod och ofta förenklar implementeringen av blockdiagram, både under utvecklingen och efteråt när man läser koden.
Ett vanligt användningsområde för formbara VI:er är att skapa allmänna funktioner för hantering av matriser, t.ex. ta bort flera element från en matris, söka efter alla element i en matris eller unikt infoga i en matris (dvs. infoga ett element endast om det inte redan finns). Här är ett exempel på en implementering av delete multiple elements från en array.
Ett formbart VI skapas genom att filändelsen för ett standard-VI ändras till .vim. VI:t måste också konfigureras för inlined, ha felsökning inaktiverad och vara inställt på reentrant exekvering.
I LabVIEW 2019 accepterades att property- och invoke-noder inlines och stöds även av formbara VI:er, vilket gör den här funktionen ännu mer användbar (se Inlineable property-noder / Framkalla noder när det är lämpligt - NI Community). Nedan visas ett exempel på en förenklad disable-kontrollfunktion som implementerats i en formbar VI. Notera att det inte finns någon coercion av referensen och att den strikta typen behålls.
Type Specialization Structure introducerades i LabVIEW 2018 och kan användas för att inaktivera en specifik del av koden baserat på kompileringsresultat. Detta är användbart t.ex. för att hantera både skalär- och array-ingångar. Funktionen disable control ovan kan sedan utökas till att även hantera en array-ingång. Ingångskontrollen kan definieras antingen som array- eller scalartyp, båda fungerar som visas nedan.
Varje fall i typspecialiseringsstrukturen tilldelas något av dessa värden
- Declined = underdiagrammet har syntaxfel
- Accepterad = första subdiagrammet som kompileras utan fel
- Ignorerad = ett tidigare fall i listan är redan accepterat
För att tvinga en formbar VI att avvisa specifika datatyper eller endast acceptera en delmängd av datatyperna kan funktionerna i kategorin Assert Type i paletten Comparison användas.
Formbara VI:er kan i vissa fall leda till brutna kablar när en polymorfisk ingång till en formbar VI kopplas. Detta händer om det formbara VI:t inte kan fastställa rätt datatyp för utdata, t.ex. om typgjutning används eller om en fallstruktur matar ut olika datatyper beroende på fall. I detta scenario är det enklaste sättet att hantera detta att lägga in den del som bryter funktionaliteten i en standard sub-VI och anropa denna sub-VI från den formbara VI:n.
Detta dummy-exempel demonstrerar detta, blockschemat för den formbara VI:n visas till vänster. I det här fallet accepterar den numeriska värden, men inte t.ex. booleska datatyper och strängdatatyper.
Men om du flyttar ärendestrukturen till en sub VI, kommer alla datatyper att accepteras.

