Solving caster communications the expensive way

During my Bad Casting Day, I was having problems with the communications between my caster computer interface and the 14-year-old Windows laptop I was using to drive it. They connect using a USB cable, and I thought electrical noise might be the source of the problem. The computer would apparently randomly stop receiving status from the caster interface, or would stop some of its internal test cycles that are there to exercise the caster.

I eventually determined that the problem was the clock in this aging laptop. It no longer remembers the time on power-up (and replacing the internal battery did not help) so I have to set the time when I boot it, especially if I want to browse to any secure websites (using https instead of http). As it turns out, once I set the clock, after an hour has passed it jumps back to the time I set it, so the laptop keeps reliving the same hour over and over again, reminiscent of the movie Groundhog Day.

The caster-control application on the laptop is written in Java (so it should port trivially to MacOS and many Unix clones), and uses the java.awt.Timer class to run its internal timers. This class turns out to be sensitive to unstable computer clocks. It schedules the next thing to do based on the clock, so if it schedules something for 10ms in the future, then the clock jumps back an hour, that event does not occur for 1:00:00.010. If the clock continually jumps back the event never occurs.

My code did not need most of the features of this Timer class (such as a thread pool) so I changed the code to use the lock-with-timeout builtin language support instead. This is the feature that Timer uses to wait until its (mis-calculated) next-event time anyway. This seems to be insensitive to the irregular clock so I prepared the package with the new code.

I returned to the workshop to find that the caster cooling loop (which I had just refilled after finding it dry) had blown off one of its hoses and drenched, amongst other things, the laptop. I did not think the pump developed enough pressure to blow off the hoses, and it had seemed fine up until that time. Perhaps having the tank run dry warmed up the pump, pipe fittings, and hose enough to loosen the hose.

I tried to dry out the laptop over several days, and inspected it inside for visible damage, but it was dead.

So now I have a new laptop, I’m getting used to Windows 11, and the clock works properly, and the software wouldn’t care even if it didn’t. So the problem has been fixed by correcting the software or replacing the computer (or both), your choice.

I’ve also put hose clamps on the cooling loop and a more secure cover over the pump and tank.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*