The accesses to -KEC1 always time out on the attempt to update the
output values. We noticed that this is related to the timing between
the reading of the inputs and the following write to the outputs.
Fix -KEC1 accesses by waiting before sending the next request to the
board after receiving the reply for the previous one.
When one device fails, this should not influence updates of the other
devices. Thus, early return was the wrong strategy here.
Instead, when communication with a device fails, skip the process data
update and continue with the next device.
We noticed huge load spikes with the latest changes. This was caused
by the modbus goroutine blocking the entire daemon for long periods of
time while doing its data transfer.
Fix this by only holding the lock while performing data accesses.
This mount is a new iteration with the following improvements:
- 25% less DIN rail space required. This allows installing 25% more
Modbus-based technology!
- Designed for a clip that can be unlatched more easily.
- Fixed the BeagleBone hole pattern to match reality (why BeagleBone,
why D:)
Another HP HMI thing: "Only show information that is immediately
relevant". Let's hide the pirani voltage as it is mostly no longer
interesting to the user. For situations where it is, it can be revealed
by hovering over the pirani pressure value.
In the process automation world, there is a trend to move away from
colorful user-interfaces, towards more "boring" colorschemes. The
argument is about situational awareness - by only using colors to
highlight abnormal situations, they become instantly recognizable to the
operators.
This design philosophy is outlined by the ISA-101 [1] under the name
"High Performance HMI". While it covers much more than just colors, I
think this is the most important part and the one that is most
applicable for our usecase.
So let's do a bit of HP HMI - reduce colors usage such that only
important information is highlighted.
[1]: https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa101
Add a hysteresis value that can be optionally configured for
thresholdOutput blocks. This will hopefully help to prevent jumping
outputs from feedback that is caused by the thresholdOutput itself.
This improves the structure of the code, separating the data/control
interface out and then implementing the http interface as a user of this
interface.
Rahix
Serge Bazanski