intent to merge Ulf's changes ?

[fenugrec]

Hi,
I'm trying to combine bits and pieces from the various forks of this project... seems like @ulda has a few unmerged branches that can be cleanly rebased + applied on this repo.

It would be nice also to add a 'pyvisa bridge' like what https://github.com/PhilippCo/python-vxi11-server has; (I'm in the process of making that file slightly less hardcoded ). Ulf has a 'GPIB bridge' but I'm not sure exactly how to make it work.

Am I just wasting my time and everybody just does their own personal fork ?

[ulda]

hi, ulda here.
my branch was motivated by a problem at my former employer tdk.
i fully emulated a gpib-ethernet bridge für a machine that used to need one.
this is mostly special functionality, but does not interfer with normal functions and could be merged.
i already upstreamed the common usable parts like bugfixes and srq interrupt usage.
so you can cherry pick or leave it rotting :-)
bye
ulf

[coburnw]

Thanks for the interest!

I'd welcome any bug fixes, enhancements that are focused on the vxi-11 specifications, or clean up the interface to make it easier to share with others applications. Any examples that are strictly focused on testing a specific feature of the library, while demonstrating its use should get consideration also.

Ulf had offered up changes to make the library pip installable which i regret not accepting at the time, as i have re-implemented it at least three times since while flip-flopping on whether it makes sense or not. Sorry Ulf!

While building your pyvisa-bridge, im sure you will come across errors or omissions in the library. Please be sure keep in touch.

[fenugrec]

Thanks @ulda for clarifying. I thought I had seen a few stray commits in your gpib-* branches that were unmerged but didn't thoroughly check.

Good to hear from you too @coburnw . I rebased @PhilippCo's pyvisa-bridge and updated a few methods to match new signatures; quick tests seem OK but it seems like propagating errors is problematic. i.e. if the bridge gets a timeout or other error (while talking to physical hardware), the nature of that error is lost through the vxi11 connection.

I also notice some odd delays while testing invalid commands (i.e. misconfiguring the bridge in a way that it can't be initialized) before the client gets (or reacts to) a response.

TTYL