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

[HKJ]

I have a script that I am devloping that seems to crash Test Controller/Java runtime every single time I run it.  More specfically there is a #while iteration loop and when that loop goes 59 times it crashes.  I can run the script once with iterations at less than 59 times.  If I then run it again in the same Test Controller session once the second run plus first run reaches 59 times Test Controller/Java run time crashes.

When it crashes the Java run time goes to high CPU and clicking to change something in Test Controller does nothing.  Even clicking the upper right close appliation X does nothing.  I have to force close Java run time.

I have no real idea.
One possible idea is that turning log on/off very fast may not give TC enough time to clean up.

[gby]

HKJ,

Thanks for the suggestion.  Adding #delay 0.25 just after the #log 0 command did not change anything.

I pulled Windows Task Manager up and watched the memory for Java.  It starts around 82 Meg and builds steadily upwards while running this #while loop.  Once Java memory gets to somewhere between 311 and 315 Meg Test Controller freezes up and I have to force end the Java run time task.

What I find odd is that if I set the #while loop to less iterations than crashing Windows Task Manager shows that the built up memory usage does not drop.  I can clear the screen, load another script, start logging manually and nothing I tried would lower the memory usage.  It is acting like there is a memory leak that just builds up.  The only way I have found to lower the memory usage is to restart Test Controller.

I will keep playing around with this issue to see if I can make a simple example to show you.

If the problem is a memory leak type issue is there anything I can do diagnostically to help narrow it down?

[gby]

HKJ,

I made a simplified test case that should show the problem on your system unless there is something unique on my PC.  Simplifying to just one socket device connected (Aim Tti CPX400DP in my case) when I run the below simple #log on, #log off script Test Controller does crash.

Code: [Select]

#logcmds 0
= var n = 0
#while ( n < 50)
   #log 0.1
   #delay 0.75
   #log 0
   #delay 0.25
   = "Point: "+n
   = n = n + 1
#endWhile

On my PC Task Manager shows Java run time memory usage steadily going up with each iteration.  Once you get to enough iterations Test Controller crashes.  With the fixed 50 iterations in the above script I find I have the Restore and Run again before it crashses.

Hopefully you can try this script and see the issue.  Perhaps others can try this script on their setups to see if they see the problem also.

By the way, I am running the lastest Test Controller Ver 3.48.

[HKJ]

HKJ,

I made a simplified test case that should show the problem on your system unless there is something unique on my PC.  Simplifying to just one socket device connected (Aim Tti CPX400DP in my case) when I run the below simple #log on, #log off script Test Controller does crash.

Code: [Select]

#logcmds 0
= var n = 0
#while ( n < 50)
   #log 0.1
   #delay 0.75
   #log 0
   #delay 0.25
   = "Point: "+n
   = n = n + 1
#endWhile

On my PC Task Manager shows Java run time memory usage steadily going up with each iteration.  Once you get to enough iterations Test Controller crashes.  With the fixed 50 iterations in the above script I find I have the Restore and Run again before it crashses.

Hopefully you can try this script and see the issue.  Perhaps others can try this script on their setups to see if they see the problem also.

By the way, I am running the lastest Test Controller Ver 3.48.

Thanks, I will take a look at it tomorrow.

[HKJ]

V3.53 is up.
New devices, new functionality in TC and some bugfixes.
   Fixed: Sometimes switching log on/off from script could lock TC (Thanks gpy)
   Added: Color schemes to chart (Thanks Flash2b & KungFuJosh)
   Added: Digcreat XDM1041 DMM (Thanks gby)
   Added: GridPanel now has a option to reset panels and math separately (Thanks KungFuJosh)
   Updated: Siglent SDM4055A & Siglent SDM4055A-SC Bench DMM's (Thanks KungFuJosh)
   Added: Guildline 6560 Precision Resistance Calibrator (Thanks Cyclotron)
   Updated: Yokogawa 7552, 7555, 7563, 7562, 7561, 7551 Bench DMM's (Thanks Flash2b)
   Added: HP 6060B Electronic load (Thanks Cyclotron)
   Added: Agilent/Keysight E3640A, E3641A, E3642A, E3643A, E3644A and E3645A Power supplies (Thanks Cyclotron)
   Added/Fixed: Digital scale now has a color setting (Thanks Flash2b)
   Added: Atorch S1BWP Wi-Fi smart metering socket (Thanks akapuma)
   Added: HP E3631A PS (Thanks Cyclotron)
   Added: Ebyte ME31-XEXX0600, ME31-XEXX0800, ME31-XDXX0400, ME31-XDXX0800 PT100/K-thermocoupler 6/8 channel thermometer (Two have displays) (Thanks Flash2b)
   Added: Weirui TS85-A, TS85-B Thermometer and Humidity devices (Thanks Flash2b)
   Updated: HP E3632A, HP E3633A, HP E3634A PS (Thanks Cyclotron)
   Added: Chroma 63003-150-40, Chroma 63004-150-60 Electronic Load (Thanks Cyclotron)
   Fixed: GPIB network interface to allow multiple devices on one interface (Thanks Cyclotron)



A addition to TC is color schemes for the chart, it is found in the chart layout menu (Right click on chart).

A long standing issues has been fixed, now each GPIB interface can support multiple devices (If it is a good idea varies).

[gby]

HKJ,

Thanks for the new version.  I installed version 3.53 to try this new version.  Unfortunately, the log on/off from a script problem is still there on my machine.  I also note that manually doing logging on/off via the Commands tab Log button also slowly walks the memory usage up.

I then proactively updated my Java to latest version, rebooted my machine and tried again.  Same behavior.  Starting/stopping logging either via script or via the Commands Tab Log button increments Java run time memory usage up until around 312 Meg when Test Controller freezes.

Maybe the last fix you did for this bug accidentally did not make it into the V3.53 available via the web site download?  When I run it Configuration About button says 3.53 though...

[HKJ]

HKJ,

Thanks for the new version.  I installed version 3.53 to try this new version.  Unfortunately, the log on/off from a script problem is still there on my machine.  I also note that manually doing logging on/off via the Commands tab Log button also slowly walks the memory usage up.

I then proactively updated my Java to latest version, rebooted my machine and tried again.  Same behavior.  Starting/stopping logging either via script or via the Commands Tab Log button increments Java run time memory usage up until around 312 Meg when Test Controller freezes.

I tried your simple script before I fixed anything and TC locked up, I fixed that and have not seen a lockup after that.
But there is a memory issue. It puzzles me a bit, because Java do not leak memory, i.e. I must have some sort of list with the memory.
Note: My computers has lot of memory, i.e. a few GB in usage do not really matter for me (But it is still not supposed to happen).

Maybe the last fix you did for this bug accidentally did not make it into the V3.53 available via the web site download?  When I run it Configuration About button says 3.53 though...

It is in the release version.

[gby]

Yes, it is puzzling.  My computer has 32 GB of RAM so I don't think my machine RAM is an issue.

Is there anything I can do on my end to gather more information on what might be happening?

[HKJ]

Yes, it is puzzling.  My computer has 32 GB of RAM so I don't think my machine RAM is an issue.

I have one with 16GB and one with 64GB, TC do not lock up on either.

Is there anything I can do on my end to gather more information on what might be happening?

I will look at the memory issue, but if you have a script that locks up TC it is interesting.

[gby]

HKJ,

Exact same script as before still locks up TC on ver 3.53.  Just need to get over 59 iterations.

Code: [Select]

#logcmds 0
= var n = 0
#while ( n < 60)
   #log 0.1
   #delay 0.75
   #log 0
   #delay 0.25
   = "Point: "+n
   = n = n + 1
#endWhile
Like I said, on my computer log on, log off whether via script or via manual button steadily increase Task Manager listed memory for the Java process.

Question:  Are you running 32 bit or 64 bit Java on your machines?  My pc has 32 bit Java.  Per Google 32 bit Java limits heap to 4 GB.

[HKJ]

HKJ,

Exact same script as before still locks up TC on ver 3.53.  Just need to get over 59 iterations.

Code: [Select]

#logcmds 0
= var n = 0
#while ( n < 60)
   #log 0.1
   #delay 0.75
   #log 0
   #delay 0.25
   = "Point: "+n
   = n = n + 1
#endWhile
Like I said, on my computer log on, log off whether via script or via manual button steadily increase Task Manager listed memory for the Java process.

Like I said before: It do not, but it eats some memory. I have played a bit with a java heap analyzer and it is not really helping.

Question:  Are you running 32 bit or 64 bit Java on your machines?  My pc has 32 bit Java.  Per Google 32 bit Java limits heap to 4 GB.

I run 64 bit and have done for years.

[KungFuJosh]

My pc has 32 bit Java.  Per Google 32 bit Java limits heap to 4 GB.

