Python-krav fra LabVIEW og TestStand

Python-krav fra LabVIEW og TestStand [NI Package Manager]

Når du skal i gang med at bruge Python fra LabVIEW og TestStand, er der krav til, hvordan Python installeres. I dette indlæg kan du se processen for, hvordan du pakker Python til både LabVIEW og TestStand vha. NI Package Manager.

Udover at være softwareudvikler hos GPower, og en fantastisk kollega 🤣, er Jesper Kjær Sørensen ikke mindst en kæmpe Python-, LabVIEW- og TestStand-entusiast. Som følge heraf deltager Jesper i forskellige events; denne gang GLA Summit.

Se Jespers præsentation

Gik du glip af Jespers præsentation om ”Pythonic Requirements from LabVIEW and TestStand? Så kan du se eller gense videoen nedenfor. Videoen er en trinvis guide til hvordan du kan pakke dit Python miljø, inklusive Python pakkerne til dine NI Programmer.

Et citat fra Jesper

“I de foregående år var der masser af præsentationer til både @GLAsummit og @GDevCon, som forklarede, hvordan Python er blevet brugt i samarbejde med LabVIEW og TestStand. Alle sammen rigtig gode præsentationer om programmeringen, men ikke desto mindre under samme præmis. Nemlig præmissen om, at Python var installeret på den PC, hvor koden blev exekveret.

Som systemingeniør tog jeg den modsatte tilgang og forsøgte at afdække, hvad der ville gøre det muligt for udviklere nemt at pakke, implementere og eksekvere Python-kode fra LabVIEW og TestStand. En præsentation, som afdækker:

    • Konsekvente installationskonfigurationer
    • God afhængighedsstyring
    • Virtuelle miljøer
    • Download og installation af Python-pakker i det nye miljø”

Vil du vide mere om “The Pythonic Requirements from LabVIEW and TestStand”, så skriv til Jespers mail.

Hvad er GLA Summit?

Udover at GLA Summit er en spændende mulighed for at lære af avancerede LabVIEW-udviklere fra hele verden, er det også en event, der giver mulighed for at netværke og deltage i en inkluderende og digital LabVIEW-begivenhed. Læs mere om teamet bag eventet her.

Download IO-Link til LabVIEW og TestStand gratis

Download IO-Link til LabVIEW og TestStand helt gratis!

Er du LabVIEW- eller TestStand-udvikler, bør du virkelig prøve GPower IO-Link! En universel driver til mere end 30.000 IO-Link-enheder! For første gang er det plug 'n' play at få adgang til indkodere, digital og analog IO, lystårne, trykknapper og meget mere ved blot at indlæse deres IODD-fil i LabVIEW eller TestStand.

Introduktion

Selvom IO-Link har eksisteret i mere end et årti, har der ikke været nogen nem måde at forbinde enhederne med NI’s tool chain. Meeeeen det er der nu, og det gør GPower IO-Link revolutionerende. Ved blot at installere et toolkit får du adgang til data fra mere end 30.000 enheder i din LabVIEW-kode. Desuden har vi taget vores egen medicin ved at bruge vores IO-Link LabVIEW Toolkit til at bygge IO-Link steptyper til TestStand.

Hvordan dokumenterer man sin kode med built-in tools i LabVIEW?

Hvordan dokumenterer man sin kode med built-in tools i LabVIEW?

Brug en type def. cluster og en single feedback node, tjek betingelserne en enkelt gang fra sidste iteration, og skriv kun til den enkelte værdi, når det er nødvendigt, med henblik på at skabe mere overskuelighed. Få flere tips til dokumentation i LabVIEW i blogindlægget.

Alle har utvivlsomt stødt på udokumenteret kode på et tidspunkt, ligesom den der er vist i toppen af billedet, og stillet sig selv spørgsmål som:

    • Hvorfor er denne kode skrevet?
    • Hvad er betingelserne for udførelsen?
    • Hvorfor er betingelserne for casestrukturerne afhængige af VI’ens output?
    • Hvorfor er dette output inverteret?

Ovenstående spørgsmål kunne imidlertid have været undgået, hvis man havde gjort en lille indsats ved at dokumentere koden ved hjælp af de indbyggede værktøjer i LabVIEW.

På nederste del af billedet har jeg opsat nogle pointer i forbindelse med, hvordan man dokumenterer en VI ved at gøre brug af det mest simple værktøj i LabVIEW. Jeg har brugt Cluster datatype sammen med en feedback node til at håndtere dataene i hver iteration, da disse giver god dokumentation af den tilgængelige data. Og ved at tilføje labels og sub-diagram labels for casestrukturerne bliver forståelsen for udførelsesprocessen meget tydeligere.

