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

[HKJ]

I'm still trying to figure out how you can replicate the performance bug. That's the primary reason I changed from JDK to JRE; just to see if it had an effect. It didn't matter.

I also tried enabling a ton of measurements across multiple devices, and while that slowed down TC's response time, it didn't freeze.

It appears the freeze only occurs for me when the timing of the DynamicM[N] commands execute. So it seems it's the advanced scripting that causes trouble for TC.

It is a very hard area to find bugs in, because TC is multitasking to improve performance with calculations and/or many devices.
Basically anything related to obtaining standard measurements from devices and doing calculations on them is multitasking and runs in parallel. I.e. getting the measurement from 10 devices takes about the same time as getting a measurement from the slowest device.

Now that you have my full definition file, can you copy the dynamic measurement commands and use it with your dummy driver to try and replicate the performance issue?

Or maybe we can convince Batronix to loan you one of their Magnova scopes.

I am not going to replicate the Magnova in the dummy driver! The scope looks very nice, but I would not want into all the trouble with borrowing one.

[HKJ]

I received a 34410A today, so I'm working on a driver definition that will cover the 34410A and 34411A. I also have a definition for the DAQ6510 I'll eventually release when it's done.

I suppose they are fairly easy, there are already drivers for similar devices.
Or do you plan to do a more advanced driver for the DAQ6510

[KungFuJosh]

I received a 34410A today, so I'm working on a driver definition that will cover the 34410A and 34411A. I also have a definition for the DAQ6510 I'll eventually release when it's done.

I suppose they are fairly easy, there are already drivers for similar devices.
Or do you plan to do a more advanced driver for the DAQ6510

The 34410A is similar to the 34401A, but uses ethernet instead of serial. Those drivers will be similar, but I might do a little more advanced stuff with it. There were also some things the 34410A didn't like.

The DAQ6510 is more advanced than the others, so I will probably be doing something more fun with that since it's my favorite meter. We'll see though, I don't have as much free time as I'd like to mess with this.

Thanks,
Josh

[KungFuJosh]

I am not going to replicate the Magnova in the dummy driver!

You don't need to. The only thing you need is the setup commands for the measurements, the variables, and #pgm# stuff that goes with them. If I eventually have some time, maybe I'll try and set that up with the dummy driver and see what happens.

Thanks,
Josh

[perdrix]

I just installed NI-488.2 and NI_VISA an a laptop along with an NI-USB-HS+ adapter, I want to add a 3458A that's on GPIB port 22 but I can't see how to do that.

Sorry if this is a FAQ, but the prospect of looky through 300+ pages on posts isn't attractive.

Guidance greatly appreciated.

[HKJ]

I just installed NI-488.2 and NI_VISA an a laptop along with an NI-USB-HS+ adapter, I want to add a 3458A that's on GPIB port 22 but I can't see how to do that.

Sorry if this is a FAQ, but the prospect of looky through 300+ pages on posts isn't attractive.

Guidance greatly appreciated.

TC do not use the VISA interface driver, it uses its build in connection capabilities. But it do not support NI-488.2

[perdrix]

So you are saying that you don't support the NI GPIB-USB adapters? 

Well that's one heck of a big limitation.  Can I work round this by installing the HP stack as a secondary stack?

David

[HKJ]

So you are saying that you don't support the NI GPIB-USB adapters? 

Well that's one heck of a big limitation.  Can I work round this by installing the HP stack as a secondary stack?

It is more the issue that I do not support the installed driver.
You can go to the "Load devices" tab and press the GPIB button, there you can see a list of support GPIB interfaces, it is fairly limited and mostly based on Prologix.
For me to support other interfaces I need the interface and documentation for it and it must not use USBTMC.
TC supports network and (virtual) serial ports, they work across platforms.

[perdrix]

I installed the Keysight IO libraries and I still can't see the device.

NI and Keysight adapters have to be the most common GPIB adapters on the planet.

It seems rather a huge limitation that you don't support them.  This tool looked ideal for what I need to do, but it seems I can't use it which is a great shame.

