# Expression to convert multiple digital signals to string **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [June 4, 2024, 7:24pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363 "2024-06-04T19:24:09Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![Zachary\_Ray](https://avatars.discourse-cdn.com/v4/letter/z/dec6dc/32.png) [@Zachary\_Ray](https://forum.inductiveautomation.com/u/Zachary_Ray)\ **Post date:** [June 4, 2024, 7:24pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/1 "2024-06-04T19:24:09Z")
Hello, I have created a UDT which stores 6 boolean values. The values represent hand, off, auto commands and indications. That is - auto command, auto indication, hand command, hand indication, etc. The UDT also contains a member tag which attempts to look at the 3 indication tags and convert these into a string. The problem is - I don't know how to combine the 3 values into a single value which the case statement can look at to determine the string value. Here is what the UDT structure looks like: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/1/d115da0d416c6bd7f46124096404fd1541d8dccd.png) Here was my first attempt at writing an expression to accomplish the above: > **First Attempt** > > ```python > // Inspect digital signals and create string format > case( > > // Off bit is high, hand bit is low, auto bit is low (OFF) > {[.]DIND_OFF}&&!{[.]DIND_HAND}&&!{[.]DIND_AUTO}, "Off", > > > // Off bit is low, hand bit is high, auto bit is low (HAND) > !{[.]DIND_OFF}&&{[.]DIND_HAND}&&!{[.]DIND_AUTO}, "Hand", > > > // Off bit is low, hand bit is low, auto bit is high (AUTO) > !{[.]DIND_OFF}&&{[.]DIND_HAND}&&!{[.]DIND_AUTO}, "Auto", > > // Default Return > forceQuality("!BAD STATE!", 0) > ) > > ``` I think one possible solution could be: > **Possible Solution** > > ```python > // Inspect digital signals and create string format > case( > // Value to inspect > toInt(concat({[.]DIND_OFF}&&{[.]DIND_HAND}&&{[.]DIND_AUTO}), -1) > > // Off bit is high, hand bit is low, auto bit is low (OFF) > 4, "Off", > > > // Off bit is low, hand bit is high, auto bit is low (HAND) > 2, "Hand", > > > // Off bit is low, hand bit is low, auto bit is high (AUTO) > 1, "Auto", > > // Default Return > forceQuality("!BAD STATE!", 0) > ) > > ``` But quite frankly I think this solution is kind of ugly... is there any other solutions you have used in the past? Thank you! ---
**Author:** ![rbabcock](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rbabcock/32/13425_2.png) [@rbabcock](https://forum.inductiveautomation.com/u/rbabcock)\ **Post date:** [June 4, 2024, 7:31pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/2 "2024-06-04T19:31:29Z")
```python if( {[.]DIND_HAND}, "Hand", if( {[.]DIND_AUTO}, "Auto", if( {[.]DIND_OFF}, "Off", forceQuality("!BAD STATE!", 0) ) ) ) ``` I tend to use nested if statements for stuff like this. It's not the prettiest, but formatted correctly you can troubleshoot it more easily, imo. ---
**Author:** ![Zachary\_Ray](https://avatars.discourse-cdn.com/v4/letter/z/dec6dc/32.png) [@Zachary\_Ray](https://forum.inductiveautomation.com/u/Zachary_Ray)\ **Post date:** [June 4, 2024, 7:33pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/3 "2024-06-04T19:33:28Z")
Thank you for the quick response. I suppose I was overcomplicating it by going for the case statement. I can also maintain looking at all three tags using this solution, so thank you! ---
**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\ **Post date:** [June 4, 2024, 7:33pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/4 "2024-06-04T19:33:52Z")
```python // Inspect digital signals and create string format case( // bit 0 bit 1 bit 2 binEnc({[.]DIND_OFF}, {[.]DIND_HAND}, {[.]DIND_AUTO}), 1, "Off", 2, "Hand", 4, "Auto", "Error" ) ``` See [case | Ignition User Manual](https://docs.inductiveautomation.com/docs/8.1/appendix/expression-functions/logic/case) and [binEnc | Ignition User Manual](https://docs.inductiveautomation.com/docs/8.1/appendix/expression-functions/logic/binEnc). I haven't sorted out your forceQuality as I'm not sure what you're doing there. ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [June 4, 2024, 7:38pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/5 "2024-06-04T19:38:08Z")
An alternative to @Transistor's `binEnc` method. ```python case( binEnum({[.]DIND_OFF},[.]DIND_HAND},{[.]DIND_AUTO}), 1, "Off", 2, "Hand", 3, "Auto", forceQuality("!BAD STATE!", 0) ) ``` ---
**Author:** ![Zachary\_Ray](https://avatars.discourse-cdn.com/v4/letter/z/dec6dc/32.png) [@Zachary\_Ray](https://forum.inductiveautomation.com/u/Zachary_Ray)\ **Post date:** [June 4, 2024, 7:40pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/6 "2024-06-04T19:40:28Z")
Thank you Transistor. This is exactly what I was looking for. > [@Transistor](#): > > I haven't sorted out your forceQuality as I'm not sure what you're doing there. I'm new to Ignition and have seen this forceQuality used in other expressions across some of our projects. I hadn't really questioned the use of it. It seemed sort of nice that the expression would return glaringly obvious issues across the displays when used on components. ---
**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\ **Post date:** [June 4, 2024, 7:42pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/7 "2024-06-04T19:42:06Z")
Be careful with this expression. Is it possible that the HAND tag can be high when in AUTO? ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [June 4, 2024, 7:42pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/8 "2024-06-04T19:42:25Z")
If you are using this on a display, is it for vision or for perspective. Because, generally speaking you don't want to convert data to a string until the point of use, and there are other methods which are specific to those applications. Also: Kudos on a well thought out, properly formatted, and clear question. ---
**Author:** ![Zachary\_Ray](https://avatars.discourse-cdn.com/v4/letter/z/dec6dc/32.png) [@Zachary\_Ray](https://forum.inductiveautomation.com/u/Zachary_Ray)\ **Post date:** [June 4, 2024, 7:44pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/9 "2024-06-04T19:44:39Z")
Thank you Irose. This is also a very clean method. The one issue I have with this is that if you ever had an error where say the hand and auto bit were high, then you would never come across it. It really should never be an issue and is a viable solution, but it was just one thing I noticed which may be a drawback. ---
**Author:** ![Zachary\_Ray](https://avatars.discourse-cdn.com/v4/letter/z/dec6dc/32.png) [@Zachary\_Ray](https://forum.inductiveautomation.com/u/Zachary_Ray)\ **Post date:** [June 4, 2024, 7:46pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/10 "2024-06-04T19:46:30Z")
Two tags _should_ never be high at the same time, but I'd like to check for that case if it ever did arise. ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [June 4, 2024, 7:46pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/11 "2024-06-04T19:46:32Z")
> [@Zachary\_Ray](#): > > The one issue I have with this is that if you ever had an error where say the hand and auto bit were high, then you would never come across it. Fair, I would definitely insure in the device that it is not possible for equipment to be in more than one state at a time. ---
**Author:** ![Zachary\_Ray](https://avatars.discourse-cdn.com/v4/letter/z/dec6dc/32.png) [@Zachary\_Ray](https://forum.inductiveautomation.com/u/Zachary_Ray)\ **Post date:** [June 4, 2024, 7:48pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/12 "2024-06-04T19:48:35Z")
> [@lrose](#): > > If you are using this on a display, is it for vision or for perspective. Because, generally speaking you don't want to convert data to a string until the point of use, and there are other methods which are specific to those applications. This is for a Vision project. What is the reasoning for not converting data to strings until the point of use? I figured it would be nice to convert inside of the UDT as then I could use it across the project all coming from the same source, but I'm happy to use the best method. ---
**Author:** ![Zachary\_Ray](https://avatars.discourse-cdn.com/v4/letter/z/dec6dc/32.png) [@Zachary\_Ray](https://forum.inductiveautomation.com/u/Zachary_Ray)\ **Post date:** [June 4, 2024, 8:02pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/13 "2024-06-04T20:02:52Z")
> [@Transistor](#): > > ```python > // Inspect digital signals and create string format > case( > // bit 0 bit 1 bit 2 > binEnc({[.]DIND_OFF}, {[.]DIND_HAND}, {[.]DIND_AUTO}), > 1, "Off", > 2, "Hand" > 4, "Auto", > "Error" > ) > > ``` Note if you come across this in the future: there's a missing comma after the "hand". **The fixed solution is** : ```python // Inspect digital signals and create string format case( // bit 0 bit 1 bit 2 binEnc({[.]DIND_OFF}, {[.]DIND_HAND}, {[.]DIND_AUTO}), 1, "Off", // 001 (Binary representation) 2, "Hand", // 010 4, "Auto", // 100 "Error" ) ``` ---
**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\ **Post date:** [June 4, 2024, 8:22pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/14 "2024-06-04T20:22:04Z")
I fixed the missing comma in post #3, thanks. One advantage with the `case` syntax is that you can accommodate all eight permutations or the likely ones. ```python case( // bit 0 bit 1 bit 2 binEnc({[.]DIND_OFF}, {[.]DIND_HAND}, {[.]DIND_AUTO}), 1, "Off", 2, "Hand", 4, "Auto", 5, "Auto", // Maybe should be "Off" depending on PLC logic. 6, "Auto" // Auto overrides "Hand". "Error" ) ``` Tailor this to suit. I'm not sure of your hand off auto logic. ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [June 5, 2024, 2:58pm UTC](https://forum.inductiveautomation.com/t/expression-to-convert-multiple-digital-signals-to-string/91363/15 "2024-06-05T14:58:50Z")
Because it is always better to work with numbers as numbers, dates as dates, etc... This is especially important with things like dates where the conversion can result in data loss. Another, not insignificant reason when scaled out, is avoiding data duplication. You already have tags which indicate the state of the thing, they're just not necessarily human readable. That's okay though, because they can be converted at runtime and displayed to the operator without the added overhead of an additional tag. The more tags you have like this the larger the impact to performance because they all take up space in the internal db. For vision, I would do something like this: Here, I have created a label with a custom integer property "state". ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/a/baf545ae507ec5aa008d1c6de2c713272f09d3f6.png) On that same label, I have added a Style Customizer configuration using the State custom property as the driving property and customizing the text, and the background color. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/3/633984e8508656c8982d7091904f338070a3cb9b.png) Then I configured an expression binding on the custom property, with just a simple `binEnc()` function. I'm using checkboxes to simulate your three tags. Here is the finial result, obviously you could tailor this to fit the actual needs of your process and logic. ![animatedLabel](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/5/f570265b380276e57820e3821912503b42347dc5.gif) Just another option.