Firmware V1.6.2609061128 is available on the Firmware Updates page. Most of what is in this build is small. One item is not, and it is the reason this article is longer than a release note needs to be.
Two weeks after publishing a fairly confident article about how GPIBEE is tested, a user reported that his adapter stopped responding during a 24 hour run. Nothing dramatic: it simply went quiet, and stayed quiet. That is a humbling piece of email to open, and exactly the kind of report you want to receive rather than not receive.
Stability is the property I care about most in this product, ahead of anything on the feature list. It is also the hardest one to promise honestly, because the only real evidence for it is time: nothing you can measure in an afternoon tells you what an adapter does on day nine. So a report like this one stops everything else until it is understood and closed, and this one did.
That report also changed how firmware gets tested here. There is now a permanent setup in which a build runs for weeks before it is called finished, exercising continuous 24/7 activity. More on that further down.
And I would rather write this article than not write it. The tidy version of this release note is a single line: "improved stability". That line is technically true, it tells you nothing, and it is what you normally get. A GPIB adapter is a thing you are supposed to be able to forget about. When it turns out not to be, that is worth a few honest paragraphs rather than a euphemism.
Why this class of bug is the bad one
A GPIB adapter is not the interesting part of anybody's setup. It sits between a computer and instruments that were often built before the adapter's designer finished school, and its entire job is to be boring. Nobody watches it. That is the point of it. Long measurement runs are exactly where GPIB earns its keep: a burn-in over a weekend, a temperature sweep that takes eleven hours, a production test that has been running since March. An adapter that works for four hours is not a slightly worse adapter. It is a different product, and not a useful one.
The failure is also expensive out of proportion to the fault. When the adapter stops at three in the morning, you do not lose the adapter. You lose the run. The instruments are still sitting there holding a state that took an hour to set up, the log file ends mid-sweep, and the earliest you find out is when you come back. Then you get to decide whether the data you did collect is trustworthy, which is its own kind of unpleasant.
And from this side of the bench
Bugs that only show up after many hours are the worst ones to chase, for a reason that is almost funny. To find out what a program is doing you add logging. Adding logging changes the timing. Changing the timing changes when things overlap, and a bug that depends on things overlapping in an unlucky order will politely stop happening. You now have a build that does not fail, no idea why, and no way to tell whether you fixed it or merely slowed it down enough to hide it.
A colleague of mine used to call this a Heisenbug, after the Heisenberg uncertainty principle: observing it changes it. He meant it as a joke. It stops being funny at the point where you have to ship the thing.
The saving grace here was having been through this before. The method is not clever, it is just patient: leave adapters running continuously, add enough extra logging to watch memory use over time rather than guess at it, and refuse to believe any theory until the log actually shows it. That took a while. A fault that needs most of a day to appear gives you roughly one experiment per day.
What it was
GPIBEE announces itself on the network over SSDP, the discovery protocol behind the Windows network view, which is how the adapter turns up there without anybody configuring anything. Windows machines send out SSDP discovery requests every now and then to see what is on the network, and every one of them gets an answer. Each answer needs a small amount of memory while it is being sent, and that memory was not being handed back afterwards.
Individually it is nothing, a few hundred bytes. But those requests keep arriving all day, from every Windows machine on the segment, so the losses accumulate, and after roughly a day of uptime there was no memory left to work with. From the outside that looks like an adapter that was fine yesterday and is unresponsive today, with no pattern to it, which is precisely why it is hard to pin down.
The humbling part is where it was hiding. Not in the GPIB timing, not in VXI-11, not in any of the places that got careful attention and a conformance suite. It was in the housekeeping around a feature whose entire job is to make the adapter easy to find. The tested parts were fine. The bug was in the part nobody thinks about, which is generally where they live.
After the fix, memory use returns to the same idle value after every announcement cycle instead of creeping upwards. It has been running continuously for several days without moving.
What happens now
A fix that cannot be reproduced any more is not the same as a fix that is proven, and "stable for several days" is a claim with a short shelf life.
So the setup built to chase this bug is staying. From now on a build runs here for weeks before it is released: adapters powered up, traffic on the network, memory use logged the whole time, and nobody touching them. It is an extremely dull test to watch, which is rather the point. A slow leak now has to get past a graph here before it can reach somebody's weekend measurement.
Years ago I had a small print server, the kind that puts a USB attached HP LaserJet on the network. It crashed about once a week. There were no firmware updates and there was never going to be a fix, so eventually it went in the bin. A perfectly good piece of hardware, one unresolved bug, worthless.
The bug in this release was genuinely hard to find. That is not an excuse available to the person who sold you the device.
Also in this release
Two smaller items, neither of which has anything to do with the memory leak above.
Screenshot downloads with GPIBEE Benches are about ten times faster
The web interface moves GPIB data in chunks, and the chunk size was 64 bytes: a conservative number chosen early and never revisited. It is now 1024 bytes. The overhead per chunk is the same either way, so doing sixteen times less of it helps considerably.
Downloading an instrument screenshot through a Bench is one of the larger transfers the web interface does, and it is now roughly ten times quicker: a 380 kB screenshot comes across in a fraction of a second. This limit only ever applied to the web interface. USBTMC, VXI-11 and the "++" protocol modes were never chunked this way and are unchanged.
Progress bars on Bench download buttons
Bench buttons that fetch a screenshot, a waveform or a saved setup now show progress while they work. Before this, a large transfer looked identical to a button that had not registered the click, which invited a second click and a certain amount of swearing.
Updating
The build is on the Firmware Updates page along with its manual, release notes and update instructions. GPIBEE appears as a virtual flash drive during an update: copy the firmware file onto it, no tools required.
If you run an adapter for long stretches, this is the build to be on. And if you ever see behaviour like this, please report it, even vaguely, even without a reproduction. "It stopped after about a day" was enough to start with.