Har lite olika mätinstrument som jag skulle vilja ha möjlighet att automatisera tester och loggning med.

Rör sig om spänningsaggregat, funktionsgenerator, DMM och liknande, av olika märken.
Gemensamt för dessa instrument är att de har LAN och USB-anslutning. LAN vore kanske det smidigaste att använda rent inkopplingsmässigt.

Jag har dock aldrig riktigt förstått vad som gäller kring alla dessa standarder runt kommunikation, alla instrument gör reklam för att de stödjer LXI, och det finns IVI-drivers till samtliga. Har ytterst dålig koll, men förmodar att dessa är några generella standarder kring instrumentkommunikation.

Så, vad finns det för sätt att faktiskt prata med alla instrument ifrån ett PC-program?
Labview är ett givet alternativ, som jag även har tillgång till. Men jag fullkomligt hatar den grafiska programmeringen i Labview.
Verkar som att instrumenten dyker upp som COM-portar i PC'n, så jag antar att man kan skriva sitt helt egna program i valfritt språk och bara prata ut på COM-portarna, men det verkar väldigt jobbigt.

Finns det inga bra generella program som kan styra "alla" instrument med dessa standardprotokoll?
Skulle vilja ha något enkelt där man typ kan ställa in ett testförlopp som:

00.00: Sätt matningsspänning 12.00V
Börja loggning på multimeter med intervall 1s
Sätt frekvens 1kHz 2Vpp

00.05: Sätt matningsspänning 11.00V
Låt övriga instrument fortsätta

00.10: sätt frekvens 2kHz 2Vpp
Låt övriga instrument fortsätta

00:15: Stäng ner allt och spara loggfil.


Och på så vis skapa i princip vilka tester som helst, som går igenom ett visst förlopp. Finns detta?

I princip alla instrument numera har ju LAN och USB, känns märkligt att man inte hittar en uppsjö med programvaror till att styra dem, annat än tillverkarnas egna "remote control"-program som inte brukar kunna göra annat än just att fjärrstyra det specifika instrumentet så att man får klicka på datorn istället för instrumentets knappar...

Jag har inte använt LXI mycket men jag tror att det kan vara svårt att hitta ett program som tar alla instrument då LXI verkar vara en halvstandard. Man ville ha en gemensam standard som man kan peka på i PR-sammanhang men ändå behålla tillverkarinlåsning.

Från lecroys hemsida

Sannolikt stödjer alla fjärrstyrbara instrument tillverkade efter 1993 en standard som heter VISA. Den specar ett antal standard-kommandon för att styra instrumenten. Typ MEASURE::VOLTAGE:: eller hur det nu är. Vill du inte använda någon av den uppsjö med program som faktiskt finns för att göra automat-testutrustningar så är du nog hänvisad till att läsa manualer och programmera själv. Så j..a svårt är det faktiskt inte om man inte har ett tok-avancerat instrument man vill använda. För vanliga generatorer och enkla multimetrar kan det omöjligen vara svårt.

Vad gäller den "uppsjö" program som finns så domineras den totalt av National Instruments och Labview, Labwindows och TestStand. Jag vet inte vart Hp VEE och keithleys vad den nu hette tagit vägen. Sannolikt ingenstans. Och så finns transeras HT-Basic säkert fortfarande. Men eftersom XI i beteckningarna har uttytts som Xpensive Instruments så förstår du säkert vart priserna på dessa programvaror ligger.

VXI = Very Xpensive Instruments
PXI = Pretty Xpensive Instruments
LXI = Lan for Expensive Instruments

Det finns något som heter EZGPIB (googla) som kan prata med instrument. Osäker på om det bara är gpib eller om det kan serieport/lan också.

Men min åsikt är att det finns inte mycket som slår bra manualer och basic i detta fall. Tyvärr är båda något kraftigt utrotningshotat. Men så har mitt arbetsliv levts i andra änden på testningen. D.v.s. att ta hand om allt mätdata som kommer ut.

