But now the issue is in the attributes readout. I general, for all this classes, when you ask many things this is asking to the low level "Visa" device and transmitted to the hardware. Even if you ask many things at the same time (this often happens with the oscilloscopes) each is ask separately.
First improvement: multiple readings.
Apart from the read_attribute() method of the device API, there is a read_attributes([]). Doing a call to the first option, the flow calls previous methods like always_executed_hook() and read_attr_hardware(). This last one, have a list of the attributes who can do a pre-read action. With the current release, the multiple attribute read, is not optimum.
The real read is when the internal methods read_XXX() (where XXX means the name of the attribute) is called. This is, when the multiple-reading is executed, the device acts in the same way than do a simple-reading n times.
The visa protocol, allows the possibility to concatenate queries to the hardware below. With this read_attr_hardware() we can centralize in the code the common way to read and optimize it.
The input parameter of the read_attr_hardware() is a list of integers. With the MultipleAttribute class I would have the attribute objects to know to who the read action is requested.
Time to code and test it.
No comments:
Post a Comment