EEVblog #975 - Human vs Autorouter

[EEVblog]

Which produces the better PCB layout, a human or a computer?

By popular request, a walkthough to see what the Altium Situs Autorouter can do on the Nixie tube PCB layout. Does it beat Dave's human layout?
How useful are autorouters?

[sleemanj]

Are you able to export a dsn file from AD?  If so would be interesting to fire it through FreeRouting and see what it makes of it compared to the AD autorouter, post the file.

[SeoulBigChris]

I would have routed the traces manually for one tube down to an imaginary point below each tube. Then duplicated those routes for each tube (may or may not be easy depending on your tools). Maybe I'm wrong, but I suspect it might result in a "prettier" layout.  That combined with gate swapping, which you decided not to do in your last video.

[EEVblog]

I would have routed the traces manually for one tube down to an imaginary point below each tube.

That's basically the "FPGA fanout method", and yeah, it can work. But doesn't add much value in this case IMO, could even make things worse unless you add pin swapping.

[DutchGert]

Nice video

I was hoping you would try out the new ActiveRoute stuff from AD17....

[Windfall]

A perfect demonstration of why autorouters suck (although this one seems particularly bad !). Most will see the board as just a random collection of single ended connections and go to town, one by one. If you do that too, you will paint yourself into a corner very quickly, and end up with the same copper spaghetti.

[Brumby]

I know I was one of those who asked for this - and I can't say I was impressed with this algorithm.

Even just casually watching, something I thought that seemed ridiculous caught my eye - so I went back and took a screen shot.

I've marked out the two traces - and it seems to me there was a far easier way to route these, with only one very minor change to another trace.



.... but this just seems to be typical.

A bit disappointing.

[AndyC_772]

It certainly used to be the case that the only worthwhile auto-router in the industry was Cadence SPECCTRA. I think it's been renamed and absorbed into Allegro since then. Maybe others have now caught up.

I used to use it to determine how many layers, and what geometry, a board was likely to require. For example, after a few hours, it would become clear that a board really couldn't be done on, say, 6 tracking layers, and really needed 8.

Sometimes it really would come up with a decent solution to the bulk of the routing, and would require only minimal modification by hand afterwards.

Remember, it's a mistake to reject a PCB layout just because it looks 'ugly'. If it meets DRC requirements for spacing, timing, noise, differential pair routing, decoupling and so on, then by definition it's OK. An auto-router, quite rightly, does not make aesthetic or other subjective judgment about whether or not a given layout is 'attractive' as well as functional.

I'm probably as guilty as anyone of trying to make PCB layouts that look "nice" as well as work, but it's important to understand that the two aren't necessarily related.

[krivx]

There are some functional benefits to "beautiful" boards, especially if they are assembled or tested by humans. It's much easier to spot a polarized component populated the wrong way round if they all face the same way for example. Tombstoned parts can be easy to find if they are all lined up in rows, the part that breaks the pattern jumps out to the eye.

[AndyC_772]

Totally agree when it comes to component placement.

[fmaimon]

Your 160V line seems a little too close to the bottom ground fill. It may be better to increase the clearance in there...

[andrew_c]

Spectacular fail or not Dave, I'm just rebuilding your schematic and will soon let the power of Diptrace Auto-place/route commence!

[digsys]

Been manually routing for ever. I've tried various auto-routers as they appeared, adn in all cases MEH. There's something satisfying in solving a tricky placement / route by
unconventional means :-)  or getting a boner on a really nice looking layout ! Humans will never be replaced !!

[james_s]

I haven't tried any recently but I never had much luck with autorouters. They work ok for doing a quick layout of a simple board where the layout is not critical but I was never really happy with the results. Seems like the router was happy to put 10 vias on a single trace and zip it all over the board.

[mikeselectricstuff]

The big problem is that current autorouters start too late in the process. Good layout is all about placement, so this us where the process should start. A router should also be able to do pin and gate swapping.
Of course all this needs more setup and constraint definition, but it ought to be able to produce a far better result in most cases.
And of course it should also be able to use GPU power to speed things up.

[andrew_c]

Soooo, Diptrace couldn't auto-place in such a small-defined board size.

It didn't do an awful job of the autoroute. Though, the data lines are all over the shop and it wouldn't auto-place the vias in the copper pour. But get this, it only took a whopping 5 seconds... A WHOLE 5 SECONDS to autoroute the board - not minutes. Crazy fast.

