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

[flash2b]

Dear HKJ,

I have made a definition for the Eletechsup 10IOA01, 10IOA02, 10IOA04 and 10IOA08 relay modules supporting both Digital Input and Digital Output.

These are very nice relay modules built around the MindMotion MM32F0010A1T ARM Cortex M0 48MHz micro controller. The module uses high quality relays and other components. It is the second relay definition that is supported by TestController and it has been extensively tested both in TC as well as with the Battery Test popup.

(Attachment Link)

It supports both Digital Traces for the input and the output and has a setup menu. It supports setting the relation between input and output as well.

For all that want to use it, you need a USB RS485 adapter to connect this module. There are many available in different price brackets, like the ones I use (purple)  https://nl.aliexpress.com/item/1005010389167788.html and https://nl.aliexpress.com/item/1005008276085365.html The chipset does not matter as long as it works in the OS you are running TC on. These adapters work for all my Eletechsup definitions.

These one also look good: https://nl.aliexpress.com/item/1005007318074871.html , https://nl.aliexpress.com/item/1005008321643522.html and https://nl.aliexpress.com/item/1005008083676644.html

[HKJ]

I have tried to be a bit more detailed about #interface definitions:

http://lygte-info.dk/project/TestControllerInterfaceDefinitions%20UK.html

I plan on linking to this from the current #interface explanation.

Comments welcome.

[Benleentje]

I do not know for sure but you can just use #port <port number>. In the connected tab of TC you should use the address.

That it is Mobus_RTU over TCP/IP should not matter writing the definition commands.

For the TCP/Ip connection there can be a overhead with additional data. This is to indentify the unit in the network and says witch packet data it is. The overhead is 11 byte's and it sends the actual RTU command. Modbus rtu over TCP/ip will only send the RTU command.

[flash2b]

I have tried to be a bit more detailed about #interface definitions:

http://lygte-info.dk/project/TestControllerInterfaceDefinitions%20UK.html

I plan on linking to this from the current #interface explanation.

Comments welcome.

This is a welcome addition to the documentation 

I am working on a #interfaceType Power for an AC/DC Power meter which can output multiple values extra to the PS and ACPS. E.g. harmonics, powerfactor, frequency, efficiency etc.

Will that follow like PS and ACPS ?

Furthermore for #interfaceType LCR I written it wrongly for my Owon LCR2000 definition.

I propose something like this

#interfaceType LCR
#interface getMode
#interface getFrequency
#interface setMode
#interface setFrequency
#interface readValue 0 1 2
#interface readFrequency 3

May be adding an example will help like for a relay an actual definition is:

#interfaceType Relay Relay:2 Relay:3 Relay:4
#interface setRelays setOutput (value)
#interface getRelays setOutput?
#interface setRelay relayOutput(value?"on":"off") (channel)
#interface getRelay relayOutput? (channel)

You could also point to a definition that uses the #interfaceType instead of showing an example.

[HKJ]

I am working on a #interfaceType Power for an AC/DC Power meter which can output multiple values extra to the PS and ACPS. E.g. harmonics, powerfactor, frequency, efficiency etc.

Will that follow like PS and ACPS ?

A power meter is for reading value, i.e. it is nothing like a power supply.
One issue with a power meter is that what output values is available is often a configuration command, this makes it very difficult to implement #interface for.

Some I would expect:
#interface readPower
#interface readVoltage
#interface readCurrent
But most other will depend on configuration, the above may also, but please lock that part of the setup so it always works.

In my power meter I have defined options for a few predefined setting and not made it possible to fully customize what it is reading (The definition is not published, because the protocol has changed and I have not updated my firmware).

Furthermore for #interfaceType LCR I written it wrongly for my Owon LCR2000 definition.

I propose something like this

#interfaceType LCR
#interface getMode
#interface getFrequency
#interface setMode
#interface setFrequency
#interface readValue 0 1 2
#interface readFrequency 3

