As the title says, I’ve been using the Perspective Equipment Schedule component for the past few weeks and have learned its some of its quirks. This post will serve as an idea board for component improvements. I’ll start it off with a few features that would make the component much more usable:
Component onEventClick action - this request seems very standard and something that people have been asking for since the Schedule component came out.
Make event marker embeddable (related to 1) - if we can use an embedded view instead of the default event marker, we’d also be able to define events on the embedded views more easily. This would require some default parameters, I would imagine, such as eventId and itemId.
The selectedEvent object should hold all of the event values instead of just the eventId and itemId.
It would be nice if we could specify a function for eventId creation or to use a uuid by default instead of something like event_1234.
Give the user the ability to move events between itemIds. I assumed an event can be dragged from one row in the Schedule to another but it looks like this isn’t the case (I’m hoping there’s a simple property I’m missing because I have to do some rework now ).
Feel free to address any of the points above or to add to the list.
Have you tried posting these recommendations to the Ignition Features and Ideas page yet? Our developers regularly look through there for community recommended improvements.
Another feature would be to give the user the option to exclude the time consumed by downtimeEvents and breakEvents from the schedule. So, for instance, if you schedule a chunk of 12 hours and a downtime event is also scheduled within that block, that time should not be counted towards what the user schedules.
So, in the case above, the Red Pens scheduled event would go until 10am since there is an hour of downtime right in the middle of it even though the event will take 12 hours instead of all of 10pm - 10am (13 hours).
Another thing I noticed: when a breakEvent is scheduled, it is applied to all items and when a downtimeEvent is scheduled it only applies to a single item.
Besides the tooltip being wrong (see below), it would be good to have a way to control that behavior… Namely, the fact that breakEvents are applied to all items.
Hopefully I’ve addressed all your points here. For feature request tickets, I can’t guarantee when they will be worked on if at all but I’ll do my best to see what I can do. I’ll keep you posted as things get merged into nightlies.
The feature request is currently in the pipeline and we are working to get it approved and merge.
I believe this has been asked before, so I will go ahead and file a feature ticket to get this worked on.
I’ll go ahead and file a feature request.
Is this something that can’t be done as part of a scripting function? Event creation is handled by the user so I’d imagine they would either use their own naming schemes or use a python library to generate uuids. I would like to get some more information on how you plan to use this.
Currently there is no way to move events between items. I can go ahead and file a feature ticket for this.
Would this mean that there would be a gap between the event and you would see a timeframe from 10pm to 4pm and 5pm to 11am? I suppose you could generate two events, but I’m guessing you’d like this to be one entry within the scheduled events array? Another question, if a new downtime event is added would you expect all the events affected by the downtime event to be auto adjusted?
I believe break events have always behaved this way (in Vision), so there isn’t any property to change that at the moment. What sort of control would you like over the break events? As for the typo, I’ll go ahead and file a bug request ticket.
Let me know if you have any other questions and feel free to DM me for a faster response. Thanks.
For 6.) the behavior you explain is what I had in mind. You’d specify a start date and duration of the event, and the component would be able to (if the user wants) exclude the break and downtime events in the schedule. This gets really tricky though - I wrote a script that will check if there are downtime and break events and schedule around them automatically, but it breaks down in the simplest of cases - when I want to add another exclusion from the schedule after I scheduled the event. This is not a big of a deal as the other items.
7.) In my mind, it would be nice to have a default behavior (such as break events will apply to all items) and give the user/developer the ability to opt out per item. This is specifically for the break events. I know I could just create downtime events, but the breaks and downtimes mean something to my DB schema.
Thank you again. I know this component is very complicated and I appreciate the dev work being done on it. I just want to help make it better!
Thanks for the clarification. Perhaps we can make this into a property that users can opt in and out of. I’ll go ahead and file a feature request and have the team iron out the details. Feel free to provide any additional input that come to mind.
I see. So something like a blacklist? Perhaps we can have an array prop or a comma separated prop to exclude break events for certain item ids. Like the above, I’ll go ahead and file a feature request ticket and have the details ironed out.
For sure. Your feedback is greatly appreciated and any feedback in improving in the component is most welcomed. Thanks!
We've added the onEventClick event and fixed the issue where the move event was firing multiple times. This should now be available in the nightlies. Thanks.
Quick question: will the onClickEvent also fire when downtime and break events are clicked? I'm creating an interface to add downtime and break events and there isn't currently a way to get the selected break or downtime event like there is for the scheduled events.
Is item #5 above a requested feature, if not could it be added?
Give the user the ability to move events between itemIds. I assumed an event can be dragged from one row in the Schedule to another but it looks like this isn’t the case (I’m hoping there’s a simple property I’m missing because I have to do some rework now ).
).
