-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for query() in transactions #99
base: master
Are you sure you want to change the base?
Conversation
@@ -452,34 +452,40 @@ def write(self, message, *args, **kwds): | |||
|
|||
>>> inst.write('source{}:value {}', channel, value) | |||
""" | |||
full_message = message.format(*args, **kwds) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps this could be refactored in some way to avoid duplication with the code below in query()
I don't think it makes sense to change the behavior of class MyDevice(VisaMixin):
def maybe_do_something(self):
if self.query(':state?') == 1:
do_something()
def do_more_stuff(self):
with self.transaction():
self.maybe_do_something() # This call behaves unexpectedly If you find it useful to chain queries together, then maybe we should add an explicit way to do it? I'd be curious to see what you think. |
I'm not sure how you would ensure that query() returns something within a transaction since you have to string the whole message together first and then exit the transaction to flush the queue. This may require some decorator magic. Currently I use the functionality like this:
As far as I can tell the existing functionality for query() calls in transactions is only to flush the message queue. In this change transaction query() calls will be returning data in the order in which they are called. |
I think you would need something to track the variable after it's already inside the transaction. Not sure if that's possible:
|
It is possible to mix write() and query() calls in transactions. Only tested with Rigol instruments (DS1054, DG811, DP711).
As seen in the updated documentation:
Some instruments (Rigol DP711) do not support multiple commands for which transactions will not work as intended.