The Voron kit build thread

[AlanB]

I have some other priorities right now so I stopped the Trident work for now. Hope to get back to it soon.

 

[7milesup]

Hi @Ken226
As I mentioned earlier, the config file really beat me up. There was a macro associated with the Tap head that I did not understand how the Probe section interacts with that.
Then I had a couple of wiring issues. I, for the life of me, could not get Z3 to operate. With the help of some awesome guys over at TeamFDM, they walked me through the config for the Z-steppers. At one point I thought that maybe the probe operation was somehow affecting the Z-3, but I couldn't confirm that. I decided to rebuild the wire harness for the Z-3, and after installing it, the Z-3 worked; however, we had also changed some lines in the config file concurrently, so I don't know if it really was the harness or the software. Regardless, I was super happy at that point to get it running.
Another issue I had was understanding Mainsail and how to utilize it. I had the printer set up with a keyboard, mouse, and monitor connected directly to the OrangePi. I then asked on TeamFDM about how to get a file (the Voron test cube) over to the printer (the Orange Pi was/is connected to my home network). I was thinking that is how the printer should work, but when I asked about uploading a file to it, they said, "No, you need to run Mainsail in your browser on your desktop, it will make your life much easier," which it did. I am still unsure if that is the only way to run it. Still a little confused about that.
Once past all of that though I was finally able to print some plastic, although I have a lot of fine-tuning to do. The project I was looking at tonight is the macros (your macros actually) for running the LED lights on the tool head. Are macros to be placed only at the end of the config file under the Macros heading, and does it matter what order they are placed in there? Can the macro for the QGL be before the LED macro, or should it be after? Those are the general questions I have. I think your LED macros have a macro associated with the probe command, but my probe command is different than yours.
On page 25 of this thread, you posted a link to TeamFDM regarding the LED macros. I started reading that tonight but got distracted by a squirrel or two. I need to hit the hay because tomorrow will be a long day at work.

 

[Ken226]

Are macros to be placed only at the end of the config file under the Macros heading, and does it matter what order they are placed in there?

It doesn't matter where the macros are in any of the config files. Mine are organized the way they are, only for the sake of keeping them organized.

I could put the LED macros in the Fans file, and the levelling/homing macros in the LED file, and it would still work fine. The order is also irrelevant. A lot of guys just have all of the macros in the printer.cfg file, but I opted to create a separate .cfg file for each "type" of macro. Ie, a separate file for LEDs, Fans, printer.cfg (steppers), and a "macros" file, for the customized gantry levelling ( customized by adding w LED status color command), my custom version of the g28 homing ( also customized to add LED homing colors) etc.

Can the macro for the QGL be before the LED macro, or should it be after?

They can be anywhere you want and in any order.

Klipper reads from the printer.cfg file first. If it sees "include mainsail.cfg", then it also treats "mainsail.cfg" as if it is part of "printer cfg". My "printer.cfg" file contains "include mainsail.cfg, include macros cfg, include fans.cfg, include LEDs.cfg", so as far as Klipper is concerned, those are all the same file.



If you look at my "macros.cfg" file, youll notice that I have some macros that mimick some stock klipper routines. Like G28 with a rename "g2828". All this macro does is add some led effects to the stock homing command. I did similar to the levelling command and a few others.

You can kinda trace the LED macros by starting in the macros.cfg file. My quad gantry leveling macro includes the command "led_leveling". Scroll down the the bottom of the file and you'll see a "led_leveling" macro, which contains some LED commands. Those commands reference some individual LED effects, which are defined in the LEDs.cfg file.


Just this morning I added a M600 macro with some LED color changes, to allow klipper to pause/park/resume the print when it encounters PrusaSlicers color change (m600) g-code. Unlike Marlin, Klipper doesn't recognize m600 without the macro.

Those are the general questions I have. I think your LED macros have a macro associated with the probe command, but my probe command is different than yours.
On page 25 of this thread, you posted a link to TeamFDM regarding the LED macros. I started reading that tonight but got distracted by a squirrel or two. I need to hit the hay because tomorrow will be a long day at work.

Yes. I added a "quad gantry level" rename macro. When klipper encounters the gantry level command, it runs my macro instead of its own gantry level routine.

My gantry level macro just gives an LED command first, then runs the default klipper command. I recently added a nozzle brush macro and m600 color change macro the same way.





Basically, I have it all set up so there's a different color/fancy light show effect for each function.

For example, when I start a print, while the nozzle and bed are heating I get red/violet pulsing colors on the logo and enclosure lights. Then when it starts homing the enclosure lights repeatedly chase towards the toolhead, like a comet.

