Printer custom start G-code makes part slice under bed  

RE: Printer custom start G-code makes part slice under bed

When you issue G92, you are telling the printer where it is, regardless of homing. In your example, you are telling the printer the current position -- whatever it actually is -- is Z40. If the printer happened to have been homed previous to starting this job, you are telling it that the Z0 position is 40mm below the bed. I am unclear on why you're trying to do things this way, but it seems very error-prone unless you know exactly where the nozzle will be at the start of every print. Even then, it seems error-prone.

Why are you using G92 Z0 in your start gcode? Why aren't you letting the printer set the Z position from your endstops when homing with G28?

RE: Printer custom start G-code makes part slice under bed

Posted by: @bobstro

When you issue G92, you are telling the printer where it is, regardless of homing. In your example, you are telling the printer the current position -- whatever it actually is -- is Z40. If the printer happened to have been homed previous to starting this job, you are telling it that the Z0 position is 40mm below the bed. I am unclear on why you're trying to do things this way, but it seems very error-prone unless you know exactly where the nozzle will be at the start of every print. Even then, it seems error-prone.

Why are you using G92 Z0 in your start gcode? Why aren't you letting the printer set the Z position from your endstops when homing with G28?

Because my custom End G-Code always raises to 40mm i.e.

M104 S0
M140 S0
;Retract the filament
G92 E1
G1 E-1 F300
G1 Z40 F1000 ; printer will always finish here
G1 X110 Y190 F2000
M84

This means I do not need end stops for the Z axis- my first layer Z height has been consistent for years using this method.

Any ideas as to why is the custom G-Code causing the slice to happen below the bed ?  Thanks

RE: Printer custom start G-code makes part slice under bed

Save a 3MF project file with your part and settings, zip it up, and attach it to a reply here so we can take a look. The slicer in unaware of your start gcode so it is most likely a setting. 

RE: Printer custom start G-code makes part slice under bed

@eci22

Just because you raise the nozzle at the end of the print doesn't mean you have to tell the printer next time where "home" is, it will happen automagically with the G28 command. 

And as @bobstro pointed out, I don't think the slicer preview takes your start gcode into account (I may stand corrected on that one) so I don't see how your extra command would cause the model to sink below the print surface. I know you said you have a "fix" but what happens when you just delete the G92 Z40 line? Does the preview look correct now?

RE: Printer custom start G-code makes part slice under bed

A common mistake, which may or may not be relevant, is not being aware of the difference between absolute and relative positioning. Obviously there is a world of difference between move to 5mm above the bed and move up 5mm.

Always a good idea to force the mode at the start of a script, although admittedly that has pitfalls as well. 

RE: Printer custom start G-code makes part slice under bed

Does anybody know a way to determine which positioning mode is current?

RE: Printer custom start G-code makes part slice under bed

basepulley

@bobstro

Thank you so much for taking the time to look at the project, much appreciated. I have attached the zipped 3mf file to this post

@fuchsr

"what happens when you just delete the G92 Z40 line? Does the preview look correct now?"

Yes that's correct, I either remove the line and everything looks fine or set Z offset' in 'size and coordinates' to 40 but this causes the exported gcode to be 40mm in the the air

@towlerg

If it was a problem between relative and absolute mode then the problem would also occur on sli3er which it doesn't.

I have managed to get a development version of sli3er to run on kubuntu and the slice works fine with my custom start/end gcode so this issue isn't critical anymore, but it would be nice to know if I've missed a setting or it's bug, I would bet it's the former.

RE: Printer custom start G-code makes part slice under bed

"If it was a problem between relative and absolute mode then the problem would also occur on sli3er which it doesn't." not necessarily, the Prusaslicer gcode before your script is inserted will certainly be different than the equivalent from Sli3er.

RE: Printer custom start G-code makes part slice under bed

This PS github issue may be relevant - https://github.com/prusa3d/PrusaSlicer/issues/5918  

RE: Printer custom start G-code makes part slice under bed

I stand corrected. PrusaSlicer does incorporate your startup gcode into preview mode. Why it interprets movement but doesn't show the prime line printing, and how it discerns what to include or not, I don't know. 

I sliced with the settings you provided and viewed the  generated gcode in several popular gcode previewers:

• In PrusaSlicer's gcode viewer, the part is positioned below the bed as directed by your gcode.
• In ideaMaker, the part is hovering above the bed.
• In Simplify 3D, the part is level on the bed.
• On gcode.ws, the part seems to be embedded in the bed.

I commented out the following line in your startup gcode:

G92 Z40 ; printer always finishes here. **THIS VALUE MUST MATCH THE Z OFFSET IN PRINT SETTINGS**

Sure enough, the part is positioned atop the bed in PrusaSlicer's preview. I don't know why Slic3r or other slicers handle this differently, but I can see the logic in PrusaSlicer:

• The slicer has no idea where the nozzle is in 3D space, so has to make an assumption. They assume it's at X0 Y0 Z0 in a homed position.
• Your startup gcode G92 Z40 command tells the printer that Z0 is actually Z40. PrusaSlicer assumes this is what you want, so sets this as position Z0.
• The generated gcode is set to use absolute coordinates with G90. 
• The 1st move command is G1 Z0.200 F15000.000, which moves the nozzle to the Z0.02 position, so 38.8mm below Z0.

I can make the case that this is actually what it should do. You know your printer always starts at Z40, but the slicer has no way of knowing this, so is working with the information at hand.

As to why other slicers do it differently, @towelrg may be on to something with the distinction between absolute and relative positioning.  If another slicer doesn't interpret that G92 command -- likely ignoring start gcode entirely -- and assumes it starts at Z0, it makes sense it prints atop the bed. As to why the other results... I don't know.

Unfortunately, my PrusaSlicer 2.2. install is not working at the moment, and I have no motivation to install Slic3r. It's an interesting result, but in thinking it through, it doesn't seem to be a bug. I honestly think there are much better ways of doing what you're trying to do, but I understand you've got things set up how you like them and don't want to change your workflow. Here's my only suggestion: You are 100% sure your nozzle is positioned at Z40 at the start of every print. If that is the case, insert a gcode command to move Z to 40 with G0 Z40 (where it already is, so no movement should occur), then issue your G92 Z40 to re-establish this in the slicer as position 40. I changed your start gcode lines to:

G1 Z40
G92 Z40 ; printer always finishes here. **THIS VALUE MUST MATCH THE Z OFFSET IN PRINT SETTINGS**

Doing this, the preview is correct in PrusaSlicer and the part should print on your printer. You'll need to verify of course. 

I tried adding some gibberish to the start gcode to print a line at Z0 before doing your adjustments with:

G1 X100 Y300 E16
;G1 Z40
G92 Z40 ; printer always finishes here. **THIS VALUE MUST MATCH THE Z OFFSET IN PRINT SETTINGS**

No extrusion occurs on the bed before the rest continues below the print.

So much of this issue depends on details that are likely unique to your specific setup and different from any others that I'm not sure what Prusa could do with a trouble ticket. The slicer is going a step beyond some of the others and taking your gcode into account. It is doing what you told it. If you add the extra gcode to provide the missing information, the results match what you seem to be after. This registers as a "huh" severity in my book.

Do what works for you, of course, but I cannot understand why you'd want to do it this way. I'm also not seeing any Z offset in print settings, so that part is unclear. Do you mean a setting on your printer's firmware settings?

Edit: Last thought -- Once you're printing, the Mk3 firmware will prevent extruder moves below 0.15mm (the soft endstops), so this won't result in the nozzle being driven into the bed. Other printers may vary. Perhaps this makes it GitHub-worthy and anti-suicide measures should be included.

RE: Printer custom start G-code makes part slice under bed

@bobstro

Thank you for taking the time to put together such a thorough answer. Very much appreciated.