De flesta program klarar sådana saker. Allt från C och uppåt i windows.
Skillnaden är att om man programmerar testrutiner där ett flertal instrument av olika fabrikat och språkbegåvning ska kommunicera är det mycket jobb att få i hop det i C.
I de programmerings-miljöer som är gjorda för just såant är det en fråga om minuter att göra enklare saker typ det du beskriver, men framför allt i test-miljö, har man väl en fungerande miljö så är det mycket enkelt att tillfälligt modifiera en test-uppställning,.
Typ när DMM går under 3.43 Volt, utför svep på R&S signalgenerator med dessa frekvenssvep och amplituder och spara en skärmdump från Agilent spektrumanalysator när svepet passerat 1 GHz.
Den programmeringen görs i en grafiska miljö typ Labview på några minuter, om man sedan tidigare har programbiblioteken för resp instrument installerat.
Miljön är grafisk men det går att göra mer än tillräckligt avancerat ändå. Finns inget som hindrar att man i Labview använder C och matlabscript eller anropar andras dll-filer.
Koden blir direkt effektiv utan konkret kompilering , och man kan testköra kod som inte ens är färdigskriven.
Det som ibland kan vara svårare är debugging.
Ska man skriva program i Labview för kommersiellt/industriellt bruk är det viktigt att man kan strukturera felhantering på bra sätt.
Skulle multimetern lägga av pga dåliga batterier, är det inte säkert multimetern talar om det utan är bara plötsligt är väck. Sådan händelse får inte äventyra industriella processer typ koka vatten, då det kan leda till torrkok och att fabriken brinner ner. För sådan felhantering finns ett grundstöd i Labview men i slutänden, hur feltolerant ett system fungerar är upp till programmeraren.
De flesta av dessa lite mer kompetenta system har nackdelen att prislappen är hög. För att skapa säljbar exe-fil för Labview kostar kompilatorn 50kkr.
Däremot även för industriella processer med unik kod är det sällan att man kompilerar koden till exe fil, man kör den i grafiskt men okompilerat läge där det tar sekunder om man vill omrouta några instrument utöver vad som var konfigurerat som alternativ i exe-filen.
Samma sak om du skiftar mätinstrument från något USB till äkta GPIB och skillda märken, det är i de flesta fall enkelt att uppdatera koden så den fungerar lika bra oavsett instrument.
För större industri-miljöer bruka man ge SCADA en övergripande roll. SCADA är en storebror till Labview. Det är mindre flexibelt men kan mycket väl hantera underliggande Labview-processer.

Seriösa mät-instrument har GPIB hårdvaru-bus. vilket kan säjas vara USB i industriell tappning. Ett problem är att det finns många lågpris-alternativ som inte når riktigt ända fram, inte är bus-kompatibelt osv. Den typen av interface kan duga om man vill läsa av en DMM i rimligt tempo men fungerar sällan bra i en komplex miljö med flera instrument och snabba tidskritiska data-flöden, typ från oscilloskop spektrumanalysatorer och nätverkare. Av den anledningen vill jag inte rekommendera GPIB2USB av typ Prologix och andra enklare alternativ. De har givit mej mycket bekymmer genom åren.
Däremot har många moderna instrument idag USB-anslutning som inte visar sej som en enkel serieport utan levereras med drivrutiner som internt i datorn fullt ut emulerar standard enligt IEEE 488 och kan hanteras som VISA-enheter.
I många fall, med sådana VISA-kompatibla instrument, kan man plugga in olika modeller eller fabrikat utan att ens ändra en enda rad i programkoden i Labview, trots att instrumenten i sej har olika intelligens-nivå och språk-dialekter.
Nackdelen med detta är att portabiliteten kan bli svårare, om t.ex. drivrutinerna bara finns för Windows men inte Linux/MAC/MCU..

Tack för alla svar!

Låter inte som att det finns någon riktigt "färdig" universallösning för detta alltså, okej.
Provkörde Keysight Benchvue, det verkade kunna göra ungefär det jag tänkte mig ganska enkelt, alltså att på ett smidigt sätt göra olika testförlopp. Men, då är man helt låst till Keysight-instrument, dessutom verkade programmet kosta $$$ (Bara modulen för att prata med en DMM kostade 2500:-/år, och förmodar att alla andra moduler för respektive instrumenttyp kostar lika mycket). Förmodar att det finns liknande program från andra tillverkare..

Får fundera en liten sväng om jag ska kämpa vidare med Labview där jag har något enklare testprogram idag, eller om jag ska börja om med en helt egen applikation.

Blir i så fall skriven i C# som jag är hyfsat bekväm med. Med lite välskrivna klasser för respektive instrument kanske det kan gå förhållandevis enkelt sen att göra nya testförlopp.
Det fina med det är också att jag då kan baka ihop det med respektive testprogram för den hårdvara som ska testas, de är i regel skrivna i C# på mitt jobb.

