Scada-LTS
Scada-LTS copied to clipboard
SCADA-LTS
Add parameterization capabilities for all protocols
Currently the parameterization option is only available for the modbus protocol/datasource. The multiplier and additive feature is very useful and many times, when we are communicating in other protocols, as in the case of the http receiver, when the data is numerical, there is not even the option of putting a simple 0.1 multiplier.
In this scenario, what happens is that the application developer needs to create a datapoint in the metadatasource just to correct the value.
My suggestion and that of other colleagues with whom I've talked about the subject is that there is a traditional parameterization option for all numeric datapoints, regardless of the datasource.
Additionally, if this suggestion is accepted, it would be interesting to add one more feature. Today, the parameterization considers only the linear parameterization rule, in the traditional y=a.x+b where "a" is the multiplier and "b" the additive, this already meets 90% of the demands, but there are sensors with quadratic scales, so, in order not to come back to this topic in the future, my suggestion would also be to leave the option of y=a.x²+b.x+c and the parameters "a" can come by default with the value "0", the parameter " b" which already exists today and is called a multiplier can keep the default value "1" and the additive can also keep the default value "0".
In this case, if the parameterization is the default, just keep a=0 and everything is fine.
Here's a concept image drawn not yet old UI.
old pr: https://github.com/SCADA-LTS/Scada-LTS/pull/965
this idea is already old, but as they are redoing all the UI of the datasources, I thought it was pertinent to put this now
@fabiodurao Have you looked at Modbus Serial? #1694
Why not use the Meta Data Source to do any calculations of the value of many points, or a point that needs to be converted?
Modbus topic answered.
For larger projects, the organization gets very messy, because we have to duplicate all the variables, one real variable, and another one in the meta datapoint. The management of this isn't cool, I don't know how the PC's resource consumption performance is, maybe it's the same thing if you implement this function in the datapoints, but it's much easier to rescue a single variable, because we start having to invent names different variables to be able to identify which is the raw variable and which is the rendered one. Example:
Http Receiver : Datapoint: name= loc01_sta_05_p5 - Battery voltage DataSource Meta : Datapoint: name= loc01_sta_05_p5 - Battery voltage Rendered Note: loc=location, sta=station, p=parameter
I have a project with almost 1000 datapoints all in http receiver, I'll have to create another 1000 meta datapoints just to render, but the problem also happens in other datasources like dnp3, snmp among others.
There is also the issue of communication management, you need to disable both datapoints, configure the data storage of both, sometimes some of them are context for a meta datapoint that really needs to exist and if you disable one it gives context problem in the other, there is also the issue of managing profiles and access levels. Anyway, there are several problems that could be solved and simplified if only the parameterization were already in the datapoints of all protocols.
This is a very common problem and it gets in the way a lot, because as Fábio said when we have many items it ends up being unfeasible to use protocols such as SNMP. A direct linearization function in the datasource configuration would be very interesting.
- If we only want to save the original value, but only display the converted value, then we can extend the renderer function to introduce js script, it would give us freedom in value conversion, similar to the Meta Data Source.
- If we want to save the converted value, but without the original value, then we could add such a function to the point, similarly as above.
- If we want to save the original value and the converted one, then the configuration of two points seems to be a natural solution.
It might make sense for this rendering to go along with the datapoint properties, along with the part where we put units and formatting with the decimalformat class. I know that in previous versions, the original and converted value were saved, you could see this when a report was taken, in the table attached to the email it was possible to see the column of the original value and the converted value.
In practice, when a value is numeric, I never needed to use the original value, I always rescued the rendered value, and in the script component for the server I had the option to use "renderedText" or "value" so I had flexibility, although I never used "value". With binary variables, we often use the text rendering properties to do something like:
"0" = "Off" "1" = "On"
And depending on how we are going to present it on screen, it is possible to have an interest in presenting the original value in some cases and rendered in others.
I don't quite understand what you mean by the js script.
What version did you see this conversation in? If there were no two points, the original value was probably saved and it was additionally recalculated for the report. I think the optimal solution is to keep the original value and recalculate it in different contexts. Retaining the original value is important. As for the script, you wrote about square-scale values here, but it can also be logarithmic and probably different, here the solution seems to be using javascript, just like in Meta Data Source.
The tests I am referring to are from versions of ScadaBR, up to ScadaBR 1.1 and 1.2 this behavior in the reports is the default, but I believe that in Scada-lts this is no different, you must be right in the fact that only the original point should be stored and makes even more sense.
Regarding the quadratic and logarithmic scale, I think they are rarer and can be delegated to metadapoints without major problems, I only suggested because I imagined that if any changes were to be made, it would not impact. But having the parameterization for linear scale in datapoints in all protocols will solve a huge problem for most of the community.
I see that we have such a function on Modbus IP in Scada-LTS. There is a multiplier and the ability to add value.
Not implemented in HTTP receiver.
If we will come back to this conversation when I discuss the topic with the Scada-LTS team. Of course, we could use support in the form of help in testing, maybe in development, I hope we can count on ourselves.
Yes, this function already exists in Modbus Serial and Modbus IP, so I took the inspiration, it helps a lot and as it is the most used protocol, we ended up getting used to it lol.
If they manage to expand this function as it is implemented, for the other protocols, it will be show.
Hello, we want to add the proposed converter: ax^2 + bx + c = y The situation when we get the value from the driver is simple, we substitute for x and calculate y. However, in the case of setting the value at such a point, i.e. a situation where we have y and we want to calculate x, the situation becomes a bit more complicated. That is, if the delta of such an equation is greater than 0, it means that the equation has two solutions, that is, we have the equation:
ax ^ 2 + bx + c1 = 0
where: c1 = c - y;
then: delta = b ^ 2 - 4 * a * c1
If delta> 0 then there are two equivalent solutions x1 and x2.
How does it look in practice? Is such a situation permissible?
Great news Limraj,
In practice, I never needed to do anything in reverse like what you mentioned, the most that happens is that instead of needing to multiply by 10, I need to divide by 10, then just multiply by 0.1 which is the same as 1/10.
In my view, there is no need to predict the reverse calculation.
So if someone enables conversion and sets the parameter a != 0, settable should be blocked?
Sorry, I didn't understand that the problem was there, now it's clear what you mean by having two roots. You are thinking about the question that the database will only store the "X" and the "Y" will be calculated and rendered when presenting the value, right? I can't think of a solution for this.
No, you wrote that the raw value was not important to you, so we are going to save only the converted value, i.e. Y. Only the converted value is saved in modbus ip.
My question concerns the settable function, so that you can set a value at this point, you will have to convert it to the other side, i.e. calculate X and here is the problem I described above. So we can lock the settable function if the coefficient A would be different from zero.
Then it has the consequence that we cannot set values through this point.
Okay, if I understand correctly, when someone writes a value, two conversions need to be done? Y -> X -> Y is that it? Wouldn't it be possible to configure a bypass just for the configurable option? Since it will be the final recorded value. My suggestion would be to add an option, if the value received is written and not read, then use the value without converting.
The point is, if the driver sends something on some scale, it probably takes values on that scale as well. So you get X from the driver and convert to Y and if you want to send you enter Y value but you have to send X. Looking at Modbus ip implementations we have this two way conversion.
if you don't have another solution, just leave the linear conversion, even with the multiplier and additive, the rest we do in the meta datapoint, I imagined it would be simpler, but if there is this return of the calculation, I think it makes no sense to use so much energy in this, because it would be confusing for the user to understand why in certain situations he can't write.
How will you know what to send if we are not saving the original values? You must be knowledgeable about the given driver, it will lead to errors... Besides, it may be unclear that we are shipping a raw value different from what we see. The question of how often is a square needed?
There's a math problem, a quadratic equation can have two equivalent solutions ... it's not some magic. If there is no practical solution to this problem, it is probably better to stick to additive and multiplier...
Perhaps such a driver is enough to send any solution? For him, X1 and X2 have the same effect... although the values are different. In what cases is this scale used?
it is rare to use quadratic scale, there are some sensors that use this pattern, but it is the minority, most of them are linear scale. As I said, the most important thing is to have a linear scale in all communication protocols that have numerical variables. In my mind, I imagined that if I were to change it, it would be nice to consider the quadratic scale, but you are absolutely right in the aforementioned statements. Let's just keep the linear scale, if it is replicated to other datasources, we will already have a huge gain. For all other exceptions, we keep the meta datapoints.
Hi,
-
I was looking at the possibility of implementing these additive multipliers in all Data Sources, but there is no separate logic for sending a value to the driver, this is where we write the value to our database, these two activities are related, hence the preparation of multipliers for of all Data Sourach, it would involve a lot of work that outweighs the business benefit, not to mention the testing needed for each Data Source. Therefore, we have to choose the Data Sources that are relevant here.
-
However, if we approached the problem in a different way, praised the raw values, and depending on the context, displayed the converted, then here we could develop a universal mechanism.
Forgive me for the delay that I had a break from last week Tuesday until today.
The most relevant datasources are certainly (I'll leave it in order of what I use the most):
- Modbus serial/ip
- http receiver
- http retriever
- SQL
- SNMP
- MQTT
- OPC DA
- DNP3 serial/IP
- BACnet I/P
- IEC101 serial/IP
If I were to develop an individual approach for each data source, I would start from the beginning to the end of this list, remembering that modbus already has this feature.
I don't know what the working difference is, but a more general approach sounds better to me, but maybe it's simpler to start with the individual approach and then migrate.