Resurrection V0 - Stubborn Sausage Fingers Chronicle

[smirk]

Well despite the tempting from certain members (you know who you are!) I decided to rebuild my partially buggered V0.1 rather than build my secret V2.4.  I was never 100% happy with my first V0. Then the hot-end blocked (or so I thought) but on stripping down the mini-AB I discovered the gear is loose on the main drive shaft/gear:

Sadly I cannot remove (or tighten) the grub screw holding the gear so I'm buggered. If I'd known that before destroying the upper section of the mini-AB I could have bodged it by supergluing the gear onto the shaft. I don't think I was so daft as to use superglue in the first place but I must've been overly generous with the locktite. None of the solvents I have on had seem to have any affect.

Clearly a combination of masochism and stubbornness  means the "only" option is to rebuild the machine, it would only niggle at me otherwise. All the wonderful experience I've gained from the first two V0 builds will make this time around a breeze.........(or possibly an icy-blast from the bowels of hell)

Here's what the poor thing looks like at the moment since I've decapitated it:

 

So in terms of mods....

• Magnetic Panels.
• Klicky Probe.
• Orbiter 2 extruder.
• Belted Z.

I will also replace the linear rails - when originally building this (and after throughly reading the manunal several times) I still managed to allow some of the carriages to slip off the rails (so I "think" I lost some balls). I will probably replace the acrylic panels with ACM ones. As I type this I realise it'll be a complete rebuild of the frame!

The  other thing I'm intrigued in is the Kirigami bed. I retrofitted the Kirigami bed to this machine and I do not remember the same level of hassle as I had with the "direct" fit on my second V0. Either this bed was better manufacturered or it's just not fitted properly (and I've not noticed?!)

Last but not least I'm thinking about CANBUS, I definitely like fewer wires than more. The zillion wires makes the hotend messy. The reservations I have about the CANBUS is the implementation of the toolhead (especially the extruder motor driver) and how it will handle heat. Motor drivers (especially cheaply implemented ones) are extremely prone to overheating. Guess if it does not work out I can go for a toolhead PCB instead of having to splice wires.

That's the rough plan. Beyond disassembly not a lot will happen until February as everything else is on a slow-boat from China.

 

[mvdveer]

2 hours ago, smirk said:

So in terms of mods....

• Magnetic Panels.
• Klicky Probe.
• Orbiter 2 extruder.
• Belted Z.

I like where you're going with this.

2 hours ago, smirk said:

Last but not least I'm thinking about CANBUS, I definitely like fewer wires than more.

This is the one thing that still scares me personally - will have to bite the bullet on this with the Trident build

[smirk]

1 hour ago, mvdveer said:

This is the one thing that still scares me personally - will have to bite the bullet on this with the Trident build

It'll definitely be the way to go. I think the two areas that concern me are "thermal parameters" (for lack of a better phrase) and cabling (or more precisely the signal cable). It's data-cabling and that's (or rather should be) twisted pair. Most of the installs I've seen are just loose cabling. Any twisted pair cabling (generally) is solid core, this kinda of stuff is fixed installation (beyond vibrations) it'snot meant to be flexing around, That's something I need to ponder - anything flexible is unlikely to take (and keep) a twist without some coaxing of some form.....but still need the flexibility. I'll need to see what space is available on any toolhead board for a stonking great heatsink. The silly-little blue spiky things you generally get definitely won't cut the mustard.

[smirk]

Well  it appears to be a lot easier/quicker gutting a printer than building it. Managed to get down to the bare frame already:

I forgot how many captive M3 nuts were in the frame until they came cascading out of a couple of the extrusions

On closer inspection of plastic parts there is a little "corrosion" from the locktite  (I didn't have my plastic friendly stuff for this original build). However, on the whole most of the plastic pieces have held up well. Although, one of the XY Joints is showing a little splitting between layers but other than those issues the plastic pieces (which weren't printed on a Voron) have held up well. Likewise the bearings and most other mechanical parts look still to be in good  nick.

The Z-axis linear rails are a little "crunchy" whether that is due to loss of balls or just the fact they were the poorest rails in the set so got relegated to Z, I don't know/cannot remember.

All the bolts came loose as expected, you could tell the ones with locktite but they all undid, so God only knows what I did to the grub screw on the extruder grear!? Perhaps I did go senile and used superglue?

The Kirigami bed on this one is aluminium so I suspect more forgiving than the stainless steel one on my second V0. Having said that I suspect it could do with a little true up, I don't think the tabs were aligned as they could've been.

There's not a lot to do now until all the various parts arrive in the post over the next month. So I think the plan for the moment will be:

• Get the linear rails removed.
• Disassemble the XY joints and AB motor mounts.
• Decide what parts can be scavanged, reused, marked as spares or binned.

[claudermilk]

Two quotes come to mind so far:

"The damage doesn't look so bad from out here."

 then

"Well...that escalated quickly."

 

I am with you on CAN bus. It's intriguing--I like the idea that 4 wire gets the job done. But the software side is still pretty daunting observing the long and intensely technical thread trying to get it working.

[smirk]

I knew this was going too well! The Gods are punishing me for hubris....

I'm struggling to get the rails off. The M2 nuts are way smaller than the internal dimensions of the 1515 extrusions - thus the nut carriers not just to keep the nuts nicely spaced and in place. When I fitted them, I fitted them with nuts facing up, my logic was I wanted the nuts interfacing with the internal face of the extrusion rather than having and uncertain mount of printed plastic sandwiched between the nuts and the internal face of the extrusion.

Naturally at the time this seemed like brilliant logic. Trouble starts when you come to dissasembly and the damned piddly little M2 nuts spin in their plastic graves. So the bolts are turning but without purchase on the nut they're not doing anywhere.

Well, at least I have time to get creative....

[mvdveer]

3 minutes ago, smirk said:

I knew this was going too well! The Gods are punishing me for hubris....

Always something. And if there weren't, we would not be in this hobby. Sure your creative mind will come up with a solution sooner than later

[PFarm]

Awesome build love the reference to sausage fingers in your title I got a set of those as well LOL!

[smirk]

26 minutes ago, PFarm said:

I got a set of those as well

Just got to be realistic and pragmatic, if I listed all the other "gifts" the title would be longer than the diary! Like they say, old age does not come by itself.

[smirk]

On 1/2/2023 at 8:22 PM, mvdveer said:

Sure your creative mind will come up with a solution

Well, if brute force and the application of sufficient heat along with a soupçon of luck count as creative then I came up a with a solution.....which worked. I managed to get the rails off the extrusions:

I don't think it even involved me  speaking any "dutch" which is possibly even more remarkable given how hot I had to get things.

Anyway, lesson learned I've ordered some LDO nut bars for the rebuild process.

 

[mvdveer]

17 minutes ago, smirk said:

I don't think it even involved me  speaking any "dutch"

Goed gedaan

[smirk]

Well while I wait for the various replacement parts to arrive from the other side of the planet, I thought I would get the various parts printed up:

 

The Canbus gubbins have arrived so I'll play with getting that set up and everything will good to go once all the bits do arrive. As per my second V0, I plan on using the PICO-sandwich approach with the SKR-PICO+Raspberry PI zero.

 

[mvdveer]

2 hours ago, smirk said:

The Canbus gubbins have arrived so I'll play with getting that set up and everything will good to go once all the bits do arrive. As per my second V0, I plan on using the PICO-sandwich approach with the SKR-PICO+Raspberry PI zero.

Looking forward to following this. As you, I am not completely satisfied with my first V0 build. First Voron build- anxious to get it done and printing, rushing, not as cautious, etc etc. But it is still printing well at present 

[smirk]

Right, a little update on my "Advenutres in CANBUS-land"  or "Dear God! It shouldn't be this hard"...

For this rebuild I'm using the BigTreeTech EBB36 CAN v1.2 and the U2C v2.1, both these devices at their heart have a STM32G0B1 processor.

For the moment, I've been working on sorting out the U2C since I'm not going to get very far without my CANBUS network adapter. I'm struggling how to structure this entry without making it sound like the last day and a half have been an endless torrent of profanity (I did stop to eat several times and I don't swear with my mouth full).

The BTT documentation is, to use a colloquialism, utter pish. Not only are there important ommisions (like where to get the firmware) but there is (I think) factual inaccuracies in some of the stuff they are saying to do (network config).

They do provide pre-canned firmwares for the devices which I guess you could use but you would be dependent on them always providing up-to-date versions coupled to the vageries of Klipper updates. So I decided not to use the pre-canned firmwares. That naturally brought me to the next problem, the BTT branch/cut of the candlelight firmware does not appear to actually/properly support the STM32G0B1 processor. They do have a branch of candlelight apparently patched for the G0B1 processor but for the life of me I could not see how to actually build a G0B1 version of the firmware (all the build options just produce STM32F versions)!

I did find a version (last week) of the candlelight firmware (properly) patched for the G0B1 processor on github which then allowed me to build a correctly targeted firmware using "make G0B1_U2C_fw" and it worked! Mulling things over I'd chosen self-compiled candlelight in an effort to "keep things simple" (and avoid the more "complex" scenario of putting klipper onto the device), but having faffed about so much correcting instructions and finding a working firmware I kinda soured to the idea especially as I would be dependent on "one" person's efforts patching a branch (of a branch) of the original firmware. Besides I would have to bugger about putting the board into DFU mode by pressing an incredibly small "Boot" button when plugging in the USB cable...all too much for old sausage fingers. I changed my mind and went for the CANBOOT firmware which will allow my to update the components with the latest klipper firmware over the canbus itself. Ironically, this turned out a whole lot easier than I originally thought (but to be fair I had not properly accounted for the pish-factor).

 

The new process involves getting canboot onto the U2C (treating it as a regular USB device) and then installing klipper onto it to treat it as yet-another MCU attached to the PI.

You don't need the U2C connected to your PI at this stage (getting the software ready).The first thing to do was install some additional tools onto the PI:

sudo apt install gcc-arm-none-eabi cmake git

The "gcc-arm-none-eabi" most likely will already be installed on a machine running klipper, but I found the mainsailOS did not have "cmake" installed by default. This command is partially redundant, it really depends on what is included in the base build, but it does no harm to run it as  all it will do is grumble if things are already installed. Since software installs must be performed as the superuser (root) we use the "sudo" command to run the "apt" packaging command.
 

Then you need to clone the CANBOOT github repository:

git clone https://github.com/Arksine/CanBoot

This will create a directory called "CanBoot" in the current directory. You need to change into that new directory and then configure the software using "make menuconfig":

cd CanBoot/
make menuconfig

 

The "make menuconfig" command gives you a text menu system practically identical to the one used when configuring klipper software. For the G0B1 processor, you want the following settings:

Press "Q" to quit from the menu, and remember to press "Y" to save the changes

You can now compile the CANBOOT firmware, using the "make" commands:

make clean
make

The "make clean" simply makes sure any old cruft (or something left over from a previous compile) is all cleared up. The straight "make" command  is the one that builds the CANBOOT firmware. At the end of the compilation, assuming no errors, there will be a new "canboot.bin" file in the "out" folder. Assuming you orginally loaded the canboot firmware into your home directory (on the PI) the new firmware will be in:

~/CanBoot/out/canboot.bin

Now you need to connect the BTT U2C to the raspberry PI using a USB cable.You also need the U2C in DFU mode.To do this press (and hold) the small "BOOT" button as you connect the U2C to the PI via USB. Once the U2C is conected to the PI you can release the "BOOT" button. You can double check the device is in DFU mode either by using the "lsusb" command or the "dfu-util" command.

For example, "lsusb":

pi@voronpi:~/CanBoot $ lsusb
Bus 001 Device 003: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

If "lsusb" does not list something in DFU mode then try holding the "BOOT" button for a bit longer when plugging in the U2C.

An example of the "dfu-util -l" command:

pi@voronpi:~/CanBoot $ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=0200, devnum=3, cfg=1, intf=0, path="1-1", alt=2, name="@Internal Flash   /0x08000000/64*02Kg", serial="204432495841"
Found DFU: [0483:df11] ver=0200, devnum=3, cfg=1, intf=0, path="1-1", alt=1, name="@Internal Flash   /0x08000000/64*02Kg", serial="204432495841"
Found DFU: [0483:df11] ver=0200, devnum=3, cfg=1, intf=0, path="1-1", alt=0, name="@Internal Flash   /0x08000000/64*02Kg", serial="204432495841"
pi@voronpi:~/CanBoot $ 

If it did not list anything that would indicate the U2C was not in DFU mode.

 

Now we can use the "dfu-util" command to write the new CANBOOT firmware to the board. The command is:

dfu-util -a 0 -D ~/CanBoot/out/canboot.bin -s 0x08000000:mass-erase:force

For example:

pi@voronpi:~/CanBoot $ dfu-util -a 0 -D ~/CanBoot/out/canboot.bin -s 0x08000000:mass-erase:force
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash   "
Performing mass erase, this can take a moment
Downloading to address = 0x08000000, size = 4198
Download	[=========================] 100%         4198 bytes
Download done.
File downloaded successfully
pi@voronpi:~/CanBoot $

 

Once the U2C has been flashed it will need to be rebooted. Easiest way to do this is by unplugging it and reconnecting it to the PI.

Now we can build the klipper firmware and flash that to the U2C. We do that by changing into the klipper directory and running the "make menuconfig" command:

cd ~/klipper
make menuconfig

The "make menuconfig" command gives you the familiar  text menu system. For the G0B1 processor, you want the following settings:

 

For my set up I have decided to use 1Mbps (i.e."1000000") connectivity as I want to us the accelerometer. Once you have got everything set up, it's "Q" to quit and "Y" to save the changes.

Then you can use the "make" command to compile the firmware:

make clean
make

If the compilation is succesful it will create a "klipper.bin" file (in the "out" directory) which holds the firmware:

~/klipper/out/klipper.bin

This file can now be written over regular USB to the U2C device. First you need to find out the unique USB name for the U2C device by inspecting the contents of the "/dev/serial/by-id" directory using the "ls" command. For example:

pi@voronpi:~/klipper $ ls /dev/serial/by-id/
usb-CanBoot_stm32g0b1xx_16000D000C50415833323720-if00
pi@voronpi:~/klipper $

So in my case the full path to the U2C's USB device driver (which will be used in the flash command) is:

/dev/serial/by-id/usb-CanBoot_stm32g0b1xx_16000D000C50415833323720-if00

We use the "flash_can.py" python command to write the klipper firmware to the U2C device (NB: we use the device path found previously):

python3 ~/CanBoot/scripts/flash_can.py -f ~/klipper/out/klipper.bin -d /dev/serial/by-id/usb-CanBoot_stm32g0b1xx_16000D000C50415833323720-if00

Once the klipper firmware is written to the U2C device it will no longer appear as a (standard) USB device, it is now truly a canbus network adaptor. To be able to see it properly you need the network configured. I'll post about that next. It's not difficult setting up a canbus network adaptor but this was one of the places in the BTT documentation (and in other documentation) where the pish-factor increases.

 

[mvdveer]

56 minutes ago, smirk said:

It's not difficult setting up a canbus network adaptor but this was one of the places in the BTT documentation (and in other documentation) where the pish-factor increases.

I feel your pain. Took me ages and lot of choice words to finally first install CanBoot on the Octopus and SB2040. Then I struggled getting the network up

57 minutes ago, smirk said:

it properly you need the network configured. I'll post about that next

Would love to read this, as it took me a while to get the can0 adapter to be recognised by the Raspi. Was all up and running when testing it on the bench. Have sine installed but have not tested to confirmed it is still up and running.

Very good write up thanks - most helpful. Cannot agree more that the documentation needs to improve from BTT.

 

[claudermilk]

Great, detailed post! It also confirms that I want to remain well away from CANbus right now. I'm using too much choice language for little ears nearby as it is with what I'm currently working on.

[smirk]

Right, I got distracted playing with KAMP. Absolutely brilliant but distracting. I was about to get back to the saga of canbus but then hit another distraction: a Klipper update. When I updated klipper it grumbled that the firmware on my SKR PICO was now too old to speak to, and refused to work. "No, problem!" thinks I as it's a really simple Klipper recompile. Hahahahahahahahah...

