Resurrection V0 - Stubborn Sausage Fingers Chronicle

[smirk]

In between banging my head off a wall, I forgot to say the new Hiwin Linear rails turned up, so I've got all the mechanical parts to start the build proper....once I've go this CANbus nonsense sorted.

[smirk]

Oh, and I've also decided to add a nozzle scrubber mod on the end of a little servo thingy.

[mvdveer]

51 minutes ago, smirk said:

Oh, and I've also decided to add a nozzle scrubber mod on the end of a little servo thingy.

Now you are just going looking for trouble

 

[mvdveer]

54 minutes ago, smirk said:

new Hiwin Linear rails turned up,

Now that is good news- Nice

[smirk]

Ok, there was a Klipper (v0.11.0-89-gead81fbf), mainsail, OS update so after that all went through I tried again but before reflashing things I removed the can_uuid definitions from printer.cfg to ensure they were considered "unassigned" . To recap. I'm (now) using the BTT U2C 1.0 (with STM32F072) and the BTT EBB36 v1.2 (with STM32G0B1). I wanted CANboot on both devices (so in theory I can flash over the network) and both running Klipper firmware (rather than candleligh or whatever). I've also still capped it at 250k bps (I'll waffle about that later).

When reflashing Klipper onto the U2C, I followed the instructions I used previously (adjusting the klipper build for the slight difference in MCU type):

The BTT documentation for the U2C 1.0 exists and I could double check the pin out for the actual CANbus interface against their schematic:

The U2C now works as one might expect!
 

The documentation for the EBB36 1.2 is a different story it does not exist. However, there is documentation for the EBB36 1.1 and it also uses the STM32G0B1 processor so I took a flier and thought "close enough" (a foolish stance given how often those minor point releases encompass major changes). Referring to the schematics for the 1.1  allowed me to check the pins definitions for the CANbus:

I compiled CANboot in a similar manner to previously (for the U2C) from the start of this diary but using the following settings:

To flash CANboot the EBB36 has to be connected to your machine via the USB-C connection and to use that you need to set the 5v-USB jumper on the EBB36. You also need to hold down the "Boot" button as you plug the USB cable in to make sure the device goes into DFU mode. There are no special indicator lights to say whether the device is in DFU mode (unlike the U2C) :

 

The process for burning the CANboot firmware are the same as the ones ffor the U2C, namely use the command:

 

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

 

Once the new CANboot firmware is installed disconnect the EBB36 from USB. Remember to remove the 5v-USB power jumper and put the jumper on the "120R" termination resistor jumper. You can then connect the EBB36 via the CANbus connector (the Molex Micro connector) to the U2C. I would strongly recommend powering everything down before plugging stuff in and out of the CANbus.

With the EBB36 connected to the network you can then flash the Klipper firmware to it over the CANbus. The instructions for compiling Klipper are (as you guess) as they are at the start of the diary, except for the EBB36 I used these settings:

You can check that the EBB36 is showing up ready for flashing using the command:

python3 ~/CanBoot/scripts/flash_can.py -i can0 -q

For example, in my set up it looked like this:

pi@voronpi:~/klipper $ python3 ~/CanBoot/scripts/flash_can.py -i can0 -q
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 9bd9014c9f1c, Application: Klipper
Query Complete

The "9bd9014c9f1c" is the internal ID for the EBB36, I guess it could get messy if you had multiple nodes in Canboot mode as there's no obvious way of determining which ID belongs to which device (unless you happen to have seen it before and can make the association yourself).

If the query returns nothing it could be for a number of reasons. Since the EBB36 has just been reflashed with CANboot it should only be in CANboot mode (there's nothing else on it for it to be in another state). Things to check are: make sure the network is complete; make sure you did flash the correct canboot.bin file to the EBB36; sacrifice a goat.

NB: If the device already had klipper flashed to it, you should be able to double click the "RST" button and force it into CANBoot mode (this assumes the device is working and the original CANBoot firmware was compiled with the "Support bootloader entry on rapid double click of reset button" option).

Anyway, let's assume Klipper compiled A-OK and that the EBB36 is showing up in CANboot mode. The Klipper firmware can be flashed using the following command (NB: remember to replace "9bd9014c9f1c" with your own canbus_uuid and alter any of those files paths as well if required. In my set up both the "CanBoot" and "klipper" directories are sub-directories of the pi user's home directory):

python3 ~/CanBoot/scripts/flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 9bd9014c9f1c

Again in my set up this looked like:

pi@voronpi:~/klipper $ python3 ~/CanBoot/scripts/flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 9bd9014c9f1c
Sending bootloader jump command...
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 10f918e7e022, Application: Klipper
Detected UUID: 9bd9014c9f1c, Application: CanBoot
Attempting to connect to bootloader
CanBoot Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x8002000
MCU type: stm32g0b1xx
Verifying canbus connection
Flashing '/home/pi/klipper/out/klipper.bin'...

[##################################################]

Write complete: 13 pages
Verifying (block count = 414)...

[##################################################]

Verification Complete: SHA = 69FC20F97D8C9CAF87A5CA3ABB54DA35C1C774DE
CAN Flash Success

So far I have not had any failures during this initial flashing process.......however, more on that in a bit.

With everything flashed, and nothing plumbed into the printer.cfg file I could then run a CANbus query and discover my unassigned devices by running the canbus_query.py script:

pi@voronpi:~ $ ~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
Found canbus_uuid=10f918e7e022, Application: Klipper
Found canbus_uuid=9bd9014c9f1c, Application: Klipper
Total 2 uuids found
pi@voronpi:~ $ 

The BTT Github repos do have some example configuration files to use. The key thing is the MCU definitions that you need to add to the printer.cfg. For example from my config:

# The USB to CANbus bridge device U2C 1.0
[mcu U2C]
canbus_uuid: 10f918e7e022

# The EBB36 1.2 tool head device
[mcu EBBCan]
canbus_uuid: 9bd9014c9f1c

One thing I did find a little challenge was setting up temperature readings for the new MCU devices since that uses the "temperature_mcu" sensor type. To prevent Klipper grumbling that I had duplicates I  had to specify the "sensor_mcu" option to differentiate which MCU I was using, so in my setup I know have:
 

###################################################################################
# Monitor some system temperatures so they are displayed on the Mainsail console
# (Raspberry PI system temp, SKR PICO MCU and EBB36 MCU)
###################################################################################
[temperature_sensor raspberry_pi]
sensor_type: temperature_host
min_temp: 10
max_temp: 100

[temperature_sensor SKR_PICO]
sensor_type: temperature_mcu
min_temp: 10
max_temp: 100

[temperature_sensor EBBCan]
sensor_type: temperature_mcu
sensor_mcu: EBBCan
min_temp: 10
max_temp: 100

[temperature_sensor U2C]
sensor_type: temperature_mcu
sensor_mcu: U2C
min_temp: 10
max_temp: 100

So in all in, apart from the sample devices I've connected to the tool head (5V 3007 fan, thermistor and stepper) I now have lots of temperatures in Mainsail:

[smirk]

Some musings/thoughts/issues on the re-flashing (i.e. updating and existing klipper firmware) over the network (canboot) part, nothing that I have not done extensive testing of this.

As I said previously flashing the EBB3.6 from scratch/virgin (i.e. start with a fresh canboot install) has not failed (so far), flashing over the CANbus just works. No issue. The issues I have had have been when I've tried to reflash an updated/different(*) firmware to the EBB36. (*) I say "different" but I don't think the flash process gives two hoots if it's the exact same firmware, basically as far as I can tell you could just keep running the same flash command over and over (assuming you put it into CANboot mode each time).

The issues I've experienced (reflashing the EBB36) range from a complete failure to run the flash command (just gives up without trying) through to various "packet rety" and "comms errors" but which eventually works. The flash process does do a check-sum comparison at the end so I'm comfortable that when it says it has been successful it has indeed been successful.

I find the network/comms errors interesting as they seem to only exist at the CAN protocol level (i.e. they're not really  network errors as I'd recognise) and certainly I've never had issues during the initial flash so that suggests to me it's not poor cabling (i.e. a physical problem). At the moment my suspicion is any activity on the canbus at all disrupts the flash process (at the end of the day there's only two devices on my CAN), if I'm feeling masochistic I might look into that more.

Reflashing the U2C is a completely different bag of worms. Since it's the adaptor between PC-USB and CAN (and basically there is no CANBus connectivity without it) then you can't really flash it over CAN. The CanBoot firmware on the U2C was built simply with USB connectivity. The trouble is there's no "RST" button on the U2C (only a boot button) so there's no obvious way to trigger CANBoot mode. In normal operation (i.e. while it's in bridge mode pretending to be a network adaptor) it does not even show up as a USB device.

The only solution, I've found so far which is an utter bodge so I imagine there must be a proper way of doing it and I've been too stupid to find it (or to GOM to read the documentation). Is to trigger a firmware update actually over CAN which naturally fails horrible. For example ("10f918e7e022" is the UUID for my U2C):

pi@voronpi:~ $ python3 ~/CanBoot/scripts/flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 10f918e7e022
Sending bootloader jump command...
Resetting all bootloader node IDs...
Checking for canboot nodes...
ERROR:root:Can Flash Error

This then leaves the U2C in canboot mode and therefore visible as a USB device (naturally your machine cannot speak CAN anymore). After which it is possible to reflash the device using the "regular" method with the USB device name:

pi@voronpi:~ $ python3 ~/CanBoot/scripts/flash_can.py -f ~/klipper/out/klipper.bin -d /dev/serial/by-id/usb-CanBoot_stm32f072xb_220026000D51303752313320-if00
Attempting to connect to bootloader
CanBoot Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x8002000
MCU type: stm32f072xb
Flashing '/home/pi/klipper/out/klipper.bin'...

[##################################################]

Write complete: 14 pages
Verifying (block count = 423)...

[##################################################]

Verification Complete: SHA = E200162B76F955F77188EC4ADAF29749642CF9CD
CAN Flash Success
pi@voronpi:~ $ 

 

[smirk]

Musings on (CAN) networking or yet more rustling noises as I stroke my grey beard......

The CANBus is a low-speed network.....OK, I know many us are old enough to remember 300baud modems and teletypes but CAN is [relatively] low speed but hopefully low latency. The low latency will come from the relatively small packet size (at most arround 111-bits if they transfer the maximum 8-bytes of data). I'm being fairly loose in my thoughts here as there will be so much variablilty and so many parameters (there's headers and preambles and inter-packet spacing and variable pay-loads and a wheen of other things) so for simplicity I'll think 111-bit for each CAN packet. So for my CAN @ 250K bps we're looking at a packet latency of 0.4ms (again ignoring speed of light, round-trip replies, processing overhead  etc) for a 1Mbps CAN that drops to 0.1ms, or to put it another way thats 2252 packets per seconds (pps) and 9009 pps respectively....it's probably really stretching things to say "that's like 2.2kHz and 9kHz". CANbus is also bidirectional which certainly seems to be borne out from the protocol traces I've done which has simultaneous tramission on High and Low lines.....as an aside (thinking back to some of my previous musings) to be able to decode those packets would require indepth knowledge of how Klipper has implemented their "protocol", it may all be CAN traffic but what's in those CAN packets is specific to Klipper.

I guess where I'm going with this is for what it is....it's plenty fast (possibly even at 250K bps), thinking of ethernet traffic in the low Kbps or Mbps is definitely slow and laggy but it's not really a good comparator now that I think about it. For that reason some of the received wisdom around settings within Linux may not be appropriate specifically the "txqueuelen" setting in network configs.

The "txqueuelen" setting is not a byte/memory size, it's the number of network packets that will get queued by the OS for transmission by the NIC. Like all things this is a balancing act, too little and you could increase CPU load (say) or starve the NIC, but too much and you increase latency and could end up falling victim to bufferbloat. The txqueue is a FIFO and to be honest there's only specific conditions where you might end up filling the buffer so perhaps this line of tihnking is pointless. However, for lower speed connections, it is better to have a much lower value for the "txqueuelen". The standard 1024 setting in Linux is really intended for Gigabit networking  where it would only take around 12ms to drain down the queue (assuming it was completely full) compared to 113ms for the "same" situation on a 1Mbps CANbus. The former is an acceptable hit on latency but the latter is not.

As I say certain conditions need to prevail for that nightmare to unfold but sometimes less is more. At the moment with my 250k set up I am using a value of 64 for my "txqueuelen". Once I get an actual working set up I might/will alter that.

 

 

 

 

 

[mvdveer]

Great write up. Had to read it twice to understand half of it I am sure the end results will be good and just reward for the enormous effort in getting this going.

[claudermilk]

21 hours ago, smirk said:

OK, I know many us are old enough to remember 300baud modems and teletypes

I'm not touching CAN with a 31.5 foot pole, so just skimmed all that, but I did get a good chuckle out of this bit. Yes, I do indeed remember 300 baud modems--and all the steps between that and my current fiber modem/router. As well as teletypes (you think a Bambu is loud? Hah!). Though I didn't have to mess with the place-the-phone handset-in-the-cradle models.

[smirk]

Well I think I've done as much fluffing around with CAN as I can at the moment. Think it's about time to get on with the build proper so I have something to hang my CAN on. I will come back to the CANbus cabling as I've some thoughts on that as well (Gee a GOM with some "insightful" thoughts on somehing quelle surprise).

So by way of a starter, an exciting (grainy) picture of some extrusions:

 

[smirk]

Well another slightly blurry picture. I've managed to make progress and got the z-axis set up. Clearly I did not imagine the (relative) ease of originally retrofitting the Kirigami bed to this V0. It went easily this time as well and it fitted perfectly. No fettling or shimming was required to make the bed run true on the rails..... so I didn't even need any of those new swear words I'd invented especially. Crabsnaggets! It is worthy of note that this Kirigami bed is made of regular aluminium where as the other one I have fitted to my second V0 is a secret alloy of stainless steel and obstinateium.

Naturally I will now lie awake at night and worry "that went too well....."

[claudermilk]

PotatoCam FTW!

[Wick]

On 1/31/2023 at 11:49 AM, smirk said:

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).

found this in klippers github, but not already implemented I guess: https://github.com/Klipper3d/klipper/pull/6038

so PB5,PB6 is used for Can...

[smirk]

Thanks for that @Wick, good find. I'll try that as soon as work calms down (audit season). I'm wondering if they'll require a little hackery as PB5 and PB6 don't appear to be "standard" offerings (not rocket science to fix just a little hassle):

Which certainly explains why I haven't been able to get the U2C 2.1 to work

[smirk]

Unrelated to anything in this build but a "pop quizz". I see BIQU are running a valentines day special:

Ignoring the Chinglish, question to my compatriot GOMs:  Thinking of the organic significant "other" in your lives (i.e. not your Voron, the one with legs and arms) do you think a gift of a Manta M8P or CB1 will be met with a loving hug; call to the divorce lawyer or psychiatrist; or a swift visit to the emergency room for a painful removal of said gift from your colon?

Doctor: "Rectum? Damn near killed him!"
Patient: "Don't loose any of the jumpers!"

I'm trying to see if BIQU have branched out into medical equipment or legal services.

[PFarm]

@smirk I'm on the side of a divorce lawyer and emergency visit combo LOL! Not necessarily in the order more like the other way around. . Seems like some good deals though.

Edited February 9, 2023 by PFarm

[smirk]

I'm on holiday this week, I thought it would be a great opportunity to get on with the rebuild.......but then I fell down the rabbit hole (which I should point out had nothing to do with my V0).

I'd been noticing that my home-brew machine was making a slight "tick-tick-tick" noise when homing (from the z-axis). It didn't make noises at any other time other than homing.

"I'm on holiday! I have a whole week, plenty of time to fix that and rebuild my v0" thinks I (noting it is now Thursday). Well, I eliminated the obvious things (something catching, my 3d-printed drag chain "crunching"). I check the alignment of the rails and those were ok. Eventually I gave in and stripped and rebuilt (well completely replaced) the x-gantry and the z-axis linear rails and hardware. Who says sledgehammers don't make great nut crackers....the "tick tick tick" was gone. That burned about 2-days of the holiday.

I then decided to verfiy my mastery of printer rebuilding by doing a simple print to make sure the z-axis was fine. A really simple small (20mm^3) cylinder in vase mode. I thought this was going to be a quick verification. To my horror, it printed like something that had fallen out of the back-end of a cow. I did notice in some of my initial diagnostics it printed fine when I kept the speed to something stupid like 10mm/s. Top tip from an old fart - always ignore the little voice at the back of your mind shouting out the answer....it's probably the tofu-eating, wokerati lefty-pinko trying to seed doubt in your manly-right-thinking mind.......

I've seen this sort of problem before! I've either knocked something loose when I've rebuilt the printer or the stepper drivers are to blame. Checked, nothing loose. So, I fitted a cooling fan to the stepper drivers. No change still printing like crap. I replaced the entire set of stepper drivers for brand spanky new ones.......you guessed it....still printing like a bovine deposit.

It was by now day-three of my holiday and I was considering a full electronics replacment. I didn't fancy the hassle so I decided to blame the extruder using the tried and true process of eeny-meeny-miney-moe. Striped down, cleaned and rebuilt the BMG extruder. That made precisely hee-haw difference, still printing like crap. Replaced the extruder motor for precisely no benefit what-so-ever. Did have a little fun with rotation distances and the new motors (yes, I replaced it twice) before realising the original motor was a 0.9degree motor not a 1.8 degree motor like the rest. I hate 0.9 degree motors.

To add to the picture of decrepit incompetence, my back started playing up thanks to my hunched position over the printer so I added a variety of "Ooof" and "Aaargh, bloody back" noises and curses to the litany of profanity regards the printing difficulties.

By yesterday evening, I was completely stumped and back to considering a full electronics replacement now including the extruder and hotend.....then finally the little voice at the back of my head (taking advantage of my dejection and weakness) pointed out that since it was such a small object with such thin walls I was probably not allowing sufficient cooling time (I had just been printing th same gcode over and over for consistency)......

Sure enough checking the slicer settings and "minimum layer time" was zero and fan-speed was only 50%. There was nothing wrong wih the printer (after fixing the "tick tick tick") it was just careless slicer settings. Bloody Cura! Bloody back! Bloody old age......

 

[smirk]

Right pulled my thumb out (possibly both thumbs) and managed to get the frame squared and built. I'll check to see if any nuts (or rather how many) have been missed during the build, after tea.

[Wick]

On 2/7/2023 at 1:38 PM, smirk said:

Thanks for that @Wick, good find. I'll try that as soon as work calms down (audit season). I'm wondering if they'll require a little hackery as PB5 and PB6 don't appear to be "standard" offerings (not rocket science to fix just a little hassle):

Hi, had a chat on discord with Eric Zimmerman (many thanks Eric!), U2C 2.1 with STM32G0B1 works when ONLY flashing the firmware from bigtreetech:

https://github.com/bigtreetech/U2C/tree/master/firmware and NOTHING else (no canboot, no Klipper)

 

he also has a guide how to setup:

https://github.com/EricZimmerman/VoronTools/blob/main/EBB_CAN.md

[smirk]

Thanks @Wick I'd kinda come to  roughly the same conclusions, whilst I did find references to PB5 and PB6 for the processor in the source trying to compile just resulted in a never ending series of [compilation] failures. Just a pity BTT weren't better at publishing documentation, QA, etc, etc. Though to be fair to them, that sort of thing costs money (time and effort) and they're not operating in the cash rich end of the market. The U2C 1.0 that I have "works" fine (as does the 2.1 with the BTT firmware). Well I say "works" from my limited functional testing outside of the printer it "works" I have no doubt when I drag my lazy ass there I will find many interesting and colourful issues.

[smirk]

Well a small bit more progress, this is definitely a marathon and not a sprint. Although to be fair I have been arsing around with 2 other projects. Got the new Moons motors fitted into the chasis - glad I ordered their stepper cables with the motors as nothing I had would have probably fitted and I would not  like to have spent time trying to guess figure out what wires on the drive connector had to be actually connected.

 

As an aside the highlights are luminous orange not that tomato red colour that my camera phone decides it is. Guess it's time to fit the belted z-mod tomorrow......

 

[mvdveer]

41 minutes ago, smirk said:

fit the belted z-mod tomorrow.

Looking good so far. My first Voron was a sprint, and a mistake. I prefer a marathon now - nice and slow - methodical and meticulous.

 

[smirk]

On 2/21/2023 at 10:45 PM, smirk said:

time to fit the belted z-mod tomorrow......

Clearly, I meant in another universe as we all know tomorrow never comes. So, several weeks later, after a slow and meandering journey (bit like some travelling troubadour bad-tempered hobo) involving a bunch of new glasses (that I'm still getting used to); deleteing the entire contents of our icloud (fun trying to recover thousands of images and videos from other sources.....I hate Apple and iCloud...glorified bloody sync mechanism...grrr....not a back-up solution...gaaarr...) and playing with a side project (corexz'ing an old anet a8+) I finally came back to the actual project-in-hand and got the belted z axis fitted.

A "picture is worth a thousand words", I found it really useful to have the blender model of the belted-z to "dismantle" to figure out how it went together. Granted that involved learning how to rotate and manipulate stuff in Blender........which was fun....but I got there:

Sigh, David Bailley I ain't First time the phone camera vaguely show's the prints are "orange" rather than "red" and I don't clean the lens so there's a hair on it that makes it look like there's a huge crack in the motor mount! I literally only noticed that when I posted the image, I blame my new glasses. There is no crack....I checked.....

The only minor problem that I had during construction was with the bearing support (which I did replace after seeing that horrible picture). It was rubbing against the end of the pulley. Perhaps my pulley was a fraction too long. I could've modified the model and reprinted it (the spares I had were all the same) but I could not be bothered tryng to find the Orange filament so I just used shims:

As I say, other than that. It all went together really nicely and without any drama:

 

[smirk]

The next stage according to the V0 build manual is the X-gantry and the XY-joints.

When I was assembling the XY joints I noticed that the left hand upper had been printed on a smooth PEI sheet, but the upper right had been printed on a textured sheet. Ordinarily I avoid textured sheets as I've had not much luck with them but the textured sheet i got from Formbot with my last V0 is brilliant and actually works. I've been enjoying printing parts on it (weird I know). Anyway I've clearly been hanging around Voron-types too long and athestics are starting to matter.....up to a point...I still have soup stains down my front and crumbs in my beard, I haven't gone mad or something (I'm still a GOM). Having one upper textured and the other smooth would bug me, so I printed the upper again so I'd have both textured.

While that was printing I went to look for the HIWIN linear rail for the x-axis that I had mislaid. As weeks had passed since I last worked on the build, I'd clearly "tidied" stuff away.(I'm a GOM, "tidied" is a debatable term apparently hiding it in cupboards, under carpets at the back of a shelf is not really tidying). Eventually I found the rail, in a box in a heap of other boxes, along with an xy-joint upper printed on textured PEI. This turned out to be serendipitous, as I'd forgotten to turn on cooling during the print. I was only printing the one xy-joint upper and this is what I came back to:

 

I'll ignore the fact that if I had not "tidied" away the rail and a random xy-joint then I would not have needed to waste the filament. Anyway, I have some nice new XY-joints assembled just need to fit them onto the x-gantry which I will do after a completely unspecified duration of time:

 

(I remembered to clean the camera lens this time, and it is looking orange as it should!)

 

 

[smirk]

I thought I'd "spoil" myself by getting a lattice gantry, which is probably akin to me buying  a Speedo shark-skin swim suit to make me faster in the water (think large bad-tempered manatee with flipper-rot).

Anyway, I think it looks cool. Unlike some of these lattice grantries this one needs additional printed blocks (with heat-insets) to attach the xy-blocks to the gantry. Not a problem, unless you make the school-boy error of printing the blocks in the wrong orientation. (hint: the wrong orientation is with the layers running parallel to the lengh of the gantry, or perpendicular to the holes for the heat-insets). If you do make this mistake the blocks are likely to crack along the layer-lines when you come to tighten up the gantry (once squared). Naturally, I just know this because I am old, wise and have a grey beard.....

Once I'd you've reprinted the blocks in the correct orientation it looks something like this:

 

Not having made any school boy errors, I installed the gantry (the second time was just for fun) and fitted the "B Extrusions":