How did you spend your leap second?
It seems a little silly at first – a leap second! I’ve been seeing it everywhere on LinkedIn and Facebook, so inevitably I started thinking about how a second can matter. Those more spiritual than I might see it as time for reflecting on life, the universe and our place in it – instead, KODA starting thinking about circuits, data-loggers, monitoring and navigation systems.
Daylight Savings and Monitoring Systems
Some publicity about the leap-second mentioned Y2K-like scenarios which developed when the last leap-second ticked through. That reminded me of some problems which commonly occur with monitoring systems – usually twice a year – when good old daylight savings rolls around. Firstly, watch out for automatic updating of system time. PCs often do this, but that can be reflected into the data-loggers attached to them also. What this often means is that on one side of daylight saving you get a gap in the data for one hour, and on the other side of the gap you get an overlap for one hour. For the systems KODA was using this was mainly aesthetic, but it is worth thinking about how cycle triggering or multi-cycle alarm systems might be affected by such behaviour – depends on how you do it.
Secondly, the daylight savings data problem was compounded by certain PHP code on the web server. PHP tried to be smart in how it handled dates during this period, couple that with the different way in which our graphing control tried to be smart during this period, and you get some strange looking charts.
My advice: fix what you can, warn the project about the rest, and get over it – you’ve probably got bigger fish to fry.
When a Second Matters
A previous post about the CR6 mentioned a cool project on which KODA has been working. We discussed how we designed a latching relay circuit to control some pumps. This provided automated behaviour in the (unlikely) event that the data-logger or code or logic failed. Our primary reason for implementing the circuit was so that the pump-off event could be reliably controlled. This ensures that the pump is kept wet and that the level we’re emptying from/filling from is as consistent as possible.
The approach we’ve taken shuts off the pump immediately based purely on electrical circuits. An alternative was a logger/code based approach in which the logger continuously monitors the low float for open circuit, and then turns off the power to the pump once it is detected. Such a system is at the mercy of the scan rate selected for this task (and also has no manual backup). True - there was nothing to stop us from setting a super-fast scan rate, but when you take all project objectives into account the method we’ve chosen is best.
Scope CR66P
We’ve been lucky enough to get to try out the performance of the CR6/AM16-32B combo that we discussed – and it works great. Easy to code too; so long as you exercise a little bit of discipline and have documented the system well.
We’ve also been asked to help out with some fill rate monitoring on a distant system elsewhere on site. This meant that we could not use the CR6 to trigger the start of filling. Instead we used an on/off cyclical timer relay. This allows an ON-time and OFF-time to be set, and once it receives power it turns on, then off etc. We wanted hourly readings so I set an ON pulse for 1 second to trigger the latched relay circuit, and a 60 minute OFF period. It was not possible to set a 59 minute, 59 second off period, so, similar to the earth’s rotation, this scenario sees the logging interval shift by a second every hour. Luckily for us, 24 seconds a day was not crucial, therefore all we’ve done is implement a maintenance task to depower and repower the system weekly to cancel any accumulated leap seconds from the data collection.
A lesson learned on this particular system has to do with inductive loads running through mechanical relays. The pump on this system has twice the horsepower of the other four elsewhere on site, and while the relay was specified correctly for the pump voltage and current, there was quite severe arcing visible when the relay was opened to turn off the pump. After a few days this caused enough corrosion to destroy the contact. A massively over spec’d 30A solid state relay was used to replace the mechanical relay and things are humming along nicely.
Seconds Do Count
I also really enjoyed an extension to one of the auxiliary monitoring systems. This system was designed to simply fill to the top, then empty. No need for a data logger here to control the flows, but my client wanted some kind of notification of when in the day the bucket triggered the emptying process. Not to hard when you think about it. What I did was add in another relay so that when the pump triggered we had dry contact closure in parallel which the CR6 could pick up – just like a tipping bucket rain gauge.
This particular situation highlights a decision that often needs to be made – much like the problem of ‘When to turn pump off’, but this is ‘How should I look for pump status’. Depending on the characteristics of the system, it may be adequate to keep continuously polling the circuit at your normal scan interval. But consider what would happen if the pump ran for only 4 seconds, right in the middle of your 5 second scan rate? You miss it! A counterpoint might be found when you start to look at how many pulse input channels you have left on your data logger. Pulse inputs can’t be multiplexed, but check and measure circuits can. Food for thought. KODA is happy we had some pulse ports left.