Of course, I'm not quite using the same pads/traces. But this took a few hours re-learning this software and building components.

[sleemanj]

Soooo, Diptrace couldn't auto-place in such a small-defined board size.

Could you do an export of the DSN (without anything routed or poured, just placed components)?  File > Export from memory without looking. 

[mikeselectricstuff]

I'm sure it must be possible to apply all this new machine-learning stuff to PCB layout - there's a huge amount of examples to teach it what a good layout should look like.

[mikeselectricstuff]

Might be fun to throw the same layout at this :
http://eda.eremex.com/products/topor/

[Poe]

What the hell was that Dave?  It shouldn't take AD17's autorouter more than ten seconds on a board that simple.  Probably less than five if you exclude the ground plane.

I'm running Altium 11 on an XP machine from 2004.  I just used Autorouter on a board twice as dense and it took 55 seconds. 

Are these files public so I can download and fix Dave's setup issues? 

[Poe]

Looks like the gap between your nixie pins can accommodate at least three times as many traces as Dave's footprint, among other apples/oranges.

[Cerebus]

What the hell was that Dave?  It shouldn't take AD17's autorouter more than ten seconds on a board that simple.  Probably less than five if you exclude the ground plane.

I'm running Altium 11 on an XP machine from 2004.  I just used Autorouter on a board twice as dense and it took 55 seconds. 

Are these files public so I can download and fix Dave's setup issues?

Don't forget, Dave did say that running screen capture sucked up some juice, and I strongly suspect that translates to a lot of juice with all the redraws that Designer is doing during autoroute and I'm told more recent versions of AD live or die on graphics card performance much more so than older versions. Remember, Designer can't update the screen until screen capture has finished with it. I've known some graphic intensive things run like they are in treacle if run with screen capture, it's very package specific how bad the damage is.

[EEVblog]

Soooo, Diptrace couldn't auto-place in such a small-defined board size.
It didn't do an awful job of the autoroute. Though, the data lines are all over the shop and it wouldn't auto-place the vias in the copper pour. But get this, it only took a whopping 5 seconds... A WHOLE 5 SECONDS to autoroute the board - not minutes. Crazy fast.
Of course, I'm not quite using the same pads/traces. But this took a few hours re-learning this software and building components.

Look at how many traces it fits through the Nixie pins! 4 of them compared to 1 in my example.
Like I said in the video, do not compare autorouters unless everything, and I mean every single condition, is 100% identical.

[kalleboo]

Soooo, Diptrace couldn't auto-place in such a small-defined board size.

It didn't do an awful job of the autoroute. Though, the data lines are all over the shop and it wouldn't auto-place the vias in the copper pour. But get this, it only took a whopping 5 seconds... A WHOLE 5 SECONDS to autoroute the board - not minutes. Crazy fast.

Of course, I'm not quite using the same pads/traces. But this took a few hours re-learning this software and building components.

What the heck is going on on NX6 pin 2? Is it going up to a mm away, then going through a via to the other side and finishing there?

[bpiphany]

Why on earth not do the pin swapping? It would have made the routing so much easier and obvious it would probably have been faster in total. Could have spent some time doing a super neat "fanout" of one nixie tube and then copy pasted that. It would have looked tidier, there would be more room for clearances, the signal paths would have been more similar (not that it matters), and I would believe doable without a single track on the back.

It would probably also be an excellent exercise of an autorouter badly messing up something humanly obvious.

[EEVblog]

Why on earth not do the pin swapping? It would have made the routing so much easier and obvious it would probably have been faster in total. Could have spent some time doing a super neat "fanout" of one nixie tube and then copy pasted that. It would have looked tidier, there would be more room for clearances, the signal paths would have been more similar (not that it matters), and I would believe doable without a single track on the back.

You don't get something for nothing. Pin swapping means you have to spend more time and effort coding compared to having all the segments in sequence.
Also, might have been faster on the PCB, might have not, you don't know.

[MrBungle]

Dave, this is the internet, you're expected to try every option/combination/iteration possible to show how much time you can save 

[james_s]

I haven't found pin swapping to result in significantly more coding effort in the nixie clocks I've built. They've got 10 cathodes each so they already don't fit neatly into bytes, although since the left tube from each pair generally doesn't have to go up beyond 5 you can use a 16 bit word to drive each pair. I've used a few different techniques but usually it involves a lookup table to do the decoding and then a routine that shifts the whole string of bits out to a row of shift registers every second to update the display.