It seems they've added some more options into the "Raspberry Pi RP2040" section. Whereas before, all you had to do was select your communications mechanism (UART or USB) and the comms speed now there's a "Boot Loader offset" option. Naturally I opted for a boot loader offset (rather than "No Boot Loader") as I did not want to overwrite whatever was on the PICO and then have to bugger about connecting up to header pins to reflash said bootloader......wrong!

Something to do with the cut-down nature of the RP2040 and the lack of on-die flash which means there is no bootloader per se and it all sits in external flash. Anyway, when I opted for the "no bootloader" option (and picked the right llash option) I was rewarded with a UF2 file to upload to the PICO. My settings ended up as:

 

My PICO still works and speaks to the latest version of klipper (as at the femto-second of writing). I'll post some more about the CANBus Saga shortly....(honest)....need to walk the dog....

 

[smirk]

The adventures in CANbus-land continue and I'm trying to stay positive (and not give in) but this is all unnecessarily difficult!

After a reasonable (but rocky) start I am rather disassatisfied with the outcomes so far. At the moment I have a disembodied set-up (i.e. not inside a printer) comprising the BTT EEB36 v1.1 (running canboot and klipper), BTT U2C 1.0 (running candlelight, more on that in a sec), a stepper motor and a thermistor. All running at a measley 250k bps CANbus. It does work: the motor spins and the thermistor reports temperature.

Things were just not going well yesterday, after having got the BTT U2C 2.0 flashed with canboot and Klipper I could not see any devices beyond the the U2C. I was at the stage of breaking out the osciilscope (sigrok has a canbus protocol interpreter)  when I decided just to keep things simple and use a multi-meter. At the start of the journey I'd used the multi-meter numerous times to check for continuity on the network but clearly had got complacent as I thought issues must've been software!

Measuring resistance between the CAN-HIGH and CAN-LOW signal wires is a nice quick check. The CAN network in a printer is simple enough (probably only 2 or 3 nodes) to be able to measure at every point on the network. If the network is complete and properly terminated, then it should measure ~60 Ohms between CAN-H and CAN-L (the two 120 Ohm terminators are in parallel so it's the reciprocal of 1/120 + 1/120). If you only get 120 Ohms between CAN-H and CAN-L then it means you've got an open circuit and either one or both wires have come adrift; and if you get some ridiculously high resistance (like 40K Ohms) then you're missing a terminating resistor. As it turned out, fat fingers had struck again and I'd damaged my shonky CANbus cable. I guess I shouldn't've been surprised that I'd knackered the cable since it was a home-brew cable and I had been connecting and disconnecting it alot. I'll need to get more of those ghastly Molex Microfit-3 connectors and some better cabling (more of that later).

Sadly, my elation at my god-like diagnostic and cable-fixing skills was short-lived, as I realised the U2C (2.1) still refused to detect anything beyond itself. I broke out the U2C 1.0 that I had (it rocks a STM32F072 MCU) and flashed that using candlelight, I also reflashed the BTT EBB36 (with its STM32G0B1 MCU) to run at 250k. I decided to down grade the CANbus to a mere 250k as that's seems to be the default BTT speed (in their precanned firmwares)  which made me suspicious that they knew something I did not about their kit!

"Success" I could now see the EBB36 on the end on the CAN network - this is basically the setup that I have at the moment which "works".

 

The BTT U2C 2.1 is a piece of junk. Not having a comparator I cannot tell if it is basically rubbish; if the STM32G0B1 MCU is still "too new"; if I've borked it or if the issue is the pish documentation. When I was originally trying it, the  documentation from BTT "caused"  me to flash the wrong version of firmware to it. Initially I used their candlelight but ended up burning a version for the STM32F072, despite using their supposed G0B1 patched version?! I did find a version of candlelight clearly patched for the G0B1 elsewhere on Github but I seem to have lost that (or they've changed the repo) as it appears to be no longer possible to build a specific G0B1 version of candlelight (you always end up with the default F0xx series build). This is the reason I reverted to canboot and Klipper for the bridge device (U2C).

