TestController definities

Ha benleentje,

Zelf een definitie schijven is goed te doen. Het is vooral een kwestie van uitzoeken. Manual uitpluizen, TestController documentatie goed lezen. Wel kan daar flink tijd in gaan zitten, vooral bij je eerste definitie.

Wat flink kan versnellen is eerst zoeken naar een bestaande definitie van een apparaat dat op de jouwe lijkt. En dan die definitie als voorbeeld te gebruiken. Je hoeft dan alleen aan te passen waar jouw apparaat afwijkt van het voorbeeld.

Wat ook helpt is dat HKJ (schrijver van TestController) goed support levert op EEVblog in het eigen Testcontroller topic. Je kunt in dat topic natuurlijk ook terugzoeken naar onderwerpen die daar al voorbij gekomen zijn.

probeer het eens!

groet, Gertjan.

Wel kan daar flink tijd in gaan zitten, vooral bij je eerste definitie.

Die tijd is niet zo erg, het is toch een deel voor mij van de hobby. Blij om te horen dat het goed te doen is.

Uitzoeken moet eerst gebeuren want de manual is nogal erg vaag daarover. Maar daar gebruik dan een arduino voor.

Op zaterdag 2 augustus 2025 18:02:31 schreef benleentje:
[...]Uitzoeken moet eerst gebeuren want de manual is nogal erg vaag daarover. Maar daar gebruik dan een arduino voor.

Inderdaad is stap 1 uitzoeken hoe je precies met je apparaat communiceert.
Dat gaat prima met je favoriete terminal programma. Gaat de communicatie serieel, dan kan dat inderdaad prima met de Arduino IDE.

groet, Gertjan.

Op zaterdag 2 augustus 2025 17:13:41 schreef miedema:
Overigens denk ik dat je definitie zo niet gaat werken met GPIB. Je gebruikt "Esc D" om de meter uit te lezen. Het manual zegt daarover:

[afbeelding]

Zolang je een meter met COM poort hebt, en serieel babbelt, is bovenstaand natuurlijk niet van belang. Maar het is wél belangrijk als je in je #metadefs ook GPIB varianten wilt ondersteunen...

Voor uitlezen over GPIB zal wel een standaard GPIB functie gebruikt worden.

Ik had niet gecontroleerd of de ESC commando's ook over GPIB werden ondersteund maar het is RS232 only. Gelukkig had ik wel een limitation boven in de definitie gezet "Not tested for GPIB models," maar de rest "however using AR488 adapter should work fine" is dus niet waar.

Deze Yokogawa modellen zijn óf GPIB (xxxx01) óf RS232 (xxxx02), en nu ik de documentatie beter gelezen heb ben ik blij dat ik de RS232 (755202) versie heb. Yokogawa heeft geen specifiek output commando gemaakt, maar gebruikt het GPIB commando [GET].

Dat zou betekenen dat de ESC R, ESC L en ESC D commando zouden moeten worden vervangen door:

#scpiCmd remote tx [LLO]
#scpiCmd local tx [LOC]
#scpiCmd read? txrx? [GET]

Ik wil daar geen tijd aan besteden om het uit te zoeken, ook omdat ik geen GPIB model heb om het in het echt te testen.

Maar ik ben de PO hè, dus ik heb GPIB support gedropped, ja dat kan als je PO bent. En aangezien ik ook, in mijn eentje, het DEV team ben is dat minder werk voor het team Dus er is weer tijd voor andere Features. Maar zonder dollen, met deze MVP versie kan je al best veel wat je zonder niet kon.

@benleentje
Je MATRIX APS-7100 is geen SCPI, dus je zal net als ik heb gedaan een vertaling moeten maken van de commando's naar wat TestController begrijpt. Nou is de documentatie 'Chinees', een lijstje met commando's en that's it. Je zou met een programma als PuTTY eerst een verbinding maken met die APS-7100 en alle commando's eens uitproberen en de responses documenteren. Het is gelukkig een niet erg gecompliceerd apparaat je eerste versie zou echt heel basic kunnen zijn, bijvoorbeeld uitlezen van stroom en spanning. Dan kan je het langzaam uitbreiden. Het ding heeft een RS232 aansluiting dus met een simpele USB RS232 converter kan je meteen beginnen. Geen arduino nodig.