[bpiphany]

I agree on the code getting more involved. Once you nail the reverse mapping though it should be possible to abstract away nicely and be done with. On an embedded system optimizing processing resources through extra effort routing pins in natural "schematic order" could possibly make sense. It's of course just my personal opinion, but I think it's blatantly obvious the routing would have been so much easier.. That ratsnest is a bloody mess, no matter which way you move and rotate the shift registers.

[Bud]

I'm sure it must be possible to apply all this new machine-learning stuff to PCB layout - there's a huge amount of examples to teach it what a good layout should look like.

True, Google could make more money designing a decent auto router then their stupid self driving cars.

[andrew_c]

What the heck is going on on NX6 pin 2? Is it going up to a mm away, then going through a via to the other side and finishing there?

It's there, I promise!



I've attached my schematic, pcb and components and Autorouter DSN (Diptrace) for anyone who fancies giving it a bash.

[MrBungle]

It's there, I promise!

Yes, but I don't think he was questioning whether the connection was there, why the via?

[andrew_c]

Because Autorouter.

[EEVblog]

It's of course just my personal opinion, but I think it's blatantly obvious the routing would have been so much easier.

I said that in the video.

[sleemanj]

FWIW out of curiosity I took andrew_c's DipTrace PCB, setup the DRC and Via style as much as I could figure Dave's was, I don't know what trace width's Dave has set though, unrouted everything, removed the fills (added back after routing) and ran it through FreeRouting.  Should be noted that I am using DipTrace 2.4, not the latest version (I was surprised it allowed me to open the file, and seems to have no problem with it actually).

It took, I dunno, about 45 seconds in FreeRouting to route, and then I left it optimising for a few minutes, 7 or 8 passes, it probably could have gone a bit longer if I'd left it but I suspect the gains would be minimal.

The rules used (fwiw, this appears to have produced up to 2 traces between the nixie pins)...



FreeRouting....


Imported back into DipTrace Top Layer Only...


Bottom Layer Only...


Combined Layers without pour for clarity...

[Deridex]

Thanks for the video Dave.
Now i can throw the video at anyone that says: Why don't use the Autorouter ? 

[free_electron]

why not simply use channel design. route one tube and clone the rooms ?

[mikeselectricstuff]

why not simply use channel design. route one tube and clone the rooms ?

10 channel nixies, 8 chennel drivers.

[Brumby]

why not simply use channel design. route one tube and clone the rooms ?

10 channel nixies, 8 chennel drivers.

Exactly.  Did we not take notice of Dave's comments .... and the schematic?




That argument is better suited to a 1:1 relationship - which this design does not have.

[vinicius.jlantunes]

@sleemanj, that Freerouter routing is not too bad is it? A few quirks here and there but overall seems to be OK.

[ali_asadzadeh]

If you are serious in the Game, Just use the Human approach. actually if you are skillful enough by using some kinds of tricks you can do much better in speed terms too. Like using spinets, Copy and past, using rooms wisely, using multi-Chanel design.
And note that in terms of routing quality both approaches are not comparable, you can not achieve the great results of human with a auto-router ...even with active route in AD.
Do not be lazy... your efforts would get paid!

[Twoflower]

Wow, it seems even to forget to place some vias.

[free_electron]

why not simply use channel design. route one tube and clone the rooms ?

10 channel nixies, 8 chennel drivers.

so: bad electrical design. should have used 10 channel drivers.  now the software is also going to be a mess to control this. why not make a proper single tube drive module.
That is also part of pcb design ... compartimentizing the design , even if you sacrifice some parts it may in the end turn out to be cheaper due to less board work and less complicated software work ...

[Dubbie]

now the software is also going to be a mess to control this.

No it's not. It's no big deal at all to make a lookup.

[james_s]

It's really no problem at all. That's one of the things I liked so well about microcontrollers. Using a uC made the hardware design trivial and I could work out the details in software. Nixie clocks were the first microcontroller project I ever did and what finally motivated me to learn some programming. It was far more convenient to use off the shelf 8 bit shift registers and map the nixie cathodes arbitrarily in the code.

