Program that can log from many multimeters.

[HKJ]

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...

One place where #cmdModeCheck is used is the "R&SHMC8012.txt" definition and you can probably get a lot of hint from there.

Also use =deviceMode(handle) command to check what modes are active when you test

[HKJ]

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

Test controller do not have the concept of multichannel device only returning one channel value at a time, it always needs all channels simultaneous. If you can setup a couple of commands to return all values, you are on (That may mean a low log rate).

If you do not require high precision, you can make a alternate solution very cheaply, that works with TC: https://lygte-info.dk/project/TestControllerUserProjects1%20UK.html#10_channel_12bit_ADC_module_addition_by_Pukker

[MrPete]

Test controller do not have the concept of multichannel device only returning one channel value at a time, it always needs all channels simultaneous. If you can setup a couple of commands to return all values, you are on (That may mean a low log rate).

To say the same thing in a perhaps overly optimistic way ... many BMM devices pull multiple values sequentially in their #askValues command. The R&S8012.txt device uses 3-5 commands in a row to accomplish that. The Fluke 8808A I'm working with now does that. Depending on the specific measurements involved, yes the log rate can vary from dozens per second to one log every two seconds worst case

The key is, ALL values to be read must fit into a single #askValues sequence.

[MrPete]

@HKJ I've done a bunch of testing on modes and #cmdModeCheck

I'm not sure if these indicate some bugs. At the least, I seem to be missing a function or two to accomplish some seemingly obvious use cases

In #cmdModeCheck:
* If I use the 4th line (list of valid/invalid modes), it ONLY works if I use the inverted logic (a list of modes that are invalid for this, ie !VDC etc) Otherwise, this mode is always grayed out 100% of the time, even if I make it active by default when starting (ie line 1 last parameter set to 1 instead of 0)
* Unlike #cmdMode, every #cmdModeCheck mode is 100% independent of all others, in the sense that any mode change is ignored by this one -- the check box NEVER gets auto-unchecked.

   In other words:

 1) With regular #cmdMode modes... the regular #cmdMode modes act like a set of radio buttons: only one of them is active at a time. TC knows which one(s) is/are active via #askMode. If I switch from DCV to ACV, it knows, etc... and all columns etc change based on that.

2) With #cmdModeCheck... all of the buttons are independent. (I'll call these CheckBoxModes for the moment)
     * TC knows if I preset a CheckBoxMode to be active, and knows if I manually check or uncheck it... BUT:
     * Changing a mode that's on the list of valid/invalid Modes only makes the CheckBoxMode gray or normal (touchable or not). It never changes the active value
     * AND, there's no interaction between CheckBoxModes. Even if I'm using the DeviceModeString on line one, and NOT [localmode]... nothing auto-un-checks a CheckBoxMode that's no longer active. The user must manually uncheck.

QUESTIONS:

Q1) deviceMode(handle) and isDeviceMode(handle,mode) are great for testing modes. Is there a function that lets me set/clear a mode?

Q2) Is there a way to do some math in #cmdModeCheck so I can code the interactions between #cmdModeCheck items?

Q3) If not Q2 (and maybe anyway ) ... is there a way to set/clear Modes within the UI of #cmdSetup?

(Something that *appears* to approach this is the fancy mode capture code in devices like Siglent SDL10xxXxx... yet (I could easily be wrong on this as a noob ... it appears to be capturing, not changing modes.?)

[MrPete]

@HKJ a seemingly dumb question, but not actually documented (four items are listed but not documented at the bottom of https://lygte-info.dk/project/TestControllerPopupLog%20UK.html )

What does #haslogged actually do? I see in one of your scripts that you have two of those in a row. This indicates it does more than simply "sync" with the log file...

[jmurray]

@HKJ a seemingly dumb question, but not actually documented (four items are listed but not documented at the bottom of https://lygte-info.dk/project/TestControllerPopupLog%20UK.html )

What does #haslogged actually do? I see in one of your scripts that you have two of those in a row. This indicates it does more than simply "sync" with the log file...

Don't forget that you can always type the command into the command line text box in the program and it will provide a helpful description.



On the topic of logging, @HKJ, I notice for example on the device definition web page, there's mention of being able to test the portType variable:


Is there a global or system variable that can be queried to determine whether logging is currently running?
I have Test Controller executing a batch file that launches putty and logs the output to a filename, but would like to be able to leave a script running in the background that can execute my "close putty" script if I stop logging in Test Controller.
Not vital and if need by I'll come up with a work-around, but thought it worth asking the question.

Thanks!

[HKJ]

Q1) deviceMode(handle) and isDeviceMode(handle,mode) are great for testing modes. Is there a function that lets me set/clear a mode?

No.
But you can change between normal modes by defining a interface section that support the required script commands.
https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#A_generic_interface

Q2) Is there a way to do some math in #cmdModeCheck so I can code the interactions between #cmdModeCheck items?

No

Q3) If not Q2 (and maybe anyway ) ... is there a way to set/clear Modes within the UI of #cmdSetup?