Without breaking out the oscilliscope I am not 100% sure if the Klipper config for the CAN network on the U2C (2.1) is correct. The BTT documentation is incomplete and has no schematic informaiton for the U2C 2.1 (only 1.x versions) this means there's no way of telling which IO ports are connected to the CANbus (for the 1.x versions they are PB8 and PB9). Guessing at PB8 and PB9 results in not being able to see anything on the network which I cannot be 100% is because the U2C is using the wrong pins or there is some other (software related) issue. Without recompiling for every combination and checking (with a scope or whatever) I have no real way of knowing. Being grumpy enough as it is I am not going to waste time on that. The U2C 1.0 works (to a point) and there's a non-zero chance that I've borked the U2C 2.1 by originally burning the wrong firmware to it (despite it appearing to work/respond now).

The main issue I know have with the setup (beyond the dimished confidence in it) is that I cannot flash the EBB36 using canboot. The canboot flash process detects the note and communicates with it but then craps out complaining it cannot find the node. I might post more about that as I'm conscious that I've not posted anything about how I flashed the EBB36 to start with.

 

 

 

[claudermilk]

Switch your printer to CANBus they said. It'll be fun they said.

[smirk]

Things getting weirder the further down the rabbit hole you go. I wrote a "snotty" e-mail to BTT asking them for some up-to-date information on their U2C 2.1 - I was being optimistic (or just wanted someone new to vent my spleen upon). Anyway I thought I'd try the hellish option to recompiling Klipper for the U2C 2.1 (using every combination of port for the CANbus) and that didn't work, I could not probe the network any further than the device itself.  In desparation I tried the pre-canned BTT firmware from their github (U2C_V2_STM32G0B1.bin) and it kinda-sorta worked. It works in the sense that Klipper can control the EBB using it's canbus UUID, but if I probe the canbus network (using canbus_query.py) it just tells me it cannot find any uuids! There are no errors on the can0 virtual network device (in Linux) but it all seems to work. Werid, clearly it must've worked with the U2C 1.0 otherwise I would have had no way to know the UUID of my EBB36 without being able to query it with the canbus_query.py routine.

I did eventually dig out my scope thingy and hooked it up. The CAN protocol analyser in sigrok does work:

I should point out if you hear any rustling noises, it is me stroking my grey (handsomely grizzled) beard in a thoughful sort of way.....rather than saying "ooo, pretty" and admitting that I have not the faintest what the heck that means. However, I guess it does tell me there is some real CAN traffic flowing on the network, which is all a little more useful than watching the resistance fluctuate between the CAN-H & CAN-L pairs (which only gives a vague indication of life). It is interesting to note there are a few CAN (protocol) warnings which pop up occassionally but those are not reflected in the network levell so I imagine those are not hideously fatal and are within the bounds of what one might expect from CAN.

[PFarm]

@smirk Some great info I'll be converting one of my Artillery  X1 to Canbus. Appreciate the awesome write-up.

[smirk]

3 minutes ago, claudermilk said:

Switch your printer to CANBus they said. It'll be fun they said.

All depends on your definition of fun, I guess.

[smirk]

2 minutes ago, PFarm said:

I'll be converting one of my Artillery  X1 to Canbus.

Despite my significant investment in rubber-ducks I might trivially say "avoid BTT stuff", however, having had a quick peruse of the Mellow CAN offering (mainly in the EBB36 range) their Github repo seems to be equally devoid of any proper info....if anything even worse.....so at the moment I'm tempted to keep being bloody minded and keep buggering on (although Churchill I ain't).

[PFarm]

@smirk It's a shame that companies put out products with a lack of proper support/information!

[smirk]

4 hours ago, smirk said:

if I probe the canbus network (using canbus_query.py) it just tells me it cannot find any uuids!

This GOM thing about never reading is really biting me in the arse. I was rummaging in the canbus_query.py code and noticed the code makes reference to variables and functions like "query_unassigned". Reading the Klipper documentation and there's the line:

Note that the canbus_query.py tool will only report uninitialized devices - if Klipper (or a similar tool) configures the device then it will no longer appear in the list.

So clearly what I was experiencing is by design. I managed to configure Klipper to use my EBB36 as an MCU so it no longer shows up in a Canbus query! The GOM in me still mutters bloody stupid - a query should show everything on the bus.