Program that can log from many multimeters.

[klausES]

Perhaps it would help to avoid this, but in any case it would clarify if the uploaded zip name ends with Vx.xx

[HKJ]

Perhaps it would help to avoid this, but in any case it would clarify if the uploaded zip name ends with Vx.xx

Then I would have to modify the webpage each time I made a new version and that would have the same problem with caching.

[MikeLud]

HKJ,

What about keeping the file on something like GitHub, I was going to say what about attaching the file to the post but the size is past the 5,000 KB limit

[HKJ]

What about keeping the file on something like GitHub, I was going to say what about attaching the file to the post but the size is past the 5,000 KB limit

I have never gotten around to learn github, but I do have more than TestController that could benefit from it.

[masterx81]

In some of my old equipment I found a PrologixEthernet interface, with this as test I expect to make PrologixUSB, PrologicEthernet and AR488 interfaces. I will first be able to test the AR488 interface when I get a cable.

2. The National Instruments GPIB controllers are also popular. One that is frequently mentioned is  the NI-GPIB-USB-HS. I have one that you are welcome to use for development, though shipping from the States to Denmark is not ideal.

With USB interfaces I can only handle the types that uses a virtual serial port. What do this interface do?

3. The Prologix and NI adapters for GPIB-USB would have to be plugged into the machine running TestController in order to access the USB port. Any plans to support **remote** GPIB adapters? That is, having TestController run on a network machine rather than on the machine with the controller itself?

I suppose with the PrologixEthernet it may be possible to do some remote interface. I could also make a version of AR488 that uses a network connection (That would be fairly easy).
Then you only need a small driver that copies data directly between USB and a socket. I do not know if something like this already exists, but it would be easy to do in Java.

There are also National Instruments serial to GPIB adapters, like GPIB-232CT and GPIB-232CT-A.
Manual of the GPIB-232CT:
https://www.ni.com/pdf/manuals/320114.pdf
and manual of the GPIB-232CT-A:
https://www.ni.com/pdf/manuals/370898a.pdf

[HKJ]

There are also National Instruments serial to GPIB adapters, like GPIB-232CT and GPIB-232CT-A.
Manual of the GPIB-232CT:
https://www.ni.com/pdf/manuals/320114.pdf
and manual of the GPIB-232CT-A:
https://www.ni.com/pdf/manuals/370898a.pdf

Being serial they are probably fairly easy to implement, but I do not have any of them to test with.

[masterx81]

Have one of them (the older GPIB-232CT that can be found quite cheap on ebay), and a solartron 7150plus to try it out. This evening i connect all together and try to send something to it...

[masterx81]

Managed to get some values, reset the device, lock front panel, disable display, etc.
It's quite simple.
interesting gpib interface commands are:
clr x - reset the x gpib device
wr #n,x - send n bytes to x gpib device
rd #n,x - read n bytes from x gpib device

The solartron output a continuous stream of data every display update. It output a 7.5digit value 
But can be configured also for "single shot" measurement.
For example, the "wr #2,1<cr lf>M2" put the meter in ohm reading.
In continuous data stream can be buffered 65KB of data. The problem is that the buffer can be truncated everywhere.
So issuing a "wr #2,1<cr lf>T0" is disabled the continuous pooling, and can request a single value reading with "wr #1,1<cr lf>G" followed by "rd #10,1" gets 10 byte from the meter.
The meter manual can be found here:
http://bee.mif.pg.gda.pl/ciasteczkowypotwor/Solartron/Solartron_Schlumberger_7150_Plus_User_Manual.pdf

Seem quite easy to interface with this gpib adapter

[HKJ]

The manual looks like it the adapter is easy to use, but I cannot test it.
It also looks like you usually do not need the byte count.

TestController is not good at the streaming data from the Solartron, it works better when requesting a value.

[masterx81]

From the tests that i've done both wr and rd commands need the byte count. The wr isn't much a problem as you know what you are sending, the rd, in "single value" mode accept a bigger buffer than the actual data to receive. If you are waiting a max 10byte value, you can read 20 bytes without any problem.
Yes, the streamed data isn't much useful, better the ask/aswer mode. The multimeter at poweron os in T1 mode, bit can be switched back easily win the "wr #2,1<cr lf>T0" command, issued after when the connection is made, or after a reset of the device
With the "driver" needed to handle the gpib adapter, i can write myself the dmm definition.

