Author Topic: Program that can log from many multimeters.  (Read 489609 times)

0 Members and 5 Guests are viewing this topic.

Offline MrPete

  • Contributor
  • Posts: 20
  • Country: us
Re: Program that can log from many multimeters.
« Reply #3300 on: January 03, 2024, 03:11:31 am »
Noob here, but not to the topic in general... ;)

I'm starting out on TestController the hard (?) way: by defining a new device (Fluke 8808A).

I'm not sure if the following is normal or unusual... but in any case it doesn't seem to be documented that I see... nor have I seen it discussed.

Measurements returned by this device may be either of these formats:

Tx <meas?>
; F8808: Rx <+28.399E-3 VDC>
;; F8808: Rx as numbers <0.028399 NaN>

or (if doing two simultaneous measures)

 Tx <meas?>
;; F8808: Rx <+1.192E-3 VDC,-0.001E-6 ADC>
;; F8808: Rx as numbers <0.001192 NaN -1.0E-9 NaN>

(I *may* be able to disable the unit info, although that seems valuable for auto-changing the measurement mode???)

QUESTIONS

1) Units

Clearly this DMM provides measurements using engineering units (ie powers of ten scaled by multiples of 3)

This is not documented in the #value setup. What am I supposed to use for #value here?


2) Measurement type

Are there examples of reading from DMM's that supply the type of measurement?

3) Single / Double measures

I see two types of double-measure documented lightly:

DMM and DMM:2 (for in essence two whole meters)

vs a more complex setup supporting primary/secondary measures (haven't figured that out yet.)

Any recommendations on which path to take?

THANK YOU SOOO MUCH! This is an incredible tool :)

Pete
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 2904
  • Country: dk
    • Tests
Re: Program that can log from many multimeters.
« Reply #3301 on: January 03, 2024, 09:40:02 am »
Updated my Powersupply test.

I have added the update to my webpage: https://lygte-info.dk/project/TestControllerUserScripts1%20UK.html#Power_supply_load_sweep_by_Pukker

Once I bought an ADC10F103C and didn't nothing with it.
3.3 volt max. input makes it not always useful for me.
I liked to have an universal voltage logger,
so I made an resistor interface and so it is an usefull voltage logger to max. 60v.

This is also added to my webpage: https://lygte-info.dk/project/TestControllerUserProjects1%20UK.html#10_channel_12bit_ADC_module_addition_by_Pukker

It is a nice way to make the module more practical, now it just need a 3D printed box (This would required a USB extension cable).
 
The following users thanked this post: Pukker

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 2904
  • Country: dk
    • Tests
Re: Program that can log from many multimeters.
« Reply #3302 on: January 03, 2024, 10:00:09 am »
I'm starting out on TestController the hard (?) way: by defining a new device (Fluke 8808A).

I'm not sure if the following is normal or unusual... but in any case it doesn't seem to be documented that I see... nor have I seen it discussed.

Measurements returned by this device may be either of these formats:

Tx <meas?>
; F8808: Rx <+28.399E-3 VDC>
;; F8808: Rx as numbers <0.028399 NaN>

or (if doing two simultaneous measures)

 Tx <meas?>
;; F8808: Rx <+1.192E-3 VDC,-0.001E-6 ADC>
;; F8808: Rx as numbers <0.001192 NaN -1.0E-9 NaN>

(I *may* be able to disable the unit info, although that seems valuable for auto-changing the measurement mode???)

You do generally not need the unit information, because you can usually poll it with another SCPI command. In TC you can use a expression to remove the unit, before parsing the numbers.
You use the #readformat and #readmath to adjust the input line: https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#mathFormat_&_readmath

1) Units

Clearly this DMM provides measurements using engineering units (ie powers of ten scaled by multiples of 3)

This is not documented in the #value setup. What am I supposed to use for #value here?


TC will as default handle this kind of format and use SI prefix when displaying the values.

2) Measurement type

Are there examples of reading from DMM's that supply the type of measurement?

