Odd behavior on "reprints"

Post Reply
geneb
ULTIMATE 3D JEDI
Posts: 5364
Joined: Mon Oct 15, 2012 12:47 pm
Location: Graham, WA
Contact:

Odd behavior on "reprints"

Post by geneb »

I've noticed that even with the 1.12 firmware, "reprints" don't start the way they should.

By "reprint" I mean that I've hit cancel and then restarted the print job.

What happens is that the bed will heat and then go straight into the calibration (my start g-code is g28, g32) without heating the hot end. On the first try of a new print, it always heats the bed up.

It's my understanding that this may be related to the T0 command that's in config.g - however, there's no way to add this to a sliced file _before_ the heating commands in S3D. S3D does include a "T0" at the end of the hot end heating command, which I would thing would satisfy that requirement, but apparently it doesn't.

Any suggestions as to what I can do to resolve this short of hand-editing the gcode after it's generated?

tnx!

g.
Delta Power!
Defeat the Cartesian Agenda!
http://www.f15sim.com - 80-0007, The only one of its kind.
http://geneb.simpits.org - Technical and Simulator Projects
dc42
Printmaster!
Posts: 454
Joined: Mon Mar 07, 2016 10:17 am

Re: Odd behavior on "reprints"

Post by dc42 »

The usual reason for this is that no tool is selected. Look in the Gcode Console tab of the web interface for error messages to confirm this. You may have a T0 command at the end of config.g, which is OK for the first attempt, however the default action when cancelling a print is to deselect the current tool.

Here are some workarounds:

1. Ensure there is a T0 command in the slicer start gcode, before the command to set temperatures. This is the recommended approach. Some slicers add the start gcode after the command to set extruder temperature, which makes this a little tricky but usually not impossible.

2. Send T0 manually before restarting.

3. With very recent firmware versions (sorry I can't remember whether it is 1.12 or 1.13b1 - see github for confirmation), you can put a cancel.g file in /sys to override the default behaviour when you cancel a print.
User avatar
Jimustanguitar
ULTIMATE 3D JEDI
Posts: 2631
Joined: Sun Mar 31, 2013 1:35 am
Location: Notre Dame area
Contact:

Re: Odd behavior on "reprints"

Post by Jimustanguitar »

I've had a different behavior. When I cancel a job and then try it again, it tries to resume from where it left off. I actually have to cut the power, re-run the calibration routine (it's not in my start GCode) and start the print "fresh" to get it to start from the beginning. The workaround that I've been using is to delete the GCode file, and re-upload it in the web browser.

Note, that's with the x.12a firmware. I haven't updated to the newest release yet.
geneb
ULTIMATE 3D JEDI
Posts: 5364
Joined: Mon Oct 15, 2012 12:47 pm
Location: Graham, WA
Contact:

Re: Odd behavior on "reprints"

Post by geneb »

dc42 wrote:The usual reason for this is that no tool is selected. Look in the Gcode Console tab of the web interface for error messages to confirm this. You may have a T0 command at the end of config.g, which is OK for the first attempt, however the default action when cancelling a print is to deselect the current tool.

Here are some workarounds:

