10-15-2014 06:14 AM
Hello freemason,
I think it might be better to create a separate post concerning your question as it does not seem to be directly linked to the original posted question in this thread.
10-15-2014 02:56 PM
@altenbach wrote:
Your VI are owned by Timing.lvlib that you failed to attach.
The code also seems quite fragile and convoluted. Can you show us an actualy use scenario?
I've attached the actual library to make things easier. As for use scenario, this is the most common one:
What makes you say that the code sems convoluted and fragile? I have not had any issues with it yet. If there is a better way of handling these situations then I would be glad to know.
10-15-2014 03:15 PM - edited 10-15-2014 03:15 PM
It seems fragile because if you would call it at very long intervals, you might up with the same "seconds" and not register a change even if one occurred.
In terms of convoluted code, here's an functionally identical alternative of your "period change" that is significantly easier to create and maintain. 😄
10-15-2014 04:05 PM
Fair point on the convoluted. I had no idea that Not Equal etc even worked with clusters.
Apart from actually going through and breaking the time down the Time/Date to a number, then dividing that number by each relevant factor that you want to check for (i.e. 1 for seconds, 60 for minutes, 3600 for hours) and rounding down to check the numbers, which seems even more convoluted, is there a better way to improve the resilience of the code?
From my viewpoint the code should never be needed/used in any instance where the possible calling time is going to be longer then desired measured interval (longer then 1 second for secondly updates, longer then 1 minute for minutely updates) apart from causing issues with the code, this also allows the possibility of having a period skipped as is seen as a common problem when people are sampling at 1-second rates on something they want to occur every second and wonder why every minute or so it loses a second.