En væsentlig pointe at nævne er desuden, at disse værktøjer er tilgængelige i alle versioner af LabVIEW.

Bliv klogere på LabVIEW

Start med at dokumentere din kode i dag!

Min intention med at skrive dette blogindlæg var at fremhæve vigtigheden af dokumentation med henblik på at reducere kompleksiteten for læseren samt at reducere fejl i koden i fremtiden.

TestStand – mere end bare testafvikling [Testmanagement]

TestStand – mere end bare testafvikling [Testmanagement]

TestStand har eksisteret som produkt hos NI i snart 20 år. Jeg har selv arbejdet med TestStand siden 2006 i forskellige sammenhænge, og jeg støder jævnligt på misforståelsen om, at TestStand "bare" er en testafvikler. I virkeligheden er TestStand et framework til testmanagement, hvor det at afvikle en test ganske vist er en vigtig funktion, men dog bare én af mange funktioner, man får med i pakken.

TestStand bliver ofte misforstået for dets kompleksitet

TestStand stiller en række af værktøjer til rådighed, som kan bruges til at opbygge en testplatform, der passer til netop den produktions- og/eller verifikationsproces, man ønsker i den enkelte virksomhed.

Denne store fleksibilitet kan få TestStand til at virke kompleks ved først øjekast, og fører desværre ofte til, at mange vælger produktet fra, inden de har sat sig tilstrækkeligt ind i, hvad det kan. Nogen går i gang med selv at udvikle en testafvikler fra bunden, hvilket altid viser sig at være en langt større opgave end først antaget.

Læs casen: “En ny platform til produktionstest” – Siemens Gamesa

Den typiske proces

Typisk har man i starten kun øje på behovet for at kunne teste og se, om testen gik godt eller skidt. Den del når man typisk i mål med på en eller anden måde. Efter kort tid vil der opstå flere behov som for eksempel at kunne danne varianter uden at ændre i eller kopiere selve testsekvensen, efterprocessering af resultater til forskellige outputs eller at paralleliserer ens test. Og måske viser det sig, at brugerstyring med forskellige privilegier til forskellige brugere er nødvendigt.

Det er her, det begynder at blive virkelig svært: Hvis man selv skal lave et system, der både opfylder de behov, der er udenom det at afvikle en test, samtidigt med at man skal vedligeholde og udvikle test til den daglige produktion, bliver det svært at holde overblikket. Risikoen for, at man får lavet et system, hvor tingene blandes sammen, og efterfølgende er sværere at opdele i moduler, der kan genbruges, er stor. Og det er her, vi ofte ser, at testafdelingerne i de fleste produktionsvirksomheder ikke har kapaciteten til at løfte en opgave som denne.

Løs dine udfordringer med TestStand

Min opfordring er derfor, at man bruger et par ekstra dage på at sætte sig ind i, hvad det er, man faktisk får ved at gå i gang med at løse sin testudfordring med TestStand. Man skal ikke lade sig skræmme af alle de muligheder, man får, men derimod fokusere på alle de ressourcer, man sparer ved ikke selv at skulle facilitere udviklingen og vedligeholdelsen af et helt test-management-system.

Og skulle det vise sig, at der er behov for lidt hjælp til at komme i gang, så er vi hos GPower parate til at træde til. Det kan være alt fra at lave en teststrategi til at designe og implementere konkrete testsystemer.

Hvordan kan man spare 80% af omkostningerne på udvikling?

Hvordan kan man spare 80% af omkostningerne på udvikling?

Hvordan kommer man hurtigst i mål med at lave robust software? Hos GPower er genbrugelighed nøgleordet, men som med så mange andre ting skal det gøres med omtanke.

Det offentlige rum er fyldt med eksempler på for dyr og forsinket software. Man kunne liste en masse eksempler, men det rækker vist at bemærke, at fordyrelser i 100-mio.-klassen er velkendte inden for offentlige IT-systemer (Klik her for mere information). Der er naturligvis en række af omstændigheder, der gør, at softwareudvikling bliver en dyr affære, men hvor kan man sætte ind, hvis man vil gøre det hurtigere og billigere?

Genanvendelse

Hvis man kigger på selve udviklingsfasen, så er der en ting, der kan gøre projektet hurtigere og billigere: Genbrug. Hvis man er i stand til at genanvende kode fra tidligere projekter, er der store besparelser at vinde. Mange af de tidskrævende opgaver ligger i at udvikle kodeblokke, der er meget generiske – og ikke er unikke for det enkelte projekt. Hvis disse dele kan udvikles på forhånd, reduceres udviklingsarbejdet markant. Faktisk viser vores erfaring, at op mod 80% af kodebasen til et projekt kan etableres på forhånd, så der er ganske store gevinster på spil.

For at kunne høste disse besparelser kræver det en meget struktureret tilgang til genanvendelse. Hvis ens tilgang er den klassiske ”cut and paste”, så er der store farer gemt i genanvendelse. Det kræver et dybdegående kendskab til den oprindelige kode, så man er helt klar over kodens formål og de begrænsninger, den måtte have.

Modulær software

Derudover er det vigtigt at indkapsle koden effektivt. For hvis koden skal bruges flere gange, vil der helt sikkert komme ændringer i den. Derfor bør al kode ligge i velafgrænsede moduler, så der er klare interfaces, og de bør generelt designes efter SOLID-principperne. I det hele taget bør koden ikke ses som ”et flagrende stykke kode”, men som et værktøj. Og som med alt andet værktøj er det værd at bruge tid på at lave det ordentligt, så det holder og kan bruges i mange situationer.

Når vi snakker om op til 80% besparelse, så begrænser det sig naturligvis ikke kun til udviklingsfasen. Hvis 80% af koden kan genbruges giver det selvfølgelig tilsvarende besparelse i testfasen, hvis koden er lavet modulært. Designfasen kan også gennemføres væsentligt hurtigere, hvis man har et godt overblik over sine værktøjer. For ikke at tale om vedligehold: Alt, hvad der sker efter endt udvikling, gavnes også af genanvendelse, da byggeblokkene når at køre i mange flere timer, så koden er gennemtestet i langt højere grad. Og da vedligehold er en fortløbende opgave, er der massive besparelser at vinde i det lange løb.

Book et uforpligtende møde

Lyder det interessant i forhold til jeres forretning? Lige nu har du muligheden for at booke et helt uforpligtende møde med os! Ring eller skriv til os: +45 51 90 57 90 eller [email protected].

Fem ting, du bør gøre, når du opgraderer TestStand

Fem ting, du bør gøre, når du opgraderer TestStand

Hvad gør man, når ens testsystem kører på en gammel version af TestStand, og man ikke er helt tryg ved bare at overføre koden til den nyeste udgave af TestStand? Her er der fem råd til at få opgraderet dit testsystem.

Skal man ændre på et testsystem, hvis det ikke er i stykker? De fleste vil nok svare nej, og derfor får teststationer tit lov til at køre i mange år, uden at der bliver rørt ved det. For det fungerer jo – for det meste. Men der kommer et tidspunkt, hvor opgradering af systemet ikke kan udskydes længere pga. eksempelvis udefrakommende krav, kompatibilitetsproblemer eller internt pres.

Systemet er blevet hægtet af udviklingen, og der er sikkert adskillige versioner op til den nyeste udgave af TestStand. Det kan være fristende bare lige at skrue en version op, så man holder skuden flydende, men den mest fremtidssikrede løsning er at opgradere til den nyeste version af TestStand.

Det kan godt virke som en uoverskuelig opgave, og man kan frygte, at testsystemet ikke længere fungerer i den nye version af TestStand. Den gode nyhed er til gengæld, at i 99% af tilfældene vil der ikke være nogen fejl. Den gamle software er helt kompatibel med f.eks. TS2019, og man kunne bare flytte sine sekvenser og kodemoduler direkte over i det nye udviklingsmiljø (medmindre du arbejder i TS 4.2.1 eller ældre, så skal du manuelt migrere dine sekvenser og konfigurationsfiler mm. (se her). Det ville til gengæld bare lade de latente problemer i koden være, og man ville ikke få nogen reel gavn af at opgradere TestStand. Derfor kommer her en håndfuld gode råd til at få mest muligt ud af at opgradere TestStand:

  1. Undersøg nye features

    Før du begynder på opgraderingen, så afsæt noget tid til at gennemgå, hvilke features, der er kommet til. Kig dokumentationen igennem på NI’s hjemmeside og kig gerne på nogle af de eksempler, der bliver udgivet af NI’s application engineers. Måske er der blevet implementeret nogle features, der løser nogle af udfordringer, som du selv har bøvlet med – og måske kun fundet en halv løsning til.

  2. Brug ikke gammel kode ukritisk

    Sørg for at have helt styr på, hvad du genbruger, og hvorfor du kan genbruge det. I udgangspunktet kan du ikke genbruge det, før det modsatte er bevist. Er koden lavet efter best practices? Dette er jo et begreb som også kan have ændret sig, siden koden oprindeligt blev lavet.

  3. Få betalt den ”tekniske gæld”

    Benyt lejligheden til at få ryddet op i det, der igennem tiden lige var den nemmeste løsning til at få noget til at virke i en fart. Her er man typisk sprunget over nogle meget lave gærder, og dermed måske kun fået løst et problem halvt. Mange af disse handlinger vil over tid summere til en stor mængde af det, vi kalder for teknisk gæld.

  4. Undersøg jeres egen proces

    Hvordan fungerer tingene i praksis? Er det en optimal proces? Ville vi måske i virkeligheden hellere gøre det anderledes? Ofte kan et af de største problemer være kulturen i firmaet og at overkomme ”sådan-plejer-vi-at-gøre-det”-paradigmet.

  5. Involvér de folk, der skal bruge systemet

    Det er også vigtigt ikke kun at involvere testudviklerne i opgraderingen, men også operatører og andre folk, der bruger systemet til hverdag. Måske er der nogle af de nye features, som løser de irritationsmomenter, de lever med i deres arbejdsdag.

Alt i alt så se det som et serviceeftersyn. For hånden på hjertet; hvornår får du igen lejlighed til at få lavet om på systemet? Udnyt chancen til at komme på forkant igen, så opgaven ikke bliver endnu sværere om yderligere et par år.

Skulle du stå med uafklarede spørgsmål, så tøv ikke med at kontakte os. Vi har erfaring med alle dele af processen: Opkvalificering af medarbejdere til nyeste version af TestStand, review af kode og best practices i udvikling og vedligehold af kode.

labview-nxg

Hvad er nyt i LabVIEW NXG 4.0?

LabVIEW NXG 4.0 blev udgivet som optakt til NIDays Europe 2019, og var blandt samtaleemnerne ved sidste års event i november. Her kommer et resumé af de vigtigste nyskabelser.

Nye interfaces

En af de store nyheder ved NIDays 2019 var annonceringen af National Instruments’ (NI’s) og MathWorks’ samarbejde, som har resulteret i en lettere integration af de to firmaers produkter, der er blandt topværktøjerne i ingeniørbranchen. For NI’s VeriStand bliver det nemmere at importere modeller fra Simulink, og for LabVIEW NXG (LV NXG) er der kommet et MatLab-interface. Det vil sige, at man kan importere en .m fil fra MatLab direkte i LV NXG og køre den som en subVI.

For brugere af TestStand er der også kommet en LV NXG-adapter, så man kan eksekvere kodemoduler skrevet i LV NXG. I LV NXG er der også kommet en TestStand-palette, der giver adgang til en række kald i TestStand. Det er dermed også muligt at lave operatør-brugerflader til TestStand.

I version 4.0 er nu også indbygget interface til databaser, om end det ikke understøtter alle typer databaser endnu. Man kan nu tilgå en lang række databaser – heriblandt SQL-databaser – direkte fra LV NXG og indsætte data fra LV NXG’s indbyggede datatyper.

Andre features

En anden vigtig tilføjelse til LV NXG er NI’s Actor Framework (AF). AF er en af de mest brugte skabeloner for avancerede designs i LabVIEW, og med version 4.0 er det nu også tilgængeligt i NXG. Kort fortalt er AF en struktur, som applikationer med flere uafhængige processer kan bygges op omkring. Fordelen er et foruddefineret system til at kommunikere mellem processerne, så racing kan undgås. Derudover er det også en veldefineret måde at starte og stoppe processer på.

Til sidst kan det nævnes, at FPGA-modulet i LV NXG endnu engang er blevet udbygget med mere intuitive brugerflader og øget hardwareunderstøttelse. F.eks. er det nu muligt at få et visuelt overblik over operationer, der strækker sig over flere clock-cycles, ligesom der også er tilføjet understøttelse af FlexRIO og USRP.

Klik her for mere information om LabVIEW NXG

Brug for assistance?

Har I brug for assistance til et projekt vedrørende LabVIEW, så kontakt GPower – de førende LabVIEW-eksperter i Danmark! Vi har erfaring med at lave brugerflader i LV NXG, som med et tidssvarende visuelt udtryk giver en bedre brugeroplevelse til dine LabVIEW-applikationer.

Klik her for at læse mere om GPower

Brugerflader med LabVIEW NXG Web Module

Brugerflader med LabVIEW NXG Web Module

Har du prøvet at lave brugerflader med Web Module i LabVIEW NXG? Her i blogindlægget giver Poul Lindholm Pedersen, Ph.D. Physics et overblik over mulighederne.

En af de store nyskabelser i LabVIEW NXG er Web Module. Web Module åbner op for at lave websider direkte i LabVIEW, og gør overgangen mellem VIs og internettet langt simplere. Det gøres gennem de nye webVIs, hvor man kort sagt kan lave frontpanelet om til en webside, mens man beholder blokdiagrammets funktionalitet.

WebVIs

Fordelene ved webVIs er, at man som LabVIEW-udvikler let kan lave en webside uden at skulle bekymre sig om HTML, CSS, JavaScript osv. Det er nemt at forbinde en webVI med en almindelig VI, så man kan let lave en mere moderne brugerflade til sin applikation, der kan tilgås overalt. Modsat web-publishing i tidligere versioner af LabVIEW så kræver webVIs ikke nogen downloads for at fungere – alle browsere vil kunne åbne den.

WebVIs fungerer på mange måder som almindelige VIs. De normale kontroller på frontpanelet er erstattet af widgets, men det grafiske udtryk er præcist det samme. Når webVI’en kompileres, bliver frontpanelet oversat til HTML/CSS, og blokdiagrammet bliver oversat til JavaScript. Da hele websiden består af HTML og JavaScript, er det også nemt at modificere koden uden for LabVIEW, ligesom man også kan tilføje tredjeparts widgets gennem den indbyggede JavaScript Library Interface.

For at gøre webVIs kompatible med mobile enheder og tablets er det i Web Module gjort nemt at skalere frontpanelet, så siden kan ses på alle størrelser af skærme. Det sker i praksis ved at gruppere widgets i bokse, der dynamisk tilpasser sig skærmens størrelse.

Data services

Ud over WebVIs er der i Web Module også forskellige data-services tilgængeligt, så websiden kan forbindes til f.eks. en backend. Der er pt. mulighed for at bruge tre forskellige API’er: HTTP, WebSocket og SystemLink. HTTP er den velkendte protokol fra internettet, og fra en webVI kan man tilgå et hvilket som helst API, der overholder REST-kravene. WebSocket er en kontinuert TCP-forbindelse, og i modsætning til HTTP-protokollen er den fuld duplex. Det vil sige, at der kan transmitteres data i begge retninger på samme tid. SystemLink er NI’s service til at integrere og administrere distribuerede systemer.

HTTP er et godt allround valg, da den giver høj fleksibilitet, og er meget udbredt. Websocket egner sig godt til streaming og kommunikation med lav latenstid, men kan være mere besværlig at implementere på server-siden, da der endnu ikke eksisterer en løsning, hvor sikkerheden er implementeret. SystemLink egner sig godt til at kommunikere mellem LabVIEW-applikationer eller op mod en NI Web Server.

NI Web server

NI Web Server er også en del af Web Module, og med den kan man opsætte en server, der kan hoste en webVI. En af de vigtigste features er, at serveren har indbygget sikkerhedsopsætning, så man kan sikre adgangen til ens brugerflade. Som et alternativ til NI Web Server, kan man også hoste sin webVI gennem SystemLink Cloud, så man undgår selv at skulle vedligeholde en server.

Læs mere om webVIs

Vil du være en bedre LabVIEW-udvikler? [Download gratis prøveversioner]

Vil du være en bedre LabVIEW-udvikler? [Download gratis prøveversioner]

Har du lyst til at blive en bedre LabVIEW-udvikler og udvikle programmer i høj kvalitet og med høj performance? Her på siden kan du blandt andet downloade gratis guides og fulde prøveversioner af vores Expression Parser.

GPower Expression Parser

GPower Expression Parser er et LabVIEW-toolset, som vi har udviklet med det formål at beregne numeriske værdier ud fra matematiske tekststrenge i stedet for statiske funktionsblokke. 

Foruden at vores Expression Parser understøtter mere end 260 ligninger og matematiske konstanter, udregner det også valgfrit værdier i enhver af LabVIEWs 14 numeriske datatyper. Du kan blandt andet læse mere om toolsettets funktionalitet og pris her.

Download guides og fulde prøveversioner

GPower Toolsets

GPower Toolsets består af 11 gratis værktøjspaletter til LabVIEW med langt over 1000 specialfremstillede GPower VIs. Vores værktøjspalette forærer LabVIEW-programmøren en række unikke funktioner, der udvider LabVIEW på centrale områder.

Har du lyst til at blive en bedre LabVIEW-udvikler og udvikle programmer i høj kvalitet og med høj performance? Ved at klikke på nedenstående link får du mulighed for at downloade vores værktøjer til blandt andet fejlhåndtering, matematik og timing.

Download GPowers toolsets