I was able to create a simple timer widget that allows you to stop or start a timer on the screen, reset to 0 and save the current reading to a variable for later use.
It took a bit to get started, but the help doc helped and good old googling helped also. Something that was not clear in the document is how to add external libraries. To enable external lib, click on the 3 dots left of the cancel and save buttons. Moment.js is available but a plugin for duration formatting is not so I had to create a timer from scratch (where google helped ).
One major thing that will need to be considered is multiple widgets on one step. We have a use case at ELO where we need multiple timers (one per machine – 6 in total) and they need to run independently. I tried a few tricks to get multiple timers working on the same page (assign random ID to the div, save props into object, etc.) but did not get it to work. I will keep trying (add a empty widget as a constructor to build out the code and the timer widgets that interact with the code).
So far this a very cool!! I am excited to be involved and keep learning.
Added the functionality to provide a setpoint in secs when a triggers is fired and a bool to update the font size, color and blinking.
With this feature the timer can be shone in a different color or size or blinking after a predefined amount of second have passed.
IMPROVEMENT IDEAS:
reorder the props – as a widget gets more features new props will be added, but we cannot reorder them (manual recreation). It would be nice to reorder them so when being used in an app they can be easy to understand
Widget publish – when a widget is saved it reloads it on the app it is being used. This will make it hard to update / change widgets and will lead to many widgets (test, release, etc.). Ability to publish will make this better.
Can you say more about the multiple timers not working as you would expect on the same step?
Thanks for the feedback on the external libraries and props re-ordering.
On the widget publish/save point. The current state is that when the app is published the widget will be locked. To edit the widget you will need to duplicate. We are following a similar process to connectors. The team is working on feature with in the platform for versioning of all components within Tulip and was easiest to follow the same approach we use with connectors for now.
Good to hear about your progress. If you want you can download as JSON (from the widgets main page) and share your widget here.
Thanks for the feedback @parth.parmar. I just updated the Knowledge Base article to show how to enable external libraries, and showing how to import/export libraries.
How the widget publishing works make sense. I have been testing without publishing and this is why I am able to make changes on the fly. Locking the widget once used on a published app is a good fail safe to ensure stable processing by the shop floor. I think component versioning will be very useful as a app designer (always adding features to enhance the capabilities).
After further testing it looks like multiple widgets is not an issue. I must have made a mistake when initially testing. What gave me pause was that each widget will be loaded onto the page and I am using document.getElementById(id) to get the element and update as needed using javaScript. I assumed if I have multiple widgets with the same id, the same functions and variables then when they load with the javaScript onto the page it would cause problems. I guess it’s not a problem (maybe the way the widget is added to the page the javaScript is scoped to just that widget div/canvas). I would love to learn more about how this works.
As you can see in the email below, multiple timer widgets work fine on the same page.
I will add some comments to the code and add it to this post so others can use this widget.
Great work Parth.Parmar and thanks for sharing the widget.
I have tried to play with it by adding a new property (AddedSeconds) so that if the value <> Null, the timer will not start from 00:00:00.
I.e if DelayStart = 10s → Timer will start 00:00:10 onwards.
For whatever reason, I can’t make it work to start with the extra seconds, if I use the trigger “On Step Enter” in a step. I wonder if you had this use case…
@DariusM – I was able to make is so you could set a new starting point (e.g. 10) and the clock would start at 00:00:10 seconds. If you used 120 sec it would go to 00:02:00.
For reset would you want it to rest back to 00:00:00 or back to the initial value you set (e.g. 10)
Once we decide on the reset value, I can repost the widget and you should be able to use.
A quick hint – the code processes everything in milliseconds (javascript) so if you have a place with the new value (e.g. 10) multiply it by 1000 and see if that fixes your problem.
@RussWaddell and @DariusM – a stop watch unit test already exists in the library (see below). It has some of the same features as this widget, it does not have the ability to alert when a certain threshold is crossed.
@RussWaddell – Tulip could update the current widget in the library and some extra functions (event when threshold is crossed, blinking, color change, etc.). Or if we want to add this widget to the library, I can update it a bit to make is more robust.
Thanks Parthparmar, I did some changes in your code and it worked (added another property where user can specify the number of seconds and if this property is <> 0 the timer will start with this addition). It might be helpful maybe to modify your widget with this new property and republished it.
@sumerlulla@EddyA Let’s flag this for an update we produce, or coordinate with Parth on getting this in through the normal library submission process.
@RussWaddell@EddyA and @sumerlulla
I will get the widget update with the new feature and fix some of the inefficient code in the widget and add it to this post. We can work on getting it to the library if it make sense.
).
