Program that can log from many multimeters.

[HKJ]

Can you think of anything else I could do to help get debug information on this issue?

I do not have any good ides, maybe it is because I close the communication port very fast after the last command.
Try replacing the .jar file with this one: http://lygte-info.dk/pic/Projects/TestController/TestController.jar
It has a short delay from the last command until it closes the port.

Messtechniker may also like this version, it has a small charge to the chart.

[gby]

I do not have any good ides, maybe it is because I close the communication port very fast after the last command.
Try replacing the .jar file with this one: http://lygte-info.dk/pic/Projects/TestController/TestController.jar
It has a short delay from the last command until it closes the port.

Messtechniker may also like this version, it has a small charge to the chart.

I tried this .jar version and got the same result.  In normal mode clicking reconnect works every time.  Clicking reconnect in debug mode fails every time.  dos window debug result was the same as before.  On the reconnect attempt the receive times out and nothing is gotten from the device query.

So, the reconnect function is doing something different in debug mode than in regular mode.  Or the communications buffer works slightly differently and debug mode remembers something it shouldn't from the first activity?

By the way, I found this issue while trying to debug a script that uses the #Device command to close active connections followed by #Device <name> <IP address> to connect.  When in debug mode running the script once connects and running it a second time it does not connect just like the reconnect button.  Again, no Java errors in dos window.

Also, I have a question.  In a script you can use the #Device <name> <IP address> command to connect to a device.  Can you do #Device <name> and leave out the IP address?  My thought is that if the device is already in the Load devices tab with an address it would default to that address.  But, it doesn't seem to work that way.  My challenge is that I am developing a test script in lab one and sending it to lab two to also use.  The IP addresses will be different.  You can edit the script, but I thought if the devices were in the Load devices tab why not leave the IP addresses out of the script to simplify use?

[HKJ]

I tried this .jar version and got the same result.  In normal mode clicking reconnect works every time.  Clicking reconnect in debug mode fails every time.  dos window debug result was the same as before.  On the reconnect attempt the receive times out and nothing is gotten from the device query.

So, the reconnect function is doing something different in debug mode than in regular mode.  Or the communications buffer works slightly differently and debug mode remembers something it shouldn't from the first activity?

I will have to look a bit more at it.

Just a note: You are aware when I say DOS window, I do not mean the log window. The Java error messages do not go into the log window, but only to the DOS/console window. They also do this without debug mode, but because there usually is no visible DOS/console window they are not seen.

Also, I have a question.  In a script you can use the #Device <name> <IP address> command to connect to a device.  Can you do #Device <name> and leave out the IP address?  My thought is that if the device is already in the Load devices tab with an address it would default to that address.  But, it doesn't seem to work that way.  My challenge is that I am developing a test script in lab one and sending it to lab two to also use.  The IP addresses will be different.  You can edit the script, but I thought if the devices were in the Load devices tab why not leave the IP addresses out of the script to simplify use?

It is supposed to work without the address and I can see it checkmarks the device on my machine.

[gby]

I will have to look a bit more at it.

Just a note: You are aware when I say DOS window, I do not mean the log window. The Java error messages do not go into the log window, but only to the DOS/console window. They also do this without debug mode, but because there usually is no visible DOS/console window they are not seen.

Yes, I know what you mean by DOS window.  I copied all the text from the DOS box into the first post on this problem.  Just now I repeated the issue, cut and pasted DOS box and TestController log window into two separate files and then did a file compare.  Except for a couple of space character differences they were identical.

It is supposed to work without the address and I can see it check marks the device on my machine.

Yes, I see now that #Device <name> without IP address does work as desired.  However, even in normal mode if I run the same script twice there is no connection the second time.  I have attached my test script.

[HKJ]

I wonder if it is timing issues, try a script with:

#CloseAll
#Device
#Reconnect
#WaitReady
#delay 5
#Device "Kollmorgen AKD1G Servo"
#Reconnect
#WaitReady

It will unload all devices, wait 5 seconds and then load the selected device.
If this fails it is probably not a timing issue, but something else.

[gby]

I wonder if it is timing issues, try a script with:

#CloseAll
#Device
#Reconnect
#WaitReady
#delay 5
#Device "Kollmorgen AKD1G Servo"
#Reconnect
#WaitReady

It will unload all devices, wait 5 seconds and then load the selected device.
If this fails it is probably not a timing issue, but something else.

Using the .jar version you linked a couple of post ago (says V1.10) I did the following:
0. Started TestController and made sure nothing is checked in Load devices tab.  Closed TestController.
1. Started TestController in debug mode.
2. Loaded a script with only the contents you list above.
3. Ran the script and everything worked.
4. Waited like 30 seconds doing nothing.
5. Ran the script again and it did not connect.

Attached is the complete contents of the debug DOS window from the above sequence.  Please note that even with the #delay commented out this script connects properly the first time.

[Messtechniker]

Thanks for making the chart settings stick in V1.10.

