Python concludes instrument set has finished before device has set value
- Dominant language
- Python
- Stars
- 459
- Forks
- 359
- Avg merge
- 3d 6h
- Merged PRs (30d)
- 73
Description
A blocking get implemented by always calling get after set solves two problems
1. Python concludes instrument set has finished before device has set value (on TCPIP, see below)
2. Takes care of any rounding or converting an instrument does.
I think this makes sense as a default behaviour for **any** set function. The parallel processing of the measurement loop should ensure the desired non-blocking behaviour for other cases and ensures proper waiting for completion before moving on to a critical step
### Steps to reproduce
1. Call a set on an instrument controlled over TCPIP
2. Get/measure some parameter on another device sufficiently fast
3. In rare cases you will get the value before the first device has updated it's settings
Note: this does not involve any parallel processing but it will also break loops using parallelism if they wait for a non-block condition.
### Expected behaviour
The get-command should wait for the initial instrument to finish setting.
### Actual behaviour
It waits for the command to finish (that is the command to be dumped in the TCPIP queue) but python concludes the command is completed before the action has been executed on the hardware.
### Proposed solution
Add an argument to parameters (upon initialization) that is get_after_set. When this is True it will always call the get_command of the instrument after the set command. This will ensure the stored value in the log is correct (as sometimes instruments round values or do similar changes).
I expect the wait for the response on the get will ensure the command is only considered complete after the device has updated it's setting (as it goes over the same communcations).
This can be tested in a testsuite by having some virtual instrument in which there is an artificially long set-command and multiple communications to the virtual instrument.
### System
**Winows 7**
**cf4d6f3**
Contributor guide
Research direction
Start by tracing the parameter set and get_command paths for TCPIP instruments, focusing on when command completion is reported versus when the hardware applies the setting. Add coverage using a virtual instrument with an artificially delayed set command and multiple communications; done means a following get waits for the setting and records any instrument rounding or conversion.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100