Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Onboard Cura slicer problem with cura ini import #1708

Closed
sundansx opened this issue Jan 12, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@sundansx
Copy link

commented Jan 12, 2017

What were you doing?

slicing an stl using the onboard cura engine.

What did you expect to happen?

cura engine was supposed to use my start.gcode and end.gcode to compensate for my printer type as described in the cura ini file. I have included several files that show the problem and may be used to reproduce this.
Cura_StandardQidiPLARightExtAstroTry4.ini - this is the profile that I made in cura engine 15.04 on Win10. If I use this profile in Cura Engine desktop applicaiton 15.04, and upload the resulting gcode to octoprint, the object prints fine, and the gcode looks like I would expect with the specified gcode startup.
cura_standardqidiplarightextastrotry4.profile octoprint profile from /home/pi/.octoprint/slicingProfiles/cura on rpi running octoprint. This was the result of importing the included ini file. It has some bizzare formatting and gcode included that was not in the original file.
M12_mount_raspi_V2.stl - the original stl file
M12_mount_raspi_V2.gco - gcode output from octoprint embedded cura slicer using included ini
M12_mount_raspi_DesktopCura1504.gcode - gcode output from desktop 15.04 slicer using same .ini
**various jpgs
** showing profile and printer settings.

What happened instead?

it did not include those gcodes and made a starup of its own from somewhere

Branch & Commit or Version of OctoPrint

Version: 1.3.0 (master branch)

Printer model & used firmware incl. version

Qidi Tech 1, sailfish 7.8 (new printer)

Browser and Version of Browser, Operating System running Browser

Firefox latest, Win10

Link to octoprint.log

included in attached zip file

Link to contents of terminal tab or serial.log

not printing yet..

Link to contents of Javascript console in the browser

NA?

Screenshot(s) showing the problem:

Including screenshots and other files from above
I have read the FAQ.
CuraProblem.zip

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 12, 2017

You've configured your printer profile in OctoPrint as having two extruders but haven't defined any start or end code in Cura for prints in dual extruder configuration:

start2.gcode = 
end2.gcode = 

My guess is that your Cura Desktop profile is set up with one extruder because it's using the custom start.gcode there just fine, could you check this please?

For reference, available gcode scripts editable in Cura for two extruders:

image

vs just one in the machine settings:

image

Extruder count in the machine settings:

image

OctoPrint takes the settings from your OctoPrint printer profile since they are not contained in Cura's slicing profile export. Your extruder count needs to match (or your start code needs to be set correctly for all possible extruder counts you want your slicing profile to work with). If OctoPrint (or Cura Desktop for that matter, the implementation here is identical) does find an empty start code/a start code without at least temperature commands it generates a stock one that should at least take care of properly heating up. That's what you saw since start2.gcode is empty in your profile and you told OctoPrint (and hence CuraEngine) that you have two extruders.

Just for reference, here's your slicing profile imported in OctoPrint, slicing an STL for a printer profile with just one extruder:

;Generated from plate.stl 73513e04b7365bb3b9ec5399be14a71882f83fb5
;Generated with Cura_SteamEngine 14.07
T0; set primary extruder
M73 P0; enable show build progress
M140 S40 T0
M134 T0 ; stabilize bed temperature
M104 S220 T0
M133 T0 ; stabilize extruder temperature
G21; set units to mm
G162 X Y F6000; home XY axes maximum
G161 Z F1100
G92 X0 Y0 Z0 A0 B0 ; temporarily define this as origin
G1 Z5
G161 Z F300
M132 X Y Z ; recall home offsets
G90; set positioning to absolute
G1 Z30; move Z to waiting height
G1 X-95 Y-73 Z30 F6000; move to waiting position (front left corner of print bed)
M6 T0; wait for bed and extruder to heat up
M108 T0 R3; set extruder speed
G92 E0; set E to 0
G90; use absolute coordinates
M320; acceleration enabled for all commands that follow
G1 Z0.2 F6000.000; move to first layer height
G1 X100 Y-73 F14000.000; move to front right corner of bed
G1 X-90 Y-73 E24 F2000.000; extrude a line of filament across the front edge of the bed
G4 P2000; wait for ooze to slow
G1 Z0 F6000.000; lower nozzle height to 0
G1 X-95; wipe nozzle
G1 Z0.2 F6000.000; set nozzle to first layer height
G1 F12000; ensure fast travel to first print move
G92 E0; set E to 0 again
M73 P0; reset build progress to 0
;Layer count: 17
;LAYER:0
M107

