Minimum resolution advertisement in type tags

[DanielSank]

A device which allows setting volgate levels should be able to specify the minimum allowed resolution for that voltage. I think this would be a useful feature in the next version of the protocol, and it might solve some other outstanding issues.

Will add LabRAD2 tag if/when others agree.

[DanielSank]

Even just suggestions about how this should work are useful. Don't have to solve the entire problem right now.

[DanielSank]

See #8 for some discussion.

[ejeffrey]

This is an interesting idea. It could also be nice when writing servers to go with @maffoo's ideas about plugable unflattening of data. So if I made a setting like:

@setting(ID=1234, f='v[Hz:102mHz]')
set_frequency(self, c, f):
    '''takes an integer f in native DAC units'''

Then: the setting would be advertised as receiving a number in Hz. The client could query metadata to find that the resolution was 102 mHz. The server could accept data in any frequency units, but pylabrad will convert to an integer multiple of 102 mHz before calling set_frequency. This would make easy interfacing with hardware that expects integer commands for instance. Finally, we could allow clients to directly send the integer representation under some circumstances -- they would have to make an explicit choice to call the integer version of set_frequency() or pass some 'raw' flag, but that would be automatically generated from the @setting decorator metadata.

We would have to figure out what the client side version of this looks like, especially if there are multiple arguments with units -- it needs to be a per item flag, we don't want to just generate a combanitoric explosion of options. Also, I am not sure what the wire format should look like.

The question is, is this actually worth it? Most of the time we don't care about the exact hardware resolution. Further more, we are always going to miss cases where our API doesn't match up to the hardware capability (i.e., consider hardware that makes voltages of the for (ax+b), or a frequency synthesizer that can make frequencies that are rational multiples of some base clock. Is it worth creating a new API for the handful of cases that would use it, or should we just do ad hoc solutions customized to the situation that requires it