Jump to content
  • 0

Voron 2.4 print start location


nannyogg82

Question

Hi, first time post here. I bought a Voron 2.4 kit a few months ago and have finally got it completed. But now I am having issues with the print start location.

So far I have only managed to actually start a print once. But it wasn't adhering. Between this failed print and trying again, I reset the Z offset and I also installed Klipper Screen, and every time since then I have tried to start a print, the print head lowers itself over the Z endstop as pictured and tries to print there. This happens with both Super Slicer and Cura. You can actually see the damage on the printhead due to banging against the Z endstop.

Does anyone have any suggestions of how to fix this? I have tried looking in the config file but I am at a bit of a loss.

image0.jpeg

image1.jpeg

Link to comment
Share on other sites

Recommended Posts

  • 0

nannyog82...

How are you printing? Are you using klipperscreen to start the print? Or are you printing from a PC thru the mainsail/fluid interface?

I'm thinking that if it's klipperscreen then maybe printing from a PC might work. Also... You can set your Z-Offset to 2mm above the print surface to see if your printer gets past the Z endstop.

I'm just thinking out loud here but it based on the video... it sure looks like the +10mm that the head should lift after probing the Z endstop is inverted and is in fact going down.

Link to comment
Share on other sites

  • 0

Ok this is "interesting" (clearly I used that term advisably as my young daughter would be quick to point out "No, it's not interesting")

There's not too much difference between your generated GCODE and my generated GCODE (ignoring the lovely embedded graphics yours puts in for the benefit of moonraker/klipper) the start up is more or less identical apart from the ordering/sequencing of the commands.

Both set the Z-height to 0.2 (!):

Your startup:

G1 Z0.6 F18000
M204 S1000
G1 X159.774 Y159.774
G1 Z0.2

My startup:

G1 F600 Z0.4
G0 F7200 X294.24 Y309.837 Z0.4
;TYPE:SKIRT
G1 F600 Z0.2

So it's not the inherent generated GCODE that is twanging the nozzle into the bed.

This does circle back to being a slicer issue.

Link to comment
Share on other sites

  • 0
19 minutes ago, Penatr8tor said:

I'm thinking that if it's klipperscreen then maybe printing from a PC might work. Also... You can set your Z-Offset to 2mm above the print surface to see if your printer gets past the Z endstop.

I was about to ask something similar - @nannyogg82 when you are printing are you printing from the slicer (i.e. SS or whatever compiles the GCODE and sends direct to the printer (via the Moonraker API) )?

I was wondering if the slicer is inserting some unexpected code as part of the sending routine which is not actually included in the generated GCODE file?

For example CURA, irrespective of the GCODE flavour (or the startup routines) decides to insert a "T0" command (fair enough it does that in the generated GCODE file in this instance). For our test I manually edited it out, ordinarily I just have a dummy T0 macro defined in klipper so it gets ignored.

But I suppose it demonstrates that sometimes slicers don't do what we expect/ask of them.

Back to @Penatr8tor question - if you were printing from the slicer, you could just try manually uploading your generated V7 cube file and see it it works that way (rather than having the slicer adding some magic sauce)?!

Again if you're feeling brave the attached is a 50% scaled Voron cube (placed centrally) see if that prints, noting I have done thing to change the z-offset so you might need to manually increase that. Guess I'm keen to know that it wasn't a one-off piece of luck that the 4 squares printed.

Bit of a straw grab.

nannyogg82-cube-v7.gcode

  • Like 1
Link to comment
Share on other sites

  • 0
17 minutes ago, Penatr8tor said:

use KIAUH

KIAUH is not something that I've used, back to a "access denied"(*) comment that @nannyogg82 made. Do you need to run KIAUH with sudo? Or does it automatically prompt for sudo access at the appropriate junctures?

I suppose if removing Klipper Screen was the "best" option I'm not 100% sure given all the other upgrade/configuration woes there's been if it would necessarily work.

(*) There are ways in Linux to hobble even the super-user but I'm unaware of any of those being enforced on a PI distro - thus my sudo question.

 

Link to comment
Share on other sites

  • 0
7 hours ago, smirk said:

That was generated out of Cura (just using their stock V2.4r2 printer definition). It just uses the PRINT_START and PRINT_END macros in the startup/finish gcode routines

Ok - what is in the Superslicer's Custom G Code section? 

@nannyogg82 Could you go look at the following in Superslicer

Printer Settings - Custom G-Code - Start G-Code and post that here? (Mine just has START_PRINT)

image.thumb.png.5ef21da81cee9e8fc8e43a49476a7d0c.png

It may be worth commenting anything in there out and just enter START_PRINT /PRINT_START. If those are already there, then it may be worth looking at those macros to see if anything in there causes this behaviour

Link to comment
Share on other sites

  • 0

I took a look at your printer.cfg and it all looks ok. There's a few direction flags inverted from mine, but that's just adjusting for wiring--if your printer is moving the direction you expect with manual gcode move commands, then it's fine.

