HP Designjet 500 story continues

The town where I live has a "Transfer Station" where you have to drop off your trash. It also has a Swap Shed where people put items that might have other uses. Old laser & inkjet printers are pretty common there, though the the inkjet ones are typically not worth fixing. This weekend I did find a HP JetDirect 600 card (stuck in an old HP laser printer) which I hoped would bring network connectivity to my big DesignJet 500.

I inserted the card into the 500, and it was recognized. However, when I tried to configure the card from the 500 front panel, it locked the printer up. I tried to reset the JetDirect card, but that didn't help. Not clear where the problem is, but I'm still on the lookout for another JetDirect card!

As a side note, I tried to find the firmware upgrades for the DesignJet 500, and HP's website is a total shambles. You can find pages that explain how to do the upgrade, and they point you somewhere else to get the download. However, those links don't actually work as another part of the website as been restructured.

Last night, I received the print heads that I had ordered. I put them in, and the printer went through the printhead alignment process -- printing much better than before. It took four cycles before the printer was happy. Color calibration was quick. The printheads that I bought were refurbished -- three of the four had already gone past their rated lifetime. Anyway, they were cheap.

Finally, I tried to print some pages, and I have to say that the quality is not very good -- it is unclear whether this is the fault of the rasterizer that is on OSX, or something else. I had to connect my MacBook to the printer with a USB cable, and then download a lot of HP software to make it work.

Anyway, now I just have to connect it to the network and try and convince the kids not to print posters!

Bringing a HP Designjet 500 back to life

I recently acquired an old HP Designjet 500 printer -- the 24inch version. I suspect that it had not been used much as the ink cartridges were full (although expired 10 years ago) and the printheads had less than 5cc of ink through them.

First, I replaced the ink cartridges with new ones (not HP). Compatible ones are dirt cheap on eBay. With new ink, I turned the printer on again, hoping for good news.

The carriage belt began to spit out little bits of decaying rubber, so another trip to eBay to get a replacement belt. This takes time to ship from China.

Replacing the carriage belt involves taking most of the printer to pieces. Nearly all the screws have T15 Torx heads. Except 1. This is either a T9 or a T8 depending on where you looked. My local Ace hardware doesn't stock anything smaller than a T10. Lowes' website is completely useless and has no search results for Torx T9. Home Depot's is not much better, but eventually reveals that they have them.

At this point, life intervenes and I realize that I'm not going to get to HD any time soon. So I resort to Amazon -- where their search engine reveals that somebody sells the Home Depot own branded kits which include T5, T6, T7, T8, T9 and T10. This makes me go and look in my pile of small tools. I find an unopened kit from Lowes which includes about 25 different small bits -- including the T9.

With the T9 in hand, I can finish the disassembly. Reassembly was simple -- until I found a piece of plastic left over at the end! I managed to fit it back in....

The moment of truth -- the printer powers up, runs the self-test. When I try and align the printheads, it fails after printing a very weak test pattern.

Now I've ordered a set of four printheads (from Hong Kong) and I'll see if everything starts to work when they arrive.

I fixed my bug!

For some time, the main GPS synchronized NTP server (and PTP master) has had unexplained 1 second jumps in the timebase. It jumps backwards for a second or two and then returns to normal. I kept adding debugging to the code (which would cause stack overflows as the vsnprintf stack frame is huge) to no avail.

Finally, I was staring at the code and saw the line:

   uint32_t tow = get32(packet) / 1000;

I'm using a uBlox 6 GPS receiver and running them in binary mode. This code was from the handling of the UBX-NAV-TIMEGPS message. The TimeOfWeek field is the number of milliseconds since the start of the week of the most recent navigation solution. I had missed this subtlety and had assumed that it was the time of the most recent PPS pulse. It turns out that sometimes the millisecond time of week does not fall on a second boundary but maybe a millisecond or so different. Given that the division does truncation and not rounding, there was my problem. Solution simple.

So, how much difference does it make? A lot. Also, I integrated the latest PPSI servo code, and a 12 hour run looks like:

The blue line is the frequency controlled by the PTP slave, while the red line is the frequency as determined by reference to another GPS receiver. This shows remarkable agreement with only a few excursions.

This shows that the offset of the PTP secondary was controlled well, with only a few excursions to as much as a microsecond. Note that the PTP master is running off a different GPS receiver (general purpose) than the PTP slave. Therefore some differences are to be expected.

Zooming in some more:

For most of the time, the offset was within maybe 400 nanoseconds of the GPS receiver. This seems remarkably good.

Thanks to Pietro for his work on the servo code: recent message.

New servo -- almost a full day

I left the code running for a full day (or so) and this is the result:

The red line is the actual clock frequency offset as determined by the GPS PPS pulses. The blue line is what the PPSI servo is controlling. On average, it does a very good job. However, there are a bunch of excursions that run into the limit (of 500,000 PPB).

This is the same chart, except with auto scaling:

There is clearly something horrible going on. I don't know what!

If I look more closely at these excursions, it appears that the clock is being reset by an amount (up to 0.25 seconds) which is then recovered by adjusting the frequency. What is not clear (at the moment) is whether this is some fault in the servo code, or in the surrounding code that drives the clock.

***UPDATE***

It turns out that there are a number of problems: one of which is that when the PTP master reboots, it sends out the wrong time for a while. Another is that sometimes something happens and the mean path delay to the master goes negative and it gets stuck there.

The PTP master reboots for reasons that I don't understand either. I have a watchdog set to reboot the board if the underlying processing stops. However, there is no easy way to figure out what went wrong in this case. I've added more debugging....