Program that can log from many multimeters.

[gby]

Not script commands, but you can export and then import the data to change the sequence.
The export menu allows you to change the column sequence (Use Ctrl-up/down arrow).
You can save a export format, making it fairly easy to reuse it.
I plan on adding script command to configure the export menu.

Ah, I did not know that the Data export screen allowed selecting one or more lines and then moving them up or down.  You might want to add some text on the screen to tell the user you can move selected with ctrl arrow.

If I save a format with data from scope number one and then later load the format with scope number two connected how would TestController format know what order to put things in?

What about using Osc?
Remap is outside script control, but you can remap on device serial number. The disadvantage with remap is that TestController may loose tracking of column format and units.

Do you mean create an interface for the oscilloscope device?  In reading the web site documentation it only lists PS, DMM, BMM, ARB, Load as possible interface types.  Are you saying there is an Osc interface type now for oscilloscopes?

[HKJ]

You might want to add some text on the screen to tell the user you can move selected with ctrl arrow.

There is a hint or tool tip (Java name) that says it.

If I save a format with data from scope number one and then later load the format with scope number two connected how would TestController format know what order to put things in?

Table and loaded devices are not linked, before you press the "Log" button.
Loading a csv file will unlink again.

Do you mean create an interface for the oscilloscope device?  In reading the web site documentation it only lists PS, DMM, BMM, ARB, Load as possible interface types.  Are you saying there is an Osc interface type now for oscilloscopes?

The interface name is not coded anywhere in the Java code, it is only in the device definitions, i.e. there is nothing preventing using other names, but to get the full benefit from the interface the names has to be coordinated.
This means I have added "Osc" to the official list (Will be published with next update) and will add other when needed.

TestController has a internal list of preferred function names and string or numeric parameter and will show them with green background in the interface test popup.

[gby]

There is a hint or tool tip (Java name) that says it.

I like the idea of and try to use tool tips.  But I must admit nothing I had done before had ever popped that specific tool tip up before.  Thanks for pointing it out.  Now the I know it is there along the side of the table I can find it easily now.

The interface name is not coded anywhere in the Java code, it is only in the device definitions, i.e. there is nothing preventing using other names, but to get the full benefit from the interface the names has to be coordinated.
This means I have added "Osc" to the official list (Will be published with next update) and will add other when needed.

TestController has a internal list of preferred function names and string or numeric parameter and will show them with green background in the interface test popup.

Okay, I will try that.  But, I do have a general interface usage question.  Sometimes you want to refer to a logged value in a script.  If I have a script working with Siglent SDG2042X and I use SDG2042X.Frequency1 in a script expression that works fine.  But, if I next connect to a Siglent SDG2122X I have to change the script to use SDG2122X.Frequency1.

If you are trying to use the interface method like:
   =var arb=getDevice("ARB")
it would be great if somehow you could use the variable arb pointing to the "ARB" device to refer to a logged value like say arb.<signal name>.  Is this already possible or something simple to add?

[HKJ]

I like the idea of and try to use tool tips.  But I must admit nothing I had done before had ever popped that specific tool tip up before.  Thanks for pointing it out.  Now the I know it is there along the side of the table I can find it easily now.

I will admit that tool tip is a bit on the discrete side, it shows up i the table area, but only outside data.
When I get around to write a help page for export, I will also list the function there.

Okay, I will try that.  But, I do have a general interface usage question.  Sometimes you want to refer to a logged value in a script.  If I have a script working with Siglent SDG2042X and I use SDG2042X.Frequency1 in a script expression that works fine.  But, if I next connect to a Siglent SDG2122X I have to change the script to use SDG2122X.Frequency1.

If you are trying to use the interface method like:
   =var arb=getDevice("ARB")
it would be great if somehow you could use the variable arb pointing to the "ARB" device to refer to a logged value like say arb.<signal name>.  Is this already possible or something simple to add?

That is what read functions are for, but to get the channel number as parameter the device must be defined as a multi channel device (You can see how that work in TTi CPX400).
The result is you can use: readFrequency(osc,1)
The channel number is last, because using the call without channel number is valid and means channel 0

[HKJ]

V1.21 is up
This is script support for histogram and range, it adds one new device and improves another.
   Fixed: It is now possible to use expressions in () for the filename in #log commands
   Updated: Kunkin KP184 Support for remote sensing and a couple of other details.
   Added: Amrel PLA800-60-300 electronic load, supplied by a reader.
   Added: #Calc switch to calculator/expression mode until next # command
   Added: Modified generation of chart script to include histogram and range (They all require table data)
   Added: #RangeSamples define the limit of the data to use for calculations/statistic.
   Added: #RangeOptions define the slope calculation time period
   Added: #SaveHistogram save the histogram(s) in a file.
   Added: #HistogramSamples define the limit of the data to use.
   Added: #HistogramOptions define the histogram bins and count or percent
   Added: #HistogramCurves   define up to 3 datasets to make histograms for




The calc mode makes it easier when doing multiple calculations. This mode can do some extra stuff when running script, but information about this will have to wait until I have written some documentation.

[gby]

NEED HELP MAKING TEKTRONIX SCOPE LXI CONNECTION WORK:

I am working on a device file for Tektronix oscilloscopes.  I have gotten communications and functionality working with MDO3000 series, TDS3000C series
and everything is looking good.

Then I tried the MSO3000 series and things are not working.  TestController connects and all SCPI query commands I have tried give replies that make sense.  But, as soon as I send a set command the process fails and the scope stops talking to TestController.  I can click the Reconnect button on the Load devices tab and nothing connects.  I can stop and restart TestController and it still will not reconnect.  To get the MSO3000 talking again I have to do one of:
   Power cycle the scope
   Use an LXI Discovery Browser that scans the subnet
My working theory is that somehow the LXI communications with this specific device is not working correctly.  When I send a set command the communications gets in a non-functional state.  Power cycling the scope or doing a "proper" LXI discovery query gets it back to normal.  Not sure why restarting TestController and trying reconnect does not work.

Attached are the debug mode dos window and the log screen contents as well as the Tektronix scope device file.  Note that some newer Tektronix scopes support socket connection and LXI while some older, like the TDS3000C, only support LXI.  This debug is with LXI to an MSO3014 scope.

The test sequence in this record is:
   1.  Start TestController and it connects successfully to the MSO3014
   2.  Manually type the query           *idn?
            Note that the debug window shows the RX line with an extra carriage return, line feed at the end of the reply putting ">" on next line.
   3.  Manually type the query           measurement:meas1:source1?
            Again, the ">" is on the next line
   4.  Manually type the set cmd        measurement:meas1:source1 CH4
            There is never a RX and at this point communications seems to have stopped.
   5.  Manually type the query           *idn?
            There is an RX line but nothing between <>'s
   6.  Used LXI Discovery Browser to reset the scope and reconnected successfully with TestController
   7.  Repeated the queries in steps 2 and 3 above.
            Note in reply to the second query that the measurement source is still CH1 and the attempt to set CH4 never worked.

To me the odd things about the communications record are:
   1.  The queries RX line seems to have an extra carriage return, line feed compared to all other devices.  Like
        MSO3014: Rx <CH1
>
instead of MSO3014: Rx <CH1>
  2.  No where ever were there any Java errors reported in the dos debug window.
  3.  Why does restarting TestController not connect while using the LXI discovery browser seems to reset the communications to working?

Any thoughts from anyone to help figure out what is going on here?
Any debug test suggestions for more data?

[HKJ]

Only message with ? in them are looking for answers.

My LXI code is not perfect and you are probably correct that is the problem. The LXI works with the devices where I have tested it and it is rather difficult to debug it without the problematic device.

For testing I have included some hard coded debug output to the console in this version:
http://lygte-info.dk/pic/Projects/TestController/TestController.jar

[gby]

HKJ, Thanks for the debug version.  I can't jump on it right away but will before my end of day.

