Program that can log from many multimeters.

[HKJ]

It return 17 bytes instead of 15 (I've set 15 byte return value), witht that strange "15" at the end.
And if i do a second time the "txrx? G" it goes in timeout

It is supposed to send the requested number of bytes, using 0 pads if necessary and then terminate with the number of significant bytes.
I check for a 0 in the message and will strip everything after it, but if you use a byte count at the exact number of bytes, I will not get any zero bytes and will not strip any data (I do not use the byte count when stripping data).

[HKJ]

Tried idea 2, no luck, the scope only accepts one SCPI command at a time.  I checked with Wireshark and the scope is definitely not send "0A" at the end of the string as the others responses do.

You can use a [delay] specification to fix it.
Both the delay and the Tx is a hack to fix a faulty answer and may fail to work at the next software update!

[masterx81]

Trying to understand what's going on, i've played with realterm.
First of all, if before doing anything i do a read (at poweron or after a "clr 1" - that reset the gpib device at address 1) i get

Code: [Select]

send:
rd #100,1<cr>
72 64 20 23 31 30 30 2C 31 0D


receive:
37 31 35 30 2B 20 56 41 43 2E 41 43 0D 0A * 2B 2E 30 30 30 30 33 34 30 20
20 56 20 44 43 0D 0A 2B 2E 30 30 30 30 33 34 30 20 20 56 20 44 43 0D 0A
2B 2E 30 30 30 30 33 34 30 20 20 56 20 44 43 0D 0A 2B 2E 30 30 30 30 33
34 30 20 20 56 20 44 43 0D 0A 2B 2E 30 30 30 30 33 34 30 20 20 56 20 44
43 0D 0A 2B 31 30 30 0D 0A
 
7150+ VAC.AC<cr><lf>
+.0000340  V DC<cr><lf>
+.0000340  V DC<cr><lf>
+.0000340  V DC<cr><lf>
+.0000340  V DC<cr><lf>
+.0000340  V DC<cr><lf>
+100<cr><lf>

Where is an * means that there was a little pause.
Here i can see that the solartron after every command send a <cr><lf>.
Maybe we can use a parameter like #gpibReadCount, eventually #gpibReadStopChar to stop the read also if the buffer isn't all received, but i've received the "end of data"? So we don't read any garbage.
It can be also seen that at the first read the meter output the model name, can this be useful?
It send the model name only if i not send anything before.
If for example i send an M? for asking the actual mode, it return the mode followed by cr lf
Other thing that can be noticed is that at the end of the 100byte buffer the gpib interface send the total bytes received, followed by <cr><lf>
Maybe this can be useful?

[MikeLud]

HKJ,

You might want to add error checking when entering Minimum and Maximum values in the Scales for chart tab. If you enter a Max value less then the Min value or a Min value greater then the Max value and you enable that value on the Chat tab it cause the program to lockup.

[HKJ]

You might want to add error checking when entering Minimum and Maximum values in the Scales for chart tab. If you enter a Max value less then the Min value or a Min value greater then the Max value and you enable that value on the Chat tab it cause the program to lockup.

I do have a trap to prevent that, but it was wat to fine for the chart library, I have adjusted it.


I also wonder if masterx81 has tried TestController with the fixed baudrate setting.

[masterx81]

So, now seem all correct. At power on i get:

Code: [Select]

;; COM9: Set params: 19200
;; 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: <M0> 4D 30
;; 50PLUS: Rx <M0>
Seem perfect! It also return the correct mode (M0)

If i do, from the command window, a "txrx? G" for getting a single shot value, this is the result:

Code: [Select]

txrx? G
;; 50PLUS: Tx <txr (i've set 15 bytex? G>
;; COM9: Tx: <WRT 1.> 57 52 54 20 31 0A
;; COM9: Tx: <G.> 47 0A
;; COM9: Tx: <RD #15,1.> 52 44 20 23 31 35 2C 31 0A
;; COM9: Rx: <+.0000330  V DC15> 2B 2E 30 30 30 30 33 33 30 20 20 56 20 44 43 31 35
;; 50PLUS: Rx <+.0000330  V DC15>
;; +.0000330  V DC15
It return 17 bytes instead of 15 (I've set 15 byte return value), witht that strange "15" at the end.
And if i do a second time the "txrx? G" it goes in timeout

Hi! Yes tested it but as you see the returned byte count cause problems

[masterx81]

Trying to understand what's going on, i've played with realterm.
First of all, if before doing anything i do a read (at poweron or after a "clr 1" - that reset the gpib device at address 1) i get

Code: [Select]

send:
rd #100,1<cr>
72 64 20 23 31 30 30 2C 31 0D


receive:
37 31 35 30 2B 20 56 41 43 2E 41 43 0D 0A * 2B 2E 30 30 30 30 33 34 30 20
20 56 20 44 43 0D 0A 2B 2E 30 30 30 30 33 34 30 20 20 56 20 44 43 0D 0A
2B 2E 30 30 30 30 33 34 30 20 20 56 20 44 43 0D 0A 2B 2E 30 30 30 30 33
34 30 20 20 56 20 44 43 0D 0A 2B 2E 30 30 30 30 33 34 30 20 20 56 20 44
43 0D 0A 2B 31 30 30 0D 0A
 
7150+ VAC.AC<cr><lf>
+.0000340  V DC<cr><lf>
+.0000340  V DC<cr><lf>
+.0000340  V DC<cr><lf>
+.0000340  V DC<cr><lf>
+.0000340  V DC<cr><lf>
+100<cr><lf>

Where is an * means that there was a little pause.
Here i can see that the solartron after every command send a <cr><lf>.
Maybe we can use a parameter like #gpibReadCount, eventually #gpibReadStopChar to stop the read also if the buffer isn't all received, but i've received the "end of data"? So we don't read any garbage.
It can be also seen that at the first read the meter output the model name, can this be useful?
It send the model name only if i not send anything before.
If for example i send an M? for asking the actual mode, it return the mode followed by cr lf
Other thing that can be noticed is that at the end of the 100byte buffer the gpib interface send the total bytes received, followed by <cr><lf>
Maybe this can be useful?

And here there are some thoughts

[HKJ]

Hi! Yes tested it but as you see the returned byte count cause problems

Try use a slightly higher byte count, the code looks for a 0 byte and strips everything after it.

[masterx81]

With a buffer of 20 it still do sometimes strange things:

Code: [Select]

;; COM9: Set params: 19200
;; 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 #20,1.> 52 44 20 23 32 30 2C 31 0A
;; COM9: Rx: <M0> 4D 30
;; 50PLUS: Rx <M0>
txrx? M?
;; 50PLUS: Tx <txrx? M?>
;; COM9: Tx: <WRT 1.> 57 52 54 20 31 0A
;; COM9: Tx: <M?.> 4D 3F 0A
;; COM9: Tx: <RD #20,1.> 52 44 20 23 32 30 2C 31 0A
;; COM9: Rx: <M0> 4D 30
;; 50PLUS: Rx <M0>
;; M0
txrx? M?
;; 50PLUS: Tx <txrx? M?>
;; COM9: Tx: <WRT 1.> 57 52 54 20 31 0A
;; COM9: Tx: <M?.> 4D 3F 0A
;; COM9: Tx: <RD #20,1.> 52 44 20 23 32 30 2C 31 0A
;; COM9: Rx: <M0> 4D 30
;; 50PLUS: Rx <M0>
;; M0
txrx? M?
;; 50PLUS: Tx <txrx? M?>
;; COM9: Tx: <WRT 1.> 57 52 54 20 31 0A
;; COM9: Tx: <M?.> 4D 3F 0A
;; COM9: Tx: <RD #20,1.> 52 44 20 23 32 30 2C 31 0A
;; COM9: Rx: <4> 34
;; 50PLUS: Rx <4>
;; 4
txrx? M?
;; 50PLUS: Tx <txrx? M?>
;; COM9: Tx: <WRT 1.> 57 52 54 20 31 0A
;; COM9: Tx: <M?.> 4D 3F 0A
;; COM9: Tx: <RD #20,1.> 52 44 20 23 32 30 2C 31 0A
;; COM9: Rx: <4> 34
;; 50PLUS: Rx <4>
;; 4

I've repeated several times the M? command and after some tries it goes crazy. If sending manually the txrx? G for read the current value, after smoe tries it return timeout
The "4" returned now seem the received byte count (M0 CR LF)

[HKJ]

I've repeated several times the M? command and after some tries it goes crazy. If sending manually the txrx? G for read the current value, after smoe tries it return timeout
The "4" returned now seem the received byte count (M0 CR LF)

I am a bit puzzled about what goes on. Before each communication I flush the communication buffer, i.e. it cannot be old data, but I do not flush anything between the writes and read, except if I get a zero byte?
Could there be some extra 0 bytes?
I have uploaded a new version (0.88) that strips any leading or trailing zero bytes, before checking for zero bytes in the message (I doubt it will help).
I have also added code to show when I flush and the raw received data (Only on console output).

[masterx81]

Really strange. this evening i'll try the new version.
And try try also doing the same thing manually with realterm to see what's going on. can't the bytecount be used to do a basic "error checking" of the transmission?

[HKJ]

can't the bytecount be used to do a basic "error checking" of the transmission?

Yes and no, the driver I am using is the line based driver, i.e. it will terminate reception on a CR or LF character. This basically means that if I get a answer like M0<CR><LF>4 the driver will return M0 and next read will return 4. Because I flush the receive buffer I am not supposed to ever see the 4.
If the answer is like: M0<00><00><00>4<CR><LF> the driver will return the full line, but the NI interface will spot the zeroes and strip them together with anything after them.

[MiroS]

Hi,
I started using it yesterday to grab 1(t) response from heating object to model DUT, program is very usefull for my purpose.
Please see the list of possible improvements:

1. Start, pause,stop buttons would be nice addtion.
2. Automatic triggering would be very usefull, e.g. start logging if measured value is 'bigger/equal/less than'
3. Clear button for content of table /chart, now I have to leve program and run it again
4. I see that quite often at first run program is hanging, I have to kill it and start it again, killing in Windows 10 sometimes has trouble to kill this app

Other than that I found it quite usefull   

[HKJ]

1. Start, pause,stop buttons would be nice addtion.

You have start and stop buttons.
Why a pause button,, you can log for a very log time.

2. Automatic triggering would be very usefull, e.g. start logging if measured value is 'bigger/equal/less than'

You can do that with scripting. Write something like this in the log window:

#wait dmmName.voltageDC>10
#log 1

Then press "Run"

3. Clear button for content of table /chart, now I have to leve program and run it again

The table/chart will automatic clear when you start a new log.

4. I see that quite often at first run program is hanging, I have to kill it and start it again, killing in Windows 10 sometimes has trouble to kill this app

I have never seen this and due to that it is a bit hard to fix.

[masterx81]

can't the bytecount be used to do a basic "error checking" of the transmission?

Yes and no, the driver I am using is the line based driver, i.e. it will terminate reception on a CR or LF character. This basically means that if I get a answer like M0<CR><LF>4 the driver will return M0 and next read will return 4. Because I flush the receive buffer I am not supposed to ever see the 4.
If the answer is like: M0<00><00><00>4<CR><LF> the driver will return the full line, but the NI interface will spot the zeroes and strip them together with anything after them.

Uh, ok, obviously if the driver is a cr/lf line based, it's quite difficult.
Actually the NI interface send all the 00's.
If i read a 4 byte with a 10 byte buffer (like M 0 CR LF) in realterm i read "M 0 CR LF 0x00 0x00 0x00 0x00 0x00 0x00 1 0 CR LF"

[MiroS]

>You have start and stop buttons.
Where they are ? I can see Start/Stop in timer , but this actually is not stopping grabing data, e.g  in Chart tab

Pause is usefull e.g. if you will pause DUT to bring a cup of tee or you will know that next hour nothing usefull will not happened or  no need to capture useless data just waiting for event to restart capturing data.
I think Pause can be scripted as well - I could net find a description for commands other in exaples, but I think with some experiments I can learn myself how to use it, anyway that would be bit wired setup for Pause

>The table/chart will automatic clear when you start a new log.
OK, but I think it will be still usefull, like cleanning chart , but lesving table, or the other way, or both.

>I have never seen this and due to that it is a bit hard to fix.
OK, clear. Java is wired/not very reliable  framework. There is something happening with connections , in my setup I have UT61E to grab current and BM869s to temperature. This is requireing to add/remodve/reconnect a few times before they will work at the same time, sometim it will stick to UT61E hard that even if I remove it Current valuse will show UT61E as DC volatege , no matter that UT61E is on AC Amp range. I think that may be something close to Java framework used for communication.

[HKJ]

If i read a 4 byte with a 10 byte buffer (like M 0 CR LF) in realterm i read "M 0 CR LF 0x00 0x00 0x00 0x00 0x00 0x00 1 0 CR LF"

According to some of you examples above, there is not always a CR LF after the data and before the byte count.
But as I wrote above a multi line answer is handled: Anything after the first line is thrown away.

[HKJ]

>You have start and stop buttons.
Where they are ? I can see Start/Stop in timer , but this actually is not stopping grabing data, e.g  in Chart tab

The log button is the start/stop button.

Pause is usefull e.g. if you will pause DUT to bring a cup of tee or you will know that next hour nothing usefull will not happened or  no need to capture useless data just waiting for event to restart capturing data.

The captured may not be needed, but the software has no problem handling them. It may get a bit slow if you capture millions of data points, but that takes days.

I think Pause can be scripted as well - I could net find a description for commands other in exaples, but I think with some experiments I can learn myself how to use it, anyway that would be bit wired setup for Pause

Commands are documented in the help window, type a # in the command line.
You cannot pause logging.

>The table/chart will automatic clear when you start a new log.
OK, but I think it will be still usefull, like cleanning chart , but lesving table, or the other way, or both.

The table and charts are linked together. The chart will always show data from the table.
You can always disable curves in the chart.

OK, clear. Java is wired/not very reliable  framework. There is something happening with connections , in my setup I have UT61E to grab current and BM869s to temperature. This is requireing to add/remodve/reconnect a few times before they will work at the same time, sometim it will stick to UT61E hard that even if I remove it Current valuse will show UT61E as DC volatege , no matter that UT61E is on AC Amp range. I think that may be something close to Java framework used for communication.

In my experience Java is very reliable and nearly never crashes.
The library I uses to handle USB HID has some problems and my workaround is not perfect.
Serial interfaces works fairly well, but if you remove a USB interface and then reconnect it, you need to do a reconnect.
It will not help to add/remove devices, it is not related to the connection, but is only a shorthand list of devices to select from.

[masterx81]

Uhm, as i remember i've never seen a cr lf before the byte count. The bytecount is placed after the buffer (filled by 0x00's if the data not fill the buffer) and followed by cr lf

[MikeLud]

Where do I add \n or is this a scope bug that I can't fix.

It is something to do with the scope. Some ideas:
1) Longer timeout, maybe the timeout is too short.
2) Because you are using ascii driver, you can do a trick: Send this command with "tx", then send another command that will answer. You are now supposed to get both answers on the same line.

HKJ,

I reported this issue to Siglent, hopefully they will fix it soon, below is their response.

Hi Mike

Thanks for your feedback. It does be a issue. I have forwarded to our R&D department and the engineers will fix it asap.

Thank you and have a good day.

[MikeLud]

Where do I add \n or is this a scope bug that I can't fix.

It is something to do with the scope. Some ideas:
1) Longer timeout, maybe the timeout is too short.
2) Because you are using ascii driver, you can do a trick: Send this command with "tx", then send another command that will answer. You are now supposed to get both answers on the same line.

HKJ,

I tried LXI mode and now I am able to get the values to read. I am having issue writing the readmath, how do I have all 3 values to read correctly 

Code: [Select]

;; 17:50:14.852 SDS1204XE: Tx <C1:PAVA? RMS>
;; 17:50:15.187 SDS1204XE: Rx <RMS,6.22E-01
>
;; 17:50:15.189 SDS1204XE: Tx <C2:PAVA? RMS>
;; 17:50:15.524 SDS1204XE: Rx <RMS,7.09E-01
>
;; 17:50:15.526 SDS1204XE: Tx <C1-C2:MEAD? FRR>
;; 17:50:16.541 SDS1204XE: Rx <FRR,9.21E-05>
;; 17:50:16.542 SDS1204XE: Rx after :readmath: getElement(value,1,",") <6.22E-01 RMS>
;; 17:50:16.543 SDS1204XE: Rx as numbers <0.622 0.0>

[masterx81]

New version, nothing changed.
One thing to notice is that it remain stuck always at the 3° send of the txrx? m? (like in the previous "dump")

Some data playing by hand with realterm:

Code: [Select]

tx c63 l6C r72  20 131  0D                                                         
tx W57 R52 T54  20 131  0D  0A
tx T54 030  0D  0A
tx W57 R52 T54  20 131  0D  0A
tx M4D ?3F 0D  0A
tx T54 M4D O4F  20 131 .2E 030  0D  0A
tx R52 D44  20 #23 232 030 ,2C 131  0D  0A
rx M4D 030  0D  0A
rx (after timeout) 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 434  0D  0A
tx W57 R52 T54  20 131  0D  0A
tx M4D ?3F  0D  0A
tx R52 D44  20 #23 232 030 ,2C 131  0D  0A
rx M4D 030  0D  0A 
rx (after timeout) 00  00  00  00  00  00  00  00  00  00  00 00  00  00  00  00 434  0D  0A
tx W57 R52 T54  20 131  0D  0A
tx M4D ?3F  0D  0A
tx R52 D44  20 #23 232 030 ,2C 131  0D  0A
rx M4D 030  0D  0A 
rx (after timeout)00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 434  0D  0A
tx W57 R52 T54  20 131  0D  0A
tx M4D ?3F  0D  0A
tx R52 D44  20 #23 232 030 ,2C 131  0D  0A
rx M4D 030  0D  0A
rx (after timeout)00  00  00 00  00  00  00  00  00  00  00  00  00  00  00  00 434  0D  0A
tx W57 R52 T54  20 131  0D  0A
tx M4D ?3F  0D  0A
tx R52 D44  20 #23 232 030 ,2C 131  0D  0A
rx M4D 030  0D 0A
rx (after timeout)00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 434  0D  0A
tx W57 R52 T54  20 131  0D  0A
tx M4D ?3F  0D  0A
tx R52 D44  20 #23 232 030 ,2C 131  0D 0A
rx M4D 030  0D  0A 
rx (after timeout)00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 00 434  0D  0A
tx W57 R52 T54  20 131  0D  0A
tx M4D ?3F  0D  0A
tx R52 D44  20 #23 232 030 ,2C 131  0D  0A
rx M4D 030  0D  0A
rx (after timeout)00  00  00  00  00  00  00  00  00  00  00 00  00  00  00  00 434  0D  0A

all work as it should... The only difference that i see is that using copy paste from notepad it paste a cr lf
If after the "bug" i exit testcontroller, and open the serial port with realterm, and sent the same request, it works:

Code: [Select]

tx W57 R52 T54  20 131  0D  0A
tx M4D ?3F  0D  0A
R52 D44  20 #23 232 030 ,2C 131  0D 0A
rx M4D 030  0D  0A
rx (after timeout) 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 00 434  0D  0A

There are some other tests that i can try?

[HKJ]

New version, nothing changed.

I do not see any logs from it with Raw and flush tags.

[masterx81]

Sorry, I've not included them. But i've not notice any difference from the logs of the Previous versions. I not used the zip from the site as was missing the ni gpib driver, so i'm using the last jar file

[HKJ]

Sorry, I've not included them. But i've not notice any difference from the logs of the Previous versions. I not used the zip from the site as was missing the ni gpib driver, so i'm using the last jar file

With these intermittent updates you use the zip as a base and then replace the jar.  The current jar is V0.88
The extra logging is only to the dos window, not the log window of TestController.