TestController definities

Ha flash2b,

Het doet me goed dat je nu een volledige versie van je Analogic DP100 definitie gemaakt hebt!
Het is bevredigender om iets goeds en moois te maken. En je doet jezelf, en alle anderen die TC met hun DP100 willen gebruiken er een plezier mee.

Nu je zo lekker op dreef bent, is dit het moment om met je Gossen-Metrawatt Interface Adapters aan de slag te gaan? :-)

groet! Gertjan.

Ik heb de nog volgende meters waar ik TestController ondersteuning voor wil maken:

De Hameg HM8112 zal wel niet makkelijk zijn, aangezien het zonder besturing al zo traag is.

De Everfine PF9901 moet wel eerst voorzien worden van RS232 of USB uitgang. De defnitie maken is wel de makkelijkste van de 4 omdat er geen commando's zijn.

De ZXP ZX8511D is SCPI met een mooie manual. Langdurig aan de onderdeel meten is niet echt nuttig en aangezien hij maar 4 frequenties heeft is sweepen ook niet een optie.

De Gossen-Metrawatt MetraHit 29S heeft de grootste uitdaging, weinig documentatie en niks te vinden op internet over de BD232 interface.

De Everfine PF9901 zou ik het hoogst op mij ToDo lijstje zetten.

Ha flash2b,

Inderdaad maak ik steeds een afweging hoe nuttig het schrijven van een definitie voor mij is.
Ik zie geen toepassing voor een LCR meter in TestController. (Dus heb ik b.v. geen definitie geschreven voor m'n DER DE-5000)

Voor DMM's kun je afvragen hoeveel DMM's je maximaal tegelijk nodig denkt te hebben om een meetopstelling te loggen.

.

.... aangezien het zonder besturing al zo traag is

Ik begrijp om eerlijk te zijn je steeds terugkerende aversie tegen "traag" niet zo goed....

Al eerder kwam ter sprake dat loggen over het algemeen geen hoge meetsnelheid behoefd. En nauwkeurigheid en snelheid zijn hier elkaars tegenovergestelden.
Bedenk dat een NPLC van 100 minimaal 2 seconden meettijd oplevert. Dus sneller dan dat loggen gaat hem dan sowieso niet worden.

De snelheid van mode omschakelen, en ranging is al helemaal niet relevant. Dat doe je alleen eenmalig om je meters in te stellen voor je de meting start.

(En loggen met meters in auto-ranging is sowieso een no-go. Dan kun je wachten op gemiste metingen terwijl een meter gaat rangen terwijl hij moet meten. Of eerst een Overload uitspuugt voor hij gaat rangen.)

.

Blijft over dat het wellicht iets lastiger om een goede definitie te schrijven, die rekening houdt met de tijd die de meter nodig heeft.

Voor SCPI heeft TC een mooie oplossing met het [*OPC] commando.
Het mooie is dat er gepauzeerd wordt tot de meter aangeeft dat hij klaar is. En de wachttijd dus nooit langer is dan strikt noodzakelijk.

Voor de Ascii driver is er het generale #cmdDelayTime commando, dat aan elk commando een aantal milliseconde wachttijd toevoegt.

Voor lokaal gebruik kun je natuurlijk altijd nog [100] toepassen. (in dit geval 100ms pauze)

Verwar deze commando's voor een delay niet met #readingDelay en #modeChangeDelay! Deze commando's geven aan hoe lang Testcontroller mag blijven wachten op respectievelijk een uitlezing of een Mode wissel (voor een time-out). Ze voegen dus geen delay in...

groet, Gertjan.

#modeChangeDelay is alleen voor de SCPI driver, en erg polulair is deze niet aangezien maar 2 apparaten deze driver gebruiken in de hele TestController suite, dat is minder dan 1% !

#cmdDelayTime is alleen voor de ASCII driver en kon ik voor de DP100 niet gebruiken.

#readingDelay staat, als je het niet gebruikt, op 1s

[*OPC] werkt niet op mijn Analogic DP100.

Fijn dat jou apparaten snel reageren, dan kan je met 100ms uit te voeten. Bij mijn Yokogawa 7552 geen enkel probleem met trage responses.

De DP100 is zelfs met de knoppen niet bijster snel. De genoemde HM8112 is nog veel erger.

Ha flash2b,

Wat je schrijft weerspiegelt mooi wat ik in mijn vorige post schreef ;-).

Uit de TestController documentatie over [*OPC]:

This function uses the *OPC SCPI command followed by some *ESR? commands, when logging only the actual delay will be shown.

Je meter moet dus wel het SCPI *ESR? commando ondersteunen, om aan te kunnen geven dat hij weer klaar is.

groet, Gertjan

Vandaag lekker (tussen de bedrijven door) progressie gemaakt met de Yokogawa 7552 definitie:

Fijn dat de meter zo lekker snel reageert op alle commando's, jammer dat het max 9600 bps is.

Wat ervaringen delen:

Het schrijven van nieuw scpiCmd voor de ASCII driver is bijna geen extra werk vergeleken met de SCPIx driver (en ik weet dat je daar ook extra commando's kan bijmaken). Doordat ik het zelf in de hand heb, sluiten de het SCPI xxxx? (get) en xxxx (set) naadloos op elkaar aan (dat was bij de DP100 niet altijd het geval). Verder is het voor de Yokogawa 7552 heel veel hetzelfde, dus ik denk dat de meter het OS commando wel kan dromen. :)

Ha flash2b,

Dat ziet er al een heel stuk volwassener uit!

groet, Gertjan.

Mijn Yokogawa 7552 heeft zeer veel instellingen, en dan ben ik pas bijna halverwege. Maar de meest gebruikte zijn nu wel geïmplementeerd !

Even Setup menu openen kost wat tijd, maar dan heb je ook wel wat:

Laatste versie van Yokogawa 7552 definitie staat op EEVBlog: https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-…

Ha flash2b,

Ziet er goed uit!

Wat mij betreft hoort het tot de taak van de ontwerper om te beoordelen wat een zinvolle toevoeging is of niet.

Zo heb ik bij m'n HP 3458A definitie bewust functies weggelaten, omdat ik verwachtte dat gebruikers daarmee in de problemen kwamen. (En dus zeer ervaren gebruikers ze toch niet gebruiken).

Nadeel van veel functionaliteit is helaas dat je veel tijd kwijt bent aan testen...

groet! Gertjan.

Final versies van beide staan op EEVBlog: https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-…

https://www.eevblog.com/forum/index.php?action=dlattach;topic=234726.0;attach=2638047;image

Ik wil de Math functies van de Yokogawa nog wel toevoegen, maar ik heb even genoeg TC ervaring opgedaan. :)

Ha flash2b,

Dat zijn een paar mooie definities die je hebt gemaakt!
Vooral de Yokogawa definitie is denk ik één van de meest uitgebreide en complete definities die er voor TestController zijn geschreven.

Het zijn definities waar je niet alleen zelf plezier van zult hebben, maar ook anderen met deze meters, nu en in de toekomst :-).

groet! Gertjan.

TestController definitie voor de Wrytech PDVS 2 mini v2

M'n PDVS 2 mini kwam al voorbij in het Je mooiste meetapparatuur topic, dus zie daar voor meer PVDS2mini info.

https://www.miedema.dyndns.org/co/2025/pdvs2mini/IMG_4448__Wrytech_PDVS_2_mini_V2_with_IUSL-600pix.jpg

Met deze driver kan TestController de uitgangsspanning instellen. Onder andere kun je dan met de "Param Sweeper" pop-up spanningsweeps maken. Verder kunnen de setting voor de uitgangsspanning, de interne temperatuur, en de batterijspanning uitgelezen en gelogd worden:

https://www.miedema.dyndns.org/co/2025/pdvs2mini/TC-screenshot-PDVS2mini-v10-600pix.png

Ook wordt in het Status Menu nog wat status info weergegeven over output, accu en laden. Vooral omdat het kan :-). Ik zag geen nut om dat ook te kunnen loggen.
In de driver zitten nog wat extra commando's verstopt, zoals het uitlezen van het serienummer, en een antwoord op *idn?.

Helaas is het wel zo dat deze driver alleen geschikt is voor de PDVS 2 mini v2. Wrytech heeft veranderingen aangebracht aan het communicatieprotocol, waardoor het met oudere (pre v2) PCVS2mini's niet werkt. Gelukkig is het niet te ingewikkeld om de driver aan te passen naar de oude commando's.

De definitie voor de Wrytech PDVS 2 mini v2 vindt je hier : WrytechPDVS2miniV2.zip

groet, Gertjan.

TestController definitie voor Hameg HM8112-1 System Multimeter

Vandaag heb ik, tussen de bedrijven door, een definitie geschreven voor de Hameg HM8112 versie 1. Er is ook nog een -2 en -3 versie van deze meter gemaakt waarbij de -2 nog wel lijkt op de -1 maar de -3 een hele andere meter is.

Het schijnt dat 'onder de motorkap' deze -1 en -2 meters veel gemeen hebben met multimeters van het merk Prema.

Gelukkig is de meter afhandeling van remote commands niet langzaam, maar het was wat puzzelen om een stabiele verbinding te krijgen met TC via een AR488. Puzzel opgelost en nu kan ik dus lekker loggen.

Omdat de meter heel weinig functies ondersteund was het schrijven van de Menu's niet veel werk. Ik heb de methodiek van mijn Yokogawa definitie gebruikt die geoptimaliseerd is voor snelheid, dus de bediening van deze Hameg is ook lekker snel.

Op het log plaatje is trouwens mijn 10V referentie drift te zien + van de HM8112 (integratie tijd 1s).

Zodra de definitie helemaal naar wens is, dan zet ik hem op EEVBlog met een link hier op CO.

Ha flash2b,

Je hebt de vaart er in! :-)

En inderdaad: als je eenmaal een paar DMM definities geschreven hebt, dan gaat het snel.
Je moet uitzoeken hoe de basis communicatie voor de nieuwe meter is. En als dat eenmaal werkt, dan is de rest overwegend hergebruik van menu items uit vorige DMM definities.

Een nit-pick: "Active mode: VD"?

Mooi dat deze Hameg system DMM nu ook in TestController gebruikt kan worden!

groet! Gertjan.

VD is Hameg code taal :)

VD=VDC, VA=VAC, O2=Ohm2W, ID=ADC en IA=AAC, kan er wel een lookup in maken hoor....

Nu ik de documentatie van de Hameg HM8112-2 ook gelezen heb, kan ik mij definitie ook geschikt maken voor die meter. De -2 heeft wel een ID? (*IDN? look-a-like) commando.

[Bericht gewijzigd door flash2b op (44%)]

Het lijken me niet hele duidelijke afkortingen voor gebruikers.

De oplossing uit de 34401A definitie is eigenlijk perfect:


#cmdSetup info Active_Mode
:read: FUNC?
:readmath: getElement("Volt DCV;Volt AC;Ohm 2W;Amp DC;Amp AC Current",listIndex(unQuote(value),"VD VA O2 ID IA"," "),";")
:updatemodechange:

Je leest de mode uit, en de modestring wordt vervangen door wat je maar wil.
Ik gebruik hem eigenlijk in elk DMM menu.

Groet, Gertjan.

Dank Gertjan, het zit er (iets aangepast) in.

Ik kwam erachter dat de Prema 5000 exact dezelfde instructies als de HM8112-1 heeft: manual, kan dus support voor deze meter zo inbouwen !

Ik had inderdaad van rbeckers begrepen dat Hameg voor de ontwikkeling van de HM8112 (hun DMM vlaggeschip) knowhow bij Prema had ingekocht. En dat de eerste versie sterk verwant was aan een Prema DMM.

Het kan dus inderdaad zin hebben om Prema manuals door te spitten om uitgebreidere info te vinden over de remote control.

Leuk zo'n meter met een 10s integratie interval. Ik heb hem maar even 1000 samples laten meten aan een 100K precisie weerstand. Je kunt duidelijk zien wanneer ik in de buurt van de meter zat te werken.

Log interval van TC op 10s, HM8112-1 op 10s en timeout van de definitie op 12s, geen enkele timeout in het TC log of Java errors. Test geslaagd _/-\o_

Final versie voor deze Hameg (en Prema) op EEVBlog: https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-…

https://www.eevblog.com/forum/index.php?action=dlattach;topic=234726.0;attach=2641941;image

Op woensdag 20 augustus 2025 09:16:49 schreef flash2b:
Final versie voor deze Hameg (en Prema) op EEVBlog

Netjes! Weer een meter waarmee je kunt loggen. En weer een meter toegevoegd aan de steeds indrukwekkender lijst van door TestController ondersteunde meters.

Aan het aantal downloads van de definitie op EEVblog is te zien dat er meer mensen geïnteresseerd zijn in deze meter :-).

groet! Gertjan.

Het blijft natuurlijk niche "markt". Dat deze meters er nog veel zijn geloof ik nog wel, maar je moet ook nog iemand vinden die wil loggen én daarvoor TestController gebruikt. Dit allemaal waarschijnlijk in de hobby sfeer. Kans is dan heel klein. Bij een Fluke, HP of Keithley model ligt de kans een stukje hoger.

