A post went out on Linkedin describing some code and a question along side it.
The post is embedded below – Or you can visit it here if you can’t see it correctly below (https://www.linkedin.com/posts/liambee_alwayslearning-plc-automation-activity-7019943695344902144-5cIO)
This is really a question about limits on data types and initial values. The reason there are an additional 2 checks is down to the fact that we don’t know how long the event of “No Wash” is going to last.
Answer
The question was:
If the first branch picks this up, why are we checking if the days are over 20? And why are we also checking if the YEAR of the last wash is 1970?
The answer is as follows
Reason For The 20 Days Check
The problem with the TIME data type is that it is limited to around 24 days. Once you go over 24 days, the TIME variable Time_Since_Last_Wash will overflow and read T#0ms.
The Days_Passed_Since_DTL is calculating the days since the date and is used to continue counting days since the Time_Since_Last_Wash has gone into overflow. On the HMI, a check can be completed checking if the following is true:
Time_Since_Last_Wash = T#0ms AND Days_Since_Last_Wash > 0
If the above condition is true, then the display is changed from Days, Minutes, Hours to just days and the Days_Since_Last_Wash is used to display the time since last wash on the HMI.
Reason For The 1970 Check
This is simple check for an error where by the Last_Wash date/time has not been set yet.
If the Filter_Data is reinitialized, the retained data is lost or the PLC’s time clock is lost and then an update to the Last_Wash occurs, the outcome could be uninitialized data is set in Last_Wash.
When this occurs, the date will be of the year 1970, since the PLC defaults to 01-01-1970 as a date.
Conclusion
The two additional branches are used as safety checks to ensure that a filter that hasn’t washed in over 24 days doesn’t suddenly clear it’s own shutdown flag when the TIME data type overflows.
In addition to that, we also safeguard against uninitialized data for the Last_Wash. This comes in useful for many reasons, such as not allowing a newly added filter to start without a wash (as it’s never done a wash before, so the Last_Wash data will be of the year 1970).
Having these types of protection in place can be considered “overkill”, but you’ll thank yourself when a filter is taken offline for 2 months for and the code recognises that and doesn’t allow a restart without a wash (which is the intended design).
📣Shoutouts
Here’s a few comments from the LinkedIn post with the correct answers or good discussion points!
This was the first post with the closest correct answer. The 1970 is along the right lines and the overflow of the TIME variable is spot on
Another great and spot on answer by James here!
You can join in with the discussion by visiting the post here:
Check Out Another Post
TIA Portal Basics – Working With Pointers
Pointers are a handy method to manage vast data sets where symbolic data allocation isn’t possible. They’re composed of constructs…
