Not if you enter it into the "Starting Script" tab in a process and then save the profile. The only gcode in the file before whatever you enter in there will be 2 lines that set the motion control and extruders to either absolute or relative positioning; G90 and M83 in my case (absolute motion positioning and relative extruder positioning).
The key is to either click "Update Profile" if you want to change the current profile or "Save as New Profile" if you want to create a new profile from the current Process settings. That way the changes persist, instead of disappearing when you close S3D.
Okay, so as I mentioned before, the S3D preprint script will be at the beginning of every file you slice, if you save it to each of your profiles in S3D. I also realized two other things may be happening somehow, that you should attempt to eliminate as problems:
- You could have a line ending problem somehow in your preprint gcode script in S3D, so it'd be smart to double check for that by just deleting the end of the lines and hitting ENTER again. If this is happening, and the printer's gcode interpreter isn't properly detecting the EOL, your blocking tool temp line could be seen as part of the prior line's comment.
- You might not have a space before the semicolon for the comment after one of the lines. It's not likely to be this, but it's possible (again) that it's a gcode parser bug in either OctoPrint or the firmware that is somehow munging the line so it gets skipped/ignored/omitted.
1 Like
It's still trying to print before the nozzle even starts to warm up, after the bed is at target temp. I ran the test gcode that I made, and that ran fine letting both get up to target temp. But, when I run a gcode with an object to print, I'm back where I started.
S3D puts the temp code in. Everything I add comes after in the "custom" script area.
Did you regenerate the gcode? Are you positive you overwrote the old one and uploaded a fresh one? I know it sounds silly, but something isn't right here. Can you give us the top of the new file, please, so we can make sure it looks right? I really think something hairy is going on here.
I'll post the gcode of the test file that worked without issues and the fresh slice that didn't.
From the test code that worked (bed to target temp and tool to target temp before any other action):
G90
M82
M106 S0
M140 S80
M190 S80
M104 S230 T0
M109 S230 T0
G28 ; home all axes
G1 Z0.25 ; position for priming
G92 E0 ; zero extruded length
G1 X100 E10 F600 ; prime
Fresh slice (bed to target temp, tried to extrude filament before tool even started to heat up):
G90
M82
M106 S0
M140 S70
M190 S70
M104 S235 T0
M109 S235 T0
G28
G1 Z0.25
G92 E0
G1 X100 E10 F600
M201 X1000 Y1000
G92 E0
G1 E-1.0000 F2400
G1 Z0.393 F1200
; process Process1
; layer 1, Z = 0.343
T0
; tool H0.250 W0.624
; skirt
G1 X51.890 Y34.685 F9000
G1 Z0.343 F1200
Great big assumption here...
To me, it looks like the first script sets up your print job for an immediate 10mm extrusion deficit. It's got an E10 which isn't (I assume) followed by a G92 E0 (or is it?) If no zero-the-extruder follows this, then the next two commands are something like:
G0 go somewhere
G1 start moving to somewhere else and extrude 1.00, let's say
Since the extruder audit is already at 10, then the next "1.00" as seen in absolute terms (M82) looks like a 9mm retraction. The next several lines would then be pushing out tiny amounts until things get back to zero and then start actually printing.
I had this problem on mine for some time before I figured it out. The front/left corner of all first layers had a 10mm deficit.
That's the script that I added. Everything else is added by S3D, before and after that.
I think it'd be helpful to see your actual scripts in S3D. Also, I'd suggest putting it into relative extrusion mode...it's one less thing to worry about. Change it in S3D's settings, though, not manually in the script.
Also, you know you can safely edit the parts that S3D adds to the script, right? It's safe as long as you leave the S3D variables in there for it to fill in the temps, etc. I still think that you have a line ending issue in there or something, but we're just seeing the gcode, not the actual script, so it's a little harder to diagnose.
The problem may be that your portion of the script doesn't have temperature commands. It appears to me that if you do, S3D doesn't prepend its own temperature commands, but instead lets your script handle it. That's contrary to what the tooltip says when you let the mouse sit over the field for the script. Try this script instead of just your 5 lines (it includes your lines):
M140 S[bed0_temperature] T0 ; Start heating bed
M190 S[bed0_temperature] T0 ; Heat bed and wait for temperature to stabilize
M104 S[extruder0_temperature] T0 ; Start heating right extruder
M109 S[extruder0_temperature] T0 ; Heat right extruder and wait for temp to stabilize
G28
G1 Z0.25
G92 E0
G1 X100 E10 F600
M201 X1000 Y1000
Given the problems you are trying to solve, this is probably not going to fix anything but if you are going to go to the trouble of issuing the sequence M140, M190, M104, M109 it would be better to do M140, M104, M190, M109 to overlap the heating. Otherwise, the simpler M190, M109 gives identical results.
Also, beds normally do not have tools so adding T0 to the M140 and M190 probably isn't needed (and I don't know if it hurts).
@b-morgan I don't think the tool argument is hurting anything, as I'm pretty sure I have it on my printers from the same manufacturer, but if it works without it, might as well omit it 
I always assumed it was intentionally available as an argument, since you could have a multi-segment heated bed, where you might only want to heat a smaller section when you weren't using it all, or when you were only using tools that rode over that section.
@Charles_Haddock So, what exactly is the solution to this? I am running into the same issue and it is driving me crazy. As soon as I hit print the extruder just goes. Doesn't even wait for the bed temp to START to rise.
I'm guessing that the fix is to add this to your OctoPrint Gcode start script before print job starts. Note my follow-up comment that the very end of that should probably have another G92 E0, however.