Also since I was building a clock that was only going to be a clock, on most of mine I only hooked up 6 cathodes in the 10s tube and all 10 in the units tube in each pair. No tube pair is ever going to read higher than 59.

[kalleboo]

so: bad electrical design. should have used 10 channel drivers.  now the software is also going to be a mess to control this. why not make a proper single tube drive module.

I suggest you watch the earlier videos in the series for the justification of the driver solution

[mikeselectricstuff]

why not simply use channel design. route one tube and clone the rooms ?

10 channel nixies, 8 chennel drivers.

so: bad electrical design. should have used 10 channel drivers.  now the software is also going to be a mess to control this. why not make a proper single tube drive module.
That is also part of pcb design ... compartimentizing the design , even if you sacrifice some parts it may in the end turn out to be cheaper due to less board work and less complicated software work ...

What complete and utter nonsense. Software is trivial - just a lookup table.
Even if there was a suitable 10 channel driver, it would still be a non-trivial mapping to 8 bit bytes.
And if a 10 bit driver existed, it would almost certainly be more expensive and less common than an 8-bit one, simple because 8 bit parts are much more widely used.
Oh, and there is no such thing as "bad design" - only more or less appropriate for a give set of constraints.

[VK3DRB]

The Altium autorouter by and large is a waste of time. You cannot beat manual routing done by a human when using Altium. I had a colleague who once said if you got all your design rules in place, the autorouter does a great job. What frogshit.

I manually route all my boards. Only once in the last 8 years have I bothered with the autorouter, and that was to give me a clue in a very complex region of interest. Then, of course, I do an undo and manually route. The autorouter is one of Altium's biggest let downs. It really is crap.

I use Altium 15, though I heard from Altium that the latest Altium has a track cleanup tool which works wonders.

[free_electron]

why not simply use channel design. route one tube and clone the rooms ?

10 channel nixies, 8 chennel drivers.

so: bad electrical design. should have used 10 channel drivers.  now the software is also going to be a mess to control this. why not make a proper single tube drive module.
That is also part of pcb design ... compartimentizing the design , even if you sacrifice some parts it may in the end turn out to be cheaper due to less board work and less complicated software work ...

What complete and utter nonsense. Software is trivial - just a lookup table.
Even if there was a suitable 10 channel driver, it would still be a non-trivial mapping to 8 bit bytes.
And if a 10 bit driver existed, it would almost certainly be more expensive and less common than an 8-bit one, simple because 8 bit parts are much more widely used.
Oh, and there is no such thing as "bad design" - only more or less appropriate for a give set of constraints.

nope. i don't agree. There are dedicated nixie tube drivers. all you need is a 4 bit register , slap an 4 to 10 decoder (74142) followed by a hv driver  (can be a transistor array). now you can simply directly shift out nibbles. no need for lookup muckery tabely thingies.

a simple 8 bit shift register can drive two nixies.
so one 'module' would be one 8 bit shift register, two 74142 and an array of HV drivers. it would be a nice compartimentalized module ready for cloning. you could even use an i2c io expander instead of a shift register.
drive two nixies directly from an i2c bus.

That is how i would design it. the modules are now reusable ,i only need to layout one block and replicate it as many times as i want and my software becomes very simple.
With nixies you will only drive one grid at a time so there is no need to wast that many bits to have fine grid control. a 4 to 10 decoder will do nicely.

anyway. to each his own. my design approach is different. i like reusable blocks. makes layout simpler.

to be fair : i wouldn't muck around with any of this. i'd use a supertex high voltage 32 bit shift register in plcc44 ... drive 3 nixies directly. leave 2 outputs unconnected.

[mikeselectricstuff]

why not simply use channel design. route one tube and clone the rooms ?

10 channel nixies, 8 chennel drivers.

so: bad electrical design. should have used 10 channel drivers.  now the software is also going to be a mess to control this. why not make a proper single tube drive module.
That is also part of pcb design ... compartimentizing the design , even if you sacrifice some parts it may in the end turn out to be cheaper due to less board work and less complicated software work ...

What complete and utter nonsense. Software is trivial - just a lookup table.
Even if there was a suitable 10 channel driver, it would still be a non-trivial mapping to 8 bit bytes.
And if a 10 bit driver existed, it would almost certainly be more expensive and less common than an 8-bit one, simple because 8 bit parts are much more widely used.
Oh, and there is no such thing as "bad design" - only more or less appropriate for a give set of constraints.