By the way, I have a perhaps related data point.  With all the remote/work from home stuff I have tried TC via VPN from home to lab.  From my house it works fine connecting to a Siglent SDG2042X generator and a Tektronix TDS3054C scope.  For a coworker of mine from his house with the exact same lab instruments, same version of TC he gets no connection.  He can pull up the scope web page showing connectivity to at least the scope. 

I have fiber/good internet and he has Satellite internet which has fairly large latency.  Could it be that too much latency in connection attempts times out for him?

[HKJ]

Could it be that too much latency in connection attempts times out for him?

That could very well be the reason, for most devices there is a 1 second timeout (It can be adjusted in the definition file).
I have never thought about using the program from a remote location. You can, of course, remote control a computer running TestController at the location, that would work.

If you want to see how fast communication is, start a log and use "#COMMANDTIME?"

[gby]

My LXI code is not perfect and you are probably correct that is the problem. The LXI works with the devices where I have tested it and it is rather difficult to debug it without the problematic device.

For testing I have included some hard coded debug output to the console in this version:
http://lygte-info.dk/pic/Projects/TestController/TestController.jar

I ran the debug code you linked with the Tektronix MSO3014 device and the same device file.  My test sequence was:
1.  Power up the scope and proved could connect to its web page.
2.  Started the TC test version in debug mode
3.  Saw TC connected OK.
4.  Did *.idn? and got a reply with the extra CR LF before the RX ">"
5.  Did measurement:meas1:source1? query and got an answer with extra CR LF on RX ">"
6.  Tried to do a set command but incorrectly typed with a "?".  Did measurement:meas1:source1? ch4
     Sorry I goofed and did not do above without the "?".  But it reacted same as yesterday correctly typed without the "?".
7.  Tried *ind? and got no answer.
8.  Tried reconnect and it could not connect.
9.  Saved the dos debug window and the log window in attached files
     MSO3014 Extended dos debug.txt
     MSO3014 Extended log debug.txt
10. Closed and restarted TC test version in debug mode
11. Did not connect.
12. Power cycled the scope.
13. Tried reconnect and it connected.
14. Saved the dos debug window and the log in attached files
      MSO3014 Extended dos debug restart TC.txt
      MSO3014 Extended log debug restart TC.txt

If you compare step 9 dos debug to step 14 dos debug file beginning of each file you get successful connection and not successful connection directly compared.  In the second case it seems like extra items are in the sequence just after the line *IDN? Check for answer:  6 0 step in the file.  Also, in the start of TC unsuccessful connection attempt it does *IDN? a second time.

If you need more data I can do more tests.

[Dwaine]

Could it be that too much latency in connection attempts times out for him?

That could very well be the reason, for most devices there is a 1 second timeout (It can be adjusted in the definition file).
I have never thought about using the program from a remote location. You can, of course, remote control a computer running TestController at the location, that would work.

If you want to see how fast communication is, start a log and use "#COMMANDTIME?"

I'm also using the program under Linux remoting through SSH with X11 forwarding.   Working pretty good with my devices.

Dwaine

[HKJ]

I'm also using the program under Linux remoting through SSH with X11 forwarding.   Working pretty good with my devices.

As long as the tx/rx is only delayed a few milliseconds it will work, but when it gets into 100's of millis it will most likely fail.
A firewall that blocks some ports can also be problematic, this can be present on the computer with TC and somewhere on the connection.

gby: I have done a change to LXI and added a bit more logging, please try again.

[gby]

gby: I have done a change to LXI and added a bit more logging, please try again.

Great progress!  Here are the details of my testing:

Downloaded the second debug version and tried it.  I used a Tektronix DPO3034 which is the exact same generation and type as the MSO3014 that I was using before except without the logic probe function.  I checked with TC V1.19 and DPO3034 exhibits the same communication issues as before.  The DPO3034 I have instant/easy local access to now.

1.  Started TC with just the DPO3034 connecting fine.
2.  Did *idn? query and it worked like before.  Got a correct reply with the extra CR LF before the RX final ">".
3.  Did measurement:meas1:source1? query and got CH1 reply with extra CR LF before final RX ">".
4.  Did measurement:meas1:source1 ch4 set and it seemed to work.
5.  Did *idn? query and got an answer!  Step 4 set did not kill communications.
6.  Did measurement:meas1:source1? query and got answer CH4 saying step 4 set worked!
7.  Saved dos debug window and TC log window as attached files
     DPO3034 Extended dos debug.txt
     DPO3034 Extended log debug.txt

Based on this test it looks like communications is working except for the extra CR LF before final RX ">".  I then started using this version to do a bunch of things to see if it really is working.  For example, right after step 7 above I just did a Load devices tab Reconnect and that worked.

One thing I accidentally tried by doing a typo was "*.idn?".  Standard query except for an extra/incorrect period after the "*".  This time there was an infinite loop and I never got control back.  Attached is "DPO3034 Infinite log debug.txt" which is about 40 seconds of waiting from the dos debug window after just starting TC and then typing the "*.idn?" query with extra period.  The TC log window upper section only had the connection and nothing else got there.  I also tried another scpi command with a typo (measurement:meas1:seurce2? with "e" instead of "o" and got the same never ending loop.  The good news is that after force stopping TC and restarting TC everything was OK without requiring scope power cycle.

Next, I tried a simple script to setup all four measurement channels on the DPO3034.  That was 16 set commands in a row and everything seemed to work fine.

Lastly, I used this version to run a scripted measurement with Siglent SDG2122X and Tektronix MDO3054 that I had originally had all working with LXI interfaces.  That also worked with this test/debug version of TC.  So, I don't think the update made new bugs in LXI communications with existing working devices.

Definitely a huge improvement if not a full fix.  Just a potential issue with miss-typed commands hanging the communications.

Thank you ever so much for this progress.

[HKJ]

Just a potential issue with miss-typed commands hanging the communications.

This was a easy fix.
I will not post a new version just yet, I got started on LXI discovery. When it is working it is possible to leave the address field empty (i.e. no IP address) and it will find the device if it is on and on the local network. This will work with both socket and LXI connections, as long as the device support LXI.

[gby]

Just a potential issue with miss-typed commands hanging the communications.

This was a easy fix.
I will not post a new version just yet, I got started on LXI discovery. When it is working it is possible to leave the address field empty (i.e. no IP address) and it will find the device if it is on and on the local network. This will work with both socket and LXI connections, as long as the device support LXI.

Great to hear.  Thanks for all your help.

I have done some further investigating and discovered some interesting information.
1.  The MDO3024 I have been using supports both LXI and socket connection.  Using #commandtime? it reports a huge difference in speed between the two interface methods in debug V1.23:
V1.23 socket:  MDO3024       last:    12.25 ms       average:    16.12 ms       slowest:    53.11 ms
V1.23 LXI:      MDO3024       last:   170.50 ms       average:   167.45 ms       slowest:   181.51 ms
V1.21 LXI:      MDO3024       last:    11.14 ms       average:    13.97 ms       slowest:    45.14 ms

Note that Ver 1.21 LXI and socket are just as fast and only debug Ver 1.23 LXI is approximately 10x slower.  I assume that is the extra debug logging and hope it is not extra communications.

2.  The DPO3034 that we have been working on the LXI problem with also supports socket connection.  But, TC debug V1.23 does not connect in that mode.  Is there anything learned in debugging DPO3034 LXI connection that could help make socket work?  I did tests connecting with Putty to these scope's socket ports.  The MDO3054 replies to *idn? after hitting the return key.  On the screen it did a line feed but no carriage return.  The DPO 3034 did nothing after hitting return.  Thoughts?

For reference below is debug V1.23 DPO3034 #commandtime? while connected with LXI:
LXI:     DPO3034       last:   172.34 ms       average:   166.21 ms       slowest:   175.50 ms
Nearly the exact same timing as MDO3024 using LXI communications.

[gby]

I got started on LXI discovery. When it is working it is possible to leave the address field empty (i.e. no IP address) and it will find the device if it is on and on the local network. This will work with both socket and LXI connections, as long as the device support LXI.

LXI discovery will be a great feature.  Looking forward to it.

While debugging the DPO3034 communications problem I have both the DPO3034 and the MDO3024 on the network and it got me thinking.  How will TC pick when auto filling in the address with multiple matching devices on the network?  Specifically, with
   Two identical devices on the network only differing by IP address
   Only one device setup on the Load devices tab
how will TC auto fill in the IP address?  Will it pick whichever one responded first during discovery?  Or, will there be a popup for the user to select the proper device when there is a question?  Certainly not a problem for individuals, but in a company lab you could easily have multiple identical devices on the same network.

The above question occurred to me while working on your suggestion to create an interface for Tektronix scopes using #interfaceType OSC.  With two supported scopes on the network when I did the
   =var osc=getDevice("OSC")
script line it picked the wrong one.  Any thoughts on how to code the script to get the right one/have a user prompt to select the right one?

[HKJ]

First part of discovery is working:
#discover?
;; 10.0.0.57 KEITHLEY INSTRUMENTS,MODEL 2460,04077759,1.6.4c
;; 10.0.0.59 Keysight Technologies,34470A,MY54700281,A.03.02-02.40-03.02-00.52-02-01
;; 10.0.0.60 KEITHLEY INSTRUMENTS,MODEL DMM7510,04076557,1.6.7c
;; 10.0.0.62 KEITHLEY INSTRUMENTS,MODEL 2280S-32-6,4083473,01.06g
;; 10.0.0.66 Keysight Technologies,34461A,MY53214390,A.03.02-02.40-03.02-00.52-01-01
;; 10.0.0.67 Keysight Technologies,34461A,MY53214418,A.02.09-02.37-02.09-00.49-01-01
;; 10.0.0.68 THURLBY-THANDAR, QL355P,  427628, 2.05 - 1.07
;; 10.0.0.69 THURLBY THANDAR, QL355P, 445308, 2.05-2.02
;; 10.0.0.75 Siglent Technologies,SDG2122X,SDG2XCAC1R0010,2.01.01.22R5
;; 10.0.0.76 Keysight Technologies,34465A,MY57502236,A.03.02-02.40-03.02-00.52-03-01
;; 10.0.0.79 KEITHLEY INSTRUMENTS,MODEL DMM6500,04395798,1.7.2b

Do I add a indicator to show what devices is supported?


And some answer to gby:
The LXI with debug is much slower than without, there is not supposed to be any extra communication.
With socket you can try to change termination between CR, LF, CRLF and see if any of them work.

With empty address field it is random what device it will use, but another solution is to put "sn:xxx" in the address field, as you can see above I get the serial number.

When using  =var osc=getDevice("OSC") it will pick the first device, you can use  =var osc=getDevice("OSC:2") to pick the second device (Second device can be second channel or another device).
Generally you are supposed to load the devices you want to use, this can be done from a script.

[gby]

First part of discovery is working:
#discover?
;; 10.0.0.57 KEITHLEY INSTRUMENTS,MODEL 2460,04077759,1.6.4c
;; 10.0.0.59 Keysight Technologies,34470A,MY54700281,A.03.02-02.40-03.02-00.52-02-01
;; 10.0.0.60 KEITHLEY INSTRUMENTS,MODEL DMM7510,04076557,1.6.7c
;; 10.0.0.62 KEITHLEY INSTRUMENTS,MODEL 2280S-32-6,4083473,01.06g
;; 10.0.0.66 Keysight Technologies,34461A,MY53214390,A.03.02-02.40-03.02-00.52-01-01
;; 10.0.0.67 Keysight Technologies,34461A,MY53214418,A.02.09-02.37-02.09-00.49-01-01
;; 10.0.0.68 THURLBY-THANDAR, QL355P,  427628, 2.05 - 1.07
;; 10.0.0.69 THURLBY THANDAR, QL355P, 445308, 2.05-2.02
;; 10.0.0.75 Siglent Technologies,SDG2122X,SDG2XCAC1R0010,2.01.01.22R5
;; 10.0.0.76 Keysight Technologies,34465A,MY57502236,A.03.02-02.40-03.02-00.52-03-01
;; 10.0.0.79 KEITHLEY INSTRUMENTS,MODEL DMM6500,04395798,1.7.2b

Do I add a indicator to show what devices is supported?

And some answer to gby:

I would add an indicator to show supported devices.  I think that would be useful.

Thanks for the hints.  I will look into them.

[HKJ]

V1.24 is up
It adds script support for export and LXI discovery.
   Added: # i.e. a empty command, this can be used to leave #CALC mode without doing anything.
   Added: Use LXI discovery to add devices when load device list is empty.
   Added: #Discover will list LXI compatible devices on the network
   Added: LXI discovery search (Leave address field empty)
   Fixed: LXI problem
   Added: Export script generator, with default export popup a script model is generated, if anything is defined a more compact script is generated.
   Added: #ExportColumns List columns to export
   Added: #ExportColumnsExclude List columns to not export
   Added: #ExportColumn Define a column to export
   Added: #ExportSamples Define what samples to export
   Added: #LoadExportFormat Load a saved export format
   Added: #ExportReduce Setup reduce format for export
   Added: #ExportTable Export table with current export setup
   Added: #ExportInit Clear export setup, this will also hide a visible export popup

The LXI discovery is a very nice function when starting first time:



The prompt will be shown when the load device list is empty.



About a second after pressing OK all available LXI devices has been added. The "sn:xxx" in the address field is not required, except when multiple of the same device is present.
Loading will be slightly slower when this function is used, but it is only about a second, exactly the same time as a "#discover?" command uses.

This way to find devices also works nicely together with DHCP.

[gby]

HKJ,

The LXI Discovery screen looks great.  It seems limiting to only run it when the device list is empty.  When working on a multi-device setup and having trouble with one device connecting it would be good to be able to run LXI Discovery manually.  Right now I use a third party tool to do this function.  It would be annoying to delete properly connecting device entries to get the device list empty just to run LXI discovery again.  Any reason not to have a button on the Load devices tab to run LXI discovery on demand?

Also, thanks a lot for the LXI communications fix.  The Tektronix DPO3014 connection seems to be working great now.   

[gby]

I am working on a device file for Keithley 2260B series of power supplies.  But, I am having a problem to get all the model numbers to show up.  I have stared at this device file for a while now and I can't figure out why only 11 of the 12 defined devices show up in the Load devices Search socket drop down.  Specifically the last device (Keithley 2260B-250-13) at the end of the #metadef list after the #meta statement does not show up. 

Can anyone spot what I am doing wrong in the attached work in progress device file?

PS  I know the file at least sort of works since it connects to a Keithley 2260B80-13 and talks fine.

[HKJ]

The LXI Discovery screen looks great.  It seems limiting to only run it when the device list is empty.  When working on a multi-device setup and having trouble with one device connecting it would be good to be able to run LXI Discovery manually.

Use #Discover? on the command line, that will show if the device is online and supported. You will, of course, have to search manually in the supported device list and add the device.

[HKJ]

I am working on a device file for Keithley 2260B series of power supplies.  But, I am having a problem to get all the model numbers to show up.  I have stared at this device file for a while now and I can't figure out why only 11 of the 12 defined devices show up in the Load devices Search socket drop down.  Specifically the last device (Keithley 2260B-250-13) at the end of the #metadef list after the #meta statement does not show up. 

Can anyone spot what I am doing wrong in the attached work in progress device file?

Nothing after a #meta will show up, you need a empty #metadef to use it directly.
I.e. use:

#metadef
#meta

And it will be included

But #replaceText only works in a #metadef, i.e. you must also move them

#metadef
#replaceText MaxVoltage 250
#replaceText MaxCurrent 13.5
#replaceText MaxWatt 1080

#meta

[gby]

HKJ,

Thanks for the clarification.  I guess I never really understood this subtlety. I will have to go back and fix the Owon ODP series device file that I did a while ago and re-submit again.

[No.15]

Hate to ask but I am a total non programmer at this point, trying to learn

I have a riden power supply and I would like to charge some lifepo batteries and log the results.  Can someone point me in the right direction to get started?
Sorry for basic question.