It has some bizzare formatting and gcode included that was not in the original file

That "bizarre formatting" is due to how the profile data format works. Multiline strings in YAML (which it is) require double spacing for actual line breaks. The additional gcode definitions you see in the generated .profile are default start and end codes that Cura Desktop itself also generates internally and are for multi extruder setups (first gcode is used for one, second for two, etc, up to four). Since OctoPrint doesn't know how many extruders you will want to use this with, it generates the stock values Cura uses internally into the converted profile.

@sundansx

This comment has been minimized.

Copy link
Author

commented Jan 12, 2017

Thank you very much for the prompt response. I actually did have cura set to 2 extruders, but had removed any start2/end2.gcode to make it simple for me to troubleshoot.
I just now added scripts for the second extruder in cura, and imported the new profile. It now looks to be including my code, and now that makes more sense. It also explains why it was not using my nozzle 0 gcode...cura plugin was trying to use nozzle 1 instead of 0. I have included the ini and the gcode output from it..and you can see it is using my second nozzle. A few questions/observations:

  1. How does one change nozzles/extruders in the octoprint gui when slicing so cura plugin uses the correct gcode?
  2. It also looks like cura plugin might be confused...In the gcode output it starts with the gcode below. As you can see, it slips some of its own code in there at first for setting the temps and extruder (T0) then it appears to use the start2.gcode instead of start.gcode. Any idea what is happening there?
  3. How can I stop cura plugin from injecting its own minimal gcode in the beginning and end of the gcode sequence?
    Thanks again for your generosity.
;Generated from M12_mount_raspi_V2.stl a4e03fde267b5c4878f4aaa5972759cd89263b44
;Generated with Cura_SteamEngine 15.04
M104 T1 S220.0
M109 T0 S220.0
M109 T1 S220.0
T0
T1; set primary extruder
M73 P0; enable show build progress
M140 S40 T0
M134 T0 ; stabilize bed temperature
M104 S?print_temperature2? T1
M133 T1 ; stabilize extruder temperature

M12_mount_raspi_V2.gco-9.txt

Cura_StandardQidiPLARightExtAstroTry6.ini.txt

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 13, 2017

It's not a case of nozzle 0 vs nozzle 1 code, it's more like "If the printer has one extruder, use this snippet of start code, if it has two, use that snippet". So it's irrelevant if you actually are using the second extruder, as long as your printer has two, start2.gcode and end2.gcode will be used.

So you don't need to "change nozzles" in OctoPrint in any way, you just have to make sure that the start code for the number of extruders you've configured (regardless of if you use all of them or not) is properly filled in.

It slips the pre-generated code in there because in your start code it can't find the mentioned {print_temperature} place holder. It looks like your code is using a {print_temperature2} place holder here which a) doesn't get replaced properly and b) doesn't trigger prevention of code generation. That actually looks like a bug in OctoPrint's handling of slicing parameters for multi extruder prints and I'll have to take a look into that.

@foosel foosel added this to the 1.3.1 milestone Jan 13, 2017

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 13, 2017

Correction: Apparently Cura does an analysis of how many extruders are used for a given object after all. Which in all likelihood I'll not be able to do from within OctoPrint due to performance limitations, at least not the same way that Cura itself does. So that makes things tricky.

