Keithley2700: handle overflow/NaN in timestamp

[FreddieAkeroyd]

As a user of the Keithley 2700 I would like the IOC to handle an overflow in the timestamp.

It looks like the device started returning "+9.9E37" which from the Keithley 2700 manual "An overflow reading is returned as +9.9E37. When a specified data element has invalid data associated with it, NAN (Not A Number) will be the response. NAN is returned as +9.9E37".

Normally the Keithley returns a comma separated list of values in groups of 3 numbers, however the IOC log gives:

Incorrect number of values read 2
2023/05/21 23:59:51.272985 L0 IN:HIFI-C11:KHLY2700_01:BUFF:READ: 11 bytes surplus input "+9.9E37,203"
[2023-05-21 23:59:51] 2023/05/21 23:59:51.273271 L0 IN:HIFI-C11:KHLY2700_01:BUFF:READ: after 30 bytes "...6E+03,3.74727466E+03"

The returned data should be "Value,timestamp,channel" style so as 203 is a valid channel seeing "+9.9E37,203" would suggest the full data returned was xxxxxx6E+03,3.74727466E+03+9.9E37,203 so the timestamp field is then 3.74727466E+03+9.9E37 which does not parse as a valid floating point format. I am surprised by this as I would have expected just "+9.9E37" for an overflow. If this analysis is correct, it would suggest the keithley timestamp overflowed however the strangeness of the format of the number might suggest instead data corruption within the Keithley buffer. Unfortunately we can't see the full part of the previous number, just that it ended in "6E+03", so it might be "3.74727466E+03+9.9E37" is a repeat of the previous number concatenated with an overflowed timestamp, or it is just a coincidence that both ended in 6E+03. It looks more like the former.

Acceptance criteria

• A field like 3.74727466E+03+9.9E37 is converted to +9.9E37 on read so is paresable as an overflow

To Test

• If ioc tests are run with original .proto file they will fail