search

coburnw / python-vxi11-server

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

Multiple create_links create multiple instrument instances and do not return the same link #23

Open ignamv opened 4 months ago

ignamv commented 4 months ago

Hi,

First of all thanks for this project, it's super useful for mocking instruments so I can test my drivers.

I made a mock instrument which worked OK when talking to it using Keysight Interactive IO, but I got errors when talking to it from another measurement software (IC-CAP). IC-CAP's VISA calls end up making two connections to the instrument, each of which calls create_link. Then it sends on one connection commands meant for the other link (which causes an "invalid link ID" error in the Vxi11CoreHandler methods)

One additional problem was that each connection creates a new instance of the instrument class. If this is supposed to mock a real lab setup, multiple connections should go to the same instrument (so changing an instrument setting in connection 1 has an impact on connection 2).

I made some quick and dirty changes to python-vxi11-server which allow this to work. Before, the Vxi11CoreHandler instances had their own instrument instance+link id, and would check that the incoming command's link id matches. Now, the instrument instances live on the Vxi11Server. The instrument instance and link are created earlier, in register(). create_link now simply returns this existing link (with repeated calls returning the same). The handler methods in Vxi11CoreHandler now just fetch the correct instrument instance from Vxi11Server based on the command's link id. destroy_link does nothing now.

Justification

I believe the VXI-11 specification says that create_link should return the same link (or at least the same abort port) when called multiple times, and should support at least two links.

RULE B.2.7: The network instrument server SHALL return the same abort port number in all replies to create_link sent on the same core channel.

image

After the first create_link, the network instrument client may create an RPC client for the abort channel, but no additional client creations are necessary after subsequent create_links. These connections may be torn down by the network instrument client once all links have been closed with destroy_link. The whole sequence could then start over.

RECOMMENDATION B.4.1: An instrument's host should support at least two network instrument servers simultaneously.

RECOMMENDATION B.4.2: An instrument's host should support simultaneous routing of at least two links to any device. The links may be through the same or different network instrument servers. RULE B.4.1: A network instrument server SHALL support links to every device accessible to any other network instrument server in the host. OBSERVATION B.4.3: The intent of this rule is to prevent the dedication of particular devices to particular network instrument servers.

If we can agree on the correct behavior should be, then I can polish the changes and make a merge request.

coburnw commented 4 months ago

Im glad some are getting use out this project. Thank you for your interest and the star! It has been a long time since i have had my head this far into the guts of vxi11, but here are some thoughts:

data sharing: How about making device parameters common between links/instances class variables of the device? Each instance of the same device can then share the variables it chooses with its siblings while maintaining some autonomy.

Another option might be to have the registry pass a data structure to each instance on creation, much like the lock. But thinking about this, perhaps i should have made the lock a class variable of the device and let the device deal with it.

_linkid's: In my mind, create link should create a new link_id, not return an existing link, See Rule B.6.3. I think the takeaway of Figure B.8 is that the two instrument servers are sharing lock information. I dont think the use of a common name of link1 in the figure should imply a common link_id.

Would you mind if we try to find a way to share variables first then attack the problem you are seeing with IC-CAP and multiple links? This might give me some time to get back up to speed. And yes, i would very much appreciate any help you might like to share.

Coburn