"Your startup gcode G92 Z40 command tells the printer that Z0 is actually Z40. PrusaSlicer assumes this is what you want, so sets this as position Z0."

If I am telling the nozzle it's at Z40, why would prusaslicer then assume that Z40 is Z0 ?

"I can make the case that this is actually what it should do. You know your printer always starts at Z40, but the slicer has no way of knowing this, so is working with the information at hand."

My counter would be if I am not printing below the bed, than the preview simulation should reflect this. The Z40 is resolved by a move to Z0. I cant think of any use-case (maybe you can?) where the user would want the print to start anywhere other than the bed when slicing, why not just ignore the start the gcode or take the entire start gcode into account so start the slicing position after the move from Z40 to Z0 which is what happens in real life (obviously for printing not slicing)

"Unfortunately, my PrusaSlicer 2.2. install is not working at the moment,"

2.2 behaves exactly the same, I checked before posting my initial question

"You are 100% sure your nozzle is positioned at Z40 at the start of every print. If that is the case, insert a gcode command to move Z to 40 with G0 Z40 (where it already is, so no movement should occur), then issue your G92 Z40 to re-establish this in the slicer as position 40. "

When I power on my printer the firmware reports position as 0,0,0 (even though physically im at 0,0,40 as this where my end gcode put the nozzle before powering down) doing a G0 Z40 at this stage moves the nozzle to 0,0,80- movement would occur. G92 Z40 then G0 Z40 would result in no movement but not the other way around, unless I have misunderstood your suggestion.

"The slicer is going a step beyond some of the others and taking your gcode into account. It is doing what you told it"

And my (albeit massive) assumption is the reason it is doing this is to create an accurate preview simulation, I don't see how the start gcode can actually effect the core functionality of slicing the model(I totally accept that I may be wrong on this). If this assumption is correct ,however, then the simulation should be accurate, If I'm not telling my printer to go 40mm below the bed than by definition a simulation should reflect this. If my nozzle ends up on the print bed, the slice should occur on the print bed.

"I'm also not seeing any Z offset in print settings, so that part is unclear. Do you mean a setting on your printer's firmware settings?"

This was my mistake, I meant "printer" settings

Set the Z offset to 40 and the slice preview occurs exactly on the print bed and everything seems to be resolved. However, if you examine exported G-Code you see:

LAYER_CHANGE
;Z:0.2
;HEIGHT:0.2
G1 Z40.200 F15000.000 ; This is a problem 🙂

Now the printer wants to start 40mm in the air :/

Please take my comments in the spirit of a friendly debate, I am not saying any development time should be dedicated to this, if for whatever reason Sli3er stops working it would be easy to write a custom post processing script of some kind. I appreciate this software is available for free and totally accept that my particular workflow would be something there is no motivation to provide support for and I'm totally fine with that. I'm not advocating anyone else throw away their end stops but as I said, the consistency I get from this method is extremely high. I only ever used sli3er so I had no idea it would cause issues in all the other slicers you mentioned. Thanks again for your input.

RE: Printer custom start G-code makes part slice under bed

Posted by: @eci22

[...] "Your startup gcode G92 Z40 command tells the printer that Z0 is actually Z40. PrusaSlicer assumes this is what you want, so sets this as position Z0."

If I am telling the nozzle it's at Z40, why would prusaslicer then assume that Z40 is Z0 ?

Sorry, let me try that again: the slicer accepts your setting that the current position -- Z0 in reality -- is Z40. I meant to say "that it is positioned at Z40".

"I can make the case that this is actually what it should do. You know your printer always starts at Z40, but the slicer has no way of knowing this, so is working with the information at hand."

We may have a disconnect on this. I didn't see anything where the printer is made aware that it is at position Z40. (see below)

My counter would be if I am not printing below the bed, than the preview simulation should reflect this. The Z40 is resolved by a move to Z0. I cant think of any use-case (maybe you can?) where the user would want the print to start anywhere other than the bed when slicing, why not just ignore the start the gcode or take the entire start gcode into account so start the slicing position after the move from Z40 to Z0 which is what happens in real life (obviously for printing not slicing)

I think this is a bit of a win-lose situation for Prusa. They seem to be incorporating the start gcode movement into the preview, and there's a case to be made that the preview should reflect the instructions the printer is being given so you can spot problems, not necessarily fix anything on the fly.

[...] When I power on my printer the firmware reports position as 0,0,0 (even though physically im at 0,0,40 as this where my end gcode put the nozzle before powering down) doing a G0 Z40 at this stage moves the nozzle to 0,0,80- movement would occur. G92 Z40 then G0 Z40 would result in no movement but not the other way around, unless I have misunderstood your suggestion.

That was based on the settings in your 3MF. (see below)

[...] And my (albeit massive) assumption is the reason it is doing this is to create an accurate preview simulation, I don't see how the start gcode can actually effect the core functionality of slicing the model(I totally accept that I may be wrong on this). If this assumption is correct ,however, then the simulation should be accurate, If I'm not telling my printer to go 40mm below the bed than by definition a simulation should reflect this. If my nozzle ends up on the print bed, the slice should occur on the print bed.

I'm taking it as "the slicer should reflect (simulate) what you are telling the printer to do, even if it won't work in reality, so you can fix it before trying to print."

"I'm also not seeing any Z offset in print settings, so that part is unclear. Do you mean a setting on your printer's firmware settings?"

This was my mistake, I meant "printer" settings

Hmm. When I import the 3MF, I see this:

Set the Z offset to 40 and the slice preview occurs exactly on the print bed and everything seems to be resolved. However, if you examine exported G-Code you see:

LAYER_CHANGE
;Z:0.2
;HEIGHT:0.2
G1 Z40.200 F15000.000 ; This is a problem 🙂

Now the printer wants to start 40mm in the air :/

There's obviously a mismatch with that initial Z offset setting, so most of my bright ideas probably don't apply to your actual situation! As they say in the old SNL sketch: "never mind"

Please take my comments in the spirit of a friendly debate, I am not saying any development time should be dedicated to this, if for whatever reason Sli3er stops working it would be easy to write a custom post processing script of some kind.

No worries. I really don't understand what the significance of the bed being at 40mm is though. Can you elaborate? This seems to be a LOT of work to resolve an issue that should not be an issue in most circumstances.

Just to expand my initial thinking:

1. You have a high degree of confidence that your nozzle is at Z40 at the start of every print. 
2. Once your gcode starts printing, you are expecting the nozzle to be moved a Z0.2 for the 1st layer. There doesn't seem to be anything preventing you from moving the nozzle down at the start of a print.
3. Why not then just home XY & Z with G28 so the printer can establish Z0, then move the nozzle back to Z40? If the idea is to clean or prepare the print, defer everything until ready to do so. (I do something like this in my startup gcode in fact.)

This may not work at all, but I simply don't see the significance of the nozzle being at Z40 at the start of a print. So v2 of my suggestion becomes:

G28 ; home xyz
G1 Z40 ; move z to 40 (for some reason).
G92 Z40 ; printer always finishes here. (a little redundant but harmless)

This has the added plus of ensuring the nozzle really is at Z40 in case you get a cat or small child in the future.

If the goal is to do the 3mm extrusion above the prime line printing position, just do that before the G28. Or after for that matter. You wait a moment for the initial homing and repositioning, but that's seconds compare to the length of a typical print job. I like to push the bed forward it heats up so I can inspect the bed and do any last-second cleanup before the job starts, so I can see why this might be desirable.

I appreciate this software is available for free and totally accept that my particular workflow would be something there is no motivation to provide support for and I'm totally fine with that. I'm not advocating anyone else throw away their end stops but as I said, the consistency I get from this method is extremely high. I only ever used sli3er so I had no idea it would cause issues in all the other slicers you mentioned. Thanks again for your input.

No worries. Again, just wondering why this is necessary. I'm as guilty as anybody of over-thinking my startup gcode!