(Something that *appears* to approach this is the fancy mode capture code in devices like Siglent SDL10xxXxx... yet (I could easily be wrong on this as a noob ... it appears to be capturing, not changing modes.?)

No
All the #cmdMode stuff is static definitions, they get parsed once when the device is loaded. The #cmdModeCheck get enabled/disable by parsing the mode names, the parser assumes enabled and if any of the listed mode check fails it will be disabled.

[HKJ]

Is there a global or system variable that can be queried to determine whether logging is currently running?
I have Test Controller executing a batch file that launches putty and logs the output to a filename, but would like to be able to leave a script running in the background that can execute my "close putty" script if I stop logging in Test Controller.
Not vital and if need by I'll come up with a work-around, but thought it worth asking the question.

No, but there will be in the next version.

[MrPete]

All the #cmdMode stuff is static definitions, they get parsed once when the device is loaded. The #cmdModeCheck get enabled/disable by parsing the mode names, the parser assumes enabled and if any of the listed mode check fails it will be disabled.

I understand that the definitions are static. However, which Mode is/are active at any time is not static, correct? It's based on the dynamics of at least the result of #askMode?

So my question relates to how could one feed dynamic information into (or within) the system so that #cmdModeCheck modes are correctly turned on and off? I guess enable/disable was the wrong way to ask it

[HKJ]

So my question relates to how could one feed dynamic information into (or within) the system so that #cmdModeCheck modes are correctly turned on and off? I guess enable/disable was the wrong way to ask it

#askMode/#modeFromValue are the primary ways to set the modes, #cmdModeCheck with [localMode] is another way.
When the active modes changes TC will reinitialize the select columns and displayed values.

[adso85swe]

TC do not have that function, but it can easily be done with scripting in TC, including naming the files with a sequence number or a date.
This example will save every 10 seconds and then restart the log:

#while 1
#log 1
#delay 10
#log 0
#savetable ("c:\\data\\log"+date())
#endwhile

Place it in the "log" window and press "Run", it will log from all connected devices

If you want to format the date different check here: https://lygte-info.dk/project/TestControllerFunctions%20UK.html#Date_&_time_functions

This is great, thanks a lot. One question though, the CVS file that is automatically saved with this script has the default dateTime format in Unix time, i.e. just a long number in seconds. Is there a way to change the log format of the date by script? Im not talking about the date in the file name, but the actually logged time stamps.

Thanks a lot for a great work with this software.

[HKJ]

This is great, thanks a lot. One question though, the CVS file that is automatically saved with this script has the default dateTime format in Unix time, i.e. just a long number in seconds. Is there a way to change the log format of the date by script? Im not talking about the date in the file name, but the actually logged time stamps.

Yes, you have to use #export instead of #savetable:
#ExportInit
#ExportColumn dateTime "" System
#ExportTable myFileName

If you want to redefine more columns for the export, use the export popup, but instead of finish with pressing "Export data" close the popup. Then go to the commands tab and right click in the log window and select "Generate script, Export script", this will give you the script needed to export in the selected format.

[MrPete]

#cmdModeCheck with [localMode] is another way.

Ahh! So #cmdModeCheck without [localMode] isn't fully implemented yet?

I'm talking about making use of deviceModeString:

Code: [Select]

#cmdModeCheck modeLabel deviceModeString defaultState
The Fluke 8808A for example has secondary modes VDC2, ADC2, VAC2, AAC2, OHMS2, FREQ2, etc... (and CLR2, which turns off any secondary measure)

So I have things like

Code: [Select]

#cmdModeCheck secVDC VDC2 0
VDC2
*CLS
!pFREQ,!pDIODE,!pCONT

This partly works: clicking the checkbox does enable the secondary mode!

However, even though all of these have correct deviceModeString values in place, TC doesn't seem to detect these modes to check/uncheck the appropriate check boxes.

(NOTE: I have to use *CLS instead of CLR2 for the "off" string, because leaving it blank breaks everything (is there a better placeholder?), and using CLR2 there causes all secondary measures to turn off pretty much all the time. Instead I have an extra button to turn secondary off:

Code: [Select]

#cmdModeCheck secCLR CLR2 0
CLR2
*CLS
!pFREQ,!pDIODE,!pCONT

This works -- kind of -- it does send the command. But then there is a checked box in the UI that only clears if the users clicks again

Anyway... shouldn't TC see the secondary modes in #askMode and cause the other #askModeCheck checkboxes to clear? I.e. the ones that don't have [localMode]?

[HKJ]

Anyway... shouldn't TC see the secondary modes in #askMode and cause the other #askModeCheck checkboxes to clear? I.e. the ones that don't have [localMode]?

That is correct, TC do not in any way control the checkboxes, that may not be ideal and I probably have to fix it in a future version. There is one issue with two way control: It can get into a loop
The reason is that not all devices changes immediately, but may take up to a few seconds.

[MrPete]

Anyway... shouldn't TC see the secondary modes in #askMode and cause the other #askModeCheck checkboxes to clear? I.e. the ones that don't have [localMode]?

That is correct, TC do not in any way control the checkboxes, that may not be ideal and I probably have to fix it in a future version. There is one issue with two way control: It can get into a loop
The reason is that not all devices changes immediately, but may take up to a few seconds.

When you say "two way control" do you mean the ability to set both primary and secondary measures? Or something else?
It seems this potential issue is there for any device that has multiple channels or simultaneous modes (ie multiple values read.)

Having a secondary set of modes seems pretty common, both in bench meters and multi channel devices.

To make this practical, here's a table of what's allowed for the 8808A. I've also included the (primary mode) modifiers. These of course are common in many bench meters.

Primary Modes

(A simple mutually-exclusive set of modes. I.e. these are the 'radio buttons' )
VDC, VAC, ADC, AAC, FREQ, OHMS-2wire, OHMS-4wire, DIODE, CONT

(Primary) Modifiers

Three sets: each can have one selected, or none. All have certain exclusions.
REL -- work with all primary except DIODE and CONT
MIN, MAX, MNMX  -- work with all primary except DIODE and CONT
DB, DBPOWER -- work with VDC and VAC (DBPOWER is DBm )

Secondary Modes

(A simple mutually-exclusive set of six modes. I.e. these are the 'radio buttons' ... but some are not available depending on the primary mode.)
VDC2, VAC2, ADC2, AAC2 -- selectable with any primary Volts or Amps
FREQ2 -- selectable with VAC or FREQ
OHMS2 -- selectable with OHMS-2wire and OHMS-4wire

Further info for understanding:

• #AskValues is simply "MEAS?" which returns one or two values
• #AskMode is a little trickier, but not hard: I pass through the primary mode, and append "2" to the secondary mode if it exists.
• Modifiers and (Fixed vs Auto) ranging apply only to the Primary mode; Secondary does something appropriate

FWIW, I am noodling over what it would take to treat the secondary modes as a second channel. The hard part there (maybe) is that there are interactions in terms of what is allowed. Plus, I don't actually see any examples of #askMode being applied in a multi-channel sense.
- Could I format a second incoming mode as "VDC2:2" and have the ":2" treated as channel 2???
- How would channels be defined in mode definitions? Maybe  #cmdMode secVDC VDC2:2  (ie on channel 2 (":2"), send string "VDC2" to set this mode)

I'm probably being creatively stupid here LOL

[HKJ]

When you say "two way control" do you mean the ability to set both primary and secondary measures? Or something else?
It seems this potential issue is there for any device that has multiple channels or simultaneous modes (ie multiple values read.)

I mean from both GUI and from the device.

Having a secondary set of modes seems pretty common, both in bench meters and multi channel devices.

Yes and mostly the TC definition is only defined to handle the primary value (Metra hit energy is an exception).

Further info for understanding:

• #AskValues is simply "MEAS?" which returns one or two values
• #AskMode is a little trickier, but not hard: I pass through the primary mode, and append "2" to the secondary mode if it exists.
• Modifiers and (Fixed vs Auto) ranging apply only to the Primary mode; Secondary does something appropriate

FWIW, I am noodling over what it would take to treat the secondary modes as a second channel. The hard part there (maybe) is that there are interactions in terms of what is allowed. Plus, I don't actually see any examples of #askMode being applied in a multi-channel sense.
- Could I format a second incoming mode as "VDC2:2" and have the ":2" treated as channel 2???
- How would channels be defined in mode definitions? Maybe  #cmdMode secVDC VDC2:2  (ie on channel 2 (":2"), send string "VDC2" to set this mode)

I'm probably being creatively stupid here LOL

You can have multiple commands after #askMode (Like #askValues), TC will look at the full answer and split it on spaces/commas, each item will be a mode. You can also do math (#askModeMathFormat ) on the result to split it into multiple modes.

[palmerr23]

I'm working on a device file for the Owon XDS series oscilloscopes.

What's the best way to decode the #askValues when the response is in the form "SS : NNN.NYY->"

• SS is a variable length string (1 - 6 chars)
• <sp>:<sp> seems a constant delimiter
• NNN.N is a four digit float, where the position of the . varies
• YY is a variable length units string, which seems SI compliant
• -> at the end seems constant

Code: [Select]

;; OwonXDS: Tx <:MEASU:CH1:VAMP?>
;; OwonXDS: Rx <Va : 1.829V->>

;; OwonXDS: Tx <:MEASU:CH1:FREQ?>
;; OwonXDS: Rx <F : 1.759KHz->>

[palmerr23]

I did some extra searching and found a previous answer:

#askValuesReadFormat xxs

[HKJ]

I did some extra searching and found a previous answer:

#askValuesReadFormat xxs

That is the best way, another way is to use a expression in #askValuesMathFormat, but it is a slower (Only a issue on very slow computer or with many devices running simultaneous).

[Gulftown]

Hi,

when i use an AR488 with test controller only one device at a time works, as soon as i enable 2 devices in "Load Devices" i get

Code: [Select]

;; COM4: Tx: <READ?.> 52 45 41 44 3F 0A
;; HP34401A: Tx <system:local>
Thread for HP34401A
java.lang.NullPointerException: Cannot invoke "dk.hkj.comm.CommInterface.write(String)" because "this.ci" is null
        at dk.hkj.shared.SharedInterface.writeWithDelay(SharedInterface.java:114)
        at dk.hkj.shared.SharedInterfaceAR488.write(SharedInterfaceAR488.java:68)
        at dk.hkj.comm.GpibInterface.write(GpibInterface.java:59)
        at dk.hkj.main.SCPICommand.writeReadInternal(SCPICommand.java:316)
        at dk.hkj.main.SCPICommand.writeRead(SCPICommand.java:339)
        at dk.hkj.main.DeviceInterface.doCommand(DeviceInterface.java:83)
        at dk.hkj.devices.DeviceSCPI.close(DeviceSCPI.java:154)
        at dk.hkj.main.InterfaceThreads$DeviceThread.run(InterfaceThreads.java:1638)
;; jSerialComm version: 2.10.3
;; COM4: Set params: 115200
Exception in thread "Scan ports" java.lang.ClassCastException: class dk.hkj.comm.DummyInterface cannot be cast to class dk.hkj.comm.SerialInterface (dk.hkj.comm.DummyInterface and dk.hkj.comm.SerialInterface are in unnamed module of loader 'app')
;; Start thread for: AR488 A:14 - Agilent 34401A Enhanced
        at dk.hkj.main.InterfaceThreads$ScanPorts.addDevicesShared(InterfaceThreads.java:643)
        at dk.hkj.main.InterfaceThreads$ScanPorts.run(InterfaceThreads.java:791)
;; Stopping thread for: AR488 A:14 - Agilent 34401A Enhanced
It works independently with both devices, but not both together.

And when does the new version with the fixed AR488Lan gets released?
The bug that the AR488Lan adds a normal AR488 is still in the current version.
I tried Prologix LAN also had no luck with it.

Thank you for your hard work!

[MrPete]

You can have multiple commands after #askMode (Like #askValues), TC will look at the full answer and split it on spaces/commas, each item will be a mode. You can also do math (#askModeMathFormat ) on the result to split it into multiple modes.

SO... Is the following a ridiculous idea, or potentially useful?

1) Architecturally, I will create and maintain knowledge of N Mode Sets. Each set can have a single Mode that's active, or none. By default TC understands one Mode Set (the "Primary Mode")

2) I'll write code to maintain the current state of each Mode Set, and feed it to TC via #AskMode. Any time ANY mode is requested/changed, ALL active modes will be returned to TC (ie either zero or one mode from each mode set)

