januari (4) februari (2) maart (6) april (3) mei (4) juni (2) juli augustus (1) september (2) oktober november december
This one day at work
2017-09-07 11:00 fromthetrenches [permalink]
Here's another nice story 'from the trenches'. Packaging stations use a barcode scanner to scan the barcode on the items that need packaging. We were able to buy a batch of really good barcode scanners, second hand, but newer and better than those that we had. A notice came in from an operator: "with this new scanner, we get the wrong packaging material proposal." The software we wrote for the packaging stations, would check the database for the item which is the best suitable packaging material to package it in. It's a fairly complicated bit of logic that used the order and product details, linked to the warehouse stockkeeping and knows about the several exceptions required by postal services of the different destination countries.
So I checked the configuration of this station first. Always try to reproduce first: the problem could go away by itself, or exist 'between the user and the keyboard', or worse only happen intermittent depending on something yet unknown... Sure enough, product '30cm wide' would get a packaging proposal of the '40cm box' which is incorrect since it fits the '30cm box'. Strange. The station had the 'require operator packaging material choice confirmation' flag set to 1, so I checked with 0 and sure enough, it proposed the '30cm box' (with on-screen display, without operator confirm, just as the flag says)...
So into the code. Hauling the order-data and product-data from the live DB into the dev DB (I still thank the day I thought of this tool to reliably transport a single order between DB's). Opening the source-code for the packaging software, starting the debugger while processing the order, and... nothing. Nicely proposing the '30cm box' every time, with any permutation of the different flags (and there are a few, so a lot of combinations...)
Strange. Very strange. Going over things again and again, checking with other orders and other products, nothing. I declared the issue 'non-reproducable' an flagged it 'need more feedback', not really knowing of any would come from anywhere.
A short while later, a new notice from the same station: "since your last intervention, scanned codes concatenate". What, huh? I probably forgot to switch the 'require operator packaging material choice confirmation' back to 1, but how could that cause codes to concatenate? I went to have a look, and indeed, when a barcode is scanned (the device emulates keyboard signals for the digits and a press of 'Enter') the input-box would select-all, so the number is displayed, and would get overwritten by the next input. This station didn't. The caret was behind the numbers, and the next scan would indeed concatenate the next code into the input field.
Strange. Very strange. Into to the code first: there's a SelectAll call, but what could be wrong with that? And how to reproduce? What I did was write a small tool that displayed the exact incoming data from the keyboard, since it's apparently all about this scanner. Sure enough, the input was: a series of digits (those from the barcode), an 'Enter', and 'Arrow Down'. A-ha! These were second hand scanners, remember? God knows what these scanners were used for before, but if having the scanner send an extra 'arrow down' after each code, is the kludge it takes to solve some mystery problem in software out of your control, than that is what a fellow support engineer has to do... Got to have some sympathy for that. And the '40cm box' was indeed just below the '30cm box' in the list, so the arrow down would land in the packaging material selection dialog, causing the initial issue.
Download the manual for the scanners, scan the 'reset all suffixes to "CR"' configuration code, done.
(Update: got some nice comments on reddit)
About vehicles of the (near!) future: electric or autonomous (not and).
2017-09-18 13:48 autoelec [permalink]
Little old humble me will try to give a naunced depiction of their complex and layered opinion about something that's recently been getting some news.
I regret that most news-items on these subjects tend to handle both the new models that have a fully electric drive-train, and the fact that onboard systems of sensors and advanced signals processing may be used to autonomously let these new models operate on the streets.
Not too long ago it was made painfully clear that the seat belt should be mandatory in every automobile, and also the fact of strapping yourself in with them. In a similar light, the design of systems that could handle the performance of said automobiles has indeed proceeded by so much as to have a far better safety record with operating vehicles than us humans. So there's no doubt that the distance between a future where self-driving cars are mentioned in the text of law to some extent, is measured in years, not decades. Perhaps even months since the time is now to begin thinking about authorization and certification.
The matter of a novel power train, on the other side, is a different thing. Electrical vehicles are not new. What is new, is that battery-technology has steadily improved, and that a certain captain of industry has thrown their weight behind an undertaking to launch mass-production of purely electric vehicles(*1), trailblazing into a new domain the settled automobile-constructors weren't committed to explore (yet). Even more important is that he is succeeding at it. And building a giant battery-producing plant just for it.
What is also painfully clear is that we may just be ahead of the required battery-technology-improvement we actually need. Getting us to drive electric vehicles is hard, not only because we cling to what we know, but also because there's no way to create all the required batteries with the methods for creating them we master now. Also recharging a battery has a vastly different dynamic than refilling a gas tank; this doesn't mean that I think it should. Quite to the contrary, but it should in itself offer an improvement over how we did things before.
Where the automobile-constructors of old are set out to explore, is at the cutting edge if these combustion engines most of us are using. There's an apparent room for improvement, but apparently it only very slowly gets filled. It may have been a very good move to switch 'back' the Formula 1 specifications to a 6-cylinder design with a fuel content more in line with most mainstream vehicles. Any advancements engineered there should find their way in construction of engines a few years down the road. But that apparently takes years.
So that's why the coverage of autonomous electric vehicles kind of rubs me the wrong way. It would be the best thing for us that autonomous cars are here soon, and find mainstream acceptance quick; and that electric vehicles take over the majority when they're ready. With advances made in bio-fuel and high-milage-engines, to be expected over one or more decades, I dare even predict that autonomous control will get even more kilometers out of what you put in, be it liters or Ampère-hours.
(*1): and space-rockets, and solar panels with an in-house battery, and an attempt to improve tunnel-boring.