I do not remember, but probably, you can handle it as I wrote above.

3) Single / Double measures

I see two types of double-measure documented lightly:

DMM and DMM:2 (for in essence two whole meters)

vs a more complex setup supporting primary/secondary measures (haven't figured that out yet.)

Any recommendations on which path to take?

You need to use modes for handle 1/2 values and it is handled with the #value lines.
If two #value lines are enabled, TC will expect two answering values.
I.e. you need to get the #askmode statement working: https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html##askMode

There a many bench meter definitions you can look in for examples, maybe a "Fluke8845A.txt" is a good start.

Also note bench meters are usually listed as both DMM and BMM, the BMM is a meter that can be computer controlled.
 
The following users thanked this post: MrPete

Offline Pukker

  • Regular Contributor
  • *
  • Posts: 148
  • Country: nl
Re: Program that can log from many multimeters.
« Reply #3303 on: January 03, 2024, 10:01:38 am »

I have added the update to my webpage: https://lygte-info.dk/project/TestControllerUserScripts1%20UK.html#Power_supply_load_sweep_by_Pukker

This is also added to my webpage: https://lygte-info.dk/project/TestControllerUserProjects1%20UK.html#10_channel_12bit_ADC_module_addition_by_Pukker

It is a nice way to make the module more practical, now it just need a 3D printed box (This would required a USB extension cable).

Nice, but the 3D printer is missing here.
but will take an box, drilling, sawing etc.
« Last Edit: January 03, 2024, 10:04:08 am by Pukker »
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 2904
  • Country: dk
    • Tests
Re: Program that can log from many multimeters.
« Reply #3304 on: January 03, 2024, 10:27:59 am »
It is a nice way to make the module more practical, now it just need a 3D printed box (This would required a USB extension cable).

Nice, but the 3D printer is missing here.
but will take an box, drilling, sawing etc.

I can recommend getting a 3D printer, it makes it much easier to get high quality boxes for your projects. Square holes are easy and precise, making special feature to mount a display on (Using short self tappers) is also easy. Only issue is that a typical 3D printed plastic box is very limited with heat.

 
The following users thanked this post: Pukker

Offline MrPete

  • Contributor
  • Posts: 20
  • Country: us
Re: Program that can log from many multimeters.
« Reply #3305 on: January 03, 2024, 04:38:42 pm »
Noob question: is there a way to reliably reload the definition file for a device from within TC? "Reconnect" doesn't do that. :(

Sure would be handy while I am working up my device definition!
 

Offline MrPete

  • Contributor
  • Posts: 20
  • Country: us
Lessons learned on initial setup
« Reply #3306 on: January 03, 2024, 04:47:54 pm »
I thought I would contribute a few things I discovered in my first setup/use of TC. (I'm a professional SW/HW/FW guy, trained to notice niggly things ;) )

USB-Serial Driver for Win 10/11

I have a USB-Serial dongle, marked Eminent 1016 but actually is Prolific 2303 GC aka Prolific 2303HXA

Here's the latest best driver. Do NOT use the most recent from Prolific. https://github.com/johnstevenson/pl2303-legacy/releases

Without this driver (or 3.3.2.102 but that version has other issues), I got "Error 433" from any serial/terminal app, and TC didn't think the COM port existed at all.

If you're having serious issues, running a free trial of "Free Device Monitoring Studio" from HHD Software may be very helpful. It traces 100% of all signals on the serial port!

Correction for ID String Definition

The documentation says:
  • #idString first two parts of *idn? answer
  • The idstring is the brand name and the device name

The correct answer: The idstring must exactly match the first portion of the *idn? answer, including any blanks etc.

Example: if *idn? returns "BRAND, MODEL,..." then this line must be "#idString BRAND, MODEL," (and not "#idstring BRAND,MODEL,")

 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 2904
  • Country: dk
    • Tests
Re: Lessons learned on initial setup
« Reply #3307 on: January 03, 2024, 05:04:19 pm »
Noob question: is there a way to reliably reload the definition file for a device from within TC? "Reconnect" doesn't do that. :(

Sure would be handy while I am working up my device definition!

Thats not possible, but you can speed up startup by emptying the "Devices" directory (All files must be restored when you are finished or TC will not support any other device)

USB-Serial Driver for Win 10/11

I have a USB-Serial dongle, marked Eminent 1016 but actually is Prolific 2303 GC aka Prolific 2303HXA

Here's the latest best driver. Do NOT use the most recent from Prolific. https://github.com/johnstevenson/pl2303-legacy/releases

Without this driver (or 3.3.2.102 but that version has other issues), I got "Error 433" from any serial/terminal app, and TC didn't think the COM port existed at all.

If you're having serious issues, running a free trial of "Free Device Monitoring Studio" from HHD Software may be very helpful. It traces 100% of all signals on the serial port!

Good information.


Correction for ID String Definition

The documentation says:
  • #idString first two parts of *idn? answer
  • The idstring is the brand name and the device name

The correct answer: The idstring must exactly match the first portion of the *idn? answer, including any blanks etc.

Example: if *idn? returns "BRAND, MODEL,..." then this line must be "#idString BRAND, MODEL," (and not "#idstring BRAND,MODEL,")

I have modified the text a bit.
 
The following users thanked this post: MrPete

Offline romany

  • Newbie
  • Posts: 3
  • Country: us
Re: Program that can log from many multimeters.
« Reply #3308 on: January 09, 2024, 07:33:12 pm »
I have a ET5420 and I'm making progress getting it to talk with Test Controller (under linux) - it can pull the version number - but the model number is where it fails.  If I look under system info on the 5420 there are 4 entries:

PRODUCT MODEL
S/N
Software Version
Hardware Version

There is no entry under PRODUCT MODEL - and this is a read only section - no way to enter one.  When I run Test Controller it comes back with this:

Device ET5420 do not match: ÿÿÿÿÿÿÿ,V1.02.2127.002,09422132071,V1.03.2136.003

EDIT:   I edited the Device file for the 5420 and replaced the  idString name with ÿÿÿÿÿÿÿ.  Got by the "do not match" error anyway...


« Last Edit: January 09, 2024, 07:50:49 pm by romany »
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 2904
  • Country: dk
    • Tests
Re: Program that can log from many multimeters.
« Reply #3309 on: January 11, 2024, 11:49:46 am »
I have a ET5420 and I'm making progress getting it to talk with Test Controller (under linux) - it can pull the version number - but the model number is where it fails.  If I look under system info on the 5420 there are 4 entries:

PRODUCT MODEL
S/N
Software Version
Hardware Version

There is no entry under PRODUCT MODEL - and this is a read only section - no way to enter one.  When I run Test Controller it comes back with this:

Device ET5420 do not match: ÿÿÿÿÿÿÿ,V1.02.2127.002,09422132071,V1.03.2136.003

EDIT:   I edited the Device file for the 5420 and replaced the  idString name with ÿÿÿÿÿÿÿ.  Got by the "do not match" error anyway...

Obvious that device has a faulty firmware version or more likely the model is in EEPROM and that entry is damaged, luckily you found a work-around.

 

Offline MrPete

  • Contributor
  • Posts: 20
  • Country: us
Re: Program that can log from many multimeters.
« Reply #3310 on: January 14, 2024, 12:29:15 am »
@HKJ, I am making more progress, and have more questions:

Background: 8808A DMM/BMM can do two values but there are many interactions... can't always do two and it's complicated.

Questions

1) What causes the expected # of values to change, in #askValues, in the current values list, in the table, regular table, in the chart? It's not clear.
   (I see something about "mode based" but stil not clear)


2) Is there a way to modify the number of values returned by #askValues based on a condition?
     My example: if I request two but only have one value being measured, the meter returns "!>" as an error string as a result!)

   I'm thinking I need to generate some kind of return string with <1st value>,  then if value2 is NOT "!>" then append (separator?)  and <2nd value>