---edit---

Reading the manual seem that in the wr command if you send a cr lf at the end of the command, the byte count can omitted.
For the read, the buffer size must be specified. But it's not a problem if the size is bigger than actual data, the result is sent anyway.

[HKJ]

If you want to test, I can make the definitions.
According to the manual it do not look like it need the count when writing, it is supposed to terminate on CR or LF.
The read look more problematic, because it will always transmit the number of bytes you requested, this means if I just request a large number of bytes, I will slow the communication down.
I want to keep the different drivers fairly compatible, this means I cannot add a byte count to the read command, but I could add a global gpib byte count, that is only used by some interfaces. The disadvantage is that it will be the same for all answers from that device. A default value for that count would have to be fairly high, like 50 or 100 bytes, to work with most devices.

[masterx81]

This evening i'll try the write command without byte count, followed by crlf, and confirm the manual.
For the read, a general configurable byte count i think that is ok, my meter send for example "+.0000000 V DC", so a buffer lenght of 15 will be ok for every range/type of measurement.
At best, a configurable byte count for every gpib address (as the same serial comm port can serve multiple gpib devices), so that if you have a device that output at max 15 byte, and the other 200 byte, the first one isn't slowed down.

[HKJ]

At best, a configurable byte count for every gpib address (as the same serial comm port can serve multiple gpib devices), so that if you have a device that output at max 15 byte, and the other 200 byte, the first one isn't slowed down.

Yes, it would be for separate for each device, then main GPIB class already has code to keep separate settings for each device.

[masterx81]

I think that it work like a charm!
Doing a parametrized byte lenght for every command for a specified device seem way an overkill. If you have a 6.5 digit meter, most of the times it output the same byte count, there isn't the chance that it output for example a 200byte buffer.
Different thing is if you connect for example a scope, that you can receive a single value or maybe a whole waveform, but this isn't the case.

I can do all the needed tests. The only problem is that by now i have only the solartron with gpib, so i can't test the interface with other devices (or the meter with other interfaces). I plan to use an usb to rs232 with it, but by now, for testing, i'm using a true com port.

[HKJ]

A completely untested version of NI interface: http://lygte-info.dk/pic/Projects/TestController/TestController.jar

You can use:
#gpibReadCount
in the device definition, to specifiy how many chars to read.
You will have to use the ascii type definition for the Solartron.

[masterx81]

Thanks! This evening i'll try it!

[masterx81]

With this simple starting definition:

Code: [Select]


#idString SOLARTRON,7150PLUS,
#name Solartron 7150Plus
#handle 7150PLUS
#driver SingleValue
#port GPIB
#gpibReadCount 15

; A list of possible column name with unit and formatter (SI, Time, Int, D0..D6)
#value VoltageDC V si V DC

#askValues G

#interfaceType DMM
#interface readValue 0


; Initial commands to meter when establishing connection
#initCmd  T0

I get only

Code: [Select]

;; Start thread for: National Instruments GPIB-232CT A:1 - Solartron 7150Plus
;; Stopping thread for: National Instruments GPIB-232CT A:1 - Solartron 7150Plus

I'm sure to have made a mistake 

[HKJ]

I'm sure to have made a mistake 

Have you done the GPIB setup correctly?

On the GBIB popup you need to define serial port and baudrate.
On the device list you need a reference to the GPIB driver (i.e. the id) and the GPIB address, it can be something like "A:5"
For GPIB device with id A and GPIB address 5.

And do not use a SingleValue driver, you need a Ascii driver. Look in the  FeelElecFY6x00-xxM.txt file for inspiration (You can ignore the #cmdSetup part). The Keithley2000.txt file is a simple dmm definition, but it missing the #scpiCmd's that is needed for Ascii devices.

[masterx81]

I was using singlevalue only for testing, as it's simpler than the scpi-like ascii syntax (that i need to study a bit  )
Yes, the configuration of the gpib is ok, set the adapter at A address, the dmm is at 1 gpib address, at correct com port/com speed.
I not know why, but after some close/reopening of the program i've got:

Code: [Select]

;; Start thread for: National Instruments GPIB-232CT A:1 - Solartron 7150Plus
;; COM9: Tx: <.> 0A
;; COM9: Tx: <TMO 1.0.> 54 4D 4F 20 31 2E 30 0A
;; COM9: Tx: <RD 15,1.> 52 44 20 31 35 2C 31 0A
;; COM9: Rx: timeout
;; COM9: Tx: <WRT 1.> 57 52 54 20 31 0A
;; COM9: Tx: <G.> 47 0A
;; COM9: Tx: <RD 15,1.> 52 44 20 31 35 2C 31 0A
;; 150PLUS: Tx <T0>
;; Found Solartron 7150Plus on National Instruments GPIB-232CT A:1
;; COM9: Rx: timeout
;; COM9: Tx: <RD 15,1.> 52 44 20 31 35 2C 31 0A
;; Mode reported: <>
;; COM9: Rx: timeout
;; COM9: Tx: <RD 15,1.> 52 44 20 31 35 2C 31 0A
;; COM9: Rx: timeout
;; COM9: Tx: <RD 15,1.> 52 44 20 31 35 2C 31 0A
;; COM9: Rx: timeout
;; COM9: Tx: <RD 15,1.> 52 44 20 31 35 2C 31 0A
;; COM9: Rx: timeout
;; COM9: Tx: <RD 15,1.> 52 44 20 31 35 2C 31 0A
;; COM9: Rx: timeout
;; COM9: Tx: <RD 15,1.> 52 44 20 31 35 2C 31 0A
;; COM9: Rx: timeout
;; COM9: Tx: <RD 15,1.> 52 44 20 31 35 2C 31 0A
;; COM9: Rx: timeout
;; COM9: Tx: <RD 15,1.> 52 44 20 31 35 2C 31 0A


One thing about the RD command, it need an # before the byte number to read.

I see also a dot after the gpib address.

And this:

Code: [Select]

;; COM9: Tx: <.> 0A
at startup is a bit strange

[HKJ]

I uploaded a new version with a #

It looks like you have not define a poll value

Ascii and SingleValue drivers will accept a device when the port is found. The Ascii driver can be configured to require a specific answer before it accept that the device is present and it is strongly recommended to do that (But not before you have the communication working).

When the device is accepted you can use the command line in TestController to send commands to the device. With the Ascii driver you either use tx/txrx/txrx? before each command or the defined scpiCmd's

[masterx81]

Whoa, the language in the definition files is a true programming language 

ended up with this:

Code: [Select]

#idString SOLARTRON,7150PLUS,
#name Solartron 7150Plus
#handle 7150PLUS
#driver Ascii
#port GPIB
#gpibReadCount 15

; A list of possible column name with unit and formatter (SI, Time, Int, D0..D6)
#value VoltageDC V si V DC

#initCmd init

#interfaceType DMM
#interface readValue 0

#cmdMode VDC M0
*cls;
:SENSE:FUNCTION:ON "M0"
sense:voltage:dc:nplc 1;

#askMode  mode?

#scpiCmd values? txrx? G

#scpiCmd init tx T0

#scpiCmd mode? txrx? M?

#askValues values?

That obviously not work 

i get this:

Code: [Select]

;; Start thread for: National Instruments GPIB-232CT A:1 - Solartron 7150Plus
;; COM9: Tx: <.> 0A
;; National Instruments GPIB-232CT A:1: Tx <init>
;; National Instruments GPIB-232CT A:1: Tx <tx T0>
;; COM9: Tx: <WRT 1.> 57 52 54 20 31 0A
;; COM9: Tx: <T0.> 54 30 0A
;; Found Solartron 7150Plus on National Instruments GPIB-232CT A:1
;; 50PLUS: Tx <mode?>
;; 50PLUS: Tx <txrx? M?>
;; COM9: Tx: <WRT 1.> 57 52 54 20 31 0A
;; COM9: Tx: <M?.> 4D 3F 0A
;; COM9: Tx: <TMO 1.0.> 54 4D 4F 20 31 2E 30 0A
;; COM9: Tx: <RD #15,1.> 52 44 20 23 31 35 2C 31 0A
;; COM9: Rx: timeout
;; 50PLUS: Rx Timeout
I always see this:

Code: [Select]

;; COM9: Tx: <.> 0AThat is strange
And also the ending dot here:

Code: [Select]

;; COM9: Tx: <WRT 1.>
Then, why after:

Code: [Select]

;; COM9: Tx: <WRT 1.> 57 52 54 20 31 0A
;; COM9: Tx: <M?.> 4D 3F 0A

(Excluding the dot..) It do:

Code: [Select]

;; COM9: Tx: <TMO 1.0.> 54 4D 4F 20 31 2E 30 0A
And not an rd for read the device mode?

[HKJ]

Whoa, the language in the definition files is a true programming language 

Yes, but you only have access to a small part of it.

#initCmd init

The ascii driver only understands tx/txrx/txrx?, anything else must be defined with #scpiCmd

;; COM9: Tx: <T0.> 54 30 0A

The dot is used to show non-printable characters, here it is a LF or 0A code, as can be see in the hex part.

Then, why after:

Code: [Select]

;; COM9: Tx: <WRT 1.> 57 52 54 20 31 0A
;; COM9: Tx: <M?.> 4D 3F 0A

(Excluding the dot..) It do:

Code: [Select]

;; COM9: Tx: <TMO 1.0.> 54 4D 4F 20 31 2E 30 0A
And not an rd for read the device mode?

The driver keeps track of timeout setting and when it is changed it will send a new timeout command to the gpib device. As long as the gpib controller is only handling one device you will probably only see the TMO command once.

To do a read you do a txrx? (txrx works the same way, but you will not get the result) and then you are supposed to see:
WRT deviceAddress
The actual string you want to write
Optional a TMO
A RD #chars,deviceAddress
And then the result, it can either be a timeout or a string.

A write is done with tx and you will see:
WRT deviceAddress
The actual string you want to write


For a more simple definition use:
#value VoltageDC V si

and put a ; before #askmode:
;#askMode

This means TestController will always show one data value for the device called "VoltageDC"
Then you can work with #askValues to get the readings from the meter.
Probably something like:
#scpiCmd value? txrx? G
#askValues value?

And you need to init the meter for single shot measurements:
#scpiCmd sampleMode tx T(value)
#initCmd sampleMode 0


When you have this working, you can implement the different modes and maybe also add range and sample time selections.

[masterx81]

#initCmd init

The ascii driver only understands tx/txrx/txrx?, anything else must be defined with #scpiCmd

Actually i've specified:

Code: [Select]

#initCmd init
#scpiCmd init tx T0


Code: [Select]

#askMode  mode?
#scpiCmd mode? txrx? M?


Code: [Select]

#askValues values?
#scpiCmd values? txrx? G

So i think that was right.

;; COM9: Tx: <T0.> 54 30 0A

The dot is used to show non-printable characters, here it is a LF or 0A code, as can be see in the hex part.

Got it, so at startup is sent an LF.

Then, why after:

Code: [Select]

;; COM9: Tx: <WRT 1.> 57 52 54 20 31 0A
;; COM9: Tx: <M?.> 4D 3F 0A

(Excluding the dot..) It do:

Code: [Select]

;; COM9: Tx: <TMO 1.0.> 54 4D 4F 20 31 2E 30 0A
And not an rd for read the device mode?

The driver keeps track of timeout setting and when it is changed it will send a new timeout command to the gpib device. As long as the gpib controller is only handling one device you will probably only see the TMO command once.

To do a read you do a txrx? (txrx works the same way, but you will not get the result) and then you are supposed to see:
WRT deviceAddress
The actual string you want to write
Optional a TMO
A RD #chars,deviceAddress
And then the result, it can either be a timeout or a string.

A write is done with tx and you will see:
WRT deviceAddress
The actual string you want to write


For a more simple definition use:
#value VoltageDC V si

and put a ; before #askmode:
;#askMode

This means TestController will always show one data value for the device called "VoltageDC"
Then you can work with #askValues to get the readings from the meter.
Probably something like:
#scpiCmd value? txrx? G
#askValues value?

And you need to init the meter for single shot measurements:
#scpiCmd sampleMode tx T(value)
#initCmd sampleMode 0


When you have this working, you can implement the different modes and maybe also add range and sample time selections.

From what i see, what i've wrote must work.

I not know if the TMO put  between the wrt and the rd can cause problems.
#scpiCmd must be specified BEFORE using it? Or the order of the commands doesn't matter?

[Messtechniker]

Just to show what Test Controller can do (in X/Y mode) some Bode plots.

[HKJ]

#scpiCmd must be specified BEFORE using it? Or the order of the commands doesn't matter?

The order do not matter, all # commands are read and sorted before the definition is used.

I will suggest try using the tx/txrx/txrx? commands from the command line in debug mode, this way you can try commands and see answers very easily.