1. Ensure there is a T0 command in the slicer start gcode, before the command to set temperatures. This is the recommended approach. Some slicers add the start gcode after the command to set extruder temperature, which makes this a little tricky but usually not impossible.
There's no way to insert this in S3D before the heating commands.
2. Send T0 manually before restarting.
This is annoying. :(
3. With very recent firmware versions (sorry I can't remember whether it is 1.12 or 1.13b1 - see github for confirmation), you can put a cancel.g file in /sys to override the default behaviour when you cancel a print.
That doesn't appear to be in the 1.12a release that I'm running.

g.
Delta Power!
Defeat the Cartesian Agenda!
http://www.f15sim.com - 80-0007, The only one of its kind.
http://geneb.simpits.org - Technical and Simulator Projects
dc42
Printmaster!
Posts: 454
Joined: Mon Mar 07, 2016 10:17 am

Re: Odd behavior on "reprints"

Post by dc42 »

geneb wrote:
dc42 wrote: 1. Ensure there is a T0 command in the slicer start gcode, before the command to set temperatures. This is the recommended approach. Some slicers add the start gcode after the command to set extruder temperature, which makes this a little tricky but usually not impossible.
There's no way to insert this in S3D before the heating commands.
Most slicers will allow you to put a command of the form:

M109 S [first_layer_temperature]

or similar after the T0 command. I dont know whether S3D supports this. The fact is, the slicer should always send a T command at the start, because if you have more than one tool then you need to say which one you want to print with, even if you are doing a single material single colour print. Putting T0 at the end of config.g is actally a hack.
geneb
ULTIMATE 3D JEDI
Posts: 5364
Joined: Mon Oct 15, 2012 12:47 pm
Location: Graham, WA
Contact:

Re: Odd behavior on "reprints"

Post by geneb »

Here's the first few lines of actual code from S3D:

Code: Select all

G90
M83
M106 S0
M140 S80
M190 S80
M104 S245 T0
M109 S245 T0
G28 ; home all axes
G32 ; auto-cal
G1 E-5.1000 F1500
G1 Z0.600 F1200
; layer 1, Z = 0.3
T0
; tool H0.300 W0.720
; skirt
As you can see, there IS a T0 issued, but long after it can do me any good. There is no automatic way to insert a T0 before the heating commands. Do other firmwares have a "default" T0 or do they consider the T0 at the end of the heating command to also be a tool select?

g.
Delta Power!
Defeat the Cartesian Agenda!
http://www.f15sim.com - 80-0007, The only one of its kind.
http://geneb.simpits.org - Technical and Simulator Projects
lignumaqua
Plasticator
Posts: 19
Joined: Fri Apr 29, 2016 10:09 am

Re: Odd behavior on "reprints"

Post by lignumaqua »

As Gene says, S3D *does* send a T0 before printing. Unfortunately it sends it after the heating commands, just before it actually starts extruding. :( It assumes that the T0 at the end of the M109 command will suffice to tell the M109 which extruder to heat.

However, I think you have hit on a solution to Gene's problem. Gene - if you add in:

Code: Select all

M109 S[extruder0_temperature] T0
As a 'Tool Change Script' in S3D then I think it might do what you need. You'll still need the T0 in the starting script to make sure it heats before auto calibration, but this should help for your re-start after a cancel.
IMBoring25
Printmaster!
Posts: 616
Joined: Wed Mar 18, 2015 1:11 am

Re: Odd behavior on "reprints"

Post by IMBoring25 »

My approach is to reissue G10. If I'm not using an extruder, active and standby can both be zero. During start gcode, when I want to micro-manage things, I set active and standby temps to the same values for all the extruders. Only just before the print do I set the final active and standby temperatures (setting all extruders' active and standby temps back to zero as part of the end gcode).
geneb
ULTIMATE 3D JEDI
Posts: 5364
Joined: Mon Oct 15, 2012 12:47 pm
Location: Graham, WA
Contact:

Re: Odd behavior on "reprints"

Post by geneb »

The tool change script code is inserted AFTER the initial heating. I still don't understand why the firmware is ignoring the heating command when it's explicitly indicating which hot end it wants heated up. :(

g.
Delta Power!
Defeat the Cartesian Agenda!
http://www.f15sim.com - 80-0007, The only one of its kind.
http://geneb.simpits.org - Technical and Simulator Projects
lignumaqua
Plasticator
Posts: 19
Joined: Fri Apr 29, 2016 10:09 am

Re: Odd behavior on "reprints"

Post by lignumaqua »

geneb wrote:The tool change script code is inserted AFTER the initial heating.
Right, it's after the initial heating, but should be before actual printing starts so it achieves the same result?
geneb wrote:I still don't understand why the firmware is ignoring the heating command when it's explicitly indicating which hot end it wants heated up. :(
No, I don't understand why the heating command ignores the final T0 either. It's an optional parameter to M109 so maybe RepRap just doesn't support it.
dc42
Printmaster!
Posts: 454
Joined: Mon Mar 07, 2016 10:17 am

Re: Odd behavior on "reprints"

Post by dc42 »

lignumaqua wrote:
geneb wrote:The tool change script code is inserted AFTER the initial heating.
Right, it's after the initial heating, but should be before actual printing starts so it achieves the same result?
geneb wrote:I still don't understand why the firmware is ignoring the heating command when it's explicitly indicating which hot end it wants heated up. :(
No, I don't understand why the heating command ignores the final T0 either. It's an optional parameter to M109 so maybe RepRap just doesn't support it.
There is no clear definition of what the M109 code means. The T parameter isn't even documented on the reprap.org wiki page. RRF supports an active and a standby temperature for each extruder. A command of the form M109 S220 T0 is interpreted as meaning set the active temperature of tool 0 to 220C and then wait until the active tool (if any) is up to temperature. Selecting the tool is a separate operation.

I think the real problem is that the gcodes generated by common slicers for single-material prints assume you have a single-head machine with one permanently-selected tool, and therefore don't give you the opportunity to say which tool you want to use. In such cases, it is up to you to select the tool before you start the print. My Ormerod has two print heads loaded with different coloured filaments, so before I print I run a macro to select the tool.
lignumaqua
Plasticator
Posts: 19
Joined: Fri Apr 29, 2016 10:09 am

Re: Odd behavior on "reprints"

Post by lignumaqua »

dc42 wrote: A command of the form M109 S220 T0 is interpreted as meaning set the active temperature of tool 0 to 220C and then wait until the active tool (if any) is up to temperature.
There's the point of discussion. I'd contend that this should be interpreted as wait until T0 is up to temperature, but I see the problem. Hmmm... :roll:
Post Reply

Return to “Duet”