hints mucho appreciaated...

« Last Edit: January 14, 2024, 03:12:44 am by MrPete »
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 2904
  • Country: dk
    • Tests
Re: Program that can log from many multimeters.
« Reply #3311 on: January 14, 2024, 04:19:05 pm »
1) What causes the expected # of values to change, in #askValues, in the current values list, in the table, regular table, in the chart? It's not clear.
   (I see something about "mode based" but stil not clear)

The number of expected and shown values is directly controlled by the number of enabled columns (#value statement)
The #value statement can optionally have one or more mode names listed (DMM's always has this). This mode is read from the device (#askMode see https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html##askMode ) or can be set manually with some commands (#cmdModeCheck). It is possible to have multiple modes active simultaneous.
https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#Selecting_mode_(Mostly_for_multimeters)

2) Is there a way to modify the number of values returned by #askValues based on a condition?
     My example: if I request two but only have one value being measured, the meter returns "!>" as an error string as a result!)

   I'm thinking I need to generate some kind of return string with <1st value>,  then if value2 is NOT "!>" then append (separator?)  and <2nd value>

It is possible to adjust #askValues based on mode https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#Selecting_multiples_modes
« Last Edit: January 14, 2024, 04:22:19 pm by HKJ »
 

Offline MrPete

  • Contributor
  • Posts: 20
  • Country: us
