search

coburnw / python-vxi11-server

A VXI-11 Instrument Server written in Python
27 stars 13 forks source link

Gpib bridge #6

Closed ulda closed 3 years ago

ulda commented 3 years ago

Hi I am trying to fake a device on a gpib bridge. Therefore i implemented some features from the VXI-11.2 spec I also had to clean up the use of link_id for the callbacks feel free to pull this fully or parts of it.

coburnw commented 3 years ago

Hi, Glad to see some are getting some use of this project.

Not knowing your project goals and having never investigated a gpib bridge, please take the following as conjecture only. Maybe @thasti has more insight?

VXI-11.2 Section B.1 states that the name parsing is to be handled by the InterfaceDevice, implying that the handling of names in the Vxi11CoreHandler may not be your best bet. Frankly, the 'inst0' related code should be factored out of the CoreHandler, it is misleading if nothing else.

Have you tried extending an InstrumentDevice class and using add_device_handler to register with a device string of, say, 'gpib0,12'?

Please keep me posted. It would be nice to ensure the library has the proper hooks in place to to be used in a bridge.

thasti commented 3 years ago

Have you tried extending an InstrumentDevice class and using add_device_handler to register with a device string of, say, 'gpib0,12'?

That's exactly what my bridge implementation does. @ulda in case you are not aware, you can find it here: https://git.loetlabor-jena.de/thasti/tcpip2instr/-/blob/master/tcpip2instr.py

It does not modify anything inside python-vxi11-server (and I did not feel it was necessary to do so). Still, please consider my implementation a 'hack', I haven't really gone into VXI-11.2 to build this. If it is of general interest, I'd be happy to include it as part of the demo_servers. It may require some very small fixes for the recent python3 updates, I could check that and make it a PR?

ulda commented 3 years ago

Hi The problem is that I need a full stack emulation because the system I'm using wants to talk to an E5810B. I'm glad that it was possible to disable SRQ usage, else I had to hack and implement the interupt callbacks, too.

So I'm subclassing DefaultInstrumentDevice and implement device_clear(), device_write() and device_docmd() (with all that ATN,REN,SRQ ... support) and use this to register as gipb0 vxi11.2 sais that you have to use the default device to do the bus control. The device_docmd() calling part in InstrumentServer had some bugs I corrected to have a clear call interface and correct parameter packing.

Then I'm subclassing InstrumentDevice to fake my device and register it as gpib0,1. The system that is interfacing to my script wants to use the handle to gpib0 and send a device_clear() via the gpib0,1 connection - perfectly allowed by spec. So I added a function to the error path of the link_id checks to refer back to the default device if the link_id is active.

That all works with my testing script and the next two days I will find out if it works in real environment.

coburnw commented 3 years ago

@ulda Thanks for patches. They were quite helpful. @thasti I wonder if it would be ok for me to add a link to your repository in the readme?

thasti commented 3 years ago

For sure, appreciate the link!

ulda commented 3 years ago

I get my test on Wednesday. If this works i'll try to create an example implementation of it

coburnw commented 3 years ago

Many of these commits were merged into master. Many thanks for the srq work. c.