Release 234 is now live on all standard release accounts! Take a look at some of the highlights, below.
App Editor
You can now print from custom widgets
Added RealWear directives to enable number overlay to the following input widgets: Number, Text, Checkbox, Toggle, and Date picker
Added two date utility functions to teh expression editor called ADD_TIME and SUBTRACT_TIME. For example, ADD_TIME(datetime, 3, âmonthsâ). For anyone who has come up with some interesting and painful hacks (like me) ⊠this is a great addition!
Users can now change the types of triggers (within a context) when editing. For example, when editing an âon step openâ trigger, you can now change it to be a âmachineâ or âon step exitâ trigger.
The text widget now supports rich text!
Analytics
Alerting is now available for control charts! There have been a lot of new features added to analytics and weâre only getting started. This feature can be added to control charts and will send alerts when any of the control chart rules have been met
Stations, Devices, and Machines
New Node Red node lets you write many attributes or tags at once.
Fixes, Bugs, and Performance Improvements
Scrollbars on array variables in the app player should now always be visible, regardless of MacOS settings (if on a Mac)
Improvement to the selection of steps to make the current step more clear in the list of all steps
Improvements to the discoverability of the right click menu for app steps
Fixed a bug with machine attribute events not saving at high data volumes
Improved performance of text search queries on Tulip Tables
Image upload widget respects the aspect ratio of the image uploaded for static value. The reset aspect ratio button works now.
Added a missing hint when connecting tables to a placeholder - did you know you can create a record placeholder directly from here?
I like the node red addition, alerting and the rich text add specifically!
That said, when using white text (which I use a lot of), it isnât possible to read within the editing box (without highlighting text). A nice update to this would be the ability to format the background and/or allow white text to be black only in editing field.
Totally agreed that this is an edge case that wasnât addressed well in the initial implementation of rich text. There is a feature request in for this and Iâll see what I can do to get it expedited.
While I appreciate the rich text feature, I think the implementation is kind of poor. In addition to the background issue noted above, having to highlight the entire contents of the field just to change text color is really inefficient.
I feel like if no text within the field is highlighted, it should change the color of all of the text when a new color is detected. Itâs otherwise made changing text color the way Iâm going to use it 99% of the time far less efficient in order to support a feature I might use 1% of the time.
Iâm very excited for the step selection highlighting and ridiculously excited for the new ADD_TIME and SUBTRACT_TIME functions. I literally have a new implementation that I am making today that this will save me a lot of time on.
Appreciate all the candid feedback. Regarding the rich text editing, some of this slipped through as untested cases and will be fixed, other parts are working as intended but will get updates as part of ongoing usability improvements.
More than likely these nodes will be exclusive to Tulip-developed devices at least for the time being. We were able to remove the need for an API bot because the device has been authed to the instance as part of the setup, if we enabled this node for any NR instance, we wouldnât be able to authenticate the data source.
One avenue I could see this functionality coming to other hardware would be if we decided to go down the road of offering our edge firmware to be run on any arm-based hardware. This could enable users to use a gigantic variety of devices with Tulip and would enable that device authentication process to enable these nodes. This is something we have discussed in some depth but isnât something we are actively working on.
Our goal with this new node is to streamline the process of connecting just about any device to Tulip. Removing the need for an understanding of APIs is a big step in that direction.
I understand your explanation. A factory is composed of different equipment, including Tulip gateways. I think it is important to offer âEdge Drivenâ capabilities for Tulip and non-Tulip gateways as well.
Some feedbacks about the new node 1) Gateway can be connected to several machines, different or the same. New Edge data source show edge gateway as data source, i think it will be easier to show machine connected to the gateway by allow different tag lists (one by machine) connected to the gateway 2) Auto Discovery : If the new node can receive msg.taglist input instead of manual input, we can think to create auto discovery Node-Red flow based on data collected from device. 3) Machine set up are still required in Tulip after connected Edge as a datasource. Why not connected machines and create automatically machines through a new machine node for exemple or have one option to create machine if their doesnât exist.
Iâm agree that it a big step compared to Machine API, but self discovery and auto-provisioning of « machines » (and not gateway) have still a room of improvements.
Great to see the Analytics builder getting upgraded! If the control charts UL and LL could be controlled variably, say from an app input, that would be super useful!
App Editor
Analytics
Stations, Devices, and Machines
Fixes, Bugs, and Performance Improvements