Superslicer

[McCosch]

 

 

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

 

 

[nklvjc]

Watch x/y stepper setting in klipper config. You should reverse direction pin with  !  character. 

[McCosch]

 

During testing, the axes move in the right direction

 

[smirk]

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?

[McCosch]

 

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

 

[smirk]

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

[smirk]

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.

[McCosch]

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

printer-2.cfg

[smirk]

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.

 

 

 

 

[McCosch]

 

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 .

 

[smirk]

<Doh!> So you did, apologies for being a blind old codger, I shall have a look at that.

[smirk]

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

[nklvjc]

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.

[nklvjc]

What start g-code you use in super slicer?

[McCosch]

 

Unfortunately I haven't looked yet

 

[McCosch]

On 7/8/2022 at 11:11 PM, McCosch said:

During testing, the axes move in the right direction

yes

[McCosch]

Hello ,
I did another test which unfortunately failed again.
Send the SuperSlicer settings and cut out the G-code.
I specifically chose the location of the cube outside, but the error message.

[McCosch]

[smirk]

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.

 

 

[smirk]

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

 

[smirk]

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.

[McCosch]

Hello,

I have already tested some coordinates,

[McCosch]

Hello,

I saved the cube as an STL file but had CrfealitySlicer create the G-code and it printed right in the middle of my bed.

what is wrong with the SS.....

[smirk]

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

[McCosch]

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?