KlipperScreen is just a fancy touchscreen interface. I have not dug into the guts of it, but my impression is it mainly just sends gcode commands (for example homing, it's just sending G28) or macro calls (for example Quad Gantry Level sends QUAD_GANTRY_LEVEL). I expect starting a print from there is the same as from Mainsail/Fluidd. I'd run commands from the PC until this is resolved, but I have my doubts it's the issue.

Now, what I am wondering is I recall mention that Cura-sliced files are working but PrusaSlicer & SuperSlicer are not. What is your printer setup in those slicers? Here's a screenshot of my SuperSlicer Printer Settings / General / Bed Shape(Set...) dialog. Does yours look something like this? 

SuperSlicer-SizeSetup.png.58dbd33031ed82b88fd635e9f4d5c2ff.png

Oh, and is the G-Code Flavor set to Klipper? IIRC that's not the default.

Link to comment
Share on other sites

  • 0

Did a little experimenting with superslicer - I was interested to know if it inserted any further gcode into the mix when transmitting files directly to the printer (clearly without telling anyone). It doesn't. In the tests I did, limited as they were, the sliced file which was just saved to the local disk is exactly the same file that gets transfered to the printer.

By way of a summary of things (and it'll probably be incomplete so sorry for missing anything):

  1. The PI has been rebuilt. Despite the interesting challenges resulting from upgrading to the latest versions of stuff, it is now "working".  This means the configs (printer.cfg, etc) are stock. They've been eye-balled as well and no one has had a eureka moment of "aha, you've not set that option". So the conclusion is the issue doesn't lie in the klipper confiigs.
     
  2. The printer manually moves, whether that's via the klipperscreen or manually typed GCODE. The tests that have run have moved the printhead in the expected directions at the expected time and the head has not veered off the bed or got stuck on the z-end stop pin. Conclusion is that the wiring, and config (direction pins, etc), basic movement are correct, and  the geometry (beyond perhaps absolute size) is also correct.
     
  3. The generated GCODE file (from SuperSlicer) has  been eyeballed by multiple people without any "Aha!" moments; the gcode file also prints on a different printer (tried it on my own printer). Conclusion Super Slicer is not producing complete pish and (as per my opening comments) isn't sneaking any naughtiness in either.
     
  4. A simple test (4 1 layer high patches) generated by me using CURA did print - with some judicious futzing to the z-offset by nannyogg. Conclusion - it didn't really print (not without help). @nannyogg82 made a remark/question about the positioning/length of the z-endstop pin....
     
  5. The generated gcode (produced by SuperSlicer or Cura) does not have any z-offset stuff in it (e.g. Klipper psuedo-command SET_GCODE_OFFSET) , there's only the expected movements in the Z-axis to position the the nozzle at the appropriate layer height. Conclusion: the issue isn't a slicer issue.
     
  6. The attached video (just after the QGL and home-all) has the printer going cronk-cronk-cronk. The printer motion system works and the  GCODE is good (works). Conclusion; the printer is not trying to drive the head off the bed or in reverse, it's catching on something.

Suggestions/Where-to-go - I think it's something to do with the z-endstop pin/z-offset. I don't have a 2.4 so I don't know how finnicky or easy that is get right or wrong. I do not think it is a failed sensor, or bad configuration (direction pins in wrong directioy), or a slicer issue (poor/incomplete GCODE). I think @nannyogg82 has called out the issue by questioning the pin height - but I'm not qualified to advise on that one.

  • Like 1
Link to comment
Share on other sites

  • 0

@smirk,

I had a similar thing happen to me when I was printing TPU... I printed something and all went according to plan. Then I went and printed something else... Well, when the printer got to the Z-Endstop pin... it just kept trying to push down onto the pin, stepper screaming, belts slipping over the pulleys... I mean watching @nannyogg82's video gave me frightening flashbacks. Turns out the pin got stuck to the nozzle the last time it homed the printhead right before printing and it literally lifted the pin out of the endstop mount and dropped it on the floor of the pinter where it rolled under the print bed.

So you may very well be onto something. Could be a z-endstop issue.

  • Like 1
Link to comment
Share on other sites

  • 0

Hmm. What endstop pin is on that printer? Stock or Sexbolt? I have had a couple of occasions where the z homing failed with the bed driving up into the gantry and I had to e-stop the machine. In those cases what happened is I set my flex plate too far back and it prevented the Sexbolt pin from pressing the switch. From the video I couldn't really tell if the machine was driving back along y or down along z. So, are all the endstops activating correctly?

Taking a step back, when the tool head goes off on an adventure check what the reported position is and compare to what look reasonable.

  • Like 2
Link to comment
Share on other sites

  • 0
15 minutes ago, claudermilk said:

FYI you can edit your profile to have your serial show up there too.

I see now. You're a good 4 months ahead so... Maybe I will overtake you.

Shhhhh... Don't tell anyone but I'm building a RatRig V-Minion (got it from @Fabreeko_Hector) this weekend so... a lot of printing might just end up on that printer.

Thanks for the pro tip! I will update my profile.

BTW... What do you think... Should I post my RatRig build in the build section of is it just for Voron builds.

Link to comment
Share on other sites

  • 0
1 hour ago, Penatr8tor said:

Should I post my RatRig build in the build section of is it just for Voron builds.

We love build diaries, it's all about sharing and learning from experiences, so I would say most definitely run a build diary for your RatRig. You can never have too many experiences. 🤪

  • Like 1
Link to comment
Share on other sites

  • 0
2 hours ago, Penatr8tor said:

I might even try to build a printer of my own design. Crazy talk, I know.

We're a bunch of people who enjoy building things; crimping wires and melting plastic. Sounds perfectly rationale to me. However, perhaps don't go shouting that sort of thing out on the streets...

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...