Ignition Version: 7.9.20
Sepasoft OEE Downtime Version: 3.79.3
What is the recommended approach to versioning shift schedules over time so as not to lose historic shift data?
I am just following along in the tutorial, but it seems like only the shift name is recorded over time by sepasoft, so if we change the schedule times over time (ex: M,Tu 8AM-5PM then change to M,F 5AM-5PM), we will lose the historic info and when reports are run later for the old time periods they may be wrong because they are using whatever the current schedule is.
I have not tested this, but I could not find an explanation in the docs and it seemed like the answer might help others.
Personally I would ensure a shift has a unique id, such as the primary key of the SQL table.
I operate by the idea that you NEVER delete SQL data, for this reason.
Instead I'd "retire" the old shift from the UI, and create a new shift.
This retains all the shift IDs.
Then the reports should still work if designed properly to look at the ID that was relevant at the time of recording the data.
Thank you for replying.
I get what you are saying from a general relational db perspective, but i am not sure how that would work with sepasoft's OEE module. From my limited perspective, it looks like they use Ignition Shifts and just reference the names of those shifts and I dont think (could be wrong) there is versioning of that shift data in Ignition or in sepasoft. In order to get versioning to work, it seems like I would have to create my shifts as follows: Shift 1 v1, Shift 1 v2, etc. I can maybe make this work but it would be very messy long-term and i need our production people to use it and they are liable to make mistakes if this is how creating and versioning shifts works. This also creates issues when it comes to mapping all people/equipment/lines to shifts, because every single one would need to be updated to the new version.
Again, this is just my naive perspective since i cannot find any docs giving a solution and cannot find any indication shift versioning is supported anywhere.
Ah sorry I haven't used Sepasoft modules specifically, I thought you might have some control over those aspects.
You should contact Sepasoft support. The lack of response suggests no-one here knows. (I'm going to guess that there is no such versioning.)
1 Like
You are probably right. I have reached out to them. Someone from sepasoft did reply to one of my other questions, so I was hoping they were active on this forum to support users, but it seems like you are better off contacting them directly.
I just found the Shift Configuration docs, but they are murky to me.
I got a reply from sepasoft and there is no shift versioning.
The expectation seems to be that you have a collection of standard shift schedules you define and then switch between over time and that is why they just track the shift name in the database. This means you cannot rename a shift in Ignition without breaking their system and you should not change the schedule mapped to a shift name once you have started using it unless it was wrong from the get go.
I am still debating a solution which works for us, which is probably going to be one of the following:
- forget about historic reporting functions and allowing people to fix bad data entries and just collect everything using Live Analysis
- Use Ignition scheduling as-is and allow users access but put a big warning at the top to stop them from modifying the schedule and breaking historic reporting
- Build a layer on top of Ignition scheduling, which generates each new version of each shift schedule when someone modifies a shift schedule and keep track of eff from/to dates. Use tag collector to pull the right schedule name for each equipment from our database mapping.