Which Java install do you have running? JRE or JDK or?

[gby]

I have 32 bit JRE.  I suspect two things
   1.  If I change to 64 bit JRE my test case will run much longer.
   2.  With either 32 or 64 bit JRE Test Controller will increase memory usage with each cycle of log on/off.

When I have time I will un-install 32 bit JRE, install 64 bit JRE, re-test and report back.

[HKJ]

   2.  With either 32 or 64 bit JRE Test Controller will increase memory usage with each cycle of log on/off.

That is correct, with 10000 loops (log on/off for each loop) in your test (delays removed) script I got above 10GB of memory.
I hope I can find the issue, it will not affect standard use of TC, but may be a issues with some scripts where you restart the logging all the time.

[gby]

HKJ,

The relatively quick TC crashes on my pc were from using 32 bit Java JRE.  Using 64 bit Java JRE I just ran a lot more log on/off cycles than 32 bit Java with no crash.  But, the Java memory usage was going up and up even with 64 bit Java.

Using TC with 32 bit Java during a full day I used to get one or two crashes.  I suspect this problem was causing that.  Perhaps now with 64 bit Java I can go a whole day inside TC without a restart.

I then changed to a faster iteration time with 0.25 sec log time and 0.05 delay time with log off.  After 100's of cycles I got to around 8.6 GB Java memory usage and TC crashed.

Still seems there is a memory usage or memory leak issue going on...

FWIW, Just starting TC with 32 bit Java JRE used only 85 MB while just starting TC with 64 bit Java used 2010 MB.

[HKJ]

HKJ,

The relatively quick TC crashes on my pc were from using 32 bit Java JRE.  Using 64 bit Java JRE I just ran a lot more log on/off cycles than 32 bit Java with no crash.  But, the Java memory usage was going up and up even with 64 bit Java.

Using TC with 32 bit Java during a full day I used to get one or two crashes.  I suspect this problem was causing that.  Perhaps now with 64 bit Java I can go a whole day inside TC without a restart.

I then changed to a faster iteration time with 0.25 sec log time and 0.05 delay time with log off.  After 100's of cycles I got to around 8.6 GB Java memory usage and TC crashed.

Still seems there is a memory usage or memory leak issue going on...

FWIW, Just starting TC with 32 bit Java JRE used only 85 MB while just starting TC with 64 bit Java used 2010 MB.

It do not crashed on my machine, but the memory usage is there and I am looking for it.

On one of my computers it uses 700MB when started, it do not really mean anything. Java has its internal memory management and simply grab a thunk of memory when started and then gives it to the application as needed. In older versions of Java it would not grab more memory, but this has been changed.

[flash2b]

TestController — delay values above 9999 in [nnnn] are silently ignored

Found while building a store/recall sequence for a Yokogawa 7552.

A deviceWrite string can carry an inline delay as [nnnn]. Up to four digits it works as documented. Above that TC does not wait at all. It does not clip to 9999, it does not log a Delay: line, and it does not report an error.

Trace, RS-232C:

111653.53ms YOKO7552_RS: Tx <[100250]>
111656.11ms YOKO7552_RS: Tx <trigExecute>
113769.38ms YOKO7552_RS: Delay: 2000ms

2.6 ms between [100250] and the next command, and no Delay: line for it. The 2000 ms delay later in the same script logs and holds correctly.

Why it matters: the delay is computed, not typed. The 7552 stores into a 1000-record ring, so with a negative data head the meter must fill the whole buffer before it will accept a trigger — a wait of 1000 × sampling interval. At SI 8 ms that is 8000 and works. At SI 10 ms it is 10000 and the wait disappears.

Measured, to show the wait is real: SI 100 ms, data head -10, 20 readings takes 1:42 on the stopwatch. 1000 × 100 + 20 × 100 = 102 s. The definition needs to wait that long and currently cannot express it.

Nothing in the UI shows the failure — the command just returns early, and the next command goes out while the meter is still busy.

Clipping to the maximum would be fine. An error would be better. Silent is the problem.

Question while I am here: is chaining [9999][9999] supported as a workaround, and do the delays accumulate?

[HKJ]

TestController — delay values above 9999 in [nnnn] are silently ignored

Correct, they are not recognized as delay values.

Question while I am here: is chaining [9999][9999] supported as a workaround, and do the delays accumulate?

Yes, you can chain them and put 1/2 or 1/4 value in each of them.