Then when it starts printing, the enclosure lights turn white and the toolhead logo light turn green.

I have something similar set up for pretty much every function the printer does.



For any of my LED macros to work though, you'll need the LED effects plugin from GitHub.

 

[Ken226]

The folks over on TeamFDM thought I needed to come up with a filament runout sensor version of my tube guide, for the exhaust housing on the previous page.

I've got one printing now, for some test and evaluation. I had a few dozen of these 1185RE8 microswitches, so i designed it to use one.

Should anyone be interested in a filament runout sensor.

The assembly will be held together by two M3 heat set inserts and two M3x18 socket head cap screws (probably )

 

[7milesup]

Absolutely Ken. I was thinking about a filament runout sensor. Love your exhaust filter design adjustment too.

 

[Ken226]

Absolutely Ken. I was thinking about a filament runout sensor. Love your exhaust filter design adjustment too.

Thanks.

I had a situation a few days ago where letting the filament run out cost me a part. I decided I need one of these. I'll try and create a macro that triggers the M600 command. It'll lift the printhead 25mm, then park it center front of the enclosure and wait for a refill.

 

[Ken226]

I got the filament runout sensor done, and the macro is working. When the filament runs out, the switch triggers the M600 command, and the printer executes the same function that it does when a color change is called for. The LED's turn to amber, and the toolhead lifts 25mm, then parks itself front center and waits for a refill.

The sensor is a little tough to load though. When trying to push the new filament through the hole, it takes some wiggling, twisting and more force than I like to get it past the roller. I ordered 4 of the little KW12-3 switches on Ebay for 4$. They are alot smaller, and will allow me to mount it with the lever arm facing rearward, which should make pushing the filament past the roller significantly easier.

I redesigned the runout sensor to accommodate the KW12-3 switch, and added a socket for a JST 2.54 connector. Once the switches arrive, i'll test fit, do any final adjustments to the design, then post the model up on Printables.

So far, here is what i've come up with for the KW12-3 runout switch housing. The face highlighted in blue is parameter controlled, so i can changed to model to tune the switch arm preload:

 

[Ken226]

I bought a BTT CB1 with a PI4B adapter a couple weeks ago, just to use as a backup to my Orange Pi, and to play around with in hopes of learning more about Linux.

This morning, just out of curiosity and a little boredom, I decided to see how hard it would be to set up and get running on my printer.

I imaged the CB1 minimal Debian OS onto a micro SD card, then edited the config.txt file to add my wifi SSID and password.

The CB1 booted up perfectly, so I updated the debian, then installed the FFMpeg LibaV codec packages.

After that, I went to github and installed KIAUH. Using KIAUH I installed Klipper, Moonraker, Mainsail and Crowsnest, then went back to Github and installed the LED effects plugin.

So, i pulled my Orange Pi out of the Voron and replaced it with the CB1. Plugged everything in, booted it up, then logged into Mainsail on my laptop browser and copied my backup config files into the CB1 mainsail installation.

I'm really surprised that everything worked perfectly, right off the bat. I copied all my backup config files from the OrangePi into the CB1 and it booted up, still has all of my settings and is working perfectly. It's printing perfectly right now, and everything is working the same as with the OrangePi.

So, as far as Raspberry Pi replacement options go, the BTT CB1 is also good-2-go. Very easy to set up and get running.

 

[Ken226]

After a few months of use, the folding housing for the Mini12864 gets a little too loose. Visibility sucks when its folded down, and the slight touch results in it being pushed back down into its vertical position.

I designed a new one that holds the display rigid at a 20 degree angle.

I just finished printing and assembling one, and it seems to work pretty well. its three pieces: the housing, bezel and the bezel accent insert.

It needs four standard Voron size m3x4mm heat set inserts and 4 m3x10mm socket head cap screws. The accent insert gets super glued in-place on the bezel.

In order to fit, you need the front left and right skirts for the Voron model one size smaller than yours. For example, I used the 250mm skirts on my 300mm Voron 2.4

Jeeze! Camera flash makes everything look so dusty.

 

[7milesup]

Jeeze! Camera flash makes everything look so dusty.

LOL. It doesn't "look" dusty, it IS dusty. LOL.


Nice work on the Mini12864 mount. BTW, that Mini would be easier to remember if they named it Mini8675309. I can remember that.

For some reason, I thought that you were using a touchscreen. That BTT ecosystem that you mentioned the other day (MP8 & CB1) is pretty dang sweet plus you could add their 7" touchscreen, and it would dovetail right into it with minimal fuss. I would have gone that route in a heartbeat had it been available when I started my Voron.