Even opgezocht wat SCPI nu is. Even in mijn eigen woorden, een soort van standaard taal gebaseerd op ASCII.

En is had er nog niet aan gedacht dat het ook gewoon met een terminal programma ook moet lukken.

Mijn stappenplan, ik had al PuTTY, Java en TestController geïnstalleerd op mijn PC en ik wist al dat ik een Non SCPI ASCII definitie moest schrijven, was:

1. Fysieke verbinding uitzoeken en aansluiten, in mijn geval RS232 met null-modem adapter
2. Meter communicatie instellen, in mijn geval 9600 8-N-1 No Handshake
3. USB naar RS232 adapter aansluiten aan computer, in mijn geval een FT232R adapter
4. PuTTY instellen op de gebruikte COM poort (computer) en RS232 parameters instellen
5. PuTTY gebruiken om commando's naar de meter te sturen en response analyseren
6. Commando structuur meter analyseren voor Identificatie, in mijn geval de Yokogawa technical manual en de voorbeeld responses van PuTTY
7. Eerste definitie maken aan de hand van het skeleton op HKJ's site zie: Skeleton
8. Eerste #scpiCmd maken voor #verifyDevice aan de hand van voorbeeld keithley199 (nu kan ook yokogawa 7551-7552) maar met de response string zoals PuTTY
9. TestController instellen op de COM poort, parameters en handle naam van de definitie
10. TestController een verbinding met de meter laten doen
11. Fouten analyseren en definitie aanpassen net zolang je een melding krijgt "Found ___ on ___", in mijn geval "Found Yokogawa 7552 on FT232R USB UART (COM3)"
12. Defintie verder aanpassen voor functie #askValues en het bijbehorende #scpiCmd voor de meter
13. TestController een verbinding met de meter laten doen
14. Fouten analyseren en definitie aanpassen net zolang je een een waarde in Current Values tab binnen krijgt
15. Herhalen van de laatste 2 stappen, als alles werkt naar de volgende stap
16. Definitie verder aanpassen voor de volgende functie #_______ en het bijbehorende #scpiCmd voor de meter
17. Zelfde stappen uitvoeren als voor #askValues totdat alle #scpiCmd die nodig zijn werken
18. Eerste versie van de definitie is een feit, je kunt nu loggen ! (Dit is een POC versie)
19. Mode (functie) menu maken (rechts onder op het screenshot hierboven)
20. Setup menu maken (links onder op het screenshot hierboven), dit is echt heel veel werk !!!
21. Alles goed testen en foutjes in definitie aanpassen
22. Definitie delen voor feedback (Dit is een MVP versie)

Bij mij was het vinden van de juiste TestController commando's voor #askValues wat het meeste tijd koste, daarna ging het een stuk sneller. Miedema heeft me ook geholpen zowel met het voorbeeld Keithley199 als over de mail. Ik kon na één ochtendje 'programmeren' van de POC versie al vanuit mijn meter loggen maar dan alleen Volt DC.

De documentatie van TestContoller is naar mening nogal cryptisch en onoverzichtelijk. Definities van andere meters als voorbeeld geven meer inzicht. Ik gebruik Notepad++ als tekst editor voor definities, die helpt een beetje om de juiste consistentie te krijgen.

Verder als je je eerste doel, bijvoorbeeld uitlezen stroom, klein houdt heb je snel een resultaat. Je kan later altijd uitbreiden en zo je doel groter maken.

Mooi stappenplan van flash2b!

Er zijn erg veel verschillende meters, met verschillende communicatiemogelijkheden. En iedereen doet het op z'n eigen manier, dus er zijn meer wegen naar Rome.