Re: Program that can log from many multimeters.
« Reply #3312 on: January 14, 2024, 11:05:11 pm »
Thanks for that link-filled answer :)

Honestly, this is starting to feel like a Catch-22 ;)
I will work my way through your references...

For now....

A) NOTE: there are two device files making actual use of #cmdModeCheck: R&SHMC8012.txt (significant), and GossenMetraHitEnergy.txt (minor) all others have it commented out ;)

B) Here's my initial observation on what you wrote:

*The number of expected and shown values is directly controlled by the number of enabled columns (#value statement)

* The #value statement can optionally have one or more mode names listed (DMM's always has this).
* This mode is read from the device (#askMode ...).
* It is possible to have multiple modes active simultaneous.
...

* It is possible to adjust #askValues based on mode

I read this as saying (in real-world sequence):

1) I can read the current mode(s) from the DMM. Presumably detecting whether one or two are active now.
2) From that, I can control #value to read one or two values

What I did NOT hear is any way to directly tweak the number of values produced from data returned by the DMM.

(in other words, I'm thinking it would be nice to simply attempt to read two values. If the return string is "1.1E3, 5.7E-6" it's 2, if the string is "1.1E3,***" it is actually only one.)

I'll get back once I've absorbed those links. THANK YOU again!!
pete
« Last Edit: January 14, 2024, 11:41:44 pm by MrPete »
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 2904
  • Country: dk
    • Tests
Re: Program that can log from many multimeters.
« Reply #3313 on: January 15, 2024, 03:29:06 pm »
What I did NOT hear is any way to directly tweak the number of values produced from data returned by the DMM.

That is correct, for TestController it is a fairly major reconfiguration change every time the number of returned parameters changes. It has to reconfigure many of its pages and tables to fit the changed parameters, this reconfiguration is triggered every time you change the mode.

You can always check the active modes for a device by typing on the command line: =deviceMode("DMM6500")
The DMM6500 is the device handle (It must be a loaded device for this to work).

TestController has a programming language with lots of functions to handle special cases, you can read about it here: https://lygte-info.dk/project/TestControllerFunctions%20UK.html
And more generally here: https://lygte-info.dk/project/Calculator%20UK.html
 

Offline MrPete

  • Contributor
  • Posts: 20
  • Country: us
Re: Program that can log from many multimeters.
« Reply #3314 on: January 15, 2024, 04:42:07 pm »
@HKJ I am starting to understand the underlying architecture better. Whew.

Does this mean that if I want to incorporate some calculated values...

* That too is one of these major hiccups requiring reconfiguration?
* And, do I therefore need to invent a mode for that?

Looking at how cmdModeCheck is used, I am guessing the following is a semi-correct expanded interpretation / documentation. Am I close?

Current Docs

Quote
If the mode on/off commands contain [localmode] the state of the mode is handled by TestController and need not be included in the #askMode. With local mode it may not be necessary to send commands to the device, but only to add more columns and modify the #askValues command with the [mode:xxx] tag.
...
"Changing number of columns, device mode is not used (Note: m2 test is not used, but must be present)."
Code: [Select]
#cmdModeCheck modeLabel deviceModeString defaultState
mode on commands
mode off commands
modes where this mode is valid, use ! to invert mode. (This line is optional)
* In the example, "deviceModeString" is always "m2" and is present in #cmdMode and #cmdModeCheck
* EVERY example in the documentation, and in the device files, uses [localmode]

My Interpretation of the above
  • Each #cmdModeCheck defines an independent additional mode that can potentially be active simultaneously.
  • Best to always use [localmode] for multi-mode devices. We have no instructions or examples of non-local (ie where the device returns good multi-mode data on its own)
  • The third line ("modes where this is valid"...) defines how this mode interacts with all other modes, in the sense of a filter. (?? By default this mode is available with all other modes. If not, then some combination of positive inclusion and/or negative removal must be used. ?? )
  • For multi-mode value reading, #askValues and #askValuesNumberFormat is used to define and limit the number of values to be read. See below.

Here's an example from R&SHMC8012.txt:
Code: [Select]
#askValues FETC?[mode:Frequency_Voltage,Frequency_Current,DCV_Power,DCI_Power,dB,dBm];FETCH2?[mode:DCV_Power,DCI_Power];CALC:POW?[mode:Limit];STAT:QUES:COND?[mode:Statistics];CALC:AVER:COUN?;CALC:AVER:MAX?;CALC:AVER:AVER?;CALC:AVER:MIN?;CALC:AVER:SDEV?;CALC:AVER:PTP?

; Format of answer: f=float, u=remove trailing letters, x=skip, *=Zero upper case values if this value is 0
#askValuesReadFormat FFFFFFFFFF
  • Counting in #askValues, one sees up to ten values returned depending on the combination of active modes. Thus, #askValuesReadFormat specifies ten floating point numbers.
  • Sometimes a single mode produces more than one value (eg Statistics); sometimes a single mode is present in more than one list, which is another way to produce multiple values (eg DCV_Power).
  • In #askValues, the modes listed in a group [mode:Mode1,Mode2...] are "OR'd" together: the following associated values are expected if any of the listed modes are active.

One more question that's slightly related:

In defining #cmdMode, the docs say:
  • All defined modes are shown in a popup window, where they are sorted in alphabetically order.
  • It is also possible to add empty positions with #cmdMode (on a line by itself)

Normally, a sorted list puts all empty records at the start or end. QUESTION: By any chance, does adding #cmdMode as a blank, cause a separate alphabetical sort before and after the blank?

(BTW a nit: it should say "sorted in alphabetical order")

THANKS as always!
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 2904
  • Country: dk
    • Tests
Re: Program that can log from many multimeters.
« Reply #3315 on: January 15, 2024, 05:54:16 pm »
Does this mean that if I want to incorporate some calculated values...

* That too is one of these major hiccups requiring reconfiguration?
* And, do I therefore need to invent a mode for that?

Generally you do not do calculated values in the driver, you do them later on the "Math" page.
It is possible, but requires some extra definitions.

My Interpretation of the above
  • Each #cmdModeCheck defines an independent additional mode that can potentially be active simultaneously.
  • Best to always use [localmode] for multi-mode devices. We have no instructions or examples of non-local (ie where the device returns good multi-mode data on its own)
  • The third line ("modes where this is valid"...) defines how this mode interacts with all other modes, in the sense of a filter. (?? By default this mode is available with all other modes. If not, then some combination of positive inclusion and/or negative removal must be used. ?? )
  • For multi-mode value reading, #askValues and #askValuesNumberFormat is used to define and limit the number of values to be read. See below.

  • Correct
  • Depend on the device, if you can read the mode from the device it is a more reliable way to track the modes
  • Correct
  • #askValues reads the values, #askValuesReadFormat/#askValuesMathFormat is optionally use to filter/adjust the returned data