When manually sweeping the Siglent I get those nasty
steps in my graphs instead of completely smooth curves.
What can I do to get rid of those?

Sweeping is initially in increments of 1000 Hz,
later on in 10000 Hz increments and slow enough.

The unit under test is a small 12 dB transformer recovered from an old telephone.

[HKJ]

When manually sweeping the Siglent I get those nasty
steps in my graphs instead of completely smooth curves.
What can I do to get rid of those?

My first idea is to apply some smoothing.

[gby]

I wonder if it is timing issues, try a script with:

#CloseAll
#Device
#Reconnect
#WaitReady
#delay 5
#Device "Kollmorgen AKD1G Servo"
#Reconnect
#WaitReady

It will unload all devices, wait 5 seconds and then load the selected device.
If this fails it is probably not a timing issue, but something else.

Using the .jar version you linked a couple of post ago (says V1.10) I did the following:
0. Started TestController and made sure nothing is checked in Load devices tab.  Closed TestController.
1. Started TestController in debug mode.
2. Loaded a script with only the contents you list above.
3. Ran the script and everything worked.
4. Waited like 30 seconds doing nothing.
5. Ran the script again and it did not connect.

Attached is the complete contents of the debug DOS window from the above sequence.  Please note that even with the #delay commented out this script connects properly the first time.

HKJ,

I went back and tried all the recent versions of TestController I had to see when the change happened.

   V1.02, V1.04, V1.06 all reconnect properly in Debug mode every time I click Reconnect button

   V1.09 and advanced copy of V1.10 both connect once in Debug mode by every time I click Reconnect button the request times out and does not connect

I do not have versions between V1.06 and V1.09 to try and narrow it down further.  Somewhere between V1.06 and V1.09 something changed in how the socket receive buffer acts during a reconnect.  Hopefully this helps narrow it down some.

[HKJ]

I hope I found the problem.
Try using the above link again, it is supposed to give V1.11 (I may take a bit time due to caching at my hosting service).

[gby]

I hope I found the problem.
Try using the above link again, it is supposed to give V1.11 (I may take a bit time due to caching at my hosting service).

You found it.  I can now reconnect over and over again in this V1.11 like with previous versions.

I know how difficult it can be to fix problems you can't see in your own setup so thank you very much.

Now back to writing fancier and more productive scripts   

[HKJ]

A few post back I was asked why not use the sound card and I decided to look at it.
First as output and I have it nearly ready as a generator, but I am wondering?

Is there any reason to support triangle/square wave output? The bandwidth is limited and it will only work at rather low frequencies (My sound card with 96k sample rate can handle about 30kHz, not anything like sampleRate/2).

I will be supporting a logarithmic sweep directly.

[Messtechniker]

Good news.

I have to date never used triangle or square
from sound cards because of the frequency
response limitations.

[HKJ]

V1.12 is up
This fixes a bug and makes it possible to use the computers sound card as a frequency generator.
   Added: Sound card output device, i.e. sound card can be used as a frequency generator.
   Fixed: Did not close devices on reload
   Changed: Chart X axis do not revert to time each when logging is started.

To find it in the device list filter on sound.



Manual for this: http://lygte-info.dk/project/TestControllerSoundcard%20UK.html

[Messtechniker]

Just tested the sound card output. Works well. 
But I have two usability problems when sweeping in chart doing frequency response graphs.
Because the sweep is continuous, sweeping at the end needs to stop at the highest frequency as otherwise the chart is messed up by the frequency returning to the start frequency or logging needs to be stopped manually just before reaching the highest frequency. Difficult in Chart because one has to return to "Command" to prevent this frequency flashback messing up the graph.

The solutions to this might be:
1.) Have a log start/stop button in a separate floating window (would also be useful in Chart when interrupting logging to setup something).
and
2.) Sweep Start/Hold/Stop Buttons in the sound card popup.
or let a single sweep stop at the end maintaining the highest frequency.

[HKJ]

But I have two usability problems when sweeping in chart doing frequency response graphs.
Because the sweep is continuous, sweeping at the end needs to stop at the highest frequency as otherwise the chart is messed up by the frequency returning to the start frequency or logging needs to be stopped manually just before reaching the highest frequency. Difficult in Chart because one has to return to "Command" to prevent this frequency flashback messing up the graph.

You can easily clean the chart by typing the sweep time in the "Last sample to display" field.
I have been thinking about it and may implement some sort of "arm" command that will run a single sweep when logging is started.

[gby]

I played with the #SaveChart script command in V1.12.  When I do something like:

   #SaveChart "myfile"

I get the file myfile.png with a picture of the chart saved in the ...\Documents\TestController directory.  But, I also get a second file named myfile.txt that seems to be a copy of the TestController log window up to the #SaveChart command in the script but not after.  Was it your intention that #SaveChart saves the .png picture as well as the log window with the one command?

What sets the picture size for the #SaveChart command?  I looked on the web site for some documentation on possible arguments for the #SaveChart command and was not able to find it.  I seem to always get 500 x 250 pixel.

Lastly, I don't seem to get the full chart in the saved picture.  My script does:

Code: [Select]

#log 0.1

#while (FtLow<50)
=FtLow=FtLow+2
#delay 1
#endwhile

#log 0

#SaveChart "myfile"which generated the attached myfile.png showing only 0.0s on the x-ais.  I would expect all 6 sec on time axis but it only seems to get the first logged data point or none.

After the script is done if I manually type #SaveChart "foo", run that one line, then the resulting picture seems fine with the full 6 sec.  Am I using the #SaveChart command incorrectly/is there a trick to getting the graph to be the full time span inside a script?

[HKJ]

I played with the #SaveChart script command in V1.12.  When I do something like:

   #SaveChart "myfile"

I get the file myfile.png with a picture of the chart saved in the ...\Documents\TestController directory.  But, I also get a second file named myfile.txt that seems to be a copy of the TestController log window up to the #SaveChart command in the script but not after.  Was it your intention that #SaveChart saves the .png picture as well as the log window with the one command?

My code need a couple of "break", it is fixed from next version.

What sets the picture size for the #SaveChart command?  I looked on the web site for some documentation on possible arguments for the #SaveChart command and was not able to find it.  I seem to always get 500 x 250 pixel.

If you are online the documentation is supposed to be below the command line in the help window.
You can directly write the file size in pixels after the filename:

#savechart test 2000 1000

When nothing is specified it used the first entry in the size list, you can change that on the configuration page.

Lastly, I don't seem to get the full chart in the saved picture.  My script does:

Oops, I am missing a update of the chart to include the newest data, before I save it. It will be fixed in next version.

[PushUp]

...just brainstorming...

Is it a good idea, being able to add an event into the chart like a small flag, which opens a text box when touching with the mouse? For example, you measure something, than change a parameter and you want to add this info into your chart, so that you have an explanation for the different outcome, being directly connected to your saved csv-file, for later use?

As far as saving "csv" is concerned:

When I want to save the content from "Table" into a csv-file, the format "csv" is already chosen at the bottom of the window, but you have to add "csv" manually to your file name; not a big deal, but I have the impression, that this was not necessary in early versions? But maybe I am wrong or it is a linux issue?!

Thanx! 

[HKJ]

...just brainstorming...

Is it a good idea, being able to add an event into the chart like a small flag, which opens a text box when touching with the mouse? For example, you measure something, than change a parameter and you want to add this info into your chart, so that you have an explanation for the different outcome, being directly connected to your saved csv-file, for later use?

That would requiring saving multiple files, i.e. make something like a "save project" option. I have been thinking about it, but have not decided if I want to go there.

As far as saving "csv" is concerned:

When I want to save the content from "Table" into a csv-file, the format "csv" is already chosen at the bottom of the window, but you have to add "csv" manually to your file name; not a big deal, but I have the impression, that this was not necessary in early versions? But maybe I am wrong or it is a linux issue?!

It has to do with points. If the filename contain a point ".", it assumes you have specified an extension and do not adds it own.

[Messtechniker]

You can easily clean the chart by typing the sweep time in the "Last sample to display" field.

Really cleans up the chart nicely.

By the way: got a HO732 LAN/USB Interface for my HMO1022.
No dropouts any more when querying via LAN now:-+

[HKJ]

You can easily clean the chart by typing the sweep time in the "Last sample to display" field.

Really cleans up the chart nicely.

And I have added a single sweep option to the sound card output and also optimized the code significantly, it was using way to much processor power. I will probably publish the new version tomorrow.

The single sweep option is an extra "on" button that will arm the single sweep (Outputs the starting frequency), start logging or press the button again to perform the sweep

[HKJ]

By the way: got a HO732 LAN/USB Interface for my HMO1022.
No dropouts any more when querying via LAN now:-+

What HMO? I do not have any HMO!
Will you share the definition?

[Messtechniker]

My definitions for the HMO1022 scope (USB-virtual comport/RS232 i.e HO720 interface plug-in module) and (USB-virtual com port/LAN i.e. HO732 interface plug-in module) are quite rudimentary and need a bit of polishing and testing at the moment.
The definitions currently only cover Level and Frequency on channel 1. No popups yet.  If still interested, I would provide the definitions in a couple of days or so.

[HKJ]

My definitions for the HMO1022 scope (USB-virtual comport/RS232 i.e HO720 interface plug-in module) and (USB-virtual com port/LAN i.e. HO732 interface plug-in module) are quite rudimentary and need a bit of polishing and testing at the moment.
The definitions currently only cover Level and Frequency on channel 1. No popups yet.  If still interested, I would provide the definitions in a couple of days or so.

I do not know if other people are using the scope, but it cannot harm to include it in TestController.
Add a #notes with requirements for interface and a explanation of what it do.