David

[KungFuJosh]

I installed the Keysight IO libraries and I still can't see the device.

NI and Keysight adapters have to be the most common GPIB adapters on the planet.

It seems rather a huge limitation that you don't support them.  This tool looked ideal for what I need to do, but it seems I can't use it which is a great shame.

David

You could get one of the supported GPIB adapters. 

[Gertjan]

I installed the Keysight IO libraries and I still can't see the device.

NI and Keysight adapters have to be the most common GPIB adapters on the planet.

It seems rather a huge limitation that you don't support them.  This tool looked ideal for what I need to do, but it seems I can't use it which is a great shame.

David

Hi Perdix,

This tool is ideal for a lot of measurement and logging applications! Especially with a 3458A.
Before TestController I messed with flaky Excel macros and other home-brew software for some logging functionality for the 3458A. Still needed hundreds of Mega bytes of VISA layers, and the added software cluttering.

NI and Keysight are popular in commercial environments. The expensive GPIB adapters, and required VISA layer are no problem for commercial use. Mostly this will be embedded in custom measurement software.

The Prologix concept on the other hand is very popular in the amateur world. No VISA layer or "stacks" required. You just address the GPIB adapter  directly on it's serial (USB) port.
AR488 is a very popular Prologix clone. It is very compact, and you can build it for under 10 Euro / Pound / Dollar:


IMG_8528_AR488_Pro-Micro_GPIB-USB_adapters_GJM-2000pix.jpg

AR488 is just an programmed Arduino Nano or Promicro, with a GPIB connector and a small interconnecting PCB. (AR488 Github)
With these small GPIB adapters it is attractive to use one on the back of each device. No more thick and cumbersome GPIB cables either
Strongly recommended!

regards, Gertjan.

[HKJ]

NI and Keysight are popular in commercial environments. The expensive GPIB adapters, and required VISA layer are no problem for commercial use. Mostly this will be embedded in custom measurement software.

TC is designed for easy setup and use, without needing a dedicated measurement computer (I you want one, use a old laptop or a rasberry pi) with specialized software installed.

I would like to support more interfaces, but there is some issues.

[KungFuJosh]

NI and Keysight are popular in commercial environments. The expensive GPIB adapters, and required VISA layer are no problem for commercial use. Mostly this will be embedded in custom measurement software.

TC is designed for easy setup and use, without needing a dedicated measurement computer (I you want one, use a old laptop or a rasberry pi) with specialized software installed.

I would like to support more interfaces, but there is some issues.

Considering that you provide the software and support for free, I think it's simply amazing what you've done with TestController. It's lightyears beyond many commercially available products, including some that come with hefty subscriptions.

So, anyways... Thank you.

[KungFuJosh]

Here's the definition for the Agilent 34410A and 34411A.

I tested it, but not extensively. If anybody has one to try it with, let me know if you have any trouble.

Thanks,
Josh

[HKJ]

Here's the definition for the Agilent 34410A and 34411A.

I tested it, but not extensively. If anybody has one to try it with, let me know if you have any trouble.

I have added them, thanks.

[Pukker]

Like to share my latest Batterytest scripts.
Modification mostly cosmetic.
Added autosaving the Log, the Graph and CSV(filtered) files.
(this for starting the test and let the computer do the job)
Added calculation for individual Cells in batterypacks.

@HKJ, should it be possible to eliminate Powersaving mode on a Windows system?
Now I use don't sleep program for this.

[Pukker]

In post 3351 I've mentioned that the ACS712 module has some noise.
That is not the problem, the noise is coming from the ADC10F103C module I used to connect the ACS712.
ADC10F103C has some noise.

[KungFuJosh]

On the Scales for chart page, if Min/Max columns are changed to Center/Span, the bottom control row still says Min/Max (between Auto bottom step and the Remove button), and doesn't work correctly with Center/Span.

*rst should be removed from the SDM3000X series DMM finalcmd. It messes up user calibration along with other settings that don't need to be touched when exiting TC.

