WinGPIB - Windows GPIB App (multi-purpose)

[tppc]

Thanks for your answer.
I will have a look at  Pawel's code. I doubt it is easy to understand (asynchronous communications and multithreaded applications are usually not the easiest ones!)

[pwlps]

Thanks for your answer.
I will have a look at  Pawel's code. I doubt it is easy to understand (asynchronous communications and multithreaded applications are usually not the easiest ones!)

Hello,

Actually some time ago I was thinking too about writing an implementation for Prologix boards, based on the SerialDevice implementation.  However, as I understand these boards cannot reliably transfer binary data (even if the manual says the opposite) since the EOI signal is always translated to a character, whith a risk of a premature abort.  Though, if you understand better the explanations about EOI handling in the Prologix manual then let me know.  However if you only have text responses from your instrument then it can work (but I was reluctant to make an incomplete implementation).

I don't have experience with Prologix board and I don't own any but I think you can first try to use the SerialDevice class without any modifications in the code.  Then of course, from the class' point of view, all gpib addresses are bound to the same device therefore there is no command-response interleaving.  Then also the gpib serial poll won't be used but if you don't have slow devices on the bus you won't notice much difference.
You will just need to integrate the Prologix gpib commands  in the command string.

3. When you select the INTERFACE Com Port, the default configuration is COM1:9600,N,8,1,CRLF
Except the com port which must be set to the Prologix virtual COM Port, are all other parameters significant and correct?
Furthermore, how do I specify the GPIB address? there is no input field for it???

This class is for serial ports, it only needs the COM port number and its configuration.  You will find the meaning of these parameters in the class' documentation on the CodeProject page.
9600 is for baudrate, the baudrate must match the one used by Prologix but I don't know what is the default settings for it. 
N,8,1 should be correct.
Prologix uses only one line terminator character, either CR or LF, so I would replace CRLF by LF to avoid double line terminations.

Prologix boards  don't use any specific gpib driver, all gpib commands are integrated in the command string sent via the serial connection, to have the board recognize the gpib commands you have to add a prefix "++",  For example,  to send the command
"*IDN?" to the gpib address 5 and get the response the command would be : "++addr 5\n*IDN?\n++read".
Note that the "auto" mode should be disabled.
But I can't test it.
Otherwise the SerialDevice class can be easily adapted to include the ++ commands automatically, I can help you with it.  If it works well I might add it in some next release.

(...) I doubt it is easy to understand (asynchronous communications and multithreaded applications are usually not the easiest ones!)

The asynchronous/multithreaded aspects are handled in the main code (IO Device) but you won't see much of it in the implementation code, so that writing implementations is simple. Look at the section "writing implementations" in the article.
Have fun!
Pawel



 

[tppc]

Hi there,

thank you very much pwlps for this very precise answer.
It feels strange to me to communicate with you in English language, but OK...

For the moment, I just browsed your source files with Notepad++ (VS not installed) which is not ideal.
I understood that the Prologix protocol was not "embeded" in your code.

I am discovering GPIB communications. My main concern was to be able to backup (and restore) the CAL RAM of my 2 HP3457A units.
This has already been done here on the EEVBlog forum, but I thought it would be a great opportunity to learn about GPIB protocol.

Another interset for me is to be able to log data from my 2 HP3457A units measuring the same voltage reference, to track calibration discrepencies and possible drifts over time.
(I had to replace the ADC hybrid on one unit, thus loosing its calibration)

I have 20+ years experience programming in C language Under NI LabWindows CVI (mostly serial communications, ModBus TCP, file I/O, data archiving…), but no experience with VS.
Anyway, I promise to install VS and experiment with your code, but this will take some time.

My GPIB adapter is not a genuine Prologix, but a so called "Prologix compatible" Fenrir-Naru clone found on Ali Express for 20$ delivered!
The PCB is installed Inside the GPIB connector and powered through the USB cord.

Thank you very much for all this valuable information, it is very much appreciated. 

I will post any progress here.

Regards

[tppc]

Hi there,
it took me a Week to read and (not fully) understand the complete documentation of the IODevice library.
Being not familiar with such advanced OOP, much of the terminology remains obscure to me.
For example, I am not sure to fully understand what a private virtual method, a child class, an abstract or a MustInherit class, a Public Shared or a Protected MustOverride Function are… 

I think you can first try to use the SerialDevice class without any modifications in the code.  Then of course, from the class' point of view, all gpib addresses are bound to the same device therefore there is no command-response interleaving.  Then also the gpib serial poll won't be used but if you don't have slow devices on the bus you won't notice much difference.
You will just need to integrate the Prologix gpib commands  in the command string.

I did experiment with the application and realized that it will not meet my needs.
In fact, I wanted to record data from 2 HP3457A units in parallel.
The meters are chained with a GPIB cable and connected to the PC with only 1 Prologix compatible GPIB-USB adapter which is seen as a serial COM port.
Therefore I can NOT set the meters as DEVICE1 and DEVICE2, since they use the same COM Port which can only be opened once.

Prologix uses only one line terminator character, either CR or LF, so I would replace CRLF by LF to avoid double line terminations.

In fact, it will work with any Terminator, CR, LF or CRLF.

For example,  to send the command
"*IDN?" to the gpib address 5 and get the response the command would be : "++addr 5\n*IDN?\n++read".
Note that the "auto" mode should be disabled.

I was NOT able to chain commands as suggested
(BTW, the HP3457A does not recognize the *IDN? query, it uses ID? instead )
the meter will not respond to the chained commands ++addr 22\nID?\n++read but it certainly will if I split it in 2 and send 1 command at a time. (the GUI has only 1 field for cyclic commands)

That's all for the moment, I didn't have time to instal VS and did not browse the source code any further.

Regards.

 

[pwlps]

Hi there,
it took me a Week to read and (not fully) understand the complete documentation of the IODevice library.
Being not familiar with such advanced OOP, much of the terminology remains obscure to me.
For example, I am not sure to fully understand what a private virtual method, a child class, an abstract or a MustInherit class, a Public Shared or a Protected MustOverride Function are… 

Yes, these are all standard OOP terms, I understand that it sounds obscure if you only code in raw C (you will find the same terminology in C++ though). 

I did experiment with the application and realized that it will not meet my needs.
In fact, I wanted to record data from 2 HP3457A units in parallel.
The meters are chained with a GPIB cable and connected to the PC with only 1 Prologix compatible GPIB-USB adapter which is seen as a serial COM port.
Therefore I can NOT set the meters as DEVICE1 and DEVICE2, since they use the same COM Port which can only be opened once.

Of course, this is what I was saying: "all gpib addresses are bound to the same device...".

I just wrote a quick implementation for Prologix boards this afternoon,  I post it in the attachment together with an updated version of the test project. (For the moment a C# version only, enough for testing, but I can translate it later to VB.NET if you want to recompile the Ian's app).

But I cannot test it without a board and the prologix manual is not always clear so I can't guarantee anything.  If you want to test it, the code is in PrologixDevice.cs (I think you don't need to know OOP to understand this code), if it doesn't work correctly you can set debugger breakpoints inside various functions there (send,receive...) and see the data being exchanged with the board.   
NB. I compiled the project with SharpDevelop v4.4  (SharpDevelop is a much lighter environment than VS so I use it on some computers where I don't want to install VS).

regards

Attachment updated :

-VB version included
- EOI configured
- (possible) bug in ReceiveByteArray corrected (timeout handled properly)

[tppc]

Hi there,
I played with your test project executable, and guess what,
IY WORKS GREAT! 
That is really amazing how you could put it all together and have it working without the adapter to test it!

Nice job! 

Thanks for your effort.

I will have a look at the code tomorrow evening.

Regards.

[pwlps]

Ha, you see how great the OOP is: no bugs    No, I was really lucky, although the rigor of C# and OOP helps a lot (in C it is much harder to get things to work without tons of debugging).

And in fact there is a little bug there (look at the updated attachment in the previous post), even if it didn't show up for you.

Tell us when you have it tested with two devices queried in parallel !

[MarkMLl]

My GPIB adapter is not a genuine Prologix, but a so called "Prologix compatible" Fenrir-Naru clone found on Ali Express for 20$ delivered!
The PCB is installed Inside the GPIB connector and powered through the USB cord.

I took delivery of one of those a few days ago, supplied by https://www.ebay.co.uk/str/color-tree which saved messing around with AliExpress which tends to be Paypal-unfriendly.

It appears to work well, although I've not tried hanging it onto multiple instruments yet. I think it's worth stressing that it's not a direct ripoff of the Prologix firmware etc., but appears to be an implementation of this design https://github.com/fenrir-naru/gpib-usbcdc and as such is documented as having 75-series driver chips.

At present I'm using it with a simple set of commands (issued from gtkterm on Linux) like

Code: [Select]

++mode 0
++auto 0
++addr 1
++read eoi

which are adequate to capture a "print" command. I'm thinking of wrapping that in a simple script and calling it e.g. gpibcat, but I'll probably do something a bit fancier to filter the text/graphics into a standard format: both have embedded HP-proprietary printer-control codes.

MarkMLl

[tppc]

Tell us when you have it tested with two devices queried in parallel !

Hi there,

sorry for the delay, I had a hard time finding a functional Installer for SharpDevelop.
(I couldn't make it with the versions available on GitHub.)

I then had another hard time trying to understand the code.
(I must be a slow learner )

@ Pwlps
The latest version you posted here doesn't work for me :
The problem is in the ReceiveByteArray

Code: [Select]

protected override int ReceiveByteArray(ref byte[] arr, ref bool EOI, ref int errcode, ref string errmsg)
{
        //this function will be repeatedly called if there is timeout on "Readline"
        //however for Prologix the "++read" command should not be repeated therefore
        //we store the status in "readinitiated" flag.
// However we have problem if timeout is caused by gpib and not ReadLine,
//then ++read would have to be repeated but with Prologix we cannot make the difference
//so that polling should always be used with this interface to avoid such situation
        var retval = 0;
        string respstr = null;           
        if (!readinitiated)
        {
              try
               {
              //string cmd="++addr "+gpibaddr+termstr+"++read eoi"; //read until eoi or timeout
              string cmd="++addr "+gpibaddr+termstr+"++read"; //read until eoi or timeout

The HP3457A does not accept the instruction set ++read eoi
and this completely blocks the application and the DMM.
Need to restart both the app and the meter.

I just removed the eoi and it works.

I plan to modify your code so that only the first Device would configure and open the serial port.
The second device (connected through the same adapter) would then use the same port (without opening it) with a different GPIB address.

Please Don't do it for me, I am trying to learn all this .NET rubbish 

Regards.

[tppc]

Hi MarkMLI,

Code: [Select]

++mode 0
++auto 0
++addr 1
++read eoi


Does ++read eoi work with your instrument?

[MarkMLl]

Hi MarkMLI,

Code: [Select]

++mode 0
++auto 0
++addr 1
++read eoi


Does ++read eoi work with your instrument?

Yes, that was a working example which accepts printout from an HP1630G. However I suspect that the EOI is not in practice issued at the end of a screen (etc.) since the adapter continues to accept data until explicitly told otherwise.

Apropos your

> The HP3457A does not accept the instruction set ++read eoi

Note that the ++ commands are controlling the adapter, not the instrument.

MarkMLl

[tppc]

Note that the ++ commands are controlling the adapter, not the instrument.
MarkMLl

Yes, I know, I've been reading GPIB manuals for weeks 

Regards.

[MarkMLl]

:-) I admit that I've only recently got "hands on" with this particular technology- largely because of the price. I remember when one of the interface chips cost a week's wages...

Slightly later: I've just sent ++rst to the adapter and find that the sequence I gave earlier no longer works. I'll try to look at this later in the day (it might turn out to be something silly like a terminal emulator problem), but what I can say so far is that the instrument is happier with  ++read eoi  than with an unqualified  ++read  command.

MarkMLl

[pwlps]

@tppc

sorry for the delay, I had a hard time finding a functional Installer for SharpDevelop.
(I couldn't make it with the versions available on GitHub.)

I got it from its former official site: https://sourceforge.net/projects/sharpdevelop/

The HP3457A does not accept the instruction set ++read eoi
and this completely blocks the application and the DMM.
Need to restart both the app and the meter.

I just removed the eoi and it works.

This means that your DMM is configured to not to assert EOI and send the a line terminator instead. It is strange because EOI is normally used in the default gpib configuration (this is also the default configuration in all libraries including Visa).  If you remove the "++eoi" option  it might not work for some other instruments which rely on EOI only and don't append any line termination characters.  To make the class configurable for either configuration you might add an option e.g. in the address string so that the address parser could set the configuration accordingly. Another possibility is to use the public flag "checkEOI" defined in the base class.
[/quote]

I plan to modify your code so that only the first Device would configure and open the serial port.
The second device (connected through the same adapter) would then use the same port (without opening it) with a different GPIB address.

Oops, yes of course, this is another bug 
Just add a static flag in the class to remember when the port is open (in C# "static" means a variable shared by all class instances). 

I am trying to learn all this .NET rubbish 

Good luck. I think there is a chance you like the rubbish at the end 

Incidentally I'm giving an introductory C# course (en français!), this is for beginners so there is not much OOP there but if you are interested I can send it to you (I don't want to pollute this forum with attachements in french).


 

[tppc]

Hi there,

Thanks for this information.
As a slow learner, it may take me a few days to get it.   

I tested the EOI configuration with Prologix GPIB Configurator (from John Miles 's GPIB Toolkit).
No succes, the configuration changes from Controller to Device and the app hangs. 


Check your PM. 

Regards.

[MarkMLl]

I tested the EOI configuration with Prologix GPIB Configurator (from John Miles 's GPIB Toolkit).
No succes, the configuration changes (...) and the app hangs. 

But you've already said that

> My GPIB adapter is not a genuine Prologix, but a so called "Prologix compatible"
> Fenrir-Naru clone found on Ali Express for 20$ delivered!
> The PCB is installed Inside the GPIB connector and powered through the USB cord.

It's neither a clone nor a ripoff of a Prologix interface, and it doesn't implement the full set of commands. You're not safe assuming that any software that /does/ require the full set of commands will work with it.

MarkMLl

[MarkMLl]

The HP3457A does not accept the instruction set ++read eoi
and this completely blocks the application and the DMM.
Need to restart both the app and the meter.

I just removed the eoi and it works.

This means that your DMM is configured to not to assert EOI and send the a line terminator instead. It is strange because EOI is normally used in the default gpib configuration (this is also the default configuration in all libraries including Visa).  If you remove the "++eoi" option  it might not work for some other instruments which rely on EOI only and don't append any line termination characters.  To make the class configurable for either configuration you might add an option e.g. in the address string so that the address parser could set the configuration accordingly. Another possibility is to use the public flag "checkEOI" defined in the base class.

I'm currently seeing the same thing with a Fenrir interface and an HP1630G, although I am pretty certain that  ++read eoi  was working yesterday (i.e. before I issued a  ++rst  which means that there might have been some odd state in NVR).

I don't quite understand what's going on though, since I'm using  ++mode 0  (device) while the Prologix manual says that  ++read  is applicable (only?) to controller mode.

I've got to drop this for the moment since I'm also looking at something else with a /dev/ttyACMx device name and I rather suspect that the two devices on the same Linux kernel module are interfering with each other in some way.

I'll be back :-)

MarkMLl
 

[MarkMLl]

Please note that everything I'm writing applies to a Fenrir HP-IB (IEEE-488, GPIB etc.) interface, which understands an approximate subset of the Prologix commands.

The  ++rst  command appears to reset the interface chip, and as such it glitches the USB interface. As a result of this it will probably be necessary to reopen the port from the terminal emulator (I'm using gtkterm on Debian Linux), do not confuse this with the interface or instrument going unresponsive.

The  ++ver  command generates output but appears to have no side-effects, so it is a useful way of making sure that the terminal emulator and interface are still on speaking terms.

The  ++savecfg  command without a parameter does not return the current state.

Below is a sample session bringing everything up from cold and getting printouts from an HP1630G. Blank lines for formatting only, lines starting # are comments and should not be entered.

Code: [Select]

# Connect interface, open using terminal emulator.

++rst

# Re-open port from terminal emulator. Might be slow (bus timeouts?).
# Disable configuration saving, check interface is still running.

++savecfg 0
++ver

# Turn on instrument. Put interface into device mode, specify address 1.

++mode 0
++addr 1

# Terminal emulator now receives printouts.

Expect to see at least some formatting codes even in text mode:

Code: [Select]

Reverse/highlight: <Esc>&dD (Implemented as underline)
Normal: <Esc>&d@

Obviously there's much more formatting if graphics is being sent to the (simulated) printer, this appears to be some variant of PCL for an HP printer rather than Epson codes.

The combination of resetting the interface and explicitly telling it to not save configuration changes will hopefully prevent the water from being muddied by side-effects from previous sessions.

I've had limited success with the  ++lon 1  command so far. What I'd like to be able to see is the disc detection protocol, but I suspect that this interface isn't up to it.

I've played a little bit with controller mode, but not to the extent that I've attempted to fabricate the binary messages that the HP1630 expects.

I've not attempted to mix modes, i.e. to send commands to set the instrument up then wait for printer output.

An HP54501A scope appears to behave fairly similarly: graphics-only hardcopy which I can see using  ++lon 1  (which regrettably doesn't specify what address a block of data has been sent to).

Finally, I think it worth saying again: the Fenrir interface is superb value, but it does not provide a complete or accurate implementation of the Prologix commands. As such, do not expect it to be fully compatible with software written for the Prologix interface.

MarkMLl

[tppc]

Hi there,

The  ++ver  command generates output but appears to have no side-effects, so it is a useful way of making sure that the terminal emulator and interface are still on speaking terms.

The  ++savecfg  command without a parameter does not return the current state.

++ver is also used to detect "Prologix like" adapters in EZGPIB utility.

Screenshot extracted from EZGPIB manual :


I do confirm that the ++savecfg command does not return anything.

The HP3457A does not accept the instruction set ++read eoi
and this completely blocks the application and the DMM.
Need to restart both the app and the meter.

I just removed the eoi and it works.

This means that your DMM is configured to not to assert EOI and send the a line terminator instead. It is strange because EOI is normally used in the default gpib configuration (this is also the default configuration in all libraries including Visa).  If you remove the "++eoi" option  it might not work for some other instruments which rely on EOI only and don't append any line termination characters.  To make the class configurable for either configuration you might add an option e.g. in the address string so that the address parser could set the configuration accordingly. Another possibility is to use the public flag "checkEOI" defined in the base class.

You were right, at power-on, the 3457A is configured to NOT assert the EOI line.
Sending the "END ALWAYS" or "END 2" commands resolves the issue.

In the manual, the "Default control" expression is a bit tricky, it does not mean that the instrument is set to that value by default.
It means that if you issue the command without arguments, it will then be set to the Default control value.



PS. I am still working on a modified version that would allow the second device to use the same COM port as the first device.
(No succes for the moment  but I keep on working)

Regards

[IanJ]

Hi all,

Thought I'd share the mother of all VB forms.

So when I am making a batch of PDVS2mini's and considering I am trying to combat DAC INL issues I have 11 setpoints 1V apart across the 0 to 10V range instead of just the two (min and max).
The problem is that it takes forever sat in-front of each PDVS2mini and setting the cal values (counts) until it reads correct on my 3458A. Each PDVS2min is a little different in Cal so there's not a magic set of default counts that can be loaded at first boot. LM399's can be quite different from eachother not to mention other components.

But wait a minute.......I have the 3458A connected via GPIB to my PC, and I have the PDVS2mini also connected via serial comms/USB......so why not write a wee app to auto-calibrate the PDVS2mini just by hitting "Go".

Tonight I finally got around to writing the code given I have a big batch of PDVS2mini's awaiting calibration (currently soak testing).............Oh! this will be sooooo much easier now!

See attached.

Notes:
- Sample rate of 3458A is set in the logging app to 0.5sec, and a real low NPLC.
- The sample comms rate of the PDVS2mini comms is 110mS.
- The count step size usually 50 or 100 counts.
- The idea is that this app does the grunt work and I finish off manually knowing I am just a hundered or so counts out.
- Usually the gain of the PDVS2mini default cal settings is low.....and which means the cal gets slower as it progresses towards 10Vdc (step size always 50/100). I am simply stepping through it, but I gues a better/quicker way would be to calculate the new cal values based on a couple of test values sent to the PDVS2mini for each voltage. A job for another day.

Ian.

[tppc]

Hi Ian
Thanks for sharing 

- Usually the gain of the PDVS2mini default cal settings is low.....and which means the cal gets slower as it progresses towards 10Vdc (step size always 50/100). I am simply stepping through it, but I gues a better/quicker way would be to calculate the new cal values based on a couple of test values sent to the PDVS2mini for each voltage. A job for another day.

Just a quick suggestion;
why wouldn't you program "sort of" a Proportionnal controller that would execute in a loop.

For each of the 11 cal points
    Execute in a loop
        Read meter
        Calculate Deviation   
        counts = counts + Pn * Deviation
    Stop the loop when Deviation within acceptable tolerance
Stop the loop when all 11 cal points done

where :
Pn = Gain of the "Proportionnal controller" for calibration point number n (use a different gain for each cal point)
Deviation = (3458A actual reading - Setpoint) or the opposite, depending on how the counts influence the reading.

Regards.

[IanJ]

Hi Ian
Thanks for sharing 

- Usually the gain of the PDVS2mini default cal settings is low.....and which means the cal gets slower as it progresses towards 10Vdc (step size always 50/100). I am simply stepping through it, but I gues a better/quicker way would be to calculate the new cal values based on a couple of test values sent to the PDVS2mini for each voltage. A job for another day.

Just a quick suggestion;
why wouldn't you program "sort of" a Proportionnal controller that would execute in a loop.

For each of the 11 cal points
    Execute in a loop
        Read meter
        Calculate Deviation   
        counts = counts + Pn * Deviation
    Stop the loop when Deviation within acceptable tolerance
Stop the loop when all 11 cal points done

where :
Pn = Gain of the "Proportionnal controller" for calibration point number n (use a different gain for each cal point)
Deviation = (3458A actual reading - Setpoint) or the opposite, depending on how the counts influence the reading.

Regards.

Absolutely!...........It was just easier for me as a first hit and as a hardware guy who tinkers with VB to do it the way I did and I wanted it up & running in minutes rather than hours.
I'll get back to it at some point and improve on it and more in line with your suggestion........I also want to see how accurate I can get the calibration without having to hand tweak it afterwards.

Ian.

[tppc]

...I also want to see how accurate I can get the calibration without having to hand tweak it afterwards.

Ian.

I am curious to see that too 
- Be prepared to see Deviation getting negative and oscillate around 0 before it stabilizes.
- It may not stabilize if Pn is too high.

Regards

[IanJ]

...I also want to see how accurate I can get the calibration without having to hand tweak it afterwards.

Ian.

I am curious to see that too 
- Be prepared to see Deviation getting negative and oscillate around 0 before it stabilizes.
- It may not stabilize if Pn is too high.

Regards

I made some mods this morning (haven't implemented the deviation calculation yet). Here's what happens now:

1. Set all 11 setpoints to arbitary value known to be a fair average between many units tested.
2. Run a pre-cal on setpoint 1 & 2 (0.00000Vdc & 1.00000Vdc), now capable of counting up/down in a loop till target is achieved. Settings are 5 bit steps and +/- 0.00010Vdc target accuracy.
3. Use the values from this to calculate the pre-cal values for setpoints 3 to 10.
4. Run a tighter calibration run across ALL setpoints. Settings are 1 bit steps and a +/- 0.00002Vdc target accuracy.

The 3458A GPIB is running at a sample rate of 0.4sec and an NPLC of 5......at the moment.

One of the limitations to running too fast on the PDVS2mini comms is the settling time of the analogue output, so I have implemented a delay at certain parts (within loops) just to give the analogue hardware a chance. This kinda makes the deviation calculation method even more useful if I can get around to it. However, I like trying different methods............but I will get there.

PS. A typical turnaround time to calibrate is 10mins, depending on how long Init-cal of setpoints 1 & 2 take, i.e. how far off the arbitary values are.

Great fun anyways!.....and this is saving me TONS of time calibrating many PDVS2mini's.

INIT-CAL: You can also see the arbitary values for the setpoints, big round numbers.


FINAL-CAL:


FINISHED:

[tppc]

PS. A typical turnaround time to calibrate is 10mins.

Do you mean 10 min for 1 CAL point or all 11 points?

The Proportional gain method should save you the init calibration phase.

P.S. Looks like we got you working hard! 

Regards.