nope. i don't agree. There are dedicated nixie tube drivers. all you need is a 4 bit register , slap an 4 to 10 decoder (74142) followed by a hv driver  (can be a transistor array). now you can simply directly shift out nibbles. no need for lookup muckery tabely thingies.

So you'd increase the chip count and use obsolete parts for the sake of a few bytes of lookup table? 

[mikeselectricstuff]

a simple 8 bit shift register can drive two nixies.
so one 'module' would be one 8 bit shift register, two 74142 and an array of HV drivers. it would be a nice compartimentalized module ready for cloning. you could even use an i2c io expander instead of a shift register.
drive two nixies directly from an i2c bus.

The way I'd have done it :
Route one nixie to a line of 10 pads, whichever way is easiest for layout. Repeat for each digit.
Route one driver to a line of pads, whichever way is easiest for layout. Repeat for each driver, spaced at 8/10ths of the nixie spacing.
Route the pad rows together in order, then delete the pads.

Easy to route, and easy to re-use if you remember to save a copy of the nixie+pads and driver+pads.

The mapping from drivers to nixies is consistent so you only need to do mapping for one digit. You can treat the whole display as a string of bits, ten per tube, all shifted out to the drivers.
If there are any unused outputs, have them at the far end so you don't need to worry about padding.
 
If your hardware supports 10 bit SPI, even simpler, If not, bit-bash it as speed isn't going to be an issue, and probably simpler than merging the 10-bit values together to form whatever word size your SPI port likes, but you could easily do the latter if you wanted.

[free_electron]

So you'd increase the chip count and use obsolete parts for the sake of a few bytes of lookup table? 

Then why use obsolete nixies in the first place ?
nixies and nixie drivers and 74142 all belong to the same era : the dark ages.

i'd sod all of them and replace all of that with a supertex hv driver.

one plcc44 drives 3 nixies directly. 8 nixies would be driven by 3 chips. simple.

actually the whoel nixie bang can be driven by one chip  : HV57009
that's a 96 bt hv driver shift register.
there is even an128 bit version. but that is a BGA ...

[mikeselectricstuff]

nixies and nixie drivers and 74142 all belong to the same era : the dark ages.

The obsolete thing was just an aside - this was a more general argument about use of parts and PCB layout - the same arguments could just as easily apply to LED displays or arrays of mechanical actuators etc.

[EPTech]

Hi all,

I have always done manual routing. I never took the step towards autorouting because I always assumed that the time it would take me to, properly set it up, tweak the rules and relaunch the autorouter for who knows how many iterations, would come close to the time it would take me to route the PCB myself. I do like that you can define some basic rules that help you real-time with manual routing. When I used to route PCB's with Ultiboard 5.72, you had to route first and then launch the DRC, solve the issues and rerun DRC, and so on, until no more DR errors were flagged.

Happy routing.

[james_s]

Because nixies look cool. In most cases I don't care what the drivers look like, and if I were going to use 74142's I'd build the whole clock out of period correct devices.

There are lots of simple ways to easily and reliably drive a bunch of nixies. They may not fit your idealistic obsession with identical subsections that can be cloned but who cares? The code is trivial regardless of how it's wired. Once you've written the code, it can be reused as many times as needed. Hardware costs money, the goal is to simplify hardware and it's ridiculous to make the hardware more complex just to make the code a little simpler. A string of 74HC595s is cheap and works great when coupled with HV transistors or integrated driver ICs. There also are some HV shift registers out there designed for driving VFDs that can be used. Those Supertex drivers do work well but unless you get them as samples they're somewhat hard to find and relatively expensive, and internally they're the same as a string of 74595's with HV transistors on the outputs.

Whatever the hardware looks like, you're still working with groups of 8 bits in software. I can whip up a lookup table in about 5 minutes that will work with any wiring layout you want and the whole clock code fits in an AVR with 2K of flash with loads of room to spare. The whole point of using a microcontroller is that all the heavy lifting can be done in software and the hardware can be greatly simplified over what would be required to use jellybean logic.

[brucehoult]

Why on earth not do the pin swapping? It would have made the routing so much easier and obvious it would probably have been faster in total. Could have spent some time doing a super neat "fanout" of one nixie tube and then copy pasted that. It would have looked tidier, there would be more room for clearances, the signal paths would have been more similar (not that it matters), and I would believe doable without a single track on the back.