Most LCR meters has two output values, not 3. The readFrequency is not really necessary.
I have some plans about changing the setMode/getMode working, basically require standard names to be used and then the definition must translate them to names used for the actual device. That would make setMode/getMode useful for device independent programming.
For that I need to make a programming command that can do the translation fairly simple, probable something like: translate(value,"VDC,V-DC","VAC,V_AC",...) i.e. pairs of TC and device names, and providing a reverse translate function would make it easy to do both ways.
I know example was for a DMM, but it also applies to LCR meters.

May be adding an example will help like for a relay an actual definition is:

#interfaceType Relay Relay:2 Relay:3 Relay:4
#interface setRelays setOutput (value)
#interface getRelays setOutput?
#interface setRelay relayOutput(value?"on":"off") (channel)
#interface getRelay relayOutput? (channel)

You could also point to a definition that uses the #interfaceType instead of showing an example.

This is a good idea, but your definition is not the best example. It may be a well defined and working definition, but it is a bit on the complicated side to read with lot of sections.

[flash2b]

You are right about the LCR meter output.

My Owon LC2020 has 2 value output + 2 optional value output, total 4 values if all are "On", but minimal always 2.

Yes sections make everything hard to read, but I am a meta master because of you ! (the Eletechsup NT48xxx is a beast !).

Should an ACPS and an (AC)Power not always have a get/set Frequency ?

[flash2b]

On the commercial relay support, are you happy with the Eletechsup 10IOAxx ??

I got some complaints that it is uses a RS485 and not RS232. There are also RS232 relays available, two channel but all use proprietary protocols.

I can take a look but I do not want to really invest money (and time) in another module. I bought the 4 channel one to have some more flexibility than the minimum 2 channel needed for the Battery Test popup.

[HKJ]

You are right about the LCR meter output.

My Owon LC2020 has 2 value output + 2 optional value output, total 4 values if all are "On", but minimal always 2.

The idea is that interface makes it possible to make scripts and TC functions device independent and most LCR meters only have two values.

Should an ACPS and an (AC)Power not always have a get/set Frequency ?

For a supply yes, for a measuring device no, a measuring device need a readFrequency, not a set/get.
In interface set/get is for configuration, read is for the actual value.

[flash2b]

Most LCR meters has two output values, not 3. The readFrequency is not really necessary.
I have some plans about changing the setMode/getMode working, basically require standard names to be used and then the definition must translate them to names used for the actual device. That would make setMode/getMode useful for device independent programming.
For that I need to make a programming command that can do the translation fairly simple, probable something like: translate(value,"VDC,V-DC","VAC,V_AC",...) i.e. pairs of TC and device names, and providing a reverse translate function would make it easy to do both ways.
I know example was for a DMM, but it also applies to LCR meters.

The readFrequency is, imho necessary since a setting a frequency, the LCR will round it to the closest it can deliver. Most LCR meter use steps and are not continuous.

[HKJ]

On the commercial relay support, are you happy with the Eletechsup 10IOAxx ??

I am happy with your definition and the usb<->RS485 adapter is not very expensive.

I got some complaints that it is uses a RS485 and not RS232. There are also RS232 relays available, two channel but all use proprietary protocols.

I can take a look but I do not want to really invest money (and time) in another module. I bought the 4 channel one to have some more flexibility than the minimum 2 channel needed for the Battery Test popup.

I would not mind having RS232 based relays, but I will not ask you to do it, you already did a good relay definition.
One issue with RS232 today is that you have a couple of versions: 3.3V, 5V and real RS232 signal levels and they are not compatible. A relay for industrial applications would use real RS232, but cheaper version may use 3.3V or 5V interface or even implement USB serial directly on the board.

[HKJ]

Most LCR meters has two output values, not 3. The readFrequency is not really necessary.
I have some plans about changing the setMode/getMode working, basically require standard names to be used and then the definition must translate them to names used for the actual device. That would make setMode/getMode useful for device independent programming.
For that I need to make a programming command that can do the translation fairly simple, probable something like: translate(value,"VDC,V-DC","VAC,V_AC",...) i.e. pairs of TC and device names, and providing a reverse translate function would make it easy to do both ways.
I know example was for a DMM, but it also applies to LCR meters.

The readFrequency is, imho necessary since a setting a frequency, the LCR will round it to the closest it can deliver. Most LCR meter use steps and are not continuous.

I would expect reading the setting from the meter, would return the actual selected frequency, i.e. getFrequency

[KungFuJosh]

The idea is that interface makes it possible to make scripts and TC functions device independent and most LCR meters only have two values.

I have a driver slowly in the works (available time depending) for Hioki IM35XX series LCR meters, and they also have 4 parameters in addition to the other measurement details like frequency (which I assume should be easy to get anyway).

My LCR is the IM3570 Impedence Analyzer, so frequency sweeps are no problem for me on the device. However, having more options in TC to do frequency sweeps including multiple parameters would be cooler than the 2 parameter limit in the analyzer mode on the device.

Thanks,
Josh

[flash2b]

#interface getFrequency should return the value the LCR meter is using indeed.

It is that I always add the setFrequency to the #askValues since I need it while logging for the graphs.

So yes you are right. But setFrequency != getFrequency for stepped LCR meters.

For the USB relay you mean these? https://nl.aliexpress.com/item/1005004782739576.html

[flash2b]

The idea is that interface makes it possible to make scripts and TC functions device independent and most LCR meters only have two values.

I have a driver slowly in the works (available time depending) for Hioki IM35XX series LCR meters, and they also have 4 parameters in addition to the other measurement details like frequency (which I assume should be easy to get anyway).

My LCR is the IM3570 Impedence Analyzer, so frequency sweeps are no problem for me on the device. However, having more options in TC to do frequency sweeps including multiple parameters would be cooler than the 2 parameter limit in the analyzer mode on the device.

Thanks,
Josh

You could use the Param sweeper with more that one parameter right?

For my Owon LCR2020 I only added frequency to support sweeping but I was planning to add bias voltage as well. TC could do both with the param sweeper.

[HKJ]

#interface getFrequency should return the value the LCR meter is using indeed.

It is that I always add the setFrequency to the #askValues since I need it while logging for the graphs.

You probably mean getFrequency, but it is not necessary, you can put a checkmark in the log box for each device in param sweeper.

So yes you are right. But setFrequency != getFrequency for stepped LCR meters.

Yes and the user of the script or popup may better be aware of that.

For the USB relay you mean these? https://nl.aliexpress.com/item/1005004782739576.html

I did not mean any specific relays, but be careful, they may use HID.

[HKJ]

My LCR is the IM3570 Impedence Analyzer, so frequency sweeps are no problem for me on the device. However, having more options in TC to do frequency sweeps including multiple parameters would be cooler than the 2 parameter limit in the analyzer mode on the device.

TC can sweep up to 3 parameters on param sweeper, but this can take a very long time!

[flash2b]

For the USB relay you mean these? https://nl.aliexpress.com/item/1005004782739576.html

I did not mean any specific relays, but be careful, they may use HID.

You are right it is HID and controlled by https://github.com/darrylb123/usbrelay

[Gertjan]

I got some complaints that it is uses a RS485 and not RS232. There are also RS232 relays available, two channel but all use proprietary protocols.

I can take a look but I do not want to really invest money (and time) in another module. I bought the 4 channel one to have some more flexibility than the minimum 2 channel needed for the Battery Test popup.

I would not mind having RS232 based relays, but I will not ask you to do it, you already did a good relay definition.
One issue with RS232 today is that you have a couple of versions: 3.3V, 5V and real RS232 signal levels and they are not compatible. A relay for industrial applications would use real RS232, but cheaper version may use 3.3V or 5V interface or even implement USB serial directly on the board.

Ideal would be modules that do not need an additional interface. Usually the bench is cluttered enough

USB would be good. Ethernet would even be better, because we can do without additional virtual COM ports with their quirks.

Problem with RS485 is that people have to buy an additional interface, and have to learn about RS485. Which raises the barrier to start using these modules. So unfortunately less users....
While everybody using test equipment will have RS232 solutions at hand. And is (hopefully) experienced in setting up RS232.

regards, Gertjan.

[HKJ]

V3.00 is up
The main attraction is a automatic battery test, but there are a couple of new devices and some older devices that have been updated. Flash2b has done a lot, but he is not the only one.
   Updated JSerialComm to v2.11.4
   Modified: I have moved all automatic tests into a submenu in the popup menu.
   Added: Eletechsup 10IOA01, 10IOA02, 10IOA04 and 10IOA08 relay modules (Thanks flash2b)
   Added: Matrix APS-4000A, Matrix APS-4000B, Matrix APS-4000C, Matrix APS-7100, Matrix APS-7105, Matrix APS-7110, Matrix APS-7200, Matrix APS-7300, Matrix APS-7500 AC Supply in both ascii and hex versions (Thanks Benleentje)
   Added: Riden RD6024, RD6030 and RD6012P power supplies (Thanks Tjuurko)
   Update: Mastech, Tase, Tenma, UNI-T thermometers definitions now support #interface (Thanks flash2b)
   Update: Yokogawa, Hameg, Analogic DMM's definitions now support #interface fully (Thanks flash2b)
   Update: BSide I8 power supply (Thanks flash2b)
   Update: eTommens definitions now support #interface fully (Thanks flash2b)
   Update: Eletechsup definitions now support #interface fully (Thanks flash2b)
   Modified: Test interface to better handle devices with more than 8 channels
   Fixed: Right click to get a var name missed the . it is fixed now.
   Added: Eletechsup N4IOA01 current source, Eletechsup N4DAC02 voltage source, Eletechsup N4DBA06 volt/current source (Thanks flash2b)
   Fixed: Updated script language to support "Auto sync to left scale" in "Chart layout"
   Fixed: Updated script language to support "Log sync" in "Param sweeper"

Battery test means TC can automatic test a LiIon battery and generate curves and CSV files:

[flash2b]

Congratulations with this milestone of V3.00 of TestController.



Thank you for all your support, HKJ !!

[HKJ]

Congratulations with this milestone of V3.00 of TestController.

It has been through a lot of versions over time, I have not skipped since I started the version numbers, many of them has only been test releases.
The reason for the release today was because I wanted the 3.00 version number and with your relay definition battery test can be used by everybody.

[Benleentje]

Problem with RS485 is that people have to buy an additional interface, and have to learn about RS485. Which raises the barrier to start using these modules. So unfortunately less users....

Yesterday it took met 3 hour to connect a modbus tcp device to get in online. That was only talking to lantronix chip inside. Talking to the device itself is for tomorrow and needs more software.

So RS485 is not that difficult and ik think even easer dan RS232 with al his problems in settings and handshakes.

[HKJ]

I have been playing with the  Eletechsup NT18B07, but it is very slow!

Why not read all values in one go with:
holding? 0 7 /10

[flash2b]

The NT48A08 is much, much, much better.

Currently it is
#scpiCmd readTempCH1? holding? 0x00
:readmath: binConv(int(value),0,2,1)

Please explain what you mean with holding? 0 7 /10

Do you mean 1 scpiCmd reading all values at the same time and then #askValues readAll ?

[HKJ]

The NT48A08 is much, much, much better.

Currently it is
#scpiCmd readTempCH1? holding? 0x00
:readmath: binConv(int(value),0,2,1)

Please explain what you mean with holding? 0 7 /10

Do you mean 1 scpiCmd reading all values at the same time and then #askValues readAll ?

Yes, the holding? commands can have a count as the second parameter, that means it can read a lot of registers at once.
Some devices support it, others do not and there might be a limit on how many can be read at once.
Only requirement is that they are in sequence,
That is basically the same as the holding command can have multiple values after it and they will be packed into one message.