För mej är en Labview en färdig universal-lösning, men den är färdig just därför att den är stabilare att vara flexibel med än det mesta annat. Dess namn antyder ju att den är anpassad för snabbt labbande och testande av olika slag och det stämmer bra.
Styvkodad miljö fungerar inte för mej, två lika mätuppställningar förekommer sällan utan samma programvara ska kunna återanvändas trots att hårdvaran och konfiguration växlar och det ska helst kunna anpassas innan mätinstrumentet hunnit boota upp.
Noterade just det att byte av spektrumanalysator var gjort fortare i Labview än vad instrumentet hann boota och då är det ett byte mellan två instrument som i grunden inte talar samma språk och har olika kommunikations-interface.

Det finns äldre versioner av Benchvue som är gratis (före 2017). Det är grafisk miljö men inte alls i närheten av Labview vad gäller programmringsmöjligheter och flexibilitet och man supportrar endast egen hårdvara. Lägg till att man alltid dragits med instabilitet pga buggar. Det är inte ens som gratis intressant för mej då det inte är mer än ett avancerad användar-interface. Inget man sätter upp en komplex mätmiljö i. När man inte heller kan styra olika tillfälliga mätobjekt så är det helt odugligt för min del. Mätobjekt är då oftast för min del radio-kretsar för ISM/2-3-4G/WIFI där mätningarna är en del i att optimerar RX/TX-egenskaper mha av design av filter och antenner för bästa effektivitet.
R&S har motsvarande programvara för sina mätinstrument kallad QuickStep.
Även Agilent VEE finns ännu en tid kvar och är så vitt jag vet gratis.

Unikt med Labview är att samtliga större och seriösa mätinstrumentsföretag som inte är extrem-nichade tillhandahåller färdiga bibliotek för sina instrument för denna miljö utan extra kostnad.
Med samtliga avses Anritsu, R&S och Keysight (HP/Agilent) som sedan 20 år har kompletta bibliotek till samtliga instrument i deras sortiment.
Givetvis finns bibliotek för mindre kända mätinstrument i mängds med i Labviews nedladdningbara samling
Bibliotek från kinesiska nykomlingar med semiproffs-instrument typ Rigol och Siglent kan även de laddas ned. Det är ett villkor för många instrumentköpare att Labview är supportat. Finns inte suporten köper man ett annat instrument.
Samma bibliotek som utvecklades för 20 år sedan är kompatibelt med Labview 2018 viket i sej är bekvämt med så lång bakåtkompatibilitet.
Mitt senaste instrument-inköp, en CMT VNA kommer med färdigt bibliotek. Bara att plugga in i min mätmiljö via USB, direkt program-kompatibelt med min 25 år gamla HP8753. Skiftar jag anslutet instrument sker byte av instrumentdrivrutiner i mätprogrammet helt automatiskt så som det är avsett att fungera i IEEE-488.

Mitt behov är att fritt kunna blanda och synkroniserat styra 4-5 mätinstrument samt även styra mätobjektet. Det är sällan mät-uppställningen är lika två ggr. Olika system, frekvensområden och olika problem som ska lösas gör att flexibiliteten i mätprogram måste vara stor. Bara en sådan sak som att min spektrumanalysator som fungerar bäst för låga frekvenser tar slut vid 3GHz.
För att kunna mäta på 10-20 GHz för spurioser körs då bägge instrumenten i sekvens i mätprogrammet, men presenterar det som en enda sammanhängande mätkurva och med gemensamt användar-interface. Om jag behöver ändra något typ referensnivåer eller upplösnings-bandbreedd så sker det simultant på bägge instrumenten men jag ser det som endast ett instrument.
Det är en fördel att denna typ av anpassning av mätmiljö sätts upp på minuter för en alternativt två instrument. Här finns dock av mej programmerad funktion för att underlätta denna typ av samkörande, men en gång programmerat, sedan är det flexibelt att välja om man vill använda det.

Styr även även enklare saker som ett Arduino-baserat vridbord.
Labview har inbyggd flash-funktion om jag behöver ändra programvaran i vridbordet men det är mer ett udda plus i kanten.

En fördel med Labview är överskådligheten av koden. Skriver man snygg Labview-kod ser den ut som ett lättförståeligt flödes-schema som man omedelbart kan se vad som utförs utan någon kommentering alls.
Självklart ska man kommentera kod utförligt men katastrofen om den saknas i Labview är liten jämfört med om koden är skriven okommenterad i kompakt Perl eller assembler.

Finns massor med nackdelar med Labview men som tidsbesparare i labbet saknar Labview alternativ.
Inlärnings-tröskeln är låg för att få de första programmen att utföra något nyttigt men det finns oändligt med utrymma att växa om man vill utveckla avancerade mätanalyser eller simuleringar.