You don't get something for nothing. Pin swapping means you have to spend more time and effort coding compared to having all the segments in sequence.
Also, might have been faster on the PCB, might have not, you don't know.

The extra coding amounts to one global array mapping the pretty pin number to the physical pin number, and one extra memory reference to look it up every time you want to set or clear a pin. Have you got ... what? ... 80 bytes of memory to spare?

[brucehoult]

why not simply use channel design. route one tube and clone the rooms ?

10 channel nixies, 8 chennel drivers.

so: bad electrical design. should have used 10 channel drivers.  now the software is also going to be a mess to control this. why not make a proper single tube drive module.

Why is the software a mess?

Something like this:

Code: [Select]

#define NUMDIGITS 8
#define NUMDRIVERS 10

byte prettyToPhysPin[] = {..., }; // 80 entries, according to routing layout

byte display[NUMDIGITS];

void outputDisplay(){
  byte pinOutData[NUMDRIVERS];
  for (int i=0; i<NUMDRIVERS; ++i) pinOutData[i] = 0;

  for (int digit=0; digit<NUMDIGITS; ++digit){
    int physPin = prettyToPhysPin[digit*10 + display[digit]];
    pinOutData[physPin/8] |= (1<<(physPin%8));
  }

  digitalWrite(latchPin, LOW);
  for (int i=0; i<NUMDRIVERS; ++i)
    shiftOut(dataPin, clockPin, LSBFIRST, pinOutData[i]);
  digitalWrite(latchPin, HIGH);
}

Easy peasy.

[james_s]

The extra coding amounts to one global array mapping the pretty pin number to the physical pin number, and one extra memory reference to look it up every time you want to set or clear a pin. Have you got ... what? ... 80 bytes of memory to spare?

The way I look at it, I figured it out on my own, more than 15 years ago as a 20-something self taught "engineer" with no formal programming lessons beyond the Apple II BASIC elective I took in 7th grade, so it can't be particularly hard. It was my first microcontroller project ever at the time, and I don't claim to be a programmer even now, just a guy who can write some code if the need arises. I built about a dozen clocks using various hardware designs and display types, and all of them fit into what are now primitive AVRs with only 2k of flash with room to spare. There is no reason to even worry about optimizing code for a clock unless that's something you enjoy doing. The code could be an absolutely horrible, terrible mess that breaks all kinds of rules and it won't even matter, all it has to do is keep time and update the display. It will spend the vast majority of its cycles spinning in loops waiting for things to happen.

[AF6LJ]

That's nuts even if you left out the grounds in the autorouter, you would spend more time fixing all the crap than it would take to have routed it yourself.
That was really good Dave thanks for posting this.

[mash107]

In this episode... Dave Jones reprises his role as John Henry... showing that man is greater than machine once ad for all

Well done!

[djacobow]

Someone should build an "autorouter" that is just an API for your PCB tool on your end, and a room full of layout folks on the other end.

Key is coming up with an appropriate "objective function" that captures a lot of the goodness that is hard to describe to a computer ("neatness","regularity","clarity","what were you thinking?", etc) and that is difficult to game. Then the "router" gets paid according to how well he or she does. Maybe from the router's perspective, it's set up like a video game, like in The Last Starfighter or Ender's Game.

If you are clever enough, you can set up the work for the "router" in such a way that he or she doesn't need to know the first thing about PCBs and electricity. Just "solve this abstract puzzle according to these rules."

I'm 82% joking, and 18% fearful that someone will take up this very idea.

[brucehoult]

The results from those programs are pretty shocking -- or should I say, from those features in those programs. Maybe they haven't put much thought or effort into them.

I'm pretty sure I could do a *far* better job of auto-routing, if I spend a year on the problem. And with much faster results too.

The problem is I'm gainfully employed doing other kinds of optimisation problems (compiler for mobile phone GPUs, at the moment) that will have huge revenue streams later. I doubt the market for a truly good PCB layout algorithm is very large.

[xjordanx]

Hi All,

I think you should see this video with Dave's design from Charles, the Product Manager at Altium in charge of routing. He's given this video to Dave, but Dave hasn't had a chance to post it anywhere yet as a response.

You should definitely check out the "ActiveRoute" tool, which Dave didn't mention. It's user-guided automation, so best of both worlds:
https://youtu.be/yaxSUBfTy7A