Maar de grote lijnen blijven gelijk.
- Je zult eerst moeten uitzoeken hoe er met je meter gecommuniceerd kan worden. (communicatie poort, protocol, soort commando's). Manual uitpluizen dus.

Als dat communiceren via GPIB gaat, dan moet je daar ook wat van af weten. GPIB is een wereld op zich, met eigen systeem opdrachten. Maar in TC gaat veel daarvan achter de schermen. in de praktijk had ik bij GPIB probleempjes genoeg aan het Prologix of AR488 manual.

- Daarna eens proberen of je contact kan maken met je meter. Dat gaat het makkelijkst met een terminal programma. (Hyperterminal, Putty etc.)
Zo kun je een beetje spelen en testen. Probeer eerst eens antwoord op *IDN? te krijgen. (Of het equivalente identificatie commando van de betreffende meter). Vervolgens eens een meetwaarde opvragen.

Als dat lukt, ben je al een stuk op dreef: het hele stuk van communicatie tussen PC en meter werkt nu.

- Laatste stap: een TestController definitiefile schrijven voor jouw meter
Ook hier eerst simpel beginnen: een kleine definitie die niet meer doet dan jouw meter herkennen, en uitlezen. Als dat werkt ben je een héél eind!

Daarna kun je de definitie uitbouwen: andere modes en bereiken toevoegen. Menu's waarmee je de meter kunt bedienen.
Voor een groot deel kun je daarbij leentjebuur spelen bij bestaande definities.
De HP/Agilent 34401A DMM heeft bijvoorbeeld mooie menu's. Die heb ik (en anderen) dus als voorbeeld gebruikt voor mijn DMM's.

Spreekt je meter SCPI, dan ben je sneller klaar. Daar is TestController voor gemaakt.

Maar ook andere en oudere meters worden ondersteund. Dat is (meestal) wel meer werk. Bijvoorbeeld voor oudere meters die "ASCII" spreken komt er een laag bij, die de originele commando's omzet naar een soort SCPI.

.

De documentatie van TestContoller is naar mening nogal cryptisch en onoverzichtelijk.

Ik denk niet dat de documentatie cryptisch is. Maar het is wel héél veel info in een paar webpagina's gepropt. Het is dus goed lezen... (en herlezen...)

Bedenk dat TestController het werk is van één man. Die dat voor z'n hobbby doet, en gratis ter beschikking stelt. Dat die ook nog tijd vindt om documentatie te schrijven is al iets om dankbaar voor te zijn
HKJ is een inteligente man, dus die schrijft efficiënt en beknopt. (Zijn Deense Engels helpt niet altijd...)

Bedenk ook dat automatiseren van meetopstellingen en loggen in het verleden specialisten werk was, waar custom software voor geschreven werd. Dat specialisten werk zit er in dat je kennis moet hebben van de meters én de communicatie protocollen én meetsoftware. Bij elkaar complexe materie...

Dat nu met TestController dit voor een groter publiek mogelijk is, is mooi. Maar het blijft natuurlijk wel voor mensen met kennis van zaken. Verwacht geen "zonder gebruiksaanwijzing lezen klikken en klaar" consumenten software .
Hier en daar zul je toch die kennis van zaken moeten hebben, en zo niet, die kennis opdoen...

.

Het pleit voor HJK dat hij niet alleen zijn software blijft verbeteren (gister was er een nieuwe versie v2.61). Maar hij blijft ook aan de documentatie werken en uitbreiden.

Zo is er onlangs een nieuwe pagina bij gekomen over de basics van een nieuwe definitie maken: TestController, New device.

.

Het is ook gewoon leuk: zo heb ik net een USB kabel achter in m'n Hameg HM8135 RF-Synthesizer gestoken. En na een kwartiertje zat ik gezellig met hem te babbelen in HyperTerminal (zie plaatje hier boven)
Hij vertelde me onder andere z'n fabricage datum. (commando FAB?) Die wist ik nog niet.

Ik zit nu krap in m'n tijd, maar wellicht rolt daar later een TC driver uit

groet, Gertjan.

HyperTerminal zoals hierboven (op WinXP) is niet meer aanwezig in een recente Windows versies en dus niet bruikbaar. Vandaar dat ik PuTTY gebruik, maar RealTerm is een alternatief als je PuTTY niks vind.

Mijn stappenplan was voornamelijk als voorbeeld voor benleentje. Zijn APS-7100 heeft ook een RS232 poort, is niet SCPI analoog aan mijn Yokogawa. En omdat de APS-7100 veel moderner is, zijn de commando's ook makkelijker te implementeren.

Een goede tekst editor, zoals Notepad++ helpt ook omdat je dan veel minder typfouten maakt, hij kijkt naar soortgelijke "woorden" en als je dan Volt_DC gebruikt zal hij bij een andere statement ook Volt_DC voorstellen zodat je geen typ fouten maakt. Alternatieven zijn er genoeg, en ook notepad uit windows is bruikbaar. Omdat alles in een file zit blijf je wel heen en weer scrollen als je een definitie gaat maken.

Tijdens het testen van de definitie moet je wel TC in debugmode opstarten, anders zie je (bijna) geen fouten. Verwacht wel de nodige Java exceptions als je aan het coderen bent want er is geen syntax checking van je definitie.

Bediening van TestController zelf, dus de applicatie, is zeker niet intuïtief maar het is wel zo dat alles wat je kunt bedenken in het programma zit of wordt ondersteund door een commando wat je in een script of een definitie kunt gebruiken, super universeel dus. Als je er veel mee werkt ga het het steeds meer waarderen en het blijft goed dat de ontwikkelaar snel reageert op vragen.

Ha flash2b,

Dat HyperTerminal venstertje hier boven draaide in Windows 7

Ook in Windows 10 gebruik ik HyperTerminal. Dat het niet standaard in het OS zit wil niet zeggen dat je het niet kunt gebruiken. Het is zelfs heel makkelijk, portable te draaien. Geen installatie nodig .

Een ander terminal programma als Putty etc. zul je ook eerst moeten installeren .

Maar laten we ons hier niet verliezen in terminal-fan discussies.
Voor dit doel is elk terminal programma prima bruikbaar. Dus gebruik wat voor jou handig is. Dat ik HyperTeminal gebruik is vooral dat ik te lui ben om voor die enkele keer simpel gebruik iets anders te installeren en aan te leren .

.

Inderdaad zit er héél véél functionaliteit in TestController verstopt!
Ook ik leer nog steeds bij, en ontdek nieuwe dingen (of leer ze van HKJ in het EEVblog topic.
Of lees de "Documentation for main pages" nog een keer opnieuw .

En... je hoeft natuurlijk geen driver te schrijven. Heel veel meters worden al ondersteund. Waaronder eigen alle populaire moderne DMM's, ARB's, voedingen, loads etc.
Dus grote kans dat je zo aan de slag kan .

groet, Gertjan.

HyperTerminal Private Edition 7.1, de laatste versie, is niet gratis en laatst geupdate op 4 januari 2022.

Alternatieven zoals PuTTY en RealTerm zijn wel gratis en recent, en dit is de reden dat ik HyperTerminal nooit zou adviseren, zeker niet voor nieuw gebruik.

Tot zo ver de terminal discussie

Ben blij dat de "TestController, New device" pagina erbij is gekomen.

Ik hoop dat benleentje snel zijn APS-7100 aan TC gaat koppelen die definitie is er nog niet.

Ik denk niet dat de documentatie cryptisch is. Maar het is wel héél veel info in een paar webpagina's gepropt. Het is dus goed lezen... (en herlezen...)

Bedenk dat TestController het werk is van één man. Die dat voor z'n hobbby doet, en gratis ter beschikking stelt. Dat die ook nog tijd vindt om documentatie te schrijven is al iets om dankbaar voor te zijn

Er zal vast nog wel iemand zich daarover ontfermen en een betere handleiding gaat maken.

Mijn stappenplan is om eerst de digitale uitlezing op mijn draaibank nu eens te installeren en werkend te maken. 2 assen werken nu al. Ik wil nu op de pinole waar oa ook de boorkop ingaat ook op de uitlezing aansluiten.
Nog een toerental uitlezing maken en die via een arduino omzetten naar wat de digitale uitlezing begrijpt. En dan staat er 500.00 (mm) maar wat dan voor mij 500RPM is.
Frequentie regelaar en de rest nu eens in een kastje inbouwen.

Daarna zou ik eraan kunnen beginnen

Ja ja flash2b...

Iemand die graag een oude meter wil gebruiken, en daar zelfs een driver voor schrijven, maar alleen moderne software wil gebruiken?

Mijn HyperTerminal is niets meer dan een kleine .EXE en één kleine .DLL. Meer heb ik niet nodig om een handvol ASCII tekens naar een COM poort te sturen...
Je wipt ze zo uit een oudere PC. Maar natuurlijk zwerven ze ook op het web, samen met de nodige "how to's" voor Win 7 en 10.

Maar zoals gezegd, als je liever wat anders gebruikt, van mij mag dat net zo goed. Voor anderen zal dat handiger of beter zijn.

Waar het om gaat is dat je simpel de verbinding en communicatie met je meter kunt testen. Waarmee je dat doet is niet relevant.

En omdat de APS-7100 veel moderner is, zijn de commando's ook makkelijker te implementeren.

Dat is alles wat ik wou horen

Voor de rest is het stappenplan ook wat ik ongeveer met programmeren of andere problemen doe. Alles in kleine stukjes opdelen en alleen die kleine stukjes eerst proberen.

TestController definitie voor de Analogic DP100 en Rohde & Schwarz UDL45 Multimeter.

Mijn 2019 "Radiomarkt Lichtmis" aankoop Analogic DP100 had geen TestController ondersteuning, maar heeft wél een RS232 poort, dus ik ben weer aan de slag gegaan om een definitie te schrijven.

Met behulp van de opgedane ervaring van het schrijven van de Yokogawa 7552 defnitie en hulp van HKJ op EEVBlog is het me gelukt om een werkende versie te maken.

De Analogic DP100 kwam uit in maart 1990. Ik denk dat mijn exemplaar uit 1995 komt, dus 30 jaar oud. Hij is nog helemaal in spec en kan nu, met behulp van de definitie, met moderne middelen worden uitgelezen. Het is een compacte meter die ook op een (in het apparaat) oplaadbare accu kan werken en heeft een onverlicht LCD scherm. Er zijn veel functies en bereiken maar verder geen geavanceerde functies en hij reageert niet altijd even snel. Het fijne is wel dat deze meter SCPI ondersteund waardoor het definitie schrijven (iets) minder werk is. Verder is er op het Volt_DC bereik, één extra digit beschikbaar voor TC, dus 6.5digit !

Hier is te zien dat de meter lekker babbelt met TestController en er grafieken en logs kunnen worden gemaakt.

De definitie hieronder is een POC versie, als Bonus is er wel een Mode (functie) menu maar een setup menu ontbreekt, ranges en geavanceerde functies (die er niet zijn !) moeten direct op de meter worden ingesteld.

Ik heb de definitie ook geschikt gemaakt voor de Rohde & Schwarz UDL45 welke een relabeled DP100 is en verder identiek.

Het betreft hier een beta versie die ik (wederom) time-boxed heb geschreven. Mocht je een geschikte meter hebben en na gebruik opmerkingen, aanmerkingen of suggesties hebben voor toekomstige versies, dan hoor ik het graag.

Analogic DP100 v0.10 POC Beta.zip

Zie: https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-…

flash2b goed bezig

Zou test controller ook een modbus RTU kunnen uitlezen? modbus rtu gaat via een ethernet kabel en poort.

Het gaat dan om een power meter voor 3 fasen die ik dan ook als power analyzer kan en wil gebruiken. Tegen die tijd dat ik dat gaat word dat wel een eigen topic want ik heb verder ook totaal geen idee van het protocol van dat ding. Ik heb wel een lijst met commando voor als het om gewoon modbus gaat dus ik hoop dat te kunnen gebruiken.

Ha benleentje,

TestController heeft speciale commando's voor modbus: Modbus serial & network.

@flash2b: netjes!

Ook ik kon het niet laten, en heb vandaag een driver geschreven voor m'n Hameg HM8135 RF synthesizer. Daarmee kan ik nu in TestController sweepen van 1Hz tot 3GHz .

groet, Gertjan.

Het is bij TestController mogelijk het log interval in te stellen:

Maar dan moet je meter hem natuurlijk wel bij kunnen houden:

Die laatste screenshot is van v0.11 definitie, zonder enige #readingDelay (in tegenstelling to de v0.10 POC), dus maximale snelheid.

Het heeft geen zin om het log interval op 0.01 sec te zetten, voor deze meter. Denk dat het wel vaker geldt voor andere apparaten die in de installatie zitten. Vanuit universeel oogpunt snap ik het, maar het is wel raar als je meter het niet haalt.....

Het is jammer dat de Analogic DP100 zo traag is, vooral als hij van mode (functie) moet schakelen. Het goede nieuws is dat ik er om heen kan schrijven om toch nog iets bruikbaars te realiseren.

Ik mag hopen dat bij recente meetapparatuur de SCPI commando structuur en snelheid een stuk beter zijn als deze DP100. Ik hoopte dat ik sneller nieuwe features kon schrijven doordat ik nu met de SCPIx driver werk en niet met de ASCII driver, maar het is allemaal marginaal. Het blijft veel werk om bejaarde meetapparatuur zover te krijgen voor besturing onder TC. In mijn mening te veel werk maar daar zal niet iedereen het mee eens zijn.

Bovenstaande alinea gaat puur over het schrijven van definities voor oude meetapparatuur ten behoeve van TestController. De meter is 30 jaar oud, dus coderen voelt ook zo wat 30 jaar geleden normaal was.

Het programma is echt een aanwinst als de definitie al beschikbaar is en het zorgt ervoor dat je verschillende merken met een programma kunt aansturen.

In mijn mening te veel werk

Ik ga het over een paar weken wel zien.
Maar voor mij is het hobby en maakt het niet uit.
En teveel werk is ook maar relatief want anders heb je helemaal niets waarmee je de meter kan uitlezen toch?

En als er al iets is dan is het merk specifiek. En moet je voor elk apparaat andere software installeren.

[Bericht gewijzigd door benleentje op donderdag 7 augustus 2025 18:23:39 (18%)]

Ter verduidelijking.

Snel een definitie maken waarmee je kan loggen, is niet te veel werk. Beide definities die ik heb gemaakt snel op een niveau dat je kon loggen, een paar uur werk ofzo.

Ik heb het over het verfijnen (alle features die het meetapparaat ondersteund) en afwerken (dat alles soepel draait, onder elke conditie of volgorde. Zo'n setup menu maken is echt veel werk, en als de SCPI commando's niet helpen ben je daar zo dagen/weken mee bezig. Voor iedereen zal dat anders zijn, hobby of niet.

Nu kan ik zowel mijn Yokogawa 7552 en Analogic DP100 uitlezen wat ik voorheen niet kon, dus ja dat is een hele stap vooruit, daar heb je gelijk in.

Gelukkig heeft die matrix voeding niet zo heel veel En als het om uitlezen gaat maar 6 waarden. En voor het instellen is het ook niet zo heel veel. Dat scheelt wel.

Uitlezen is makkelijker als instellen is mijn ervaring.

Jammer genoeg hebben hier op CO mensen geen Yokogawa 7552 of een Analogic DP100 dus ik denk dat ik mijn heil voor een beta test en feedback van de nieuwe versie maar op EEVBlog ga zetten.

Inmiddels hebben beide definities al heel wat bugfixing achter de rug en werken een stuk sneller als die eerdere gedeelde versies.

Op donderdag 7 augustus 2025 17:04:17 schreef flash2b:
Het heeft geen zin om het log interval op 0.01 sec te zetten, voor deze meter. Denk dat het wel vaker geldt voor andere apparaten die in de installatie zitten. Vanuit universeel oogpunt snap ik het, maar het is wel raar als je meter het niet haalt.....

Ik gebruik dit (een te snelle logsnelheid instellen) soms expres om te zien hoe snel een meter kan loggen. Je ziet dan in het log wat maximaal haalbaar is.

De logsnelheid wordt niet alleen bepaald door de meter maar door het systeem.
Dus naast de meter ook de communicatie interface, en de software.

Als er meer apparaten aan TestController hangen, dan zal de langzaamste de maximale snelheid bepalen.

Ook in GPIB interfaces zit verschil. AR488 is niet de snelste.

En in de meter zelf zijn het grotendeels de instellingen van de meter die z'n maximale snelheid bepalen. Denk aan NLPC, triggermode. Meestal zie in de specs al staan onder welke condities z'n logsnelheid opgegeven wordt.

Een oudere meter hoeft niet langzaam te zijn. Denk maar aan de Keithley 199 . En ook bij de K199: de MUX uitschakelen, en omschakelen van 5,5 naar 4,5 digit resolutie scheelt véél in snelheid.

Ook de manier van aansturen kan veel invloed hebben op de snelheid van de meter. Het kan zijn dat hij ongemerkt ergens op staat te wachten, een triggerconditie, een buffer waar nog wat in zit, een andere opdracht die tussendoor komt etc.
Denk ook aan een net niet correct commando, dat een time-out oplevert...

Overigens heb je die hoge logsnelheden nauwelijks nodig. Loggen gaat meestal over het bekijken van langzamer verlopende processen over langere tijd. Mijn meest gebuikte logsnelheden zijn intervallen van 1 sec of 3sec.

Een hoge logsnelheid als 0,01sec interval zou een enorme, onnodige berg data opleveren....

Als je een snel veranderend proces wilt bekijken, dan kun je beter een scoop gebruiken

groet, Gertjan.

Op donderdag 7 augustus 2025 18:22:42 schreef benleentje:
[...] En als er al iets is dan is het merk specifiek. En moet je voor elk apparaat andere software installeren.

Dat is het grote voordeel van Testcontroller: één programma voor al je meetapparatuur. je hoeft dus ook maar één programma onder de knie te krijgen.

En als je logt met meerdere meters, dan komt al je data meteen in één tabel.

.
Voorheen had ik inderdaad aparte software voor elke meter. Oudere meters betekende oudere software. Soms DOS, soms Windows3. Ik had aparte PC'tjes om die archaische software draaiende te houden. Maar je was al lang blij als je een stukje software gevonden had waarmee je kon loggen...

En dan loggen met meerdere meters: elke meter dus z'n eigen software, soms op aparte PC's...
Dan moest ik na afloop uit elk programmaatje een CSV exporteren, om die vervolgens in Excel te combineren. Dan pas kon ik de gewenste grafiek gaan maken. Over onhandig gesproken...
En dan heb ik het er nog maar niet over dat als die data van verschillende PC'tjes kwam, de klokken natuurlijk ook niet exact gelijk liepen.

.
Nee dan TestController, alle Meters aan één programma, en ik kan de grafiek bekijken terwijl de meting nog loopt.
Voor die luxe wil ik dus best wat moeite doen .

Groet, Gertjan.

Op donderdag 7 augustus 2025 20:04:11 schreef flash2b:
Uitlezen is makkelijker als instellen is mijn ervaring.

Ik denk dat het in het geval van benleentje wel meevalt.

Bij een DMM zijn de menu's inderdaad complex, en dus veel werk. Een DMM heeft veel modes, en veel settings die je moet/kunt implementeren.

Maar andere apparaten hebben geen mode, en maar een paar instellingen. Dus dan ben je ook een stuk sneller klaar.
Het klinkt alsof de voeding van benleentje in die categorie valt.

En wat altijd een goed idee is: kijk naar al bestaande definities van soortgelijke apparaten voor inspiratie .

Zo heeft de HP 34401A DMM hele nette en handige menu's. Diezelfde menu structuur gebruik ik nu dus voor al m'n DMM definities
Dat gaat veel sneller dan helemaal zelf bedenken, en er zitten handigheidjes in die ik niet bedacht zou hebben.

groet, Gertjan.

Laatste versie voor de Analogic DP100 staat op EEVBlog : https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-…