Author Topic: 3458a logging via Windows app.....revisited  (Read 7632 times)

0 Members and 1 Guest are viewing this topic.

Offline IanJ

  • Frequent Contributor
  • **
  • Posts: 899
  • Country: scotland
  • Pro EE guy many years ago, now a hobby/home biz.
    • IanJohnston.com
3458a logging via Windows app.....revisited
« on: November 19, 2018, 08:02:50 am »
Hi all,

Some time ago I messed with an Excel spreadsheet and some VBA macros to enable my Win10 PC to gather GPIB data and present it on a graph........it worked, but I do find it a little unreliable. It'll just stop logging minutes or hours in......and the Excel VBA graphs are real slow even on a fast PC. Thread here:
https://www.eevblog.com/forum/metrology/3458a-logging-via-excel-macro/

So, I finally found some time to look into this subject again, I dug out the RaspPi 3 but gave up after a couple of hours.....I know nothing about linux!......I need a proper Windows solution!

I went hunting and stumbled on Pawel Wzietek's CodeProject thread and after downloading the VB source I finally got it to compile in Visual Studio 2015 (thanks for the tips Pawel) and after playing with it and my 3458A it looks extremely reliable......with his original code you can hammer the QUERY button and it simply queues the commands and gets the messages back. Not only that but it's also configurable for a number of different interfaces, such as VISA, GBIP:ADlink, GPIB-488 and COM port......and can run two devices at the same time.
https://www.codeproject.com/Articles/1166996/Multithreaded-communication-for-GPIB-Visa-Serial-i

Again, much thanks to Pawel for the great GPIB Device groundwork......

I/O DEVICE COMPATIBILITY (TESTED HARDWARE):
VISA (HP3458A – Using E5810A/82357B) (Keithley 2015THD - Using E5810A) (Fluke 8842A - Using E5810A) (Keysight 34461A - Using E5810A)
GBIP:ADlink
GPIB-488
COM port

TEMPERATURE/HUMIDITY DEVICE COMPATIBILITY:
USB-TnH SHT10 V2.00 (Usb serial comms)

OS TESTED:
Win10

DOWNLOADS:
EXE’s - Release V1.44 attached below.
Source - Not available yet, work is still on-going on the code.

Note: I have tested the app with Win10 and briefly with Win7.

INSTRUCTIONS FOR INSTALLATION:

The zip file contains the following:
- main testIODevice.exe app
- additional .DLL's required (please replace these on any app updates).
- Empty Log.csv file
- GPIBchannels.txt file

Start the app by double clicking testIODevice.exe.


INSTRUCTIONS / NOTES FOR USE:

Assumes that you have loaded the current version of Keysight IO Libraries Suite and have it configured.
I have tested the app with an Agilent E5810A LAN-GPIB and an Agilent 82357B USB-GPIB clone. Both running in Visa mode.

DEVICES:
Set up your NAME and ADDRESS of the device(s) you want to connect to, and pick the INTERFACE type (I have tested Visa only).
The defaults shown when you install are my own as an example.
Hit the CREATE DEVICE button (you choose). An pop-up box will appear that lists the connected device. This box will remain visible at all times and will let you see the commands being sent and any queued commands.

You can effectively batch commands using the PRE RUN, AT RUN and AT STOP boxes and using the RUN/STOP button at the bottom.
PRE RUN commandsare used to set up your device.
AT RUN command is the command that is repeated at the SAMPLE RATE.
Command types are as follows:

SINGLE COMMANDS:
Enter single commands in the COMMAND boxes and hit QUERY and you'll get a RESPONSE back (if it's a command that returns a query).
Types of commands as follows:-
Blocking commands - Are immediately executed on the calling thread (usually GUI thread), this method waits until it gets response from the interface.
Query Asynchronous commands - Queries are queued and the queue is processed on a different thread (producer-consumer model). The call appends the query to the queue and returns immediately.

BATCH COMMANDS:
Send Asynchronous commands - Sent via AT RUN, and are sent similar to the Query Async commands except do not expect a reply, i.e. "fire and forget" manner.
Note: my GUI should really have a separate single command send for SendSync but I have not implemented this at the moment.....you can just use the QueryAsync single query send and the reply will just time-out gracefully.

