instruction times should be quantised to the pseudoclock clock_resolution

[philipstarkey]

Original report (archived issue) by Shaun Johnstone (Bitbucket: shjohnst, GitHub: shjohnst).

---

As per pull request #11, there is a bug where the 'extra clock tick' that can be inserted just before a break in a ramp* may be shortened incorrectly (and thus tick faster than the allowed clock_limit rate of an attached ClockLine) due to the quantisation of the pseudoclock.

EDIT: This was reported by @philipstarkey (@shjohnst was just logged into the PC)

---

* The break in ramps is a result of labscript automatically splitting ramps when another output needs to be updated during the middle of a ramp

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

• Edited issue description

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

• Edited issue description* changed title from "instruction times should be quantised to the pseudoclock clock_limit" to "instruction times should be quantised to the pseudoclock clock_resolution"

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

• changed state from "new" to "resolved"

fixes issue #40

• We now quantise all times to multiples of the pseudoclock clock_resolution.
• changed some error messages to report times, and to report the times to more significant figures so it is easy to see if the discrepancy comes from floating point rounding error)
• Added a method to Device which allows you to quantise times based on the clock_resolution of the parent pseudoclock device.

→ \<\<cset 32213b7c667309f54327390561284bf7202e3b8e>>