-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Event detectors - Add the option of a limit defined by another datapoint #2784
Comments
@fabiodurao, according to our architecture, actions are implemented by Event Handlers, not detectors, these are only used to detect some state. We have a Set Point Handler that performs this task. We can connect many such Event Handlers to each detector, so this proposed setting is unclear what it would mean and would cause confusion. Regards, |
@Limraj I believe you didn't understand what was proposed. We are not talking about taking actions, but rather triggers for taking actions. The current limitation is that it is only possible to have static thresholds for event detectors, this would allow to have a "dynamic" threshold. In fact, the intention is not for the limit to fluctuate, it could be a virtual datapoint - numeric - without updating - linked as a limit, but for the operator to be able to define this in the graphical representation. This is based on the premise that I and many other users do not like to let the supervisory operator enter the settings screens and change anything there and we do not want to give permission to do so. We generally block the operator's navigation in the fullscreen graphical representation, we even add the logout button to the graphical representation with an HTML component so that he does not need to use the standard menu or to log out. Adding the value of a datapoint as a threshold reference would be extremely useful. Regards |
Okay, I understand the idea of a dynamic limit (from a point), and I understand that it can be useful. |
Ok, this time it was me who hadn't understood you, but now I understand. The limitation you mentioned makes sense, but see, I don't intend for it to be available for the common user to set which datapoint will be used as a limit, this must be done by the admin user himself. However, as we can limit access to a datapoint in the user profile, if the admin releases access to the datapoint created specifically for this purpose and which was linked as a limit, I don't see a problem with this common user just changing the value of this datapoint and the same change the event limit. I imagine that if this is implemented it would work as follows with 2 datapoints, dapoint_real and datapoint_limit as upper limit for example: 1st user sets the datapoint_limit = 40 2nd If the datapoint_real <=40 or if the user sets the datapoint_limit to a value higher than the datapoint_real at that moment, then the event returns to normal. |
@fabiodurao That is, you are right that another user with set permissions on the limit point could change the value, and only read could be shared with other users. What you are writing about could probably be achieved through a virtual/modbus data point that would define the limit and a meta data point that would return some state, depending on the dynamic limit(modbus plc) or limit set by the user(virtual), on which you can set a detector that detects a given state and handlers that take action... |
I didn't understand the idea of the value received from a PLC and a neural network. What I suggested can already be done with a meta datapoint and another logic, and another true or false value detector returning the metadatapoint, but it is much more work, it would speed up several projects, where the client has someone internal with an administrative and who wants a screen to configure limit parameters. Does this make sense to implement or does the fact that there is already a path, however long it may be, make implementation unfeasible? |
Hello. I fully agree with the proposal from @fabiodurao . An example : compare a consumption to a threshold that depends on many things (external temperature, activity level, ...). This allows far better diagnotics capabilities than comparing to a fixed threshold. I'm currently using the alternative method proposed by @fabiodurao, it also works. |
As per the illustrative image below, it would be very productive to have the option of creating event detectors with the 'upper limit' option, for example, where instead of the user defining a fixed limit, he can place a limit defined by a datapoint intended to be a process setpoint for example.
Imagine the situation in which a process may have a limit that is adjusted for each recipe or that the operator makes manual adjustment in certain situations, there could be a text field in the graphical representation (created with a script for the server, already possible with current resources) where the operator can set this upper limit whenever necessary. If the event detector uses this datapoint as a reference, it will be much faster to define thresholds and events. This could apply to limits of the type: High limit, Low Limit, Positive CUSUM, Negative CUSUM. The names of the fields in the drawing below can be changed, I just copied what already exists in the "setpoint type event handler".
The alternative to doing the same thing today would be to create a meta datapoint that receives in context the datapoint with the setpoint function and the datapoint that is being compared and create logic that when the real datapoint is greater than the setpoint datapoint returns TRUE or FALSE , thus creating an event detector so that when the state is TRUE, it generates the datapoint. In addition to being more time-consuming and laborious, additional datapoints are created to confuse a list of variables, which could be resolved in a much simpler way.
The text was updated successfully, but these errors were encountered: