Jump to content

Superslicer


McCosch
 Share

Recommended Posts

 

 

Hello,

I have a Voron 2.4 octopus with clipper and mainsail.  I was able to do all the tests (GS28, QGL, Bad Mash, etc.).

Now I would like to print the Voron test cube but unfortunately the printer is going in the wrong direction.....why...

Maybe someone can help me

 

 

Link to comment
Share on other sites

Sorry for the  daft question, but when you say it's going in the wrong direction, when it's printing the testcube, what do you mean? Is it homing in the wrong direction (i.e. away from the end-stops), or something else?

Link to comment
Share on other sites

 

I mean when I want to print, it stops and an error message appears that the G-code coordinates are outside the print area.  I'll think about more details tomorrow.  Unfortunately it's not possible now because I'm at work.  Thank you in advance for your interest.  bus tomorrow

 

Link to comment
Share on other sites

Grumping that co-ordinates are outside the print area strikes me as a different issue than direction of travel. I'm away from home at the moment, so can't poke at my voron. I have had/seen that issue on a couple of occasions in the past, and I'm sure (in my case) it was something to do with incremental vs absolute gcode addressing (G91 vs G90). I think I'd removed the G90 (absolute) from my startup GCode and then must have done something to coax the printer into incremental/relative mode. I'll see  my memory is jogged when I look at my startup code.

 

I suppose rather than try print something you could try manually print head (using GCODE) something like
 

G28
G90
G0 X0 Y0 Z10
G0 X249 Y0
G0 X249 Y249
G0 X0 Y249

(assuming something like a 250x250 V2) that'll just move the head into each corner (10mm above the bed), after first homing and setting absolute mode (for moves).

Link to comment
Share on other sites

I remembered when I've seen the "out-of-range co-ordinates" issue, it was when printing a purge line at the start of the print. As the quick fix I just removed it from the startup but the longer term fix was minor tweak on where it was drawing the purge line but also making use I had a G90 in my startup code.

It also struck me this morning, if that experiment to manually move the head with the GCODE above fails with an out-of-bounds then you could move the co-ordinates away from the very edges of the bed for example

G28
G90
G0 X20 Y20 Z10
G0 X229 Y20
G0 X229 Y229
G0 X20 Y229

That'll move the head (hopefully) 20mm from the various edges. That could highlight an issue with where the machine thinks the end-stops are triggering or possibly the maximum/minimum co-ordinates.

Link to comment
Share on other sites

Hello,

now I would like to show you some data and pictures, then you can better imagine the problem.When I activate all axes home it always shows me red and that means outside the coordinates until it is finally at 350. I am of the opinion that it should actually be 0 and not
x=350;y=350 (as can be seen in the picture below)

Unfortunately I'm very new and I'm assembling my first Voron and I still have some construction sites on the printer.

-mini12864 LCD display activation

- RGB LED activation

 

Thanks in advance😊

20220709_130421.jpg

20220709_130547.jpg

20220709_130619.jpg

20220709_130941.jpg

20220709_131504.jpg

20220709_132023.jpg

printer-2.cfg

Link to comment
Share on other sites

I'm presuming you are using the stock printer.cfg from the VoronDesign github, otherwise it might be interesting to know what's in your printer.cfg file. There will be some settings relating to the endstop position and maximum position (maximum travel distance) for each axis. These in turn help determine the bed geometry and how far each axis can move - basically it is defining the print area.

When I first met a Voron one of the things that confused (and annoyed me) was the fact they home to the maximum position (e.g. x=220, y=220). Most other printers I had come across (includings ones I'd built) home to zero (x = 0, y = 0). The most I then had to do was  set an x & y offset as the head/nozzle were off the bed when the end-stops activated. A negative offset made sense, to me, as it was outwith the printable area (so in "negative space").

The Voron set up is kinda of backwards in  my old-fashioned way of thinking.

So that is all a very long winded way of saying, when you home X & Y it should be sitting at something like x=350, y=350 rather than x=0 and y=0.

The pictures are really helpful, especially that last picture showing y=-175 which is clearly way out of the print area, and must be an attempt to move the y-axis to the centre of the bed. I can see why you described it as moving in reverse. Having said that a move of -175 (in an absolute sense) would be fine to take the y-axis from 350 down to 175.

If you are using the stock klipper config then my hunch would be the slicer is doing something odd and misunderstanding the "unique" Voron set up. That's why I suggested the manual movement above, to eliminate the slicer. Did you try entering those GCode commands into the terminal? Naturally I'd amend them to reflect your 350mm setup rather than my assumed 250mm setup.

 

 

 

 

Link to comment
Share on other sites

 

I sent my Printer.cfg with it.  I'll reconsider everything.  And also try with another program. Have already tried it with Creality and it doesn't print exactly (may be due to the setting) in the middle.  But I can print.  Many thanks for the quick response .

 

Link to comment
Share on other sites

That printer.cfg file looks fine, nothing weird in the setup for the y axis.  So my money would be on the slicer configuration, and probably something in the GCode startup or if there are any setting related to "bed origin" those could be wrong (if it thinks the zero point is in the middle of the bed rather than a corner). If you've tried the Crealty slicer and it's not exactly in the middle that is down to settings (its understanding of the bed-size and off-sets). Personally I use Cura, I've never got into SuperSlicer but I'll have a look to see if there's any obvious problematic settings

Link to comment
Share on other sites

Hi, looking through your config file i see position end-stop Y is outside your print area. You have position_endstop: 350 and position_max: 350 on stepper_y. Change that to 355. Y position when G28 must be greater than 350. So you should also adjust home_xy_position. Also check moving directions for x and y in mainsail.

  • Like 1
Link to comment
Share on other sites

It's interesting all the co-ordinates in that generated GCODE are negative (well the ones that we can see in the screen shot). Not a scientific check, but when I slice the test cube (with a skirt for adhesion) using Cura I get something that looks like:

;TYPE:SKIRT
G1 F600 E1.75
G1 F1500 X9.089 Y16.467 E0.03271
G1 X9.14 Y15.699 E0.03576
G1 X9.27 Y14.941 E0.03573
G1 X9.478 Y14.201 E0.03571
G1 X9.762 Y13.486 E0.03574
G1 X10.119 Y12.805 E0.03572
G1 X10.544 Y12.164 E0.03573

As I say not scientific as I've got a different printer, different slicer and I'm not even guessing at your filament settings. However, to me it points to a slicer issue (rather than a klipper config issue).

Perhaps if someone who has a 2.4 sliced the test cube and gave you the GCODE you could try and print that and see if it generates the out-of-bound errors.

 

 

Link to comment
Share on other sites

Think I've spotted the issue! When I was experimenting with my Cura set up, the only way I could get the slicer to generate negative co-ordinates was by making the "bed origin" in Cura to be the centre (rather than the bottom left edge).

I notice in that 3rd last picture of the Superslicer platter, that the "zero marker" is in the centre of the bed. The bed-origin should be at (0,0) in super-slicer. I think that will be the cause of the out-of-range co-ordinates.

 

If you look in "Printer Settings" in superslicer you want the bed shape option, in that you can set the origin to (0,0):

 

ss-bed-origin.jpeg

Link to comment
Share on other sites

Looking at the GCode in your screenshot it is also using Absolute Co-ordinates (G90) (which it should be doing) but that means klipper (the printer) is taking the co-ordinates generated by SS as literal/gospel. So when SS says "G0 X-9.695 Y-17.087 E0.06836" then the printer absolutely takes that as a move into unprintable (negative) space and out-with the regular co-ordinates and produces the error. That makes me more confident the issue is the bed origin in super slicer, rather than some strange klipper set up.

Link to comment
Share on other sites

Ok, I do have super-slicer (although I don't use it as I don't want to make my life harder).I've sliced the Voron Cube (I used Super Slicers default Voron 2.4 350^2 profile) and I took the temperatures from your listing of GCODE (200C for filament, 60C for bed). The bed origin is (0,0)

I am using version 2.3.57.12 (which I think is the previous version to the latest stable release). You could try the attached file (produced by my superslicer), noting that I don't have a Voron 2.4 to test it on so I'm trusting to the profile that SS gave me. However a quick look at the GCODE and it's not producing negative co-ordinates.

Voron_Design_Cube_v7.gcode

Link to comment
Share on other sites

10 minutes ago, smirk said:

Ok, I do have super-slicer (although I don't use it as I don't want to make my life harder).I've sliced the Voron Cube (I used Super Slicers default Voron 2.4 350^2 profile) and I took the temperatures from your listing of GCODE (200C for filament, 60C for bed). The bed origin is (0,0)

I am using version 2.3.57.12 (which I think is the previous version to the latest stable release). You could try the attached file (produced by my superslicer), noting that I don't have a Voron 2.4 to test it on so I'm trusting to the profile that SS gave me. However a quick look at the GCODE and it's not producing negative co-ordinates.

Voron_Design_Cube_v7.gcode 2.68 MB · 0 downloads

will test it tomorrow. I can also take the Creality if the SS causes problems. what slicer do you use?

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
Reply to this topic...

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

 Share

×
×
  • Create New...