Mijn drie definities ondersteunen nu 5 + 2 + 4 = 11 modellen. Maar het blijven wel buitenbeentjes. Als TC kanji schrift zou ondersteunen, dan zou ik met een Japanse versie misschien nog wat meer gebruikers kunnen aanboren voor de Yokogawa. Maar dan zal ik het ook wereldkundig moeten maken in een Japanse blog ofzo.

Je zou verbaasd zijn hoeveel Hameg liefhebbers er zijn..... Dat bleek weer toen ik de apparatuur van rbeckers verkocht.
Yokogawa is een prominente fabrikant. Dus daar zullen ook liefhebbers van zijn.

Ook b.v. de Keithley 199 en Fluke 8840A hebben een grote schare liefhebber. Recent heeft iemand voor die 8840A een nieuwe netwerkkaart ontworpen, met onboard loggen en Wi-Fi.

Natuurlijk zijn dat allemaal liefhebbers en hobbyisten. maar dat is ook grotendeels de doelgroep voor TestController. Voor professionele toepassingen zal er eerder dedicated software geschreven worden.

groet, Gertjan.

Ik heb de matrix voeding via een USB to RS232 converter aangesloten en alle instelling in de voeding geprobeerd voor zowel hex als ASCII. HEt enige wat ik altijd terug krijg als antwoord is 0X00.

En met instelling bedoel dan hef of ASCII mode. Maar mijn voeding heeft daar 0, 1, 2, 3 en 4 voor wat ik kan instellen en de handleding geeft er alleen 0, 1, 2 op.

Ik kan de baudrate ook instellen en die staat op 9600 en dat is ook het enige wat mij echt duidelijk is.

Voor de rest weet ik niet over wat voor soort poort het nu is. IS het RS232 of serial TTL. Stopbits, databits, parity dat weet ik allemaal niet.

Heb wel de voeding open gemaakt en daar zit een Sipex SP232 chip in, dat zou toch op RS232 moet duiden?

Ik heb geprobeerd met een tussen printje om via de scope de signalen te meten en het zendsignaal gaat goed, maar als ik dan de kabel naar de voeding er ook bij aansluit dan krijg ik het geïnverteerde signaal terug.
Maar dan krijg ik in mijn terminal programma geen antwoord meer terug. Dus via de scope gaat daar iets niet goed.

En zonder het tussen printje waarop de scope heb aangesloten antwoord de voeding weer wel.

Geel is mijn TX van de PC
Blauw is RX? Maar van wat?

Maar hoe kan je nu wel het signaal meten zonder dat het de verbinding aantast?
IS daar PC software voor die de signalen op de RS232 laat zien?

Volgens de handleding zou er PC software bestaan maar die kan ik op de website van Matrax technologie inc niet vinden.

IK ga het maar bij eleshop neer leggen kijken of die meer info kunnen krijgen.

In de manual staat dit:

Maar ik begrijp uit jouw verhaal dat het in het echt anders is. Als ik dit bekijk dan zou "1" ASCII protocol zijn.

Staat ook in de manual:
"0" is to close the communication function, "1" is the ASCII protocol, and "2" is the Hex protocol.

Je aansluiting is een echte RS232 anders zou er geen dsub connector gebruikt zijn. Zijn je RxD en TxD goed aangesloten vanuit je USB to RS232 converter, ik moet telkens een null-modem adapter gebruiken !

Staat je local echo in puTTY (af wat anders) aan? Dat is wel handig als je aan het typen bent.

Als je ? MODEL (andere manual geeft ?MODEL) typt dan zou je een iets terug moeten krijgen. Meestal moet je afsluiten met een <LF> en dus werkt de <enter> knop vaak niet. Ik meen dat het control-J is maar je kunt het ook in puTTY (of wat anders) instellen.

Als je als antwoord een string terug krijgt dan ben je op je weg. Je kunt deze string gebruiken om #verifyDevice te gaan schrijven in TC. Hieronder staat een stukje TC definitie code daarvoor.

; -----  Check instrument model  ------
#verifyDevice "de string die terugkrijgt" model?

; -----  Identify instrument  ------
#scpiCmd model? txrx? ?MODEL
:string:

Over je scope, volgens mij kan je Rigol een serial decode doen zodat je de bitstream kan de-coden.