Here's an example from R&SHMC8012.txt:
Code: [Select]
#askValues FETC?[mode:Frequency_Voltage,Frequency_Current,DCV_Power,DCI_Power,dB,dBm];FETCH2?[mode:DCV_Power,DCI_Power];CALC:POW?[mode:Limit];STAT:QUES:COND?[mode:Statistics];CALC:AVER:COUN?;CALC:AVER:MAX?;CALC:AVER:AVER?;CALC:AVER:MIN?;CALC:AVER:SDEV?;CALC:AVER:PTP?

; Format of answer: f=float, u=remove trailing letters, x=skip, *=Zero upper case values if this value is 0
#askValuesReadFormat FFFFFFFFFF
  • Counting in #askValues, one sees up to ten values returned depending on the combination of active modes. Thus, #askValuesReadFormat specifies ten floating point numbers.
  • Sometimes a single mode produces more than one value (eg Statistics); sometimes a single mode is present in more than one list, which is another way to produce multiple values (eg DCV_Power).
  • In #askValues, the modes listed in a group [mode:Mode1,Mode2...] are "OR'd" together: the following associated values are expected if any of the listed modes are active.


  • #askValuesReadFormat may be specifying more numbers than the data contains, it will terminate when end of data is reached
  • When a mode is present more than once, it is because multiple command are used to fetch the data, I could also have made a entry for each mode and then listed all required commands after that
  • Yes


One more question that's slightly related:

In defining #cmdMode, the docs say:
  • All defined modes are shown in a popup window, where they are sorted in alphabetically order.
  • It is also possible to add empty positions with #cmdMode (on a line by itself)

Normally, a sorted list puts all empty records at the start or end. QUESTION: By any chance, does adding #cmdMode as a blank, cause a separate alphabetical sort before and after the blank?

The empty definitions are only valid when you take over the design by specifying a
#cmdModeLayout columns row
Then you are using the empty #cmdMode to get the best layout
 

Offline MrPete

  • Contributor
  • Posts: 20
  • Country: us
Re: Program that can log from many multimeters.
« Reply #3316 on: January 15, 2024, 08:49:37 pm »
@HKJ
Quote
The empty definitions are only valid when you take over the design by specifying a
#cmdModeLayout columns row
Then you are using the empty #cmdMode to get the best layout

Ahh! So #cmdModeLayout also turns off the auto-sort!

Quote
Depend on the device, if you can read the mode from the device it is a more reliable way to track the modes

I didn't find any example of using #cmdModeCheck to define a device-readable mode. Is there one I missed?
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 2904
  • Country: dk
    • Tests
Re: Program that can log from many multimeters.
« Reply #3317 on: January 15, 2024, 09:05:53 pm »
@HKJ
Quote
The empty definitions are only valid when you take over the design by specifying a
#cmdModeLayout columns row
Then you are using the empty #cmdMode to get the best layout

Ahh! So #cmdModeLayout also turns off the auto-sort!

Yes, both auto sizing of columns/rows and sorting is turned off.

Quote
Depend on the device, if you can read the mode from the device it is a more reliable way to track the modes

I didn't find any example of using #cmdModeCheck to define a device-readable mode. Is there one I missed?

Probably not, I do not remember any device where I have used it.
The #askMode will set multiple modes if it return multiple parameters, i.e. you can use it like:
#askMode cmdForMainMode;cmdForExtraMode
 

Offline MrPete

  • Contributor
  • Posts: 20
  • Country: us
Re: Program that can log from many multimeters.
« Reply #3318 on: January 17, 2024, 05:48:25 pm »
@HKJ Thank you so much for shedding light on various bits! I have another undefined/undocumented area that's presumably important...

