Did CleereOpti think there was no cuts for the day? (if application is restarted between end of shift and report send time cut counts get reset and report will not send)
Did Generation time out before finishing? Should have emailed Cleereman Reports on newer versions.
Does a SQL Refresh fix it? http://localhost/install.aspx
Check CleereOpti logs for errors, Did the report generate?
Did they have an internet connection when the report tried to send? Check CleereOpti Logs, or StrideLinx Logbook
Did the Google API return an error? This can happen if the google API server mishandles the request or is down, likely a one time issue on Google’s end.
Did CleereOpti report as "mimekit DLL not found" error? Restart application and manually send missed emails. This is a known, long term issue we are trying to fix.
What was the state of their PLC – PC connection when shift crossover happened? Counts may have missed reset.
Are scanned logs being extended/shortened on the ends?
Check SQL database tables and entries, does the the stored data show anomalies?
Is their PLC to PC connection unstable?
Does their SQL Database have data for that shift/time period? Do the entries make sense? Start/Stops correspond across the shift. Regular cut/log data was submitted properly etc.
In the main PLC, check “Downtime Tracking” triggers to ensure downtime is not be exited by “ghost inputs”.
Small encoder movements can cause “CarriageVelocity” in the PLC to spike momentarily due to vibrations in the mill.