Det går säkert bra att köra PyVISA mot ip-port om instrumentet stödjer det.
Fungerar jättebra för sådant som en hobbyist normalt använder det till.
Gratis program, enkel program-miljö och i värsta fall kan man ladda hem NI-VISA för att kunna kommunicera med somliga instrument.
Det förändrar inte att det är kraftigt begränsande inom produktions-industrin och för seriösa mätlab, varför det inte alls förekommer där.
Det är som att köra ut grus till motorvägsbygget med skottkärra. Ett lass varannan dag 3 mil t.o.r..
Kärran är nästan gratis och kräver måttligt funderande för att hantera, men motorvägen kommer bli otroligt dyr att producera med sådana verktyg.
Labview är total dominant med världens största standardiserade instrument-bibliotek. Om inte annat är det av stor betydelse den dagen ett utgånget instrument utefter produktions-linan behöver bytas och ersättas med instrument av annat fabrikat. Styrprogramvaran för produktions-processen kan inte tillåtas vara beroende av byte av instrument skulle kräva ny validering av produktions-linans funktion, det ska bara fungera.
Samma med komplicerade mätprocesser i mitt lab. Inte sällan är instrument utbytta, tillfälligt eller permanent och programvaror för att mäta vanliga parametrar kan inte behöva skrivas om bara för att ett instrument i kedjan är utbytt. Det kräverr lite eller inget jobb i Labviews programvara att byta VNA från Keysight till R&S trots stora skillnader i program-struktur.
Det är sällan man gör ett enkelt svep med en VNA för att mäta VSWR, vilket för hobbyisten kanske är främsta användningsområdet för ett ensamt instrument.
Ett i lab mer vanligt scenario är mätningar som kan pågå kontinuerligt mellan 5 minuter tilll 5 timmar. Debiterar man kunden timtaxa för labbet så blir kinden sur om man använder programvara som orsakar fördubbling av mättiden och det minskar egen möjlighet till produktivitet. Hur tidseffektiva mät och design-jobben är avspeglar sej direkt i vad jag kan fakturera.
En mätning i flera timmar, vad sysslar man med på den tiden om man inte mäter VSWR? Ett exempel är TRP.
TRP kan t.ex. mätas för optimering av antenn-impedans på en mobiltelefon (Total Radiated Power, en slags effektivitetsmätning).
Det är en viktig faktor eftersom varje förbättring direkt avspeglar sej i motsvarande längre driftstid på samma mängd batteri.
Man använder vid sådan mätning en calltester som aggerar en från min mjukvara styrbar basstation. En typisk calltester:
https://www.ebay.com/itm/Anritsu-MT8820 ... 3827972381
Mätning går ut på att via calltestern skicka kommando till telefonen att välja kanal/frekvens och uteffekt, därefter mäta med spektrumanalysator resulterande fältstyrkan. När man stegat igenom frekvensbanden beordras vridbordet flytta sej en position och mätningen upprepas. Calltester, spektrumanalysator och vridbord är alla separata GPIB-adresser.
Om jag nu ber någon att i förväg skriva ett program i PyVISA, för ännu ej exakt specificerade enheter. dvs calltester, vridbord och spektrumanalysator av okända fabrikat kommer senare specificeras olika av olika mätlab om de ska kunna använda samma mät-program.
Kommer möta mindre förståelse från PyVISA-programmeraren att skriva ett sådant program. I labview går det bra.
Mitt program, AnTune, är sådant exempel. Oavsett typ av VNA, så länge det möter en viss standard i labview-gränsnittet (488.2) kan mitt program skifta mellan en 20 år gammal HP8714 till en ny USB-VNA från Coppemine Tech. i farten.
För AnTune kommer en annan viktig faktor in, CPU-effektiviteten.
Det mest basala mitt program gör är att läsa av nätverkarens komplexa kurva, applicera korrektioner i tidsdomänet i två nivåer (short & open) och tillbaka till frekvensdomänet beräkna resulterande förluster och nya komplexa impedanser för virtuella matchningskomponenter baserat på dess uppmätta impedanskurvor (Touchstone vanligen) för att slutligen lägga ut detta på bildskärm. Det är inga problem att utföra 10 ggr per sekund och kostar ungefär 10% CPU i en måttllig dator.
AnTune försöker optimera så att nätverkaren ska tillfrågas efter data precis när den är färdig med ett svep för att ytterligare minska tidspillan/last/dötid innan nätverkarens svep-resultat hämtas.
Just In Time kan spara 5-10 % jämfört med att fråga efter data för tidigt och komma för sent, när ett svep för länge sedan är avklarat kommer direkt begränsa hur ofta man kan uppdatera resultat.
Ska matchningsnätverket dynamiskt optimeras för minsta reflektionsförlust relativt en telefons komplexa impedanskurva för Tx/Rx eller TIS/TRP efter varje svep ökar CPU-last till 20-100%.
Det går men kostar dator-last så effektiviteten för hur fort en beräknings-kedja kan hanteras blir viktig.
Halvkompilerad Python är när det gäller sådana beräkningar en total katastrof vad gäller CPU-effektivtet. Det är 10 till 100 gånger långsammare. I värsta fall blir det bildskärmsuppdatering var 10:e sekund samtidigt som man saxen klipper komplicerade mönster i kopparfolie baserad på mätvärdena, eller lite enklare förståeligt, att balansera med trim-mejsel trimma längden på en dipol med extremt högt Q.
Sådan fördröjning är som att köra snabb sportbil på alpvägar och bara få uppdateringar genom framrutan var 10:e sekund.
Man får minska farten ner till 2-3 km/h om man inte ska köra av vägen och det kommer ändå att blir vingligare framfart.
På motsvarande sätt får man öka behövda arbetstiden för att utveckla ett filter eller antenn med en faktor 10-100, bara för att man jobbar med långsam programvara och kvaliteten på jobbet blir sämre trots/pga långsamheten, just eftersom det ger ett på motsvarande sätt mer vingligt resultat.
Hur mycket långsammare är då Python relativt C++, som Labview i princip kompileras ned till vid körning? Man kan få många svar beroende på hur jämförelsen görs men typiskt matte-intensivt så är skillnaden en faktor 10 eller mer.
Långsamheten är ett helt ok pris att betala så länge man roar sej privat med enklare beräkningar men inget för en kund som ska betala tim-räkning för lab-tiden med några tusen kr per timme.
Bilden nedan är en av flera jämförelser hur mycket långsammare olika versioner av Python är relativt C och C++.
Bilden är någorlunda färsk. Den är klippt härifrån:
https://warwick.ac.uk/research/rtp/sc/r ... uction.pdf
Notera att tidsaxeln nedan är logaritmisk, så tids-skillnaden är som störst en faktor 100.
graph3.png
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.