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

Yes, I'd noticed your question and was scratching my head. I should really ask over in the quesiton (to keep it all together https://twemoji.maxcdn.com/2/72x72/1f642.png ) but it would be helpful to understand which controller board you're using (e.g. spider, octopus, etc) and whether you're using the stock (voron) printer.cfg (or really what is your printer.cfg). Does the QGL (gantry levelling) and other functions work as expected or ar they out of whack/alignment as well?

 

I'm using an Octopus board and the stock printer.cfg file expect where directed to amend it. This did work in the centre of the print bed the very first time I tried but after doing to the two adjustments I mentioned above I haven't been able to get it working at all.

Link to comment
Share on other sites

  • 0

Personally I would not click on the "factory reset" button. I agree that a good diagnostic step is to reverse the changes (ideally step by step as you did them) to get back to your known good situation (where it was printing but not adhering) and then work forward again bit by bit to isolate where it went wrong. The reason I say "don't use factory reset" is I don't know what it does (I don't use klipper screen) so would not wish to presume that it would return you to the original stock printer.cfg (moonraker.conf file, etc) file as downloaded from github. Perhaps it has it's own notion of what came from the factory.

Now, I appreciate that rolling back the changes might be harder said than done - especially if you ran an automated script like "KlipperScreen-install.sh" or didn't back up the original printer.cfg file (that would've retained the original z-offsets). Therefore, it might be easier and more reliable to blow the PI away and start from scratch  (clearly I am assuming that this is a relatively new build and you don't have a huge investment in mods and customisations 😉 )

My hunch would be something went wrong with the z-offset as that relates to movement and positioning. The klipper screen should just be another interface (like mainsale or fluidd) so I would not expect that to have borked things up. However, I'd strongly recommend going back to the start (known "good" with crappy z-offset).

Link to comment
Share on other sites

  • 0

Oh dear.

Did it "work" when you did a clean install? I say "work" as in  print in the middle albeit without great adhesion? Or was it still going the same thing even after a clean install?

All things being equal if it worked once, then stopped after some config changes (z-offset, klipper screen install), but now continues to not work after you've gone back to the basic config (fresh install) then that suggests things ain't equal. In other words, it wasn't one of those two changes (z-offset, Klipper-screen install), perhaps a hardware failure (loose wire,duff connection etc) has reared it's ugly head.

I might be being overly cautious but I think it's time to go back to basics. With a fresh install: check end-stops are working (M114 gcode or QUERY_ENDSTOPS ) and reporting correctly. It's a good test as you can manually trigger an end-stop whilst observing the results. Then try a basic movement check, first try buzzing the various stepper motors (e.g. STEPPER_BUZZ STEPPER=stepper_x  that "stepper_x" will match the definition in your printer.cfg). The motors should all move very slightly (back and forwards). Next try homing the X and Y axes ("G28 X Y" GCODE). Depending on where the head is you would expect the X and Y axes to move to the appropriate home position. Once homed you can manually move the head to the centre(ish) of the bed with a ("G90" for absolute moves followed by a "G0 X100 Y100" to move the head)

See how you get on with that.

Link to comment
Share on other sites

  • 0
On 10/29/2022 at 11:18 PM, smirk said:

Oh dear.

Did it "work" when you did a clean install? I say "work" as in  print in the middle albeit without great adhesion? Or was it still going the same thing even after a clean install?

All things being equal if it worked once, then stopped after some config changes (z-offset, klipper screen install), but now continues to not work after you've gone back to the basic config (fresh install) then that suggests things ain't equal. In other words, it wasn't one of those two changes (z-offset, Klipper-screen install), perhaps a hardware failure (loose wire,duff connection etc) has reared it's ugly head.

I might be being overly cautious but I think it's time to go back to basics. With a fresh install: check end-stops are working (M114 gcode or QUERY_ENDSTOPS ) and reporting correctly. It's a good test as you can manually trigger an end-stop whilst observing the results. Then try a basic movement check, first try buzzing the various stepper motors (e.g. STEPPER_BUZZ STEPPER=stepper_x  that "stepper_x" will match the definition in your printer.cfg). The motors should all move very slightly (back and forwards). Next try homing the X and Y axes ("G28 X Y" GCODE). Depending on where the head is you would expect the X and Y axes to move to the appropriate home position. Once homed you can manually move the head to the centre(ish) of the bed with a ("G90" for absolute moves followed by a "G0 X100 Y100" to move the head)

See how you get on with that.

I've been busy the past few days so haven't had chance to look at it yet. Is there anything I should be aware of when doing the clean install? Do I need to remove the installed firmware and start from scratch again. Still very new to this all. Thanks

Link to comment
Share on other sites

  • 0

I don't think there is anything to be aware of that you have not aready covered beyond perhaps me explainng myself better 🤣 When I'm talking about a "clean install" or going back to "basics" I'm talking about reinstalling the OS onto the raspberry PI (along with Klipper and Mainsail/Fluidd (or whatever you chose). I should point out that I presume you used a pre-made PI OS (e.g. "Mainsail OS", basically whatever comes with Linux, Klipper et al pre-installed) rather than a hand-crafted approach.

From the description of your problem I would not say it was necessary to reflash the printer control board with the klipper firmware again. That's pretty minimal with all the configuration down via the printer.cfg file loaded from the PI. Basically if that were the issue the printer would be really borked (probably nothing would move or respond). So I don't think you need to do that part unless really paranoid.

Once you've got a basic klipper Mainsail/Fluidd install back onto the PI you can start with the appropriate "generic" voron printer.cfg from the Klipper github. From there you can work forwards again.

Couple of side notes:

  • The Klipper github stores all this configuration in a sub-folder (called "configuration" of the  "firmware" folder.  Personally I view that as a tad confusing. The printer.cfg file is simply a (very important) configuration file it's not firmware, I'm being pedantic but I just feel it should be in it's own high level "Printer Configuration" folder.
     
  • Notwtihstanding the previous spraffle about reloading the enitre PI OS, in theory you could get away with only the printer.cfg file form the Voron Github and work forward from there. That would probably only work if there had been no other changes to any other aspect of the configuraiton of the machine.
     

Once you've got back to a virgin install you can then work forwards again using the Voron the instructions from the Voron Initial Install guide. Basically take it slowly a step at a time. Each time you make a change to the configuration of the machine (e.g. SAVE_CONFIG) a new copy of the printer.cfg file will be create. Or rather the version of the file before you made your changes will be saved something like "printer.cfg.20221104" in the same klipper_config directory where the current working "printer.cfg" is located.

If you are not sure if a particular change has taken effect you can do a deliberated "FIRMWARE_RESTART" which forces the printer to reload the printer.cfg file. As I say take each bit step by step and check if it works as expected and if it doesn't you can simply rename the previous printer.cf.xxxxxx file back to printer.cfg and try again.

It will be a bit of a PITA stepping through things slowly but it is the best approach. Sometimes, it's not until you go back to basics you have a euraka moment ("Oh I completely forgot to do that vital step" or "I transposed those digits"). Don't be tempted to rush ahead because you are feeling confident "that's it fixed" 😉

Other things to check (mentioned by @mvdveer and others:

  • It's worthwhile having a check of all the wiring and connections, plugs and connectors. Make sure nothing is loose and that all the wires look good.
  • The Slicer gcode start routines - for your initial testing, make sure it is something really simple (perhaps as simple as only a "G28" to home the axis or a "PRINT_START" which is a Macro that is defined towards the end of the printer.cfg file.
  • A good diagnostic throughout your testing is to check the status of end-stops (GCode M119), there's often a button on the Mainsail/Fluidd control screens to report on that. If end-stops are showing as "triggered" when they are clearly not then that points to duff wiring. Voron wires the end-stops to be Normally-Closed as a fail safe (a break in the wiring makes it look like the end-stop is triggered which prevents the printer smashing into itself).

 

Hope that helps, but if not then just ask. I know the frustration in trying to diagnose faults and  it can be tedious!

 

Link to comment
Share on other sites

  • 0
On 11/4/2022 at 8:47 AM, smirk said:

I don't think there is anything to be aware of that you have not aready covered beyond perhaps me explainng myself better 🤣 When I'm talking about a "clean install" or going back to "basics" I'm talking about reinstalling the OS onto the raspberry PI (along with Klipper and Mainsail/Fluidd (or whatever you chose). I should point out that I presume you used a pre-made PI OS (e.g. "Mainsail OS", basically whatever comes with Linux, Klipper et al pre-installed) rather than a hand-crafted approach.

From the description of your problem I would not say it was necessary to reflash the printer control board with the klipper firmware again. That's pretty minimal with all the configuration down via the printer.cfg file loaded from the PI. Basically if that were the issue the printer would be really borked (probably nothing would move or respond). So I don't think you need to do that part unless really paranoid.

Once you've got a basic klipper Mainsail/Fluidd install back onto the PI you can start with the appropriate "generic" voron printer.cfg from the Klipper github. From there you can work forwards again.

Couple of side notes:

  • The Klipper github stores all this configuration in a sub-folder (called "configuration" of the  "firmware" folder.  Personally I view that as a tad confusing. The printer.cfg file is simply a (very important) configuration file it's not firmware, I'm being pedantic but I just feel it should be in it's own high level "Printer Configuration" folder.
     
  • Notwtihstanding the previous spraffle about reloading the enitre PI OS, in theory you could get away with only the printer.cfg file form the Voron Github and work forward from there. That would probably only work if there had been no other changes to any other aspect of the configuraiton of the machine.
     

Once you've got back to a virgin install you can then work forwards again using the Voron the instructions from the Voron Initial Install guide. Basically take it slowly a step at a time. Each time you make a change to the configuration of the machine (e.g. SAVE_CONFIG) a new copy of the printer.cfg file will be create. Or rather the version of the file before you made your changes will be saved something like "printer.cfg.20221104" in the same klipper_config directory where the current working "printer.cfg" is located.

If you are not sure if a particular change has taken effect you can do a deliberated "FIRMWARE_RESTART" which forces the printer to reload the printer.cfg file. As I say take each bit step by step and check if it works as expected and if it doesn't you can simply rename the previous printer.cf.xxxxxx file back to printer.cfg and try again.

It will be a bit of a PITA stepping through things slowly but it is the best approach. Sometimes, it's not until you go back to basics you have a euraka moment ("Oh I completely forgot to do that vital step" or "I transposed those digits"). Don't be tempted to rush ahead because you are feeling confident "that's it fixed" 😉

Other things to check (mentioned by @mvdveer and others:

  • It's worthwhile having a check of all the wiring and connections, plugs and connectors. Make sure nothing is loose and that all the wires look good.
  • The Slicer gcode start routines - for your initial testing, make sure it is something really simple (perhaps as simple as only a "G28" to home the axis or a "PRINT_START" which is a Macro that is defined towards the end of the printer.cfg file.
  • A good diagnostic throughout your testing is to check the status of end-stops (GCode M119), there's often a button on the Mainsail/Fluidd control screens to report on that. If end-stops are showing as "triggered" when they are clearly not then that points to duff wiring. Voron wires the end-stops to be Normally-Closed as a fail safe (a break in the wiring makes it look like the end-stop is triggered which prevents the printer smashing into itself).

Hope that helps, but if not then just ask. I know the frustration in trying to diagnose faults and  it can be tedious!

Well I've just tried reflashing the OS on the PI and now I'm having issues when it comes to SSH'ing into the PI. I keep getting the following error message and I am stumped. Does anyone know what this error means and how I can resolve it please?

Screenshot 2022-11-08 142735.jpg

Link to comment
Share on other sites

  • 0
9 minutes ago, nannyogg82 said:

Well I've just tried reflashing the OS on the PI and now I'm having issues when it comes to SSH'ing into the PI. I keep getting the following error message and I am stumped. Does anyone know what this error means and how I can resolve it please?

Screenshot 2022-11-08 142735.jpg

I've done a google search trying to resolve this, it recommended deleting the offending key from the .ssh registry but having looked in there I'm even more stumped. 

Screenshot 2022-11-08 142735.jpg

Link to comment
Share on other sites

  • 0
19 minutes ago, nannyogg82 said:

it recommended deleting the offending key

According to Purdue, Windows stores the ssh keys in the folder shown below.

"By default, the system will save the keys to [your home directory]/.ssh/id_rsa."

This folder should have a key file for each system you've remoted into. The existing file in this folder doesn't agree with the key the new Pi install created so you just need to delete the key file(s) (on the Windows machine) for the IP address of your klipper install. Then when you ssh back into the printer you should be able to accept the new key.

Link to comment
Share on other sites

  • 0
1 hour ago, atrushing said:

According to Purdue, Windows stores the ssh keys in the folder shown below.

"By default, the system will save the keys to [your home directory]/.ssh/id_rsa."

This folder should have a key file for each system you've remoted into. The existing file in this folder doesn't agree with the key the new Pi install created so you just need to delete the key file(s) (on the Windows machine) for the IP address of your klipper install. Then when you ssh back into the printer you should be able to accept the new key.

This is turning into a nightmare! lol

I managed to delete the ssh keys as recommended and was able to configure the pi. However, all of my configuration files have now disappeared from the Mainsail OS. I've done a quick google to see what the issue is and its apparently something to do with the newest version of mainsail moving the file directory. Only problem is I have absolutely no idea how to find the new directory or change the path. Can anyone help please?

Link to comment
Share on other sites

  • 0

I'm out at the mo so just on the mobile. I'll tell you where they've moved when I get home in a hour or so. This is a perennial problem with plenty of FLOSS software stuff gets updated and moved and for a while it all goes to poo. This would.have been inevitable (I know poor comfort)

Link to comment
Share on other sites

  • 0
1 hour ago, nannyogg82 said:

newest version of mainsail moving the file directory.

Try watching this video with auto generated and translated subtitles. (if needed)

 

A few key links to go with the video:

https://github.com/Arksine/moonraker
https://moonraker.readthedocs.io/en/latest/configuration/

And on one of the Arksine/github pages I found the following script to run on the PI over ssh:

pi@mainsailos:~$ .scripts/data-path-fix.sh    <-- This was what finally fixed the folders

After running the script I rebooted and all was working again.

 

  • Like 1
Link to comment
Share on other sites

  • 0

Sorry to take longer than I wanted, I was trying to upgrade an old copy of mainsailos to see if I could get it to fail to work through their instructions. Needless to say (in good old IT support fashion) it just worked for me! I think the trouble is it looks like it could fail in a zillion different ways, so I probably should asked a couple more questions.

Bit of background.

The config files are now stored in the "printer_data" folder e.g. /home/pi/printer_data (or rather that's where they should all be stored).

What the update does is create what UNIX refers to as "symlinks" (WIndows I believe would call them "short-cuts", although it too has symlinks). These are just pointers to the original location of the files. I guess at some future date they'll just go straight for storing the files/directories actually inside the "printer_data" folder.

I think the problem occurs, because the moonraker update appears to be a two stage process, the second (and final stage) requires that moonraker is running (the old version) and needs human intervention to basically type in the main PI user's password. Trouble is this second stage is not very clear - it relies on you noticing a small system alert (the bell icon) and a rather cryptic message about needing the "sudo" password:

sudo-notice.jpeg.7fcc659f8761bc84dbd01283a9e259cc.jpeg

Miss that step (and just restart) and it all goes to shite.

Couple More Questions:

Sorry, to try and figure out where things have gone wonky and what fix is actually needed:

#1) I'm presuming you've restarted things and moonraker has not connected, do you at least get the lovely error message (in an otherwise blackscreen):

moonraker-failure.jpeg.9f786c64db0befca7ba72ea0e03d3835.jpeg

Or is the error even worse than that?

#2) If you do a "ls -l ~/printer_data" what does it say?

#3) If you do a "ls -l ~/printer_data/systemd/" does it mention anything about "moonraker.env" or does it just say "file not found"

#4) If you do "cat /etc/systemd/system/moonraker.service", what does it say - it should like out a bunch of stuff. If there are a couple of lines like:

[Service]
Environment=MOONRAKER_CONFIG=/home/pi/klipper_config/moonraker.conf
Environment=MOONRAKER_LOG=/home/pi/klipper_logs/moonraker.log

 

Depending on the answers to #3 and #4  it could indicate whether it managed to update the service definition for the moonraker service to the correct version. If #2  & #3 are fine then it would be some of those symlinks (to existing configs) are duff in #2.

 

Sorry I know it's a pain all the questions but it's important to know at what stage it failed in the update.

 

Link to comment
Share on other sites

  • 0
14 minutes ago, smirk said:

Sorry to take longer than I wanted, I was trying to upgrade an old copy of mainsailos to see if I could get it to fail to work through their instructions. Needless to say (in good old IT support fashion) it just worked for me! I think the trouble is it looks like it could fail in a zillion different ways, so I probably should asked a couple more questions.

Bit of background.

The config files are now stored in the "printer_data" folder e.g. /home/pi/printer_data (or rather that's where they should all be stored).

What the update does is create what UNIX refers to as "symlinks" (WIndows I believe would call them "short-cuts", although it too has symlinks). These are just pointers to the original location of the files. I guess at some future date they'll just go straight for storing the files/directories actually inside the "printer_data" folder.

I think the problem occurs, because the moonraker update appears to be a two stage process, the second (and final stage) requires that moonraker is running (the old version) and needs human intervention to basically type in the main PI user's password. Trouble is this second stage is not very clear - it relies on you noticing a small system alert (the bell icon) and a rather cryptic message about needing the "sudo" password:

sudo-notice.jpeg.7fcc659f8761bc84dbd01283a9e259cc.jpeg

Miss that step (and just restart) and it all goes to shite.

Couple More Questions:

Sorry, to try and figure out where things have gone wonky and what fix is actually needed:

#1) I'm presuming you've restarted things and moonraker has not connected, do you at least get the lovely error message (in an otherwise blackscreen):

moonraker-failure.jpeg.9f786c64db0befca7ba72ea0e03d3835.jpeg

Or is the error even worse than that?

#2) If you do a "ls -l ~/printer_data" what does it say?

#3) If you do a "ls -l ~/printer_data/systemd/" does it mention anything about "moonraker.env" or does it just say "file not found"

#4) If you do "cat /etc/systemd/system/moonraker.service", what does it say - it should like out a bunch of stuff. If there are a couple of lines like:

[Service]
Environment=MOONRAKER_CONFIG=/home/pi/klipper_config/moonraker.conf
Environment=MOONRAKER_LOG=/home/pi/klipper_logs/moonraker.log

Depending on the answers to #3 and #4  it could indicate whether it managed to update the service definition for the moonraker service to the correct version. If #2  & #3 are fine then it would be some of those symlinks (to existing configs) are duff in #2.

Sorry I know it's a pain all the questions but it's important to know at what stage it failed in the update.

I've restarted multiple times and it has always reconnected. I've never seen any of the messages listed above. The only error I can see is the lack of the config files. Sorry if I'm being stupid here...

Screenshot 2022-10-03 143934.jpg

  • Like 1
Link to comment
Share on other sites

  • 0

One thing I probably should say/point out/presume/ask (take your pick) 🤔 the original (pre-buggered-up configs) should still exist on your machine they will still be in the "/home/pi/klipper_config/" directory (e.g. printer.cfg, moonraker.cfg, mainsail.cfg, etc). The upgrade doesn't destroy or remove these.

  • Like 1
Link to comment
Share on other sites

  • 0
3 minutes ago, nannyogg82 said:

I've restarted multiple times and it has always reconnected. I've never seen any of the messages listed above. The only error I can see is the lack of the config files. Sorry if I'm being stupid here...

No, you're not being stupid. That picture was useful, perhaps looks better than I thought.

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