foosel added a commit that referenced this issue Jan 13, 2017

Cura: Fix selection of which start/end gcode to choose
So far the plugin selected the gcode script corresponding to the number of
extruders configured in the printer profile. After a close look into the
implementation in Cura itself, prompted by #1708, it turns out that this is
in fact wrong.

Cura selects the gcode script to use based on the maximum of the number of
extruders needed for printing the models in the scene and the minimum number
of extruders needed for generating support (if support extruder is "both" or "first"
or there is only one extruder, that's 1, if it's "second" and there is more than one
extruder, it's 2).

This commit changes the plugin's implementation to mirror this implementation.
The difference to Cura is that we have the number of extruders needed for the
models in the scene hard coded to 1 since we only support STL right now which
can never contain more than one object. If we ever decide to support merging of
multiple STLs into one single multi-extruder print or other model files like AMF
or OBJ from OctoPrint's slicer support, we need to change this.
@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 13, 2017

Fixed in the above commit. OctoPrint should now actually behave like Cura and use start.gcode when you slice a file for which only one extruder will be utilized and start2.gcode when it needs 2 extruders and so on. Note that since OctoPrint's Cura integration only supports STL files - which by design can only ever contain one object - and no merging of multiple files into one slice result is possible, that means that in general OctoPrint will now use start.gcode, unless you've specified to use the second extruder for support material in your profile, in which case start2.gcode will be used.

If OctoPrint's slicer support ever gets extended to allow slicing of multi-extrusion files (e.g. multiple joined STLs, OBJs or AMFs), this will have to be changed, but for now it's the only valid approach.

I've also fixed the placeholder handling for printer_parameter2 and similar (that was an off by one error).

Both fixes are already pushed to the maintenance branch, will be merged to devel ASAP and will also be released with 1.3.1.

As an additional side note regarding the automatically generated prefix: OctoPrint (and Cura) will check the provided start code for the {print_temperature} placeholder corresponding to the extruder count for the print (so {print_temperature} in most cases, {print_temperature2} if support is set to the second extruder and a second extruder actually does exist). If that is not found, the necessary temperature lines will be generated. Same goes for {print_bed_temperature} if the printer profile has a bed configured. So if you don't want a prefix to be generated in either OctoPrint or Cura, make sure your custom start code contains all required temperature placeholders.

@sundansx

This comment has been minimized.

Copy link
Author

commented Feb 6, 2017

Wanted to follow up: This issue seems to be fixed in the new release. Thanks for your support

@StevenBruinen

This comment has been minimized.

Copy link

commented May 2, 2018

How should I configure my ini files to prevent the adding of extruder temperature gcode in the sliced file?

In OctoPrint's printer profile I configured 2 extruders. But when I want to use only 1 for a print it still adds gcode to set the temperature for the 2nd extruder. For example I've sliced a simple XYZ calibration cube:

;Generated from xyzCalibration_cube.tmp.1525278632258.stl505ccd9b89060a2383faaf0533ce02b27524a196
;Generated with Cura_SteamEngine 15.04.6

M140 S50.0
M104 T1 S220.0
M109 T0 S220.0
M109 T1 S220.0
T0
M190 S50.0
[...] 
M104 T0 S?print_temperature

Why is this temperature setting for T1 also added to the gcode file generated?

I've confgured my ini file like this:

start.gcode = 
[...]
	M104 T0 S?print_temperature?
end.gcode = 
[...]
	M104 T0 S0

start2.gcode = 
[...]
	M104 T0 S?print_temperature?
	M104 T1 S?print_temperature2?

end2.gcode =
[...]
	M104 T0 S0
	M104 T1 S0

`
(I'm running the latest version of OctoPrint with all updates installed.)

@renevaessen

This comment has been minimized.

Copy link

commented May 12, 2018

Is there some documentation somewhere of which settings in the profile are related to dual extrusion.
For instance;

how to setup the slicer to use the second extruder for support material?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.