Platform Release 306 - February 2025

[jaksif]

Exciting news - Release 306 is here!

The Tulip team has rolled out some fresh updates across multiple features, along with some bug fixes. Check out the release notes and dive into what’s new.

Share your thoughts and questions below

[youri.regnaud]

How write attributes are link to MQTT write function? I miss something?

[canaalpaslan]

Hey @youri.regnaud,

Before this release, we could only ingest MQTT data through machines, and write to it from connectors - this work was to allow you to go bidirectional directly through machines if you are not working with complex payloads (or if you are working with OPC UA).

With this release, you can utilise at this station trigger mapping to build apps that can be more easily leveraged across stations.

If you are working with complex business objects, like in a UNS use case, you can still write to these complex objects through connectors.

[thorsten.langner]

Wow… some big bangers seem to enter the room

[Beth]

Some great things included in this release from Tulip Community!!

Testing mode connector environment label has been updated to match the rest of the product.

• Consistency in Connector Environment Labels from @nicolettenaya

With the new when “input is exited” condition option for triggers of text, multiline, and number input widgets, the following requests are resolved!

• Allow for text\numeric input widgets to have trigger logic when "input changes" from @bklempa
• OnChange-event trigger for input widget from @ChrisF

Last but not lease, conditional formatting on interactive tables is here!!

• Individual record field background color - Interactive table from @oviland
• Highlight interactive table rows from @OliverGnepper
• And the great discussion and input here [Request for Input] Conditional Formatting for Table Analysis & Interactive Table Widget from @oviland @abeer.garman @Todd-DMG_MORI @OliverGnepper and @ASharp-J

Thanks all for the great input and let us know how you like these new features

[pwied]

Thank you for the implementation of conditional formatting👏

I have seen in the release notes that this function is being further developed. It would be very helpful if the comparison of values from 2 different columns of the interactive table could also be implemented, e.g. to be able to compare target and current quantity or shipping date and completion date.

[thorsten.langner]

I love the conditional formatting. I already use it an a new App and it helps a lot.
I really appreciate this feature!

However, here are my challenges, I had to work around or had to discard (for now):

• I want to format based on a column, that is not displayed (as possible in sorting and filtering).

  • Use case: I have a helper column to postpone or unscope a topic. If this is true I would like to grey this row out and push it to the bottom. But I don’t want to show the “out of scope” column in the widget.

• I want to compare a column value with another column value

  • E.g. target and actual amount, tolerance and actual measurement…(as @pwied mentioned)

• I would love to have a select all button to select all columns (“Apply to” section)

  • Its just unhandy to select 20 columns manually

• I’m missing an is in and is not in condition (as available on filters)

  • Use case: This would allow to set up a list even for the ID. So you could achieve any condition, because this condition can be checked in any other trigger and then fill an ID in a list or remove it. So no helper columns are needed in the table itself… Also you could provide conditions for some kind of multi select from a table (push to a list and highlight the row…)

[canaalpaslan]

Hey everyone @jjj, @pwied, @thorsten.lagner!

@jjj, Regarding conditional formatting for Table Analysis, this is actively under consideration on our end. If others are interested in this feature, please upvote the comment to help us prioritize it!

@pwied and @thorsten.langner , We’re currently implementing field comparison within a condition. I’ll update this thread once the next iteration is released!

Thank you for the feedback @thorsten.langner, I am glad you liked the feature We’ll further develop this incrementally, and having these feedback is very valuable for the next iterations. Please keep updating the thread when you have more

[Beth]

I went ahead and moved @jjj request into a separate product suggestion thread, so anyone interested in bringing conditional formatting to analytics should go ahead and vote on it there!

Conditional Formatting in Analytics

[ta-aoki]

I think “input is exited” trigger does not resolve these request. (I tested the trigger in my sandbox instance)

OnChange-event trigger for input widget

Hi, I would like to get the OnChange event trigger for the following input widget too: Number widget In my use cases the change of a value (input widget) via up/down-control effects other fields (calculation results) So it would be helpful to get this trigger also as it exists for the single select widget Is this on your timeline/radar? Regards Chris

Allow for text\numeric input widgets to have trigger logic when "input changes"

Hello! Interested to hear if a possible update can be made to text and numeric entry widgets to allow for a trigger timing of “input changes” (similar to date time entry widget). There are several use cases for this, most notably performing calculations when a value is entered. The “when enter key is pressed” timing forces extra button presses\clicks that are not inherently intuitive to operators\manufacturing personal - as these entries are the only ones that require them to perform trigger l…

Those requests are asking to make a trigger when input changes.
“input is exited” is triggered only when the input is exited.

[thorsten.langner]

Hi @ta-aoki

on one hand I agree, on the other hand I see the risk of an actual input change trigger.

You could easily set a more complex filter (e.g. full text search), that is calculated on the database. Therefore you must reload the whole table by a connector function.
Imagine you would build this and type 25 characters.
This ends up in 25 connector calls and processing the data afterwards in tulip.

Or you set this data to load a record, change a record and clear it again. Then you write a whole message of 100+ characters.
This would force the trigger to run 100+ times.

• operators would call tulip a ridiculously slow system
• you would not be able to type smoothly because it would load after each character

there are possible solutions (e.g. loading after 300ms after the last change or so) but then someone would wonder why its not pushing every single character to an arras or whatever…

I simply want to say: It’s not that simple and might cause some other issues…