Program that can log/control many multimeters and other devices.

[felixd]

I assume YES here is for one device only on Prologix adapter

I know somebody asked that before but that was weeks ago. Is it now possible to log from many devices using one Prologix GPIB USB adapter (clone) or is it still limited to one device per GPIB-USB adapter?

Yes.

Sampling is always set in my case to 0.1s. It happens only when I am switching (turning on and off) visible options on the chart. If I don't touch that it can easy work as long as needed.

BTW, I believe I have asked You years ago about GitHub Issue tracking project for Your software. Any mind change on that?

It's not the first time I have managed to recreate that problem.

When I am looging for a long time [48h+], always with some Math functions (I just haven't tried without them), when I amswitching random chart positions ON and OFF it sometimes starts to utilize 100% CPU and hangs.

At this step I can't do anything more with the application and data is lost.

That is a very hard problem to fix, I will look for it, but I am not very optimistic on finding it. Does changing the log rate change the time before the lockup happens?

You can avoid data loss by selecting "Direct to disk" in the log menu.

[flash2b]

I am writing a new definition for the Analogic DP100 (Similar model as R&S UDL45) Multimeter.

I like to use the SCPIx driver but the answer of the *IDN? is not according to the SCPI spec, so I want to modify it with the #modifyIDN command, but it am successful  :'(

This is the ID string returned with PuTTY after sending *IDN?<CR>

Code: [Select]

Analogic DP100 Ver. 1.6
=>

Here is some log:

Code: [Select]

Starting
;; jSerialComm version: 2.11.0
;; Start thread for: COM3 - Analogic DP100
;; COM3: Set params: 9600
;; COM3: Tx: <*IDN?.> 2A 49 44 4E 3F 0D
;; COM3: Rx: <Analogic DP100 Ver. 1.6> 41 6E 61 6C 6F 67 69 63 20 44 50 31 30 30 20 56 65 72 2E 20 31 2E 36
;; COM3: RxBin:
;; FT232R USB UART (COM3) Device "Analogic,DP100" do not match answer: "Analogic DP100 Ver. 1.6"
;; COM3: Close
;; Stopping thread for: COM3 - Analogic DP100
;; COM3: Close
My definition has

Code: [Select]

#idString Analogic,DP100
#name Analogic DP100
#handle ANADP100

#driver SCPIx
#eol \r
#removePromptChars 2

The #modifyIDN I use is:

Code: [Select]

#modifyIDN replace(IDN," DP100",",DP100") replace(IDN," Ver.", ",Serial," )
I want to go from "Analogic DP100 Ver. 1.6" to Analogic,DP100,Serial,1.6.

I could not find any other definition files that use #modifyIDN nor any examples other that this command can be used to change the IDN.

Hope I can use it, otherwise I am stuck with ASCII driver again.

If I change the idString to (without comma !)

Code: [Select]

#idString Analogic DP100
#name Analogic DP100
#handle ANADP100
i get

Code: [Select]

Starting
;; jSerialComm version: 2.11.0
;; Start thread for: COM3 - Analogic DP100
;; COM3: Set params: 9600
;; COM3: Tx: <*IDN?.> 2A 49 44 4E 3F 0D
;; COM3: Rx: <Analogic DP100 Ver. 1.6> 41 6E 61 6C 6F 67 69 63 20 44 50 31 30 30 20 56 65 72 2E 20 31 2E 36
;; COM3: RxBin:
;; Found Analogic DP100 on FT232R USB UART (COM3)
*idn?
;; ANADP100: Tx <*idn?>
;; COM3: Tx: <*idn?.> 2A 69 64 6E 3F 0D
;; COM3: Rx: <Analogic DP100 Ver. 1.6> 41 6E 61 6C 6F 67 69 63 20 44 50 31 30 30 20 56 65 72 2E 20 31 2E 36
;; COM3: RxBin:
;; ANADP100: Rx <Analogic DP100 Ver. 1.6>
;; Analogic DP100 Ver. 1.6
How does #modifyIDN work, I would really like an example how to modify the IDN string. so that Make,Model,Serial,Version are parsed.

[HKJ]

I want to go from "Analogic DP100 Ver. 1.6" to Analogic ,DP100,Serial,1.6.

Try
#modifyIDN replace(replace(value," ",","),"Ver.","Serial")

I.e. replace all spaces with comma and then replace the Ver. string with Serial

[flash2b]

It seems that the #modifyIDN replace(replace(value," ",","),"Ver.","Serial") is not executed.....

#idString Analogic DP100
#name Analogic DP100
#handle ANADP10

Code: [Select]

;; jSerialComm version: 2.11.0
;; Start thread for: COM3 - Analogic DP100
;; COM3: Set params: 9600
;; COM3: Tx: <*IDN?.> 2A 49 44 4E 3F 0D
;; COM3: Rx: <Analogic DP100 Ver. 1.6> 41 6E 61 6C 6F 67 69 63 20 44 50 31 30 30 20 56 65 72 2E 20 31 2E 36
;; COM3: RxBin:
;; COM3: Tx <RWLS>
;; COM3: Tx: <RWLS.> 52 57 4C 53 0D
;; COM3: RxBin: 3D 3E 0D 0A
;; Found Analogic DP100 on FT232R USB UART (COM3)

I use the #driver SCPIx. How do I tell TC to use it before just after it receives the response from the *IDN? automatically ? (I do not use #verifyDevice as in the ASCII)

(Or how do I get the output from the automatic *IDN? into value for the #modifyIDN ?)

[HKJ]

It seems that the #modifyIDN replace(replace(value," ",","),"Ver.","Serial") is not executed.....

This is a bit embarrassing, I have coded the function, I just never call it!

Try replacing the .jar file with this one:

http://lygte-info.dk/pic/Projects/TestController/TestController.jar

[flash2b]

HKJ you are my hero !!

Code: [Select]

;; jSerialComm version: 2.11.0
;; Start thread for: COM3 - Analogic DP100
;; COM3: Set params: 9600
;; COM3: Tx: <*IDN?.> 2A 49 44 4E 3F 0D
;; COM3: Rx: <Analogic DP100 Ver. 1.6> 41 6E 61 6C 6F 67 69 63 20 44 50 31 30 30 20 56 65 72 2E 20 31 2E 36
;; COM3: RxBin: 0A 3D 3E 0D 0A
;; COM3: Tx <RWLS>
;; COM3: Tx: <RWLS.> 52 57 4C 53 0D
;; COM3: RxBin: 3D 3E 0D 0A
;; Found Analogic DP100 on FT232R USB UART (COM3) sn: 3380
;; ANADP100: Tx <FUNC?>
;; COM3: Tx: <FUNC?.> 46 55 4E 43 3F 0D
;; COM3: Rx: <VDC> 56 44 43
;; COM3: RxBin:
;; ANADP100: Rx <VDC>
*idn?
;; ANADP100: Tx <*idn?>
;; COM3: Tx: <*IDN?.> 2A 49 44 4E 3F 0D
;; COM3: Rx: <Analogic DP100 Ver. 1.6> 41 6E 61 6C 6F 67 69 63 20 44 50 31 30 30 20 56 65 72 2E 20 31 2E 36
;; COM3: RxBin: 0A
;; ANADP100: Rx <Analogic,DP100,3380,1.6>
;; Analogic,DP100,3380,1.6

That was probably also the reason that no other definition uses the #modifyIDN command 

But now it's working, thank you !

[flash2b]

The Analogic DP100 uses PromptChars: =>

So I use #removePromptChars 2 in my definition to get rid of them. These prompt chars are send consistently, but the speed it sends then is not consistently.

So when switching modes the time the meter sends these prompt chars is not consistent. Sometimes very quickly, sometimes slowly depending on de mode change made going to VDC, ADC, FREQ, OHMS4 very quickly, but going to VAC, AAC, RTD and OHMS very slowly. If they are slowly, the next command FUNC? fails since the PromptChars are not removed.

I already added a [2500] delay in the #cmdMode but that is between commands, and does not influence the time TC waits for the prompt chars.

I also added a #readingDelay, but this also does not influence the time TC waits for the PromptChars.

I also added a #modeChangeDelay, but this also does not influence the time TC waits for the PromptChars.

TC assumes that the PromptChars are received quickly after a command is send, cleaning the prompt chars with a RxBin. However this time between is a fixed time.

Is it possible to set the time between sending the command and removing the PromptChars ?

[HKJ]

So I use #removePromptChars 2 in my definition to get rid of them. These prompt chars are send consistently, but the speed it sends then is not consistently.

So when switching modes the time the meter sends these prompt chars is not consistent. Sometimes very quickly, sometimes slowly depending on de mode change made going to VDC, ADC, FREQ, OHMS4 very quickly, but going to VAC, AAC, RTD and OHMS very slowly. If they are slowly, the next command FUNC? fails since the PromptChars are not removed.

The correct one to use is #readingDelay, the  #modeChangeDelay is only supported by SCPI driver.
This is supposed to work as timeout for the removal of prompt characters.

Note: Most read communications starts by flushing the input buffer, i.e. the prompt will only affect fast communication or when TC multitask the interface.

[flash2b]

Sad to hear  #modeChangeDelay is not supported on SCPIx.

I use #readingDelay 0.5, if I set it very high I cannot log quickly anymore since also #askValues is affected by this.

Even if I put it to 10, which is annoyingly slow, I still leads to the same problems with the PromptChars.

My workaround is to send the Mode command twice so like this: OHMS;[2500] OHMS;[2500] and now #readingDelay 0.2 also works.

I see the = or > or => sometimes in inside the response of a VAL? or FUNC? command.

[HKJ]

I use #readingDelay 0.5, if I set it very high I cannot log quickly anymore since also #askValues is affected by this.

Even if I put it to 10, which is annoyingly slow, I still leads to the same problems with the PromptChars.

If a high value affect anything, your definition has a issue. There is not supposed to be any timeouts during normal communication and it only affect how long before the communication timeouts.

I will have to check out if I get the timeout sat correctly for the removal of the prompt.

[flash2b]

More log, this is before the IDN has acknowledged that the Analogic DP100 is found
;; COM3: Tx <RWLS>
;; COM3: Tx: <RWLS.> 52 57 4C 53 0D
;; COM3: RxBin: 3D 3E 0D 0A
;; COM3: Tx <FORMAT 0>
;; COM3: Tx: <FORMAT 0.> 46 4F 52 4D 41 54 20 30 0D
;; COM3: RxBin: 21 3E 0D 0A

Should those BOLD line not be sent from ANADP100 and not COM3 ?

If I type from the TC command line I get this:
RWLS
;; ANADP100: Tx <RWLS>
;; COM3: Tx: <RWLS.> 52 57 4C 53 0D
;; COM3: RxBin: 3D 3E 0D 0A
FORMAT 0
;; ANADP100: Tx <FORMAT 0>
;; COM3: Tx: <FORMAT 0.> 46 4F 52 4D 41 54 20 30 0D
;; COM3: RxBin: 21 3E 0D 0A



Here is some log with the issue:

Here you see my problem:
;; ANADP100: Tx <VDC>
;; COM3: Tx: <VDC.> 56 44 43 0D
;; COM3: RxBin:
;; ANADP100: Delay: 2000ms
;; ANADP100: Tx <VDC>
;; COM3: Tx: <VDC.> 56 44 43 0D
;; COM3: RxBin: 3D 3E 0D 0A
;; ANADP100: Delay: 2000ms
;; ANADP100: Tx <FUNC?>
;; COM3: Tx: <FUNC?.> 46 55 4E 43 3F 0D
;; COM3: Rx: <=>> 3D 3E
;; COM3: RxBin: 56 44 43
;; ANADP100: Rx <=>>
Unknown mode: =>
Known modes: , Amp_DC, Volt_AC, Amp_AC, Ohm_2W, Ohm_4W, Temp, Freq,
;; ANADP100: Tx <Volt DC>
;; COM3: Tx: <Volt DC.> 56 6F 6C 74 20 44 43 0D
;; COM3: RxBin: 3F 3E 0D 0A
;; ANADP100: Tx <VDC>
;; COM3: Tx: <VDC.> 56 44 43 0D
;; COM3: RxBin:
;; ANADP100: Delay: 2000ms
;; ANADP100: Tx <VDC>
;; COM3: Tx: <VDC.> 56 44 43 0D
;; COM3: RxBin:
;; ANADP100: Delay: 2000ms
;; ANADP100: Tx <FUNC?>
;; COM3: Tx: <FUNC?.> 46 55 4E 43 3F 0D
;; COM3: Rx: <=>> 3D 3E
;; COM3: RxBin: 0A 3D 3E 0D 0A
;; ANADP100: Rx <=>>
Unknown mode: =>
Known modes: , Amp_DC, Volt_AC, Amp_AC, Ohm_2W, Ohm_4W, Temp, Freq,

Clearly the PromptChars have not been properly removed !

If I type FUNC? again from command line within TC, I get the normal response VDC.

[flash2b]

Hi HKJ and others,

I have made a full feature definition file for the Analogic DP100 and Rohde & Schwarz UDL45 Multimeter.



All Function and Query commands available for this meter have been implemented. The meter itself supports SCPI but not fully standard and executes Function commands very slowly. But that its expected for a meter that is 30 years old. In the VDC mode there is an extra digit available so 6.5 digits while the meter is just a 5.5 digit DMM. I hope others will test this definition if you do, please report problems and suggestions (other than due to the slowness of the meter) to me.

Here you can see the Mode and Setup menu:


The definition file is attached below. Just copy it into the $documents\TestController\Devices folder.

Please note that to function properly use V2.62 of TestController (see some posts above for the JAR file) as the #modifyIDN command does not work properly in last release V2.61 of TestController.

I will update with the feedback to a 1.00 version, that can be included in the next release of the TestController suite.

I will release a 1.00 version, and HKJ can then add this to the release.

Definition file here: https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/msg6010581/#msg6010581

[marco58]

FY6900-60M - FeelElec AWG - Firmware v1.8
Issues (FeelElec changes something):
- Frequency value entered is multiplied (10^6)
- Waveform names in TestController are not correct / out of sequence

I recently purchased a FeelElec FY6900-60M V1.8.0 - HW revisions: Power supply board (5V only) V1.4 - FPGA board V3.31 - MCU board V2.4

TC identifies correctly my device:

*idn?
;; FeelElec,FeelElec FY6900-60M, 1563840597, V1.8

There are some issues relative to set frequency unit (read is ok) and waveform table.
This is due to changed base unit for frequency and new waveforms added/modified by Feelelec.
4-Pulse and 8-Pulse now are the last before ARB series.

I don't know in which FW version these modifications were introduced, but someone else made 2 different drivers for his python SW, for older and newer FY6900 (https://github.com/hb020/sds1004x_bode) with these annotations:
- Feeltech FYxxxx A range of Chinese generators. This driver is a newer driver that has some improvements over the older FY6600 driver, and supports FY2300, FY6600, FY6800, the older FY6900 and probably more.
- Feeltech FY6900 A Chinese generator. This driver has some improvements that are needed for the later FY6900 versions, that require the frequency to be sent as Hz instead of uHz. For the rest it is the same driver as the generic FY driver.

I modified FeelElecFY6x00-xxM.txt to try resolving for my FY6900 version.

I don't know how this file is used with other versions, so I do my modifications to test them, but I leave to others, if desired, the solution to resolving for newer FY6900 without breaking previous versions...

I resolved (I hope) set frequency unit, lines 191 and 211 in my version use

(formatDouble(value,0,8,0,6))

instead of

(formatDouble(value*1000000,0,14,0,0))

I've tried to resolve waveform table misalignment, but I don't understand why and how are used the 4 tables present in the file... I understand 2 tables: they are necessary because CH2 doesn't have Adj-Pulse.
Anyway I found something weird (temporary modifying each fist table line as "sine-### 0" where ### is the number of line code I find which table is actually used for CH1 and CH2): 

CH1 use table starting at line 439 (442 of my modified file), after

334 #cmdSetup comboboxHot Waveform Output_1
(...)
339 #metaSection WAVE1
(...)
438 #metaSection WAVE2

CH2 use table starting at line 700 (709 of my modified file), after

595  #cmdSetup comboboxHot Waveform Output_2
(...)
600 #metaSection WAVE1
(...)
699 #metaSection WAVE2

so I think only

#cmdSetup comboboxHot Waveform Output_X 

is valid and

#metaSection WAVE1 (or WAVE2)

for some reason are not valid / not recognized and always the 2nd one table is used (perhaps overrides the 1st one...).
So I modified the 2nd tables and now waveforms seems ok.
But I don't know if

#metaSection WAVE1

sections are really useless and so I leave that in place.

I also made some minor improvements: renamed the 2 different Trapezoid (using same name is FeelElec fault and is also on the instrument panel!) to distinguish which is which (the first has rise/fall time adjustable, the second has fixed slope).

FeelElecFY6x00-xxM_myMOD.txt is attached.

Ciao
marco

[flash2b]

How do I substring the second line? Should I just count up?

TC add a NewLine between each line, you can use the getElement() function to fetch the decided line.
A NewLine is written as \n in a string.

In my case the /n is nowhere to be found in the string that TC returns after reading all lines from the txtrx n command. Since there is no separator, I cannot getElement()

[Gertjan]

In my case the /n is nowhere to be found in the string that TC returns after reading all lines from the txtrx n command. Since there is no separator, I cannot getElement()

Hi flash2b,

It just works
At the moment I am working on a definition for a device that sends a 4 line answer:

Code: [Select]

<Status>
Output Voltage: 10.00000 V
Output Status:  OK: 0.00 V
Power Status:   DC: 19.0 V
Int. Temp:      31.7 °C

To get the voltage from the first line, i use this code:

Code: [Select]

#scpiCmd readVolt? txrxn? 4 <Status>
:readmath: getElement(value,0,"[\n]");
:readmath: getElement(value,1,"[:]")

And to get the Temperature from the fourth line:

Code: [Select]

#scpiCmd readTemp? txrxn? 4 <Status>
:readmath: getElement(value,3,"[\n]");
:readmath: getElement(value,1,"[:]")

Regards, Gertjan.

[flash2b]

Yes, the \n can be used, but since my lines are not so nicely formatted as yours, getElement does not work for me

Code: [Select]

;; YOKO7552: Tx <askMode?>
;; YOKO7552: Tx <txrxn? 10 OS
:string:
:readmath: getElement(value,1,"[\n]")
:readmath: getElement(value,1,"F")>
;; COM3: Tx: <OS.> 4F 53 0A
;; COM3: Rx: <MDL7552> 4D 44 4C 37 35 35 32
;; COM3: Rx: <F1R0> 46 31 52 30
;; COM3: Rx: <M0IT4SI220TD0> 4D 30 49 54 34 53 49 32 32 30 54 44 30
;; COM3: Rx: <NL0AZ1> 4E 4C 30 41 5A 31
;; COM3: Rx: <NS500RD0> 4E 53 35 30 30 52 44 30
;; COM3: Rx: <SM0AT100> 53 4D 30 41 54 31 30 30
;; COM3: Rx: <CO0CF1> 43 4F 30 43 46 31
;; COM3: Rx: <KA+0.00000E+0KB+1.00000E+0> 4B 41 2B 30 2E 30 30 30 30 30 45 2B 30 4B 42 2B 31 2E 30 30 30 30 30 45 2B 30
;; COM3: Rx: <KC+0.20000E+2KD+1.00000E+0> 4B 43 2B 30 2E 32 30 30 30 30 45 2B 32 4B 44 2B 31 2E 30 30 30 30 30 45 2B 30
;; COM3: Rx: <HI+0.00000E+0LO+0.00000E+0> 48 49 2B 30 2E 30 30 30 30 30 45 2B 30 4C 4F 2B 30 2E 30 30 30 30 30 45 2B 30
;; YOKO7552: Rx <1R0>
Unknown mode: 1R0
Known modes: Volt_DC, Amp_DC, , , Volt_AC, Amp_AC, Freq_AC_V, Freq_AC_A, Ohm_2W, Ohm_4W,

I use :readmath: substring(value,9,10) for now, but I wanted to go position independent as I need to query the OS command a lot of time for each feature the meter offers (and that are many !).

I is a breeze to work on the Yokogawa 7552 again, processing is very quick like a cheetah compared to the Analogic DP100 was a snail.

[Gertjan]

Let TC add an EOL character to each line, and split on that?

[flash2b]

Yes, that works !

Code: [Select]

; ----- Query instrument function -----
#scpiCmd askMode? txrxn? 10 OS
:string:
:readmath: getElement(value,1,"[\n]")
:readmath: substring(value,1,2)
Is a whole bit better than counting from the start.

Even better

Code: [Select]

; ----- Query instrument function -----
#scpiCmd askMode? txrxn? 10 OS
:string:
:readmath: getElement(value,1,"[\n]")
:readmath: getElement(value,1,"F")
:readmath: substring(value,0,1)
Better and cleaner and I can use the letter (like F, R, AZ) as the pointer to the value.

[HKJ]

FY6900-60M - FeelElec AWG - Firmware v1.8

I have added the definition to TC and added a "a" to all the names to makes it possible for them to coexist with the old definitions.

[HKJ]

Hi HKJ and others,

I have made a full feature definition file for the Analogic DP100 and Rohde & Schwwarz UDL45 Multimeter.


...

I will update with the feedback to a 1.00 version, that can be included in the next release of the TestController suite.

I will release a 1.00 version, and HKJ can then add this to the release.

I have added this definition to TC and will update it when you post a updated definition.

[HKJ]

Better and cleaner and I can use the letter (like F, R, AZ) as the pointer to the value.

TC don contain more advanced functions to extract text, but they are harder to use if you do not know regular expressions:
https://lygte-info.dk/project/TestControllerFunctions%20UK.html#getMatch_&_getMatchGroup

[HKJ]

In my case the /n is nowhere to be found in the string that TC returns after reading all lines from the txtrx n command. Since there is no separator, I cannot getElement()

The code to read lines with looks this way:

      while (line > 0) {
         String s = read();
         if (s != null) sb.append(s);
         sb.append('\n');
         line--;
      }

I.e. I am pretty sure the \n are present

[flash2b]

Hi HKJ and others,

I have made a Release Candidate definition file for the Yokogawa 7551/7552/7561/7562 Digital Multimeter



The Yokogawa 7552 cost 160,000 JPY in December 1988 when it was released, which is €945 (that is €2203 today in 2025). I think my unit is from 1991, so 34 years old. It is still completely in spec and can now be read by modern means, using this definition. Furthermore, it is a very nice meter in terms of appearance, documentation and features and it also reacts very quickly.

Most Function and Query commands available for this meter have been implemented. There are some that still need implementation, described in the definition file. The meter itself does not support SCPI but the documentation of Yokogawa is wonderful clear, it is a star performer running and executing remote commands, but there are so many available taking the Setup menu some time to load. And also the RS232 it is only 9600 bps communication speed. I hope others will test this definition if you do, please report problems and suggestions to me.

Here you can see the Mode and Setup menu:


The definition file is attached below. Just copy it into the $documents\TestController\Devices folder.

I will update with the feedback to a 1.00 version, that can be included in the next release of the TestController suite. I will also add support for the Yokogawa 7563 Digital Thermometer without supporting the thermo-couple functions so it will function like a 7561,

I will release a 1.00 version, and HKJ can then add this to the release.

Definition file here: https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/msg6010581/#msg6010581

[Gertjan]

Hi flash2b,

I prefer to use as much as possible to use the same nomenclature in the menus as on the meter.
So when deciding what text/name to put in a menu, I look on the meter and/or in the manual what name the manufacturer was using for that function.

This helps to make functions clearer for the user. They expect to set the meter in TC, as they are used to setting it on the front panel.

So, for example in your "Null Setting" menu, I would change "Calibrate" for "Null Set".

Regards, Gertjan.

[flash2b]

Thanx for the feedback !

I will change to Null Set and Zero Set.

On the meter INTEG TIME and INTVL are printed, I use Integration Time and Sampling Interval instead because it is more clear (and also called like this in the manual).

I did however use N RDGS and not Number of Readings, since there is a LED on meter with the short name like Auto, Single, N RDGS.

I do not know why TestController put additional font spacing between de RDG and the S or it might be due to the font on Windows.

I do not like Volts, Ohms, Amps and prefer Volt, Ohm, Amp because it is also not Hzs. It is less American that way.

The meter uses DC V but I prefer the Volt DC, in the mode selector like the Keithley, Fluke and Analogic.

I ordered the Mode selector horizontally Volt, Amp and vertically DC, AC just like the Analogic. In your Fluke 8845A menu ordering is more like the order on the meter I believe but. I like my way better, but this is more a personal preference.

Those were my considerations.