In my scenario, I have a task that the user needs to perform in every shift. Let’s imagine, I have a morning, day and night shift. I know how to calculate the next day, week, etc. using an expression in the trigger but how can I calculate the date/time for the start of the next shift?
In Tulip, we can maintain the “Shifts & Schedules” in settings. In their, I can set-up a shift plan with time information. But I did not find anyway to use this information in a trigger.
The shifts within Tulip are not really generically “accessible”.
We solved this issue by using a table which has the shift schedule pasted in from Excel after calculating them for a couple of years (so I don’t have to touch it any time soon).
The first column is just the time stamp in milliseconds since we just need a unique value and it makes it easier to extend the table later.
Then we create a query & aggregation to make it accessible in an app:
You’ll need to limit the result to 1 record and depending on record order you may need to use the sort option as well.
For the aggregation when you just want to return the value of a single record, just choose “Mode” in the aggregation.
Next you’ll need to setup the query & aggregation up in the Records part of the app.
Then in the app we run this trigger on app entry and at intervals using a timed trigger. If you only need it during an operator interaction your life is even easier and just run it when needed.
If you just want the shift number you’re done, if you want the time, you just setup a second aggregation that returns it. You may need to use “Unique Values” instead.
This also makes it possible to write the shift to tables or the Machine Activity Table (if needed). This allowed us to do MAT analytics based on shift which was a major customer need.
thank you very much for the clarification and the detail guide.
I will then use an approach like this and create a new item in the Features/Suggestions area because I feel the current Schedules and Shifts need more functionality to really make them useable.
Before query/aggregations we also setup a connector function that would query the same table.
The benefit to this method is that I could return an array of both the current and previous two shifts (or as many as I wanted by adjusting the record limit) along with the start time of the shifts in one shot.
The down side is that we’re basically doing an external call back to the Tulip platform which really shouldn’t be necessary. And of course if for some reason the REST call stalled, it would hold up the App for the 60 second timeout before it would respond again.