Thanks,
Josh

[HKJ]

Like to share my latest Batterytest scripts.
Modification mostly cosmetic.
Added autosaving the Log, the Graph and CSV(filtered) files.
(this for starting the test and let the computer do the job)
Added calculation for individual Cells in batterypacks.

Update the webside.

@HKJ, should it be possible to eliminate Powersaving mode on a Windows system?
Now I use don't sleep program for this.

It is possible, but I do not know how and if it can be done from Java.

[HKJ]

On the Scales for chart page, if Min/Max columns are changed to Center/Span, the bottom control row still says Min/Max (between Auto bottom step and the Remove button), and doesn't work correctly with Center/Span.

As far as I can see it works correctly. Yes it stays in min/max and sets the min/max values, that is then translated to center/span and shown in the column.

*rst should be removed from the SDM3000X series DMM finalcmd. It messes up user calibration along with other settings that don't need to be touched when exiting TC.

Are there any other that have comments on this?

[Gertjan]

*rst should be removed from the SDM3000X series DMM finalcmd. It messes up user calibration along with other settings that don't need to be touched when exiting TC.

Are there any other that have comments on this?

In general, it is common practice, and a good idea, to reset the meter to it's default settings at the end of a session.
This way one finds the meter in a default, known state when used next time. And errors because of an overlooked leftover setting somewhere are prevented.

That is why in all my TC configuration files the instrument is set to default settings in #finalcmd.

That said, it is a bit stupid of Siglent to provide user calibration settings, and have them erased with the common *RST "set to defaults" command...

A workaround would be to replace *RST with a series of SCPI configuration commands with the same functionality.
This way the DMM is set to the same default state as *RST would do, but one can leave the unwanted part out.
It would be functional the same as *RST, but leaves the custom calibration in place.

In the end it is the call of the writer of the configuration file how to handle this. It is his script, written with his knowledge and insights.
But one is always free to make a locally used adjustment.

regards, Gertjan.

[KungFuJosh]

In general, it is common practice, and a good idea, to reset the meter to it's default settings at the end of a session.
This way one finds the meter in a default, known state when used next time. And errors because of an overlooked leftover setting somewhere are prevented.

This is certainly true for some devices, but I don't find it to be a beneficial practice for the specific meters in question.

I generally leave my meters set a certain way, and I don't want those settings changed based on logging software usage. For a meter like those in the SDM series, where all meaningful settings are shown on the screen, there's no real benefit to resetting anything. For me, it's a nuissance.

Yes, of course I've made different changes to my SDM definition. Others will want to do the same if they don't want to lose their preferred configuration.

IMO the default should not be destructive.

All that said, if somebody feels like they need the *RST included, they too can modify their definition file to include it.

Thanks,
Josh

ETA: 2 other things that annoy me that *RST changes: 1. it disables the screen save, and 2. it disables statistics. I don't want those changed either.

[HKJ]

ETA: 2 other things that annoy me that *RST changes: 1. it disables the screen save, and 2. it disables statistics. I don't want those changed either.

You know it is very easy to generate a configuration script in TC, at least if the settings is in the setup menus.

Two steps:
1) Use menu to configure the meter
2) Right click in log window and select "Generate script, Mode and setup", the script can be saved as a menu item and will perform the commands you just did.

[HKJ]

One extra note:

You can configure multiple devices in one go and TC can generate a script to either do it in sequence or in parallel (Optimize checked).

[Gertjan]

I generally leave my meters set a certain way, and I don't want those settings changed.....

A good definition should take into account all kinds of users, and offer optimum support for all use cases. Not please the specific preferences of a single user.

As said before, I think there is a solution to please (almost) everyone. It is what I would do, if I were the author of this definition:

A workaround would be to replace *RST with a series of SCPI configuration commands with the same functionality.
This way the DMM is set to the same default state as *RST would do, but one can leave the unwanted part out.
It would be functional the same as *RST, but leaves the custom calibration in place.

regards, Gertjan,