Honestly I was surprised to find that Mango does not check for extreme outgoing values. It is seriously problematic on multiple levels, and I feel strongly that discarding extreme values must occur by default when setting a point value, even if that is done only on the back end, with no front end interface changes. When I first posted this, I thought it was a bug.
We must not assume that just because certain equipment supports a particular value setting, the process or application that it controls should accept the value without causing harm. We must also not assume that all PLCs in different devices at a site are available for customization by their end users, nor that the Modbus device is a PLC at all.
Picture a scenario where you have an oven that can be commanded to heat anywhere from 25 to 200 Celsius. The oven is an off-the-shelf device whose firmware is not customized by the end user: it just does what is commanded.
In your process, you do not want to heat the contents above 75 Celsius because it will damage the batch. The operator usually enters a number between 25 and 75 Celsius, but one day he enters 96 instead of 69 Celsius, which destroys the batch. Moreover, if the admin had configured "Discard extreme values" to 75 Celsius, the typo would neither be caught nor logged by Mango, and the user would not be alerted. I think this is dangerous.
This is made more dangerous by the fact that when extreme values are set:
- the extreme values are rejected by meta data points but not by Modbus points.
- the extreme values are not displayed in any of the Modbus point views
- the user is not alerted about the entry error
The Meta data point extreme value behavior seems to be what users would expect, but the combination of "proper" metadata extreme value behavior and extreme value hiding by Modbus points leads admins into thinking that extreme Modbus values are rejected. I would not have discovered that they are not, were it not for tcpdump and a Modbus device that contains a derived value at another register address.
I could cite more examples using liquid levels, voltages, currents, etc, where the equipment manufacturer allows a wider range of values than what would be desired for the particular application. It is impractical and often infeasible for each manufacturer to customize their equipment to each application; that can be done by customized end-user software at each installation site. Even if the PLCs are configured for a certain value range, Mango must allow that value to be further constrained by the point configuration.
The obvious short term solution to prevent this dangerous behavior is to apply the extreme value range when the point value is set. I truly believe that is the configuration most users would want, and may in fact think they have. I think this should be a priority.
Do you think it is better to tell the user they are wrong in setting such a value or to have the data source send and record the extreme value?
I think it is safest to reject the value rather than setting the limit value on the Modbus device: when there is an error, it is best to assume it is a typo rather than a deliberate error. The user has the opportunity to manually enter the limit value after reading the alert. The alert should include the value limits, the entered value, and the point name.
Longer term solutions could be applied, but I don't consider them a priority compared to limiting the set value on the back end, with no front end changes. For instance:
- Immediately alert the user when discarding an extreme value that was set.
- Display the extreme value range next to the point value data entry field
- Allow separate extreme value settings for data entry vs. logging. I cannot think of a use case for this, even though it is the current behavior, in that the current range allowed is different: it is the entire floating point value range.
If any changes are made to the extreme value point logging code, rather than the above listed options, I think it makes more sense to allow the user to choose an event level to generate when extreme values are discarded. However, implementing the ability to limit entered point values for Modbus points rather than just Metadata points should be a high priority. I consider it a bug fix, because I cannot think of a reasonable scenario where a user would want to reject read and logged extreme values but not reject set extreme values.