The various BMM/DMM device files have a variety of #interface read... definitions (see below).

Documentation says:
Quote
#interface read... column
#interface read... column column...

The definition of read is very easy, because it uses the same reading as "current values" and logging, i.e. the "#askValues" command and only the actual index of the value must be specified. For multichannel devices multiple indexes must be listed, one for each channel. The first value the device returns is numbered 0.
The read definitions also defines a name... command that can be used to get the column name for the value from the actual device.

QUESTIONS:

1) Given that the parameter to these is a zero-based column number, is it a bug to have only "#interface readValue 1" ?

2) The document suggests using "readValue column column..." but nobody does that. Instead they have separate "readValue 0" "readValue2 1"... WHY?

3) What's the meaning of readValue, readValue2, readValue3...? Not documented.

4) In NO case do I see any of these used anywhere else in the device files, nor the auto-generated nameValue* that's described. Do these definitions set up something inside TC?

5) One device has "BMM" without "DMM". I have not yet found an explanation of what these interfaceTypes actually accomplish. Is there a table somewhere of perhaps variables or controls that are defined or enabled through use of these?


Code: [Select]
;Rigol DM30xx, Fluke8846A
#interfaceType DMM BMM
#interface readValue 0

;Fluke8845A
#interfaceType DMM BMM
#interface readValue 1

;R&SHMC8012
#interfaceType DMM BMM
#interface readValue  0
#interface readValue2 1
#interface readPower  2

;MTX328x
#interfaceType BMM
#interface readValue  0
#interface readValue2 1
#interface readValue3 2
#interface readValue4 3
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 2904
  • Country: dk
    • Tests
Re: Program that can log from many multimeters.
« Reply #3319 on: January 17, 2024, 06:45:32 pm »
Documentation says:
Quote
#interface read... column
#interface read... column column...

The definition of read is very easy, because it uses the same reading as "current values" and logging, i.e. the "#askValues" command and only the actual index of the value must be specified. For multichannel devices multiple indexes must be listed, one for each channel. The first value the device returns is numbered 0.
The read definitions also defines a name... command that can be used to get the column name for the value from the actual device.

QUESTIONS:

1) Given that the parameter to these is a zero-based column number, is it a bug to have only "#interface readValue 1" ?

No, but it means you cannot read the first column with a read... function.
But it looks like the Fluke8845A is wrong, it has to be 0.

2) The document suggests using "readValue column column..." but nobody does that. Instead they have separate "readValue 0" "readValue2 1"... WHY?

You list multiple column after the read... command when the device implements multiple devices.
Try checking out the R&SHMC8043.txt, it is a 3 channel power supply.

Using "readValue2 1" is sort of a hack, usually you use readVoltage, readCurrent, etc., but if you have two columns where the type of data changes depending on mode, using readValue with a number is a usable hack.

3) What's the meaning of readValue, readValue2, readValue3...? Not documented.

See above.

4) In NO case do I see any of these used anywhere else in the device files, nor the auto-generated nameValue* that's described. Do these definitions set up something inside TC?

They do, all the interface names are accessible from scripts, see here: https://lygte-info.dk/project/TestControllerFunctions%20UK.html#Test_controller_device_functions
They are also used in some of the grid panel controls. This is mostly invisible, because it is used as a filter on what devices you can select for that grid panel item.

5) One device has "BMM" without "DMM". I have not yet found an explanation of what these interfaceTypes actually accomplish. Is there a table somewhere of perhaps variables or controls that are defined or enabled through use of these?

That is a error, BMM is bench multimeter and means that it can be controlled from TC, not only read. See here: https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#The_#interfaceType_definition

These interface types are often used to filter what devices can be selected, especially in grid panels, but also in some other places.
 
The following users thanked this post: MrPete

Offline jmurray

  • Contributor
  • Posts: 32
  • Country: au
Re: Program that can log from many multimeters.
« Reply #3320 on: January 19, 2024, 01:02:50 am »
Hi HKJ,

Just a minor UI request: when importing a log file into the table to quickly review the charts, it would be nice to have a "Select All" checkbox for the listed parameters that have been logged, instead of having to check each individual box.



Thanks!
 

Offline MrPete

  • Contributor
  • Posts: 20
  • Country: us
Re: Program that can log from many multimeters.
« Reply #3321 on: January 21, 2024, 02:16:40 pm »
@HKJ, a new set of confusions  :P

I'm working on the definition for a BMM with primary and secondary modes/measures (Fluke 8808A). As is common, some functions are only available on primary, and there are limitations on which functions can be used on secondary.

I've got all the primaries working ok. Secondary has me a bit confused. I have two questions, both relating (I think!) to #cmdModeCheck:

Background: I'm using #cmdModeCheck for the secondary measurements, and for the modifiers (Rel, MinMax, etc) particularly because it allows defining which (primary) modes are allowed. (In general: any combination of DC/AC Volts/Amps can be on either one; can do ohms on P or P+S (and select 2/4 wire on P), Freq with select other things, and Modifiers go with almost every Primary mode.)

1) Modes Where This Mode Is Valid

I am not understanding how this line functions.
If I define the valid modes, and the invalid modes (with !Mode)... OR just define the valid modes... The result is that I get grayed-out result no matter what I do, unless I remove this line completely??!

2) How to do interlocking secondary modes?

If I choose Secondary AC Volts, by definition any other Secondary mode is no longer active. So that's not exactly a check-uncheck item... more like a second set of mode radio buttons.

It's pretty clear to me that the Mode Off Commands in #cmdModeCheck can't be used in this case. Those appear to ONLY work well when thinking of a single #cmdModeCheck as an isolated item that can be turned on/off.

So... how would you suggest handling a secondary set of modes that interlock? It almost feels like a radio button version of #cmdSetup??
This can't be the first device that has such a setup...


 

Offline jorgemef

  • Regular Contributor
  • *
  • Posts: 134
  • Country: pt
Re: Program that can log from many multimeters.
« Reply #3322 on: January 21, 2024, 02:56:17 pm »
Hello,
Not sure if already addressed in the 129 pages. :) I have keitley2000 and 2001 TSC scan multiplex card. It works with SPI protocol. Any simple way to use the multiplex channel wit Testcontroller? I would like to use it to monitor 3 different voltage reference signals from some boards I am setting up. :)
Thanks, Jorge
 

Offline MrPete

  • Contributor
  • Posts: 20
  • Country: us
Re: Program that can log from many multimeters.
« Reply #3323 on: January 21, 2024, 06:00:53 pm »
... I have keitley2000 and 2001 TSC scan multiplex card. It works with SPI protocol. Any simple way to use the multiplex channel wit Testcontroller? I would like to use it to monitor 3 different voltage reference signals from some boards I am setting up. :)
(Search at top-right... "multiplex" has not been said before ;) )
I downloaded the user guide. Looks like it ought to work for you. Simple? Not sure...
* While there's already a Keithley2000.txt device file, yours is likely a bitt different. You may need to work out a device definition. Once you've got the basic device recognition (even without much of anything else)...
* ensure the existing #value (data types) to be read are OK
* work out how you want to set it up to do what you want. NO NEED to automate that to start.
* work out a set of commands that would at least define how to read the data you want (that part MUST be sent by TC.) Got to have #askValues defined.
* use testcontrollerdebug.bat to see the interaction at the outset and make sure it isn't blowing up
* use the Current Values tab to watch data come in
* then turn on logging and collect a bunch of data :)

Simple? Depends on your expectations. It WILL take some learning :)

Hope that helps a little!
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 2904
  • Country: dk
    • Tests
Re: Program that can log from many multimeters.
« Reply #3324 on: January 22, 2024, 11:56:21 am »
Just a minor UI request: when importing a log file into the table to quickly review the charts, it would be nice to have a "Select All" checkbox for the listed parameters that have been logged, instead of having to check each individual box.

I will think about it.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf