GPIB-ENET Support under Windows 10

[joeqsmith]

Finally had a few minutes to have a look at it.  I started out just sending a very simple command to an instrument.  Looks like it opens to port 5000 and only seems to use TCP.   Once it gets beyond what appears to be some sort of setup, there does not appear to be a whole lot in the commands.  Maybe one that looks like it sends out the size of the next message.   Let me see if I can get a simple multiplexer working with just using the Ethernet support.  

[joeqsmith]

Put together a very crude program in Labview to cycle the mux that is sitting on the GPIB-ENET using the Ethernet library and it works.   

It appears there are fourteen messages sent after making the connection that are used for some sort of setup.  These do not appear to change and are handled by Labview without sending any commands to the GPIB bus.   As far as then sending a command to the GPIB bus, it looks like there are three messages sent.  It looks like the first tells the GPIB-ENET what to expect, followed by a constant (maybe a finish if you were stacking GPIB commands) and finally the GPIB command.  Right now I am just sending a couple of bytes to the mux.   I'll try some different size data sets and try reading back some data and see how this works. 

So far it does not appear to be a big deal to make it work.  I'm surprised support for it was dropped.  

[RenKylo2]

Hey Joe!

That is pretty neat! Sounds like you are making some pretty good progress. Our R&D Department determines how long we support a certain product. I personally don't know the details, but I would think the decsion depends on the amount of resource they would spend on updating the driver and return in value.

If you think the your code can be a great example, I encourage you adding it to the forum as an example program and share the knowledge! 

[joeqsmith]

I changed to using an HP 34401A multimeter for a test device.   Have the raw Labview Ethernet talking with it now and displaying the voltage off it. 

I've maybe spent three hours on it now with no documentation and I can't belive it would have been a big deal for the team that actually had the documents for it. 

There are some things that I could really use some help with.   When you send out a GPIB command, you send a TCP message something like:

3400 0001 0000 0017 0000 0002

It appears the 34 is for a write and a 31 is for a read.   The 17 seems to represent the bytes sent, sort of.  I have seen cases where it is 1+ the number of bytes as well (if the payload is 2 bytes for example it sends a 3).    The rest I have not seen change but have I not done a very exhaustive test.

The next TCP message is who knows what. It's always two bytes.  It does not appear to be a checksum or number of byte in the out going or incoming.  Any help on how this is calculated would be great.  

Next is the command.

[joeqsmith]

Got it.  It looks like it's the GPIB address.    I wonder if the device address it embedded into the TCP read message.   Lots more testing to do.