- Generated by
1.9.8
|
Motion Master 6.0.0-alpha.86
Next-generation motion control software
|
The maximum one firmware latency reached, as command 22 reported it. More...
#include <somanet_drive.h>
Public Member Functions | |
| std::string | describe () const |
| One line describing the reading, ready to put in front of a user. | |
Public Attributes | |
| somanet::FirmwareLatency | latency {somanet::FirmwareLatency::kSetpoint} |
| Which latency. | |
| uint32_t | maximumNanoseconds = 0 |
| uint32_t | configuredNanoseconds = 0 |
The maximum one firmware latency reached, as command 22 reported it.
A pair, and the second number is the point of it. The drive records the latency's own maximum, and alongside it whatever latency was configured at the moment that maximum happened — so the two together say whether the configured figure covered the worst case actually observed. The configured number is taken from a different firmware variable for each latency (the DCS/MCS alignment offset for kSetpoint, the estimated upstream processing time for kFeedback), which is why it travels with the latency it belongs to rather than on its own.
Both are zero on a drive that never measured anything, which is indistinguishable from a genuine zero: the firmware records a value only while the measurement is enabled, and nothing reports whether it is. A zero pair means "no measurement ran", in practice.
| std::string mm::node::FirmwareLatencyResult::describe | ( | ) | const |
One line describing the reading, ready to put in front of a user.
| uint32_t mm::node::FirmwareLatencyResult::configuredNanoseconds = 0 |
The latency configured when that maximum was reached, in nanoseconds — same unit, same width, same ceiling.
| somanet::FirmwareLatency mm::node::FirmwareLatencyResult::latency {somanet::FirmwareLatency::kSetpoint} |
Which latency.
| uint32_t mm::node::FirmwareLatencyResult::maximumNanoseconds = 0 |
The largest value measured since the measurement was started, in nanoseconds.
The drive sends 10 ns units in 24 bits, multiplied out here because nanoseconds is exact for every value it can send. That width is also a ceiling: a latency above 167.77 ms is truncated by the firmware as it packs the reply, not reported as an overflow.
1.9.8