pyvisa / pyvisa-sim

A PyVISA backend that simulates a large part of the "Virtual Instrument Software Architecture" (VISA_)
https://pyvisa-sim.readthedocs.io/en/latest/
MIT License
69 stars 39 forks source link

multiple instances of ResourceMaganer #68

Closed yn4k4nishi closed 1 year ago

yn4k4nishi commented 1 year ago

when I create multiple instance of ResourceManager, dialogue response is wrong. Is it not recommended?

my environment:

MatthieuDartiailh commented 1 year ago

Could you provide a sample script illustrating your issue ?

bilderbuchi commented 1 year ago

Not sure what @yn4k4nishi means, but I also observe weird problems running pytest tests with pyvisa-sim backed fixture objects, in that replies remain in a read buffer despite the objects + resource managers being destroyed:

>>> import pyvisa
>>> rm = pyvisa.ResourceManager(visa_library='@sim')
>>> instr = rm.open_resource('ASRL2::INSTR')
>>> instr.write('*IDN?')
7
>>> instr.read()
'SCPI,MOCK,VERSION_1.0\n'  # OK, that's what I expect
>>> instr.write('*IDN?')  # we don't fetch that response from the instrument
7
>>> id(instr)
140011221241280
>>> del instr  # Kill the instrument
>>> del rm
>>> rm = pyvisa.ResourceManager(visa_library='@sim')
>>> instr = rm.open_resource('ASRL2::INSTR')
>>> instr.read()  # Why is this response in this different instrument object?
'SCPI,MOCK,VERSION_1.0\n'
>>> id(instr)
140011221241472  # the IDs of the instr objects are different, so it's not somehow the same

Is that expected?

MatthieuDartiailh commented 1 year ago

Here you are assuming that when you delete the instr and the resource manager they instantaneously go away. This may not be true because the rm and the library object are in a reference cycle and the gc may dispose of them only later on. Could you run the same code but explicitly closing the instr and rm rather than relying on __del__ being invoked.

bilderbuchi commented 1 year ago

Ah, you are right. instr.close() is neither sufficient nor necessary, rm.close() does the trick. Thanks! Argh, Python's behaviour around __del__ is annoying at times. :angry:

MatthieuDartiailh commented 1 year ago

The fact that closing the instrument does not solve the issue still says that something is off. Instruments do not share outgoing buffers between connections and we should mimic that.

bilderbuchi commented 1 year ago

The fact that closing the instrument does not solve the issue still says that something is off. Instruments do not share outgoing buffers between connections and we should mimic that.

@MatthieuDartiailh is that something that still should be followed up separately? (to avoid this disappearing in a closed issue comment)

MatthieuDartiailh commented 1 year ago

It would make sense yes