-
Notifications
You must be signed in to change notification settings - Fork 0
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
error handling support in Lantz #16
Comments
Nice! Lantz is undergoing a large refactoring. With the same spirit, but with a larger community we are trying to build a better Lantz. Better error messages is definitely an area to work. I would say something like this is in principle interesting, but should be done for the current develop which is still very fluid. Join our discussions. |
This should be in the standards (in lantz_driver) as it relies on SCPI. But given how slowly we are making progress don't expect it soon. |
@phsdv Would you like to look at it and contribute? |
Yes, I want to help with this. Probably I will need some pointers as I do not know the internals yet of Lantz. |
Question, clearly I am still learning the concepts, an error checking action as described above, should this be in the IEEE4882Driver (lantz\drivers\ieee4882.py) class? More in general, what functionality is supposed to be in the MessageBasedDriver, IEEE4882Driver or SCPIDriver? I am a bit confused on the terminology, I see that many drivers are using the MessageBasedDriver class, while they are also IEEE4882 devices. And I do not see a link between the two. Or shoudl a real IEEE4882 instrument inherent from both the messagebaseddriver and IEEE4882driver? |
Actually we split the lantz project so the lantz repo is NOT the place to look into anymore. The lantz_core repo defines the internal machinery used by all drivers, and the backends (ie VISA, direct dll calls, etc)VisaMessageDriver is defined there. The lantz_drivers repo defines the actual drivers and the standards base classes. Sadly we have not yet agreed on a single driver. However you can look at the DC Sources PR if you are interested. Once again you will find a ieee module with commands such as *ESR?, and a package SCPI. Please note that not all SCPI compliant instruments are IEEE488 compliants so ideally those should be decoupled. One way to do that would be to redefine query in VisaMessageDriver by adding a call to a no-op function checking for errors (PR in lantz_core), and implementing this function in specialized subclasses (IEEE, SCPIErrors, ...) (PR on my PR DC Sources, otherwise we would end up with a lot of conflicts). |
In the tutorial you have an query function with error handling, like this:
However not every instrument will send an error back but set an bit in the ESR register
So I propose something like this:
The first new part will check the ESR bit to see if an error exists and what kind of error it is. The print statement should be changed to the Lanz equivalent logging function.
The second part reads out the Status Error. Depending on the equipment used this might not be supported or use an different command. There could be multiple errors stored therefore a while loop is used. Something similar should be done for the write command, as this can generate errors too.
Do you think this would be worthwhile to integrate into Lanz? And only enable it by the driver if the instrument supports it.
For example the Yokogawa WT310 supports this and the command to read out the error status is ":STATus:ERRor?". The Agilent DSOX-3000 scope has the command "":SYSTem:ERRor?"" for this. And the TTI CPX400P power supply uses "QER?". Therefore each driver should define this error command and if it is defined the errors will be checked as described above.
What do you think something worthwhile to integrate in Lantz?
The text was updated successfully, but these errors were encountered: