Hello everyone,
I have a Text Field in Ignition Perspective that displays the pressure value. I want to show the value along with the unit "kPa", but Ignition converts all the letters to UPPERCASE.
For example, when I set the value like this:
Instead of "0.0 kPa", it shows "0.0 KPA".
How can I add the unit "kPa" without converting the letters to uppercase?
Is there a setting in the Text Field that could solve this issue?
Additionally, I've noticed that when I add a format in the Text Field, the bidirectional setting gets disabled. Does anyone know why this happens, and if there is a way to keep bidirectional enabled while adding the format?
How are you bringing in the kPa to display? I tested a couple by manually adding it in without a binding and also linking to the engUnit of a tag and both did not display it in all uppercase. You could always have the first field be bound directly to the tag and a second tag set to the engUnit property.
Bi-directionality can't work with a transformed value. You are changing the value that would be on a tag and it wouldn't be able to work back to the source value.
I sincerely thank everyone who responded to my question and provided guidance in the Inductive Automation forum.
I uploaded two images to illustrate two different methods for displaying the "kPa" unit:
In the first method, the text was displayed in uppercase.
In the second method, I attempted to create a unit within a UDT (User-Defined Type), but both approaches were unsuccessful.
It was suggested that using a Label component for displaying the unit could solve my problem. While this may work, my main question is whether this is the correct approach in Ignition SCADA.
Can’t we combine the value and the unit together?
I have very little experience with Ignition. About eight years ago, I worked with it briefly, and I have only recently started using it again.
In other SCADA software, it is possible to display both the value and the unit within a single Text Field.
When entering a value, the operator can only modify the numeric value.
After submitting, the operator sees the value along with the unit.
Is such functionality possible in Ignition, or should I use a Text Field for receiving and displaying the value and a Label for displaying the unit?
However, the big problem is that a Text Field component has no idea about numeric values and restrictions on legal characters. That means that 105.32 kPa 105 .32 kPa 10.5.32 kPa 105.32kPa 105,32 kPa
would all be accepted.
The Numeric Entry Field component
will only accept numbers and the decimal separator.
has a spinner option.
has input bounds.
has a built-in format option.
three mode options.
an invalid-entry style option (e.g. red-border if you go out of range).
will align numbers to the right (although this can be overridden).
But the real deal is that your method is creating a string that can't be output back to a numeric tag type. Also, visually, displaying the units in an editable field suggests that they can be edited. I don't know why the other software you refer to would support this.
I sincerely appreciate all of you who took the time to guide me and help solve my issue. Your insights, suggestions, and experiences have been incredibly valuable to me.
I was trying to display both the value and the unit in a single input field, but as mentioned, this approach can cause issues regarding data types and the ability to rewrite values. Your suggestion to use the Numeric Entry Field instead of the Text Field seems logical and practical, and I will definitely give it a try.
A big thank you to everyone who participated in this discussion and shared their experiences. I hope to contribute my own experiences to the community in the future as well.
In others that I've seen, clicking on the input field typically opens a popup with numeric (er, tag value) entry only, limiting the suggestion that the units can be edited. The 'formatted string' for that live value is then displayed on the overview.
I much prefer the method of Perspective, so that units can be formatted with any style - intentionally different from the process variable (or setpoint - as @Transistor demonstrated):
Yes, you're right. Weekend reply