IO DEVICES POP-UP:
When the CREATE DEVICE buttons are pressed a pop-up box will appear that lists the connected device(s).
This box will remain visible at all times and will let you see the commands being sent and any queued commands.
Note that you can close this window without any effect on the app. You can use the button "Show Device List" to show it again if needed.
Please note that there are some issues in this regard, i.e. you may see some errors appear and the queue grow, but in the case of my 3458A and Keithley 2015THD everything usually settles down until you just see one line for your devices as it communicates.

TEMPERATURE/HUMIDITY:
There is only 1 Temperature/Humidity sensor I have tested and that is available here:-
http://www.dogratian.com/products/index.php/menu-sensors/menu-usb-tnh-type-a-sht10
It's a serial USB type sensor and does not require any drivers except what Win7/Win10 loads automatically as you insert it. You should see a COM port which you can pick from the list on the app.

DATA LOG / CSV:
For CSV generation, per the defaults, set up your filename and path to where you want the CSV to be saved. At the moment there is not file generated if it doesn't exist so make sure you have an empty .CSV text file at the path specified.
The check box ENABLE CSV will start saving data to the .CSV file.
The EXPORT CSV file will copy the active .CSV file to the same folder and append the current date & time as the filename.
EXPLORER will launch Windows Explorer and pointing to the path folder.
You can clear the current CSV file with the RESET CSV button, there's a check box next to it which must be set before the reset will work.
ENABLE LOG check box will activate the log file display window.
E NOTATION TO DECIMAL check box will convert ########E-02 to the decimal equivalent. This is for the CSV and well as the log window.

CHART:
Enable either or both device charts via the check boxes.
With the boxes un-checked you can hit the CLEAR CHART to reset the chart windows and remove the data.
You can change the resolution of the chart with the X-AXIS SCALE POINTS entry. Once the chart display reaches the set number of data points on it the chart will start to scroll off to the left as new data appears at the right.
The range of the Y-axis is adjustable via the SCALE MIN AND SCALE MAX enries. You can manually set them or hit AUTO SCALE and the chart will look at the existing trace and from it's highest and lowest position will centre and scale the chart.
The UP and DN buttons allow the current set scale to be adjusted in 10% steps.

PLAYBACK CHART:
For offline display of the generated .CSV files. The user can select the Device to be displayed on the graph (since there are 2 devices available), and also zoom in/out and scroll back/forward through the graph.

SAVE SETTINGS:
Most of the entries are saved off so when you restart the app they will be there.

Have fun.

Ian.
« Last Edit: December 30, 2018, 07:01:41 am by IanJ »
Ian Johnston
www.ianjohnston.com
Manufacturer of the PDVS2
 
The following users thanked this post: beanflying

Offline Andreas

  • Super Contributor
  • ***
  • Posts: 2168
  • Country: de
Re: 3458a logging via Windows app.....revisited
« Reply #1 on: November 19, 2018, 09:11:21 am »
but I do find it a little unreliable. It'll just stop logging minutes or hours in......
Hello,

your plans are really high sophisticated. (with the graphical display).
But how do you get W10 working reliable?
Every time I want to log one of my ADCs via RS232 in a W10 machine it tries to install some software and reboot over night.
I have found no way to stop this behaviour. So I usually use old XP or W7 machines for measurements.

Just one hint:
instead of trying to put all software into one application I use several  small programs.
E.g. one program for temperature sensing and one for sensing the reference voltage.
The easiest way is to log 1 minute averages and combine the results via spread sheet calculations.

Another interesting way is to use a virtual file for data exchange.
So the values of e.g. a NTC-sensor ADC can be used from other software applicatons
and logged together with the readings or could even be used for T.C. corrections.

with best regards

Andreas
 

Offline Conrad Hoffman

  • Frequent Contributor
  • **
  • Posts: 994
  • Country: us
    • The Messy Basement
Re: 3458a logging via Windows app.....revisited
« Reply #2 on: November 19, 2018, 11:38:40 am »
I do this with a small PowerBASIC program and an old Prologix adapter that uses an FTDI chip. I can easily call their drivers and have few reliability problems... but I haven't tried it on my Win10 machine. I don't expect any serious problems. The same program, with some minor changes reads my HP3478A, HP3455A and frequency counter (can't remember the model). I suspect similar code could be done with Visual Basic or most any language. I just happen to like Basic and FTDI chips.
 

Offline alanambrose

  • Regular Contributor
  • *
  • Posts: 247
  • Country: gb
Re: 3458a logging via Windows app.....revisited
« Reply #3 on: November 20, 2018, 02:26:35 am »
Another data point - I have quite a lot of C# GPIB code which runs fine. I have used both and USB<->GPIB adaptors and LAN<->GPIB and both work good. There's a bit of nonsense with the different manufacturers (NI, Keithley, Agilent etc) all trying to be the visa interface on your machine - I'm using the Agilent version right now but I think I've used others in the past. I've found that the different manufacturer's test equipment has its own GPIB idiosyncrasies, timing behaviour etc. A bit of care with good exception handling and dealing with corner cases will pay dividends. The good thing about the Microsoft environment (I'm sure others will list the negatives) is that visual studio is 'grown-up' and has a good built-in debugger. You can even make some code changes within the debugger and it'll do an incremental compile on-the-fly and continue running from where you hit the break point - i.e. without a full re-build, app re-start etc.

Alan
“A foolish consistency is the hobgoblin of little minds"
 

Offline alm

  • Super Contributor
  • ***
  • Posts: 1235
  • Country: 00
Re: 3458a logging via Windows app.....revisited
« Reply #4 on: November 20, 2018, 02:53:29 am »
C# and before that C has been used for decades for instrument control. According to Wikipedia, LabWindows (the LabVIEW framework with G code replaced by C) started in 1987 (for DOS). So of course there is no reason you couldn't develop something that is at least as good as the Python + PyVISA solution you might use on a Raspberry PI (which should also work on Windows). The only disadvantage compared to the Raspberry PI solution I can see is price and power usage if you want to run it 24/7.

Like Andreas, I would reconsider the monolithic approach, and consider separating data acquisition and analysis / plotting. You can later create something that manages both (e.g. connect to acquisition using a socket and embed the plotting), but this makes it much easier to do unattended logging (e.g. start as service), offline analysis, combining data from multiple instruments, etc. I would also separate logging from the DMM (including its internal temperature if you care) and logging from the environment sensor(s), since the latter data may be used for multiple instruments that are in the same room.
 

Offline Conrad Hoffman

  • Frequent Contributor
  • **
  • Posts: 994
  • Country: us
    • The Messy Basement
Re: 3458a logging via Windows app.....revisited
« Reply #5 on: November 20, 2018, 03:09:04 am »
As Alan says, different instruments have their own quirks. It took me forever to figure out how to get my HP 8903B back to local from program control. Long ago I interfaced to an HP network analyzer that had a very early version of HPIB. I did it with a big old Data Translation card that had a bunch of I/O lines. Quirky doesn't begin to describe it. Huge PITA, but the interface cards were quite expensive back then. I'd never think about using anything other than a National or Prologix interface now.
 

Offline alm

  • Super Contributor
  • ***
  • Posts: 1235
  • Country: 00
Re: 3458a logging via Windows app.....revisited
« Reply #6 on: November 20, 2018, 03:32:02 am »
Instruments certainly have their quirks. Some in hardware: I think the designer of the Prologix interface had to spend a lot more time than he expected to get his GPIB interface to work with all kinds of instruments. In my experience, newer (e.g. post-IEE-488.2 / SCPI) instruments are better behaved than older ones: if you go back far enough, then they implemented GPIB entirely in discrete logic gates, and the programming might be "send a byte with the first bit set and the other seven bits the voltage you want to set" without having any feedback. In my experience HP/Agilent instruments are better behaved than Keithley or Philips instruments from the same era. I've had to write more "if garbage data, then ignore" code or "avoid this sequence, since the instrument may lock up" for the latter two than for HP equipment. But I'm sure that's not universal across instruments.
 

Offline IanJ

  • Frequent Contributor
  • **
  • Posts: 899
  • Country: scotland
  • Pro EE guy many years ago, now a hobby/home biz.
    • IanJohnston.com
Re: 3458a logging via Windows app.....revisited
« Reply #7 on: November 20, 2018, 06:29:11 am »
Hi all,

New screenshot posted in message #1 above......

3458A connected via E5810A......and I've done a bit more coding, enough to see if the concept will work reliably.
I have a PDVS2 connected to the 3458A and set to ramp the voltage up & down between 0 - 10Vdc.

The procedure with the app is to manually send a few commands (will vary with instrument I guess), then trigger readings from then on, i.e.:

END ALWAYS - GPIB EOI mode, this is needed so the 3458A can respond correctly
NRDGS 1 - Number of readings
TARM SGL - Trigger readings (1)

PS. I haven't played with NPLC etc yet.....thats next to do.

Then with TARM SGL left in the COMMAND window, set the sample rate, in this case 1 second and hit "Run"
Over on the right on the DATA LOG the sample are being logged to screen along with Date, Time and Temperature. I've not processed the sampled reading so have left it as per sent by the 3458A for now.
The current Sample count is recorded in the Device 1 area.

At the moment "Stop" will cease the sampling, but will leave the 3458A connected. I will add another button to properly "disconnect" later.

No CSV file yet, I want to make sure, as a few have hinted, that Win10 is happy.

Noted alm post regarding Keithley instruments less well behaved.....I have a couple of 2015 THD DMM's so will hook them up at some point and give them a go. I also have some Fluke's, Racal-Dana gear also.

So far seems to be working fine, and much more reliable than my Excel spreadsheet/macros.

Ian.
« Last Edit: November 20, 2018, 06:36:29 am by IanJ »
Ian Johnston
www.ianjohnston.com
Manufacturer of the PDVS2
 

Offline IanJ

  • Frequent Contributor
  • **
  • Posts: 899
  • Country: scotland
  • Pro EE guy many years ago, now a hobby/home biz.
    • IanJohnston.com
Re: 3458a logging via Windows app.....revisited
« Reply #8 on: November 20, 2018, 09:44:04 am »
Like Andreas, I would reconsider the monolithic approach, and consider separating data acquisition and analysis / plotting. You can later create something that manages both (e.g. connect to acquisition using a socket and embed the plotting), but this makes it much easier to do unattended logging (e.g. start as service), offline analysis, combining data from multiple instruments, etc. I would also separate logging from the DMM (including its internal temperature if you care) and logging from the environment sensor(s), since the latter data may be used for multiple instruments that are in the same room.

I hear ya.......however, at the moment I just want something operational that mostly fits my own needs.......and it's just easier for me to integrate everything into the one app. My forte is uC C++, this is my ummm 4th Visual Studio VB app....ever, so there's a lot I don't know.
The source code will be posted at some point (warts and all).....so anyone else can take it on after that if I don't look into it.

Update:
Have added a checkbox to format returned data in numerical data format with correct DP position. Useful for 3458A data. Screenshot above updated.
One issue I do have which I need to look at is manually terminating GPIB and not have the 3458A front panel controls locked out.......a job for tomorrow. Then I'll look at writing to CSV.

Ian.
Ian Johnston
www.ianjohnston.com
Manufacturer of the PDVS2
 

Offline Conrad Hoffman

  • Frequent Contributor
  • **
  • Posts: 994
  • Country: us
    • The Messy Basement
Re: 3458a logging via Windows app.....revisited
« Reply #9 on: November 20, 2018, 02:34:54 pm »
My effort was much less ambitious, didn't even put a title on the title bar, but it does the job. It's reading 1.23456 VDC from the calibrator-
 
The following users thanked this post: IanJ

Offline IanJ

  • Frequent Contributor
  • **
  • Posts: 899
  • Country: scotland
  • Pro EE guy many years ago, now a hobby/home biz.
    • IanJohnston.com
Re: 3458a logging via Windows app.....revisited
« Reply #10 on: November 21, 2018, 10:04:59 pm »
Hi all,

Hit upon a wee problem last night......all was working well, I could connect to the 3458A and I recorded some 60k+ samples at 1sec intervals no problem, I can connect to the 3458A via a series of commands every time without problem.

However, disconnection is another matter!.......LOCAL 7 or LOCAL 722, or any other combination of RESET, CLEAR etc etc etc will not release the meter from remote back to local.......and as a result some subsequent commands in an attempt to do so just time-out, almost like it is half way between remote and local.....and the funny thing is that it does accept SOME command but not all, i.e. BEEP and RESET work. I did read the GPIB manual, including Appendix B.....to no avail.

So, I fired up the Agilent E5810A's web inteface and sent some commands from it, the same commands I am sending from my VB app and it reacts in exactly the same way.

The only way I can get back to local mode on the 3458A after I have sent the commands is to press the LOCAL button on the 3458A itself.....or pull the GPIB connector from the back of the 3458A.

Tonight I will try the Agilent USB-GPIB adaptor (clone) I have and see if it does the same.

It's not a huge issue, but I would prefer that it all works as perfect as possible............any Ideas?

Ian.
Ian Johnston
www.ianjohnston.com
Manufacturer of the PDVS2
 

Offline alm

  • Super Contributor
  • ***
  • Posts: 1235
  • Country: 00
Re: 3458a logging via Windows app.....revisited
« Reply #11 on: November 22, 2018, 01:21:46 am »
So you are saying it does not just fail to release the keyboard, but also fails to respond to commands it would respond to before you send "LOCAL 722"?

If new commands were sent after "LOCAL 722", then I could understand the instrument going back to remote immediately.  Note that the "22" is the GPIB address, so if the instrument is at GPIB address 16, you should send "LOCAL 716". Did you also try to send the GTL GPIB command (ibloc), instead of sending the string "LOCAL ..." to the instrument?
 

Offline pwlps

  • Contributor
  • Posts: 22
  • Country: fr
Re: 3458a logging via Windows app.....revisited
« Reply #12 on: November 22, 2018, 01:46:26 am »
Hi Ian,

As far as I remember the command for Agilent stuff should have been either "LOCAL:RESET" or "LOCAL OFF", did you try those?

Also, did you try to Dispose the class instance? Dispose calls the "viClose" Visa function, this might reset the instrument to local but I'm not sure.

Otherwise, if it doesn't work tell me and I could try to implement the GPIB "GTL" command in the library.  GTL is a GPIB bus message and Visa implements it e.g. with :
 
ViStatus viGpibControlREN(ViSession vi, ViUInt16 mode);

with this option: (from Visa manual):
mode                                                  Action Description
 
VI_GPIB_REN_ADDRESS_GTL                Send the Go To Local command (GTL) to this device.

But then check first in the manual if GTL is supported by your 3458A - not sure this belongs to the list of mandatory 488 functions (there are several levels of compatibility for GPIB but I don't remember them).

The call to this function could be added to Dispose just before the call to viClose.

Pawel
 


 

Offline IanJ

  • Frequent Contributor
  • **
  • Posts: 899
  • Country: scotland
  • Pro EE guy many years ago, now a hobby/home biz.
    • IanJohnston.com
Re: 3458a logging via Windows app.....revisited
« Reply #13 on: November 22, 2018, 01:47:16 am »
It fails to respond to LOCAL 7 or LOCAL 722, and yes my GPIB address is 22.

So, I send my preamble commands and ultimately TARM SGL every second and logging begins.....I then eventually stop sending TARM SGL and then send LOCAL 722 or CLEAR or RESET etc and those commands fail. This happens both with my VB and also at the command line on the E5810A web interface. And when those commands fail if I send BEEP or RESET instead then the 3458A responds......so not as if all comms has ceased. If I then try to start logging again (TARM SGL etc) then it fails, it's like the 3458A is half-ib and half-out of remote/local. I have to manually hit LOCAL on the front panel and manually RESET.......or pull the GPIB connector.
I will try your suggestions tonight when I get back to the workshop.

It would be nice to know what series of commands other folks are sending when they are finished with their GPIB session.....not much on the web about that, just plenty about initiating sessions.

Ian.
Ian Johnston
www.ianjohnston.com
Manufacturer of the PDVS2
 

Offline alm

  • Super Contributor
  • ***
  • Posts: 1235
  • Country: 00
Re: 3458a logging via Windows app.....revisited
« Reply #14 on: November 22, 2018, 01:56:54 am »
For me, the instruments used for long-term logging are usually in remote mode. If I want to use them for local operation, I use the front panel to go to local, enable display and set triggering to auto. So I never bothered with sending the local command via GPIB. Will try it later today if I have time.
 
The following users thanked this post: TiN, denimdragon

Offline Conrad Hoffman

  • Frequent Contributor
  • **
  • Posts: 994
  • Country: us
    • The Messy Basement
Re: 3458a logging via Windows app.....revisited
« Reply #15 on: November 22, 2018, 02:29:51 am »
Getting my instruments back to front panel operation remotely has always been a problem. I think I've got it licked, though I'm not a programmer and can't even play one on TV. The trick is to tell your controller not to look for data after every send. If it does that, communication can never stop, regardless of what else you send. Don't know if this will help, but here's the code called by my disconnect button (PowerBASIC for Prologix adapter)-

Code: [Select]
SUB GPIB_Close
    DIM lResult AS LONG
    DIM lpBuffer AS ASCIZ * %gpibWriteLen
    DIM B2W AS DWORD
    DIM BW AS DWORD
    ON ERROR GOTO GPIB_Error_Trap

    lpBuffer = "++auto0"+$LF                     'turn off controller automatic read after write so meter will release
    B2W = LEN(lpBuffer)
    lResult = FT_Write(InstHandle, lpBuffer, B2W, BW)
    IF lResult <> %FT_OK THEN ERROR 152

    lpBuffer = "D1F1R-2RAZ1N4T1"+$LF             'turn on internal trigger and reset other settings for manual operation
    B2W = LEN(lpBuffer)
    lResult = FT_Write(InstHandle, lpBuffer, B2W, BW)
    IF lResult <> %FT_OK THEN ERROR 152

    lpBuffer = "++loc"+$LF                       'return control to front panel- this releases instrument
    B2W = LEN(lpBuffer)
    lResult = FT_Write(InstHandle, lpBuffer, B2W, BW)
    IF lResult <> %FT_OK THEN ERROR 152

    lResult = FT_Close(InstHandle)               'close the GPIB connection
    IF lResult <> %FT_OK THEN ERROR 152

    gpibConnected = 0

GPIB_Close_Exit:
    EXIT SUB


« Last Edit: November 22, 2018, 05:33:07 am by Conrad Hoffman »
 

Offline pwlps

  • Contributor
  • Posts: 22
  • Country: fr
Re: 3458a logging via Windows app.....revisited
« Reply #16 on: November 22, 2018, 05:01:48 am »
I guess the VB code posted by Conrad Hoffman is for a Prologix GPIB adapter?

Quote
lpBuffer = "++loc"+$LF                       'return control to front panel- this releases instrument

In Prologix language the "++loc" command sends a GoToLocal message to the device, this should be equivalent to the Visa function I mentioned.

edit:
In fact as there is no device address in this code, I think the "++loc" simply releases the REN line, so that all devices on the bus return to local.  Prologix manual is not clear about this.
« Last Edit: November 22, 2018, 05:13:31 am by pwlps »
 

Offline Conrad Hoffman

  • Frequent Contributor
  • **
  • Posts: 994
  • Country: us
    • The Messy Basement
Re: 3458a logging via Windows app.....revisited
« Reply #17 on: November 22, 2018, 05:37:40 am »
For the above to work, that first command in my disconnect code is needed. You have to get the adapter out of auto mode. For the Prologix it's "++auto0". No idea for other adapters, but I tore my hair out until I  figured this out.  :palm:
 

Offline IanJ

  • Frequent Contributor
  • **
  • Posts: 899
  • Country: scotland
  • Pro EE guy many years ago, now a hobby/home biz.
    • IanJohnston.com
Re: 3458a logging via Windows app.....revisited
« Reply #18 on: November 22, 2018, 07:11:35 am »
Hi all,

I'll get back to the 3458A disconnect issue later....I was starting to pull my hair out also!

Meantime I have done some more work and have got both devices working at the same time now.....HP3458A and a Keithley 2015THD......see screenshot in post#1 above.
There are now some extra text boxes:
Commands to send at run......and Commands to send at STOP......It's this 'stop' where I was trying to send LOCAL 722 to the 3458A......ahh well!

The way it works is: The preamble commands are sent, but the last command in the list is the one that is repeated over and over......hence my TARM SGL & :READ?

I also have the CSV file generation working and logging to there also.
Snapshot of CSV below.....note I have decoded the readings in it as well as the onscreen Data Log, this is optional via a checkbox.

PS. Keithley DMM has annoying 'beep' when GPIB command is sent....I am sure there's a command to disable this!.....actually I think it's an error being generated....need to fix this....UPDATE: Send ":INIT:CONT OFF" also, per page 2-55 of 2015THD manual.

PS. There's a wee bug in the data formatting below......
Code: [Select]
HP3458A,21/11/2018 8:00:37 PM,4.53913284,25.0 C,33.2 %RH
KEITHLEY,21/11/2018 8:00:37 PM,4.53913284,25.0 C,33.2 %RH
HP3458A,21/11/2018 8:00:40 PM,8.55030307,25.0 C,33.3 %RH
KEITHLEY,21/11/2018 8:00:40 PM,4.53913284,25.0 C,33.3 %RH
HP3458A,21/11/2018 8:00:42 PM,8.55030307,25.0 C,33.3 %RH
KEITHLEY,21/11/2018 8:00:42 PM,8.55030307,25.0 C,33.3 %RH
HP3458A,21/11/2018 8:00:45 PM,5.93175246,25.0 C,33.4 %RH
KEITHLEY,21/11/2018 8:00:45 PM,8.55030307,25.0 C,33.4 %RH
HP3458A,21/11/2018 8:00:47 PM,5.93175246,25.0 C,33.4 %RH
KEITHLEY,21/11/2018 8:00:47 PM,5.93175246,25.0 C,33.4 %RH
HP3458A,21/11/2018 8:00:50 PM,1.10277879,25.0 C,33.4 %RH
KEITHLEY,21/11/2018 8:00:50 PM,5.93175246,25.0 C,33.4 %RH
HP3458A,21/11/2018 8:00:52 PM,1.10277879,25.0 C,33.4 %RH
KEITHLEY,21/11/2018 8:00:52 PM,1.10277879,25.0 C,33.4 %RH
HP3458A,21/11/2018 8:00:55 PM,4.37050003,25.0 C,33.4 %RH
KEITHLEY,21/11/2018 8:00:55 PM,1.10277879,25.0 C,33.4 %RH
HP3458A,21/11/2018 8:00:57 PM,4.37050003,25.0 C,33.4 %RH
KEITHLEY,21/11/2018 8:00:57 PM,4.37050003,25.0 C,33.4 %RH
HP3458A,21/11/2018 8:01:00 PM,3.19072211,25.0 C,33.4 %RH
KEITHLEY,21/11/2018 8:01:00 PM,4.37050003,25.0 C,33.4 %RH
HP3458A,21/11/2018 8:01:02 PM,3.19072211,25.0 C,33.4 %RH
KEITHLEY,21/11/2018 8:01:02 PM,3.19072211,25.0 C,33.4 %RH
HP3458A,21/11/2018 8:01:05 PM,7.16935305,25.0 C,33.4 %RH
KEITHLEY,21/11/2018 8:01:05 PM,3.19072211,25.0 C,33.4 %RH
HP3458A,21/11/2018 8:01:07 PM,7.16935305,25.0 C,33.4 %RH
KEITHLEY,21/11/2018 8:01:07 PM,7.16935305,25.0 C,33.4 %RH
HP3458A,21/11/2018 8:01:10 PM,8.15781706,25.0 C,33.4 %RH
KEITHLEY,21/11/2018 8:01:10 PM,7.16935305,25.0 C,33.4 %RH
HP3458A,21/11/2018 8:01:12 PM,8.15781706,25.0 C,33.4 %RH
KEITHLEY,21/11/2018 8:01:12 PM,8.15781706,25.0 C,33.4 %RH
HP3458A,21/11/2018 8:01:15 PM,1.56956653,25.0 C,33.5 %RH
KEITHLEY,21/11/2018 8:01:15 PM,8.15781706,25.0 C,33.5 %RH
HP3458A,21/11/2018 8:01:17 PM,1.56956653,25.0 C,33.5 %RH
KEITHLEY,21/11/2018 8:01:17 PM,1.56956653,25.0 C,33.5 %RH
HP3458A,21/11/2018 8:01:20 PM,4.12928689,25.0 C,33.5 %RH
KEITHLEY,21/11/2018 8:01:20 PM,1.56956653,25.0 C,33.5 %RH
HP3458A,21/11/2018 8:01:22 PM,4.12928689,25.0 C,33.5 %RH
KEITHLEY,21/11/2018 8:01:22 PM,4.12928689,25.0 C,33.5 %RH
HP3458A,21/11/2018 8:01:25 PM,2.5474837,25.0 C,33.5 %RH
KEITHLEY,21/11/2018 8:01:25 PM,4.12928689,25.0 C,33.5 %RH

Ian.
« Last Edit: November 22, 2018, 07:42:34 am by IanJ »
Ian Johnston
www.ianjohnston.com
Manufacturer of the PDVS2
 
The following users thanked this post: Conrad Hoffman, denimdragon

Offline alm

  • Super Contributor
  • ***
  • Posts: 1235
  • Country: 00
Re: 3458a logging via Windows app.....revisited
« Reply #19 on: November 22, 2018, 08:03:04 am »
PS. Keithley DMM has annoying 'beep' when GPIB command is sent....I am sure there's a command to disable this!.....actually I think it's an error being generated....need to fix this....UPDATE: Send ":INIT:CONT OFF" also, per page 2-55 of 2015THD manual.
I remember the error beep and having to send ":INITIATE:CONTINUOUS OFF" as one of the Keithley quirks, indeed. Took quite a while until I figured out the solution.
 

Offline alm

  • Super Contributor
  • ***
  • Posts: 1235
  • Country: 00
Re: 3458a logging via Windows app.....revisited
« Reply #20 on: November 22, 2018, 09:49:53 am »
A quick test on a HP 3458A connected to an Agilent E2050A (predecessor of the E5810A without all the new-fangled stuff like web interfaces :P). I used a Python shell with python-vxi11 to send commands through the E2050A. This instrument is on GPIB address 20.
Code: [Select]
# Initialize
>>> import vxi11
>>> instr = vxi11.Instrument("TCPIP::1x.x.x.x::gpib,20::INSTR")
# Send a random command to make it go to remote mode
>>> instr.write('DISP ON')
# At this point the REM annunciator is lit, and front panel keys other than local are disabled.
# Send GTL
>>> instr.local()
# The REM annunciator turns off, and front panel keys work again
I checked the manual again, and the LOCAL 7 commands are for HP 200/300 BASIC, so they're irrelevant for modern computers. Sending those to the 3458A produces an error, as expected. You just have to tell the GPIB controller to send the GTL command and / or release the REM line. In the NI 488 C bindings, this would be ibloc(), and pwlps describes a few posts earlier how to do it with VISA. In the VXI-11 bindings I was using for this test, it's Instrument.local(). Before this, I issue DISP ON and TRIG AUTO to get the DMM into a usable state for interactive use.
 
The following users thanked this post: IanJ

Offline IanJ

  • Frequent Contributor
  • **
  • Posts: 899
  • Country: scotland
  • Pro EE guy many years ago, now a hobby/home biz.
    • IanJohnston.com
Re: 3458a logging via Windows app.....revisited
« Reply #21 on: November 22, 2018, 10:15:39 am »
I checked the manual again, and the LOCAL 7 commands are for HP 200/300 BASIC, so they're irrelevant for modern computers. Sending those to the 3458A produces an error, as expected. You just have to tell the GPIB controller to send the GTL command and / or release the REM line. In the NI 488 C bindings, this would be ibloc(), and pwlps describes a few posts earlier how to do it with VISA. In the VXI-11 bindings I was using for this test, it's Instrument.local(). Before this, I issue DISP ON and TRIG AUTO to get the DMM into a usable state for interactive use.

Aha!......this prompted me to do more testing because pwlps had sent me an updated DLL to do just this (there are two applications, I am just modifying one of them right now)......but I think it was written to call GTL on shutdown of the app, which indeed does work and it releases the 3458A back to local mode. A good step forward though.

Ian.
Ian Johnston
www.ianjohnston.com
Manufacturer of the PDVS2
 

Offline Conrad Hoffman

  • Frequent Contributor
  • **
  • Posts: 994
  • Country: us
    • The Messy Basement
Re: 3458a logging via Windows app.....revisited
« Reply #22 on: November 22, 2018, 12:02:28 pm »
Wow, that reminds me of the HP 85 I used to use. We've come a ways.
 

Offline acts238willy

  • Regular Contributor
  • *
  • Posts: 59
  • Country: us
Re: 3458a logging via Windows app.....revisited
« Reply #23 on: November 22, 2018, 01:48:30 pm »
+Sadly, the old gear is still very good, ppm-wise.
The Datron, HP, etc., GPIB stuff that all calls for
the HP85 needs a modern solution for data collection.
I get some help from Digelent's program called
'Labview Home'... it's a student copy of Labview,
dated 2014, for less than $60. It has good tools
for my 3458s.
 

Offline Conrad Hoffman

  • Frequent Contributor
  • **
  • Posts: 994
  • Country: us
    • The Messy Basement
Re: 3458a logging via Windows app.....revisited
« Reply #24 on: November 22, 2018, 03:03:29 pm »
With the right meter setup, say "F1R0Z0N3T3D3" to blank the display and fix the range, I can read at about 60 ms intervals. OK for what I tend to do, but not record breaking speed. How fast is your program?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf