Jump to content
Ultimaker Community of 3D Printing Experts

bill-havins

Member
  • Content Count

    13
  • Joined

  • Last visited

    Never

Community Reputation

0 Neutral
  1. Please accept my apologies if this has been covered before. I have adapted my Rostock MAX for dual hotend printing. I am using a Rambo 1.1 running a variant of Repetier Firmware 0.83 (adapted for the Rostock MAX). In Cura 14.01 I have discovered an interesting "quirk." As one might imagine, I set up my machine settings including the appropriate offset for my second hotend/extruder (T1). When one sets up a printer with two hotends/extruders Cura automatically offers templates for start/end code. In the start code the Z height is brought to a certain level and then both extruders are "primed." The second extruder (T1) is primed before the first extruder (T0). This leaves the first extruder ready to print when the main body of the g-code executes. Here's the "quirk." If you choose to print a "raft" under your print you would expect the raft to print using the extruder you designated for support material (in my case, T1 - my second extruder). The layers depicted in the GUI indicate that that is exactly what will happen. But that is not what happens when the print actually runs. T0 is used to print the raft. Now, you might think you could simply go into the g-code and insert a few lines of code (three, actually) to cause T1 to print the raft. But that can't be done because of T1's offset - if the raft is printed with T1 the raft print will be "off" by the amount of T1's offset. Oops! So, the moral of the story is, T0 will print the raft in spite of what you see in the GUI. Here's another interesting "need." If one is printing with, say ABS, and using, say, HIPS for support material. The "unified" retraction settings in 14.01 may leave one filament "starved" for material. So far in my experience ABS has seemed to require a greater amount of retraction than HIPS. If you optimize the retraction settings for ABS the HIPS portion of the print will be "starved." So there is a need to strike a compromise that causes some problems. I have tried 14.02_RC5 but it tends to want to hang up and freeze on my Windows 7 64-bit computer. So for now I am running Cura 14.01. Thanks to Daid for all of his hard work! Despite the above I still prefer Cura to other slicers that are available. Bill
  2. Hi, Daid. I have just finished a new PC build based on Windows 7 64-bit. So, I don't know how much of what I've experienced is due to the new PC. When I go into the Start/End Gcode tabs to set things up for my Rostock MAX (Rambo 1.1) the text editor quickly slows and then freezes. This occurs as I attempt to edit what is already there and add new text. As I said, I don't know if this is attributable to my new PC/Windows 7 64-bit or if it is, indeed, a Cura 14.02_RC[n] issue. Thanks so much! Bill
  3. Daid, You got the exaggerated moves (see my posts, aboove) taken care of in 14.02_RC4. I do "see" a "ghost" image in the slices I do (see other posts, above); in one slice it occurred at layer 4. The "ghost" does not appear in the gcode. For now I'm just ignoring it. I have not attempted a print on my dual head Rostock MAX yet - I've just attempted to slice models using the dual head configuration. Thank you for your hard work! Bill
  4. Hi, Daid. Perhaps I was getting a bit too eager. I "uninstalled" RC2 and downloaded and installed 14.02_RC3. The exaggerated travel moves persist when attempting a dual head print. Here is a sample of code (the exaggerated moves are in the 5th line): G0 F5400 X-110.46 Y23.97 G1 F420 X-109.63 Y24.80 E10.41135 G1 F900 E5.91135 G1 Z1.60 G0 F5400 X-7162.27 Y-6927.34 G0 X-98.63 Y3.13 G1 Z1.10 G1 F900 E10.41135 G1 F420 X-96.56 Y3.13 E10.51452 As above, this is for my Rostock MAX fitted with dual heads and controlled by a RAMBo 1.1. Everything works well with 14.01. Good luck with the bug fixes! They are always fun... Bill
  5. This may be a silly question, but here goes. Will "Profiles" developed in 14.01 work with 14.02_RC3? Is it as simple as opening the desired .ini file? Thanks! Bill
  6. It was a dual extrusion print. The extruder 2 offset is set to X: 25.1, Y: -.3.
  7. Hi, Daid. I have been trying out 14.02 this morning and it is generating travel moves that want to take the hotend well off the print bed. I am using your slicer on a Windows 7 dual core computer (i.e., 32 bit). My printer is a dual head Rostock MAX with a RAMBo 1.1 controller. Here are a few lines of gcode from a slice I did this morning; the "extreme" travel move is listed in the 4th line (colored red): G1 F420 X-96.56 Y7.33 E15.61459 G1 F900 E11.11459 G1 Z0.80 G0 F7200 X-6493.01 Y-6289.32 G0 X-82.10 Y-31.31 G1 Z0.30 G1 F900 E15.61459 G1 F420 X-82.10 Y-21.88 E16.32066 I have checked and re-checked machine settings, etc., and they are the same ones that worked reliably with Cura 14.01. Thank you for your great work! Bill
  8. bill-havins

    End Gcode For Rostock MAX in Cura 13.11.2

    Thanks, gadgetfreak. Deleting the configuration string (the last line of the gcode) solved the problem. I am now using Cura 14.01 for all slicing tasks and it is performing well. I really appreciate the efficiency of motion it produces (few-to-no unnecessary hotend movements). I have successfully converted my Rostock MAX to a dual extruder configuration and Cura slices models such that they print very well. It would be nice to have the option to "turn off" inclusion of the configuration line in the gcode. But, hey, if that's the only problems I have with Cura it's no big deal. Next week I'll begin printing files using HIPS for support material. I hope things continue to work well. Thank you, Daid, et al. This is a great slicer. Bill
  9. bill-havins

    End Gcode For Rostock MAX in Cura 13.11.2

    Here is an end gcode routine that works well in Slic3r and KISSlicer. I wonder if the problem is a firmware issue? G92 E0; zero extruder G91; incremental mode G1 Z3 E-8 F5000; raise Z and reverse filament G90; absolute mode G28 ; home axes M104 S0 ; turn off temperature M140 S0 The above just doesn't seem to work with Cura. Disappointing. Bill
  10. bill-havins

    End Gcode For Rostock MAX in Cura 13.11.2

    Deleting the "M84" command has no effect on the reported problem. I'm not sure what to try next. Bill
  11. bill-havins

    End Gcode For Rostock MAX in Cura 13.11.2

    Thanks for the response. I'll give that a try. I "think" I have already tried the end gcode without the "M84" and got similar behavior. I'll report back later today. Thanks again! Bill
  12. Hello to All, I am considering using Cura 13.11.2 as the "preferred" slicer for my Rostock MAX. This most recent version of Cura has some very attractive features and seems to work very well. Bravo! I am having difficulty developing end gcode that works reliably. The "postfix" I am presently using works pretty well, but, after the "G28" is issued (see below) the axes do home, but then begin to step backward very, very slowly. This includes the extruder. The only way I can stop this backward stepping is by turning the printer power off. M104 S0 M140 S0 ; bed heater off G92 E0 ; set extruder position to zero G28 ; home X, Y, and Z axes M84 ; disable stepper motors I would appreciate suggestions for developing better end gcode. Thanks! Bill
×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!