The only thing that feels unclear to me at this point, is how the calculated (#CmdModeCheck) modes may interact with this... but i'll cross that bridge when I am further along.

Sample real-world setup

Mode Set: Primary = VDC, VAC, ADC, AAC, FREQ, OHMS-2wire, OHMS-4wire, DIODE, CONT

Mode Set: PrimModRel: REL (available for all Primary except DIODE and CONT)
Mode Set: PrimModMinMaX: MIN, MAX, MNMX (avail for all Primary exc DIODE and CONT)
Mode Set: PrimModDb: DB, DBPOWER (avail for VDC, VAC)

Mode Set: Secondary: VDC2, VAC2, ADC2, AAC2  (avail w/ any primary Volts or Amps)
                                 FREQ2 (avail w/ Primary VAC or FREQ)
                                 OHMS2 (avail w/ Primary OHMS-2wire and OHMS-4wire)

[HKJ]

when i use an AR488 with test controller only one device at a time works, as soon as i enable 2 devices in "Load Devices" i get
It works independently with both devices, but not both together.

Yes, that is a known bug.

And when does the new version with the fixed AR488Lan gets released?
The bug that the AR488Lan adds a normal AR488 is still in the current version.
I tried Prologix LAN also had no luck with it.

Thank you for your hard work!

I have not been putting much time into TC lately and it is not really for a official release, but you can get a test version here (jar only) with the above fixed:
http://lygte-info.dk/pic/Projects/TestController/TestController.jar

[HKJ]

SO... Is the following a ridiculous idea, or potentially useful?

That might work, just be aware that #cmdMode do translate mode names. You can use same name as both first and second parameter to avoid that.

[Gulftown]

Thank you,
i can configure an AR488Lan now, but i still its trying to use some local port:

Code: [Select]

;; jSerialComm version: 2.10.3
;; Start thread for: AR488Lan A:2 - HP 66311B
;; Stopping thread for: AR488Lan A:2 - HP 66311B
The local com port its still working and the AR488 is also working via telnet.

If you dont have time for TestController, have you thought about hosting the sourcecode an github?
You put a lot of effort into this awesome software, it would be sad if the development stops.

Greetings.

[HKJ]

Thank you,
i can configure an AR488Lan now, but i still its trying to use some local port:

Code: [Select]

;; jSerialComm version: 2.10.3
;; Start thread for: AR488Lan A:2 - HP 66311B
;; Stopping thread for: AR488Lan A:2 - HP 66311B
The local com port its still working and the AR488 is also working via telnet.

I am not really sure what the problem is here.

If you dont have time for TestController, have you thought about hosting the sourcecode an github?
You put a lot of effort into this awesome software, it would be sad if the development stops.

Since start of summer my lab has mostly been packed down due to some construction work, it was supposed to last the summer, but is not finished yet. This has slowed down my work significantly.