The is an automotive scantool. For those who aren't DIY mechanics, it connects to your car's and reports on engine operation and trouble codes (ie, why your “check engine” light is on).

• Free Serial Number

My car has passed 100,000 miles, and received its first (hopefully spurious) trouble code a few weeks ago; the $200 investment seemed worthwhile. Except that right now, the tool is an expensive doorstop, sitting in the manufacturer's repair shop, and I wasted a couple of hours last week.

Free Serial Number

All because I ran the manufacturer-supplied update, which failed catastrophically. As I look back on the experience, I see several problems with their update process, some of which are rooted in a 1990-vintage design mentality, but all of which represent some fundamental failing that every developer should avoid. #1: They used their own protocol to communicate with the device In 1990, most embedded devices used an RS-232 serial port to communicate with the outside world. Manufacturers had no choice but to develop their own communications protocol, using something like for file transfers. But the CP9580 has a USB port. And I'm betting that it has flash memory to store its data files.

Both of which mean that a custom protocol doesn't make sense. Instead, expose the flash memory as a removable drive and let the operating system — any operating system — manage the movement of data back and forth. Doing so should actually reduce development costs, because it would leverage existing components. And it would make user-level debugging possible: simply look at what files are present. #2: They deleted the old firmware before installing the new Again, a vestige of 1990, when devices used limited-size EEPROMs for their internal storage. Not only was the amount of space severely limited, but so were the number of times you could rewrite the chip before it failed.

Better to simply clear the whole thing and start fresh. This is another case where flash memory and a filesystem-based design change the game entirely. Consumer demand for memory cards has pushed the price of flash memory to the point where it's not cost-effective to use anything less than a gigabyte.

And with a filesystem, version management is as simple as creating a new directory. It's also a case where the game changed and the system designers half-changed.

In the old days, communications code was in permanent ROM. If an update failed, no problem: you could try again (or reload the previous version). However, it seems that the CP9580 stores everything in flash memory, including the loader program (at least, that's what I interpret from the tech support person's comments, but maybe he was just being lazy). The iPhone is a great example of how to do updates right: you can install a new revision of iOS, run it for months, and then decide that you want to roll back; the old version is still there. But it's not alone; even an is smart enough to hold onto its old software while installing an update. #3: They kept the update on their website, even though they'd had reports of similar failures The previous two failings can be attributed to engineers doing things the same way they always have, even when the technology has moved forward.

This last failure runs a little deeper. After the update failed, the second time I called tech support I was told that “we've had several cases where this happened.” Yet the software was still on the website, without a warning that it might cause problems. And it's still there today. One of the best-known parts of the is the exhortation to “do no harm.” Programmers don't have to swear a similar oath, but I think they should — if only to themselves. Too often we look at the technical side of a problem, forgetting that there's a human side.

Sometimes the result ends up on, but more often it ends up quietly causing pain to the people who use our software.

I have software for my OBD scanner that I'm trying to install and when i try to run it, I get an error stating 'there is no windows program configured to open this type of file' it seems to be a wine error. I'm having difficulties trying to build a 32bit wine in my 64bit Ubuntu 12.10. Is there some way that I can tweak something in crossover to be able to install and run this through crossover? Please help with detailed instructions if you can I'm not a pro at this stuff and have been getting extremely frustrated trying to get anywhere with it. Could I get a legal copy of that software, or a demo? I have a USB based ODB scanner to use it with. On your end, you could get a debug log by, a pointing it to the software's executable.

You can ask for a log in the debug options. In the log, you should look for complaints about missing files in particular. There might be something in the resulting log to indicate what is wrong. Having tried this a while ago, I ended up using virtualbox and a winxp virtual machine. I would be tempted to try this again via Crossver as we have went through 2 versions since my last try. Know that the big trouble isn't with running software, it's getting Wine/Crossover to actually interact with the scanner. The device needs to be accessed directly, unlike a printer where the instructions are routed through cups, and this is hit and miss under Wine/Crossover.

Yes I believe their software is available for download here you can scroll through to see if you have one of their scanners but I'm assuming that most of the software is the same, just different drivers. I have a backtrace.txt bug file from Wine failing to install the software, but I wouldn't know where to begin trying to decipher what it is lacking and the winehq forum moderators are kind of giving me very vague instructions and their build instructions have left me with an unusable chroot build that can't even be accessed from terminal. I'm just hoping crossover will be able get this thing going for me, otherwise I'm just going to build a dual OS with full XP alongside linux on another dang computer! I had a bit of time before leaving my office, so I gave it a go. It's a bad news, good news sort of situation.

Bad news: The software doesn't install properly, hence your error message. Something is preventing it from managin file paths properly during install. Not really sure what to do yet, but I have some ideas. Good news: Screwing around with my win7 virtual machine, and copying files from it, I got your software running. You will need the Visual Basic 6 runtime in your crossover bottle to run it.

Since I'm already short on time, I can't really be more specific, but at least you know this isn't impossible. All right, the install does work now. Brandon, If your scanner is like mine, you'll have to finish the process while the scanner is hooked up to both an ODB port and your computer. Otherwise, it might not register for lack of power.

I don't know why but my scanner has no power whatsoever unless it's hooked up to an ODB port, so I think you best keep that in mind going forward. In case you didn't notice the steps necessary to attempt connecting your scanner is If you have any questions, I'll keep watching. Hey jean-patrick, scanner is not showing up at all using ls in the /dev or lsusb, plugging it in does turn it on, but ubuntu is not recognizing it as a device that is plugged in. Yeah, that's pretty much was my last experience. I too managed to get my software running, but couldn't get anything going for the hardware. Althought I finally got my scanner to register with the system, Wine/Crossover prooved to be too much a barrier. And by the way, I'm not really sure what the hell I did to get my system to see my device, so I really dread the idea of reinstalling Arch on my system.

If I do reinstall, I think my virtual machine solution will break. I'm really greatfull to have chosen a rolling release like Arch, just because of that. As I'm writing this, I have just had sort of an idea worth trying with Crossover (no really clear path), but it is a really long shot. I'll give it a go with my stuff in the next few days, and if successful, you will be the first to know.

I guess dual-boot is the only sure shot here.