I Fixed a Tractor Using John Deere's Self-Repair Service. Farmers Aren't Sold

Because it doesn't address the actual problem.

Here's how it's always worked for me:

1. A code comes up on the computer.

2. A. The problem is self evident. Or;

2. B. I search online and find the problem. Or;

2. C. I search online and find the diagnostics manual, which I use to find the problem. Then I have diagnostics manual pdf forever, and can use this in the future.

3. A. I search online and find the parts diagram. Or;

3. B. I search my dealers website and find the parts diagram.

4. I order the part.

5. I install the part.

Has something changed with newer equipment that prevents farmers from doing this?

So the author is looking at one third of the problem (from the perspective of an IT worker), in a comfortable stage-managed experience put on by Deere themselves. A sensor with a disconnected cable - a five minute visual inspection would have also diagnosed the problem!

I'm quite comfortable with computers. And yet when working on my own vehicles, anything that mentions "use the manufacturer software" is avoided unless it's impossible not to. For example my experience using Honda HDS:

1. Spend hours installing Windows in a VM, HDS software from dodgy forums (to avoid the even dodgier "cloud" offering), running an ethernet cable 75 feet outside to where I was working - when my goal was to have my hands dirty fixing the car.

2. Massively slow scan times. We're talking 20 minutes sitting there initializing its understanding of the bus by probing every device every time the software starts up. The software starts up a lot because every time it hits some unexpected condition it needs to be restarted. Every time you choose a different option to check something about another subsystem, the software needs to be restarted. Every time you need to check if you've made a permanent or temporary change, it needs to be restarted. Every time you actually get your hands dirty and make some change on the car, it needs to be restarted. And so on. Companies view these tools as pure cost centers, making it so embedded developers DGAF about any kind of robustness or polish.

3. No actual description of what can be set, or theories of operation of any hardware device. The best you get is references from procedures in service manuals designed to be blindly followed.

4. Along with that, the chance of touching a lot of things you don't really want to be touching! HDS made me reenter the VIN number every time it started up (which remember, is often), and I think this was actually writing the VIN number somewhere! I entered it wrong once and it appeared that I had actually changed something.

Now obviously Deere is not Honda, but I don't see a reason to expect this would be any better. And of course this is not even touching:

> Prices start at an annual cost of $195 per individual machine

All this overhead adds up when you're working on one or two vehicles in a personal-bespoke capacity. I'm never going to reach for that software again unless I absolutely have to, even though I know in theory it can tell me a lot in one central place. I'd rather simply model a vehicle's computers as black boxes. I'm sure if you're a Honda tech you develop a model of how the software works, what steps of the procedures to batch and when to pause and check things over, etc. But from an individual perspective where I've got one car to fix rather than one every day? It's utter trash.

Adding digital control networks to vehicles increases their inherent complexity. This is unavoidable, similar to adding any new system (eg ABS, 4WD, emissions controls themselves, etc). I think mechanics could respect that, if it wasn't bundled with a whole bunch of unnecessary complexity including top-down surveillance/control. Knowing a thing or two about technology and engineering, what would I actually expect?

1. PDF documentation with thorough bus diagrams. For every node on the bus, documentation from its manufacturer - its theory of operation, the settings it has, the messages it reads from and reports to the bus, additional message/register definitions for what can be read by diagnostic tools. Everything that you'd get if these were dip switches and LEDs rather than CAN messages.

2. Machine-readable descriptions of CAN PDUs published by the manufacturer themselves. All the message/register/etc definitions documented in the above files, in a well-defined format ready for use by third party tooling.

3. Third party libre software with the usual `make && make install` install path (ie easily incorporated into every operating environment) that uses those definitions to display bus messages in symbolic form, as well as craft new messages to tickle device functionality.

I think that about covers it. I know this would still be frustrating for many, but people would eventually get over it and even embrace it - it should be more convenient to have the computers display what they're reading rather than having to work around them. This would become standard procedure if the tooling weren't so infuriating.