LabWindows/CVI är en textbaserad närstående programmerings-miljö skriven för ANSI C som kommer från samma företag, National Instruments.
Utöver programvaran säljer National Instruments egen-utvecklade mätinstrument med mycket samma modul-tänk som i Labview, så en instrumentdel kan konfigureras till att vara del i olika typer av instrument, allt efter hur man programmerar enheterna.

Har kollat på Labview-alternativ typ ATEasy och DASYLab men de är i mitt tycke långt från fullvuxna att hantera lab-mätningar. Möjligen har dessa mera en roll som övervakare av industriprocesser.
VB var min kontrollmiljö i labbet för 20 år sedan, och delvis var det senare en runda i C++ som var motiverat av klena dator-resurser för tidskritiska system men sedan 10 år regerar Labview,
Många spår att PyLab_Works kommer invadera mätlabben. Jag är tveksam men det är open source vilket tilltalar många.
MyOpenLab var ett annat alternativ som såg lovande ut men något hände som gjorde att utvecklingen gick in i en återvändsgränd.
FlowCode är inget för ett lab.
FlowStone verkar mycket lovande och ser fräscht ut och har tilltalande pris men det kommer ta dom lång tid att få instrumenttillverkare att per automatik utveckla bibliotek på samma sätt som med Labview.
Har man mer oföränderlig mätuppställning där VISA-server inte är intressant så behöver man kanske inte fulla biblioteken, det går bra att anropa de för varje instrument dokumenterade kommandona i GPIB, vilket kan göras direkt i C# eller vad man nu känner sej mest hemma i.
Men kostar sådant omkodande i timmar varje vecka för att anpassas mot senaste mätbehovet så lönar det sej bättre ur produktivitets-synpunkt med Labview även om det är en initial kostnad att köpa in programmet jämfört med open source och att det kommer ta en tid att lära sej och bygga upp grundstommar till de mätscenarion som är vanligast.

Lägg till att Labview är enkelt att utföra efter-analys i, spara dokumentation om att aktuella mätningen inklusive instrument-konfig och lätt att skapa mätrapporter i Word med relevanta diagram och mätomständighet automatiskt inklistrade vilket förbättrar uppföljning tidigare mätresultat och underlättar rapport-skrivandet då den redan finns halvfärdig efter utförd mätning.

Labview har en mycket stor och aktiv användarbas med flera aktiva forum vilket höjer programmets värde då det alltid finns möjlighet att få snabb feedback om man kör fast.
De största forumen är NI's egna forum och LAVA vilka båda håller hög kvalitet där det är enkelt att hitta tidigare liknande problem som ens egna. Dessutom har NI-forumet en egenskap som gör att grafiska bilder med kopplingsexempel på forumet går att direkt med musen dra in í sitt egna program där bilden då omvandlas till körbar kod.

Jag testade detta när jag köpt mitt oscilloskop DS1054Z.

https://pypi.org/project/python-vxi11/

samt,
https://github.com/eevidtron/eevt002.git

Jag har inte så mycket information om dessa annat än att det senare fungerade finfint för att styra oscilloskopet med.

Jag styr mycket instrument i C#.
Det fungerar utmärkt.

Förenklat jag jag exakt det TS beskriver att han vill göra.
Olika instrument är mer eller mindre kompatibla med varandra, så det är en del klurigheter ibland för att få alla att fungera som man vill.
Särskilt med felhantering och långsamma instrument.

Kolla C# och NI Visa paketet.

Har nu landat ganska så stabilt i att det får bli C# ändå.

Labview må ha en del fördelar, men jag har aldrig och kommer inte inom närtid komma överens med den grafiska programmeringen.. Dessutom har jag tillgång till ett ganska begränsat utbud mätinstrument, så det kommer att vara tämligen sällan som de byts ut. Att då behöva kompilera om vore det minsta problemet.

Idag har jag fått ihop en välfungerande klass för att styra klimatskåpet på jobbet.
Har även fått igång ett par superenkla testprogram för att se grundläggande kommunikation till en Keysight DMM (via ethernet), och en NI cDAQ (via USB), det tycks fungera utomordentligt bra.

Så imorgon ska jag jobba vidare med att få ihop en vettig och användbar klass för multimetern. Därefter cDAQ'en och så lite loggning.
Sen får det bakas in i ett befintligt testprogram till en ny produkt som väntar på klimattester.. Blir nog bra detta!