- User Since
- Jul 26 2017, 1:13 PM (86 w, 1 d)
Fri, Mar 8
You can close this task (I don't believe I can).
Fri, Feb 22
I have opened a Marlin issue, 13228, as this probably should be fixed in the core Marlin firmware.
Thu, Feb 21
Jan 11 2019
I have a TAZ 6 so I can't actually test it but a manual inspection of the .gcode looks good to me.
@DRobertson, could you please post the .gcode? The .stl would also be useful.
Jan 9 2019
Unless there is a task to remove G20 and G21 from the start GCODE, this task should not be closed until that work is completed.
Dec 25 2018
Dec 24 2018
Here's the bug fixed version:
I think there is a bug in the script when used a second (and third, etc.) times. I'm looking into it now and will post a revised version when I find and fix the bug!
Dec 18 2018
Sep 18 2018
I have looked at it but have not tested it yet. I'll let you know if I find any issues.
Aug 10 2018
I did not do the same experiment with 1.1.8 but I have been using the released versions of the firmware without incident. Is there something specific about 1.1.9 you would like tested?
Jun 14 2018
If you take into account that the end gcode retracts the filament quite a bit then the purge should be enough to actually have filament at the nozzle when you start your next print. I think I upped my personal purge value(s) to G92 E-25.
@karrad Thanks for the extra screenshot. Looks good to me but I'll download 3.2.22 and take a look after my current (long) print job is finished.
Did you do anything about the placement when the "Cancel" button is displayed? "Cancel" is shown while slicing is active (after the "Prepare" button is pressed and before the "Save to file" is shown.
Jun 12 2018
The Dual V2 start gcode in 3.2.21 still has some issues with the E values.
It still isn't fixed in 3.2.21
This task can be closed. Recent versions of CuraLE have the correct nozzle diameter
Jun 8 2018
May 15 2018
May 3 2018
Then I humbly submit that "All" should be "Supported" and perhaps "Experimental" should be "Third-party" or "Other" or "Unsupported".
I believe T2497 may be a separate issue from naming and classification as I don't see anything in the material definitions that controls what categories are included when the user selects "All".
Apr 19 2018
Changing the line width to .34 did not help.
These exact same profile settings have been slicing numerous other parts all week.
@alexei : The line width equals the nozzle size (.35 line width, .35 nozzle in the printer that fails).
I have 5 TAZ 6 printers defined. A Single Extruder V2.1 with a .5 nozzle, one with a .35 nozzle, one with a Dual Extruder V2, one with a Dual Extruder V3, and one with an Aerostruder. I have another Single Extruder V2.1 with a .2 nozzle but I haven't printed any parts with it under CuraLE 3.2. My AppData folders are clean 3.2 folders created around 3.2.11 timeframe.
PolyLite PLA (Polymaker). I think this is the profile settings you need (how do I get a text output of these setting changes?):
Windows 10 Pro (64-bit), 32GB ram. LulzBot TAZ 6, Single Extruder V2.1 with a .35 nozzle. PLA with a layer height of .2 (initial .4), 100% infil, no supports, skirt. Log file:
Apr 18 2018
Apr 13 2018
If I change to hotend 2 to print the skirt/brim/raft, CuraLE retracts hotend 1 at the beginning of the print. If hotend 1 prints the skirt/brim/raft, CuraLE does not retract hotend 2 at the beginning of the print.
I'm most concerned about the retract but this also applies to standby temperatures and anything else that CuraLE does on a tool change.
Apr 8 2018
Something is screwy with CuraLE 3.2.14. If I look at Preferences, Materials the settings there are way different than what was loaded into Extruder 2.
Apr 4 2018
In case you didn't notice, I added code to capture the "current temperature" and use that when appropriate instead of trying to resume a print with a 0 temperature. This should fix T2257.
Apr 1 2018
Mar 29 2018
The attached .zip file contains a slightly modified TweakAtZ.py (check for ";LAYER=0" before tweaking to avoid tweaking the start gcode) and a working (better) version of PauseAtHeightorLayer.py. IMO, this can replace PauseAtHeight.py if you (change the name references in the code and) accept that it fixes bugs as well as adds pausing by layer number.
After changing my method of examining the .gcode output, the plugin is working however it is inserting its command(s) more than one level away from where it should be. This is something I might be able to fix. Stay tuned...
Mar 28 2018
@marcio : Good point. I would vote for X100 Y300 (plus or minus if necessary). That will dump the filament onto the "floor" or into the same tray that I'm using for catching the purge filament (see my previous post image).
Mar 24 2018
See T2205 for an already written Pause at Height or Layer plugin.
Can we get either a Pause at Layer plugin or modify the current Pause at Height to allow either layer or height as input for CuraLE 3.2, please?
Mar 22 2018
How about right here?
Alternate location for the "park", X100 Y300. Instead of spitting out filament onto working parts of the bed, put it on the "floor". Another catch tray needed to assist in the cleanup.
22.214.171.124 will have to do :-)
Mar 21 2018
The more I use Change Filament from the LCD, the more I think there should be an additional choice on each step to "Cancel" ("Resume Print" might work, I haven't tried a "Change Filament" in the middle of a print job).
Mar 19 2018
You win! Change Filament is there above 120 degrees C and disappears below 120 degrees C. I guess I had a senior moment.
@marcio : What I didn't say is that because I was using the Movement LCD menu to retract and extrude filament, I must have been at or above minimum extrusion temperature. In either case, I still double check and get back to you.
I'll double check but if I remember the conditions that caused me to create this task, I was using the Movement menu to retract the filament and at a certain point, the filament had elongated and no longer in contact with the hob bolt. I then remembered using the Change Filament entry before (with other toolheads) which has a more robust retraction rate so I ran the filament back into the nozzle and then went to look for Change Filament.
I'd be happy to give it a try but I need a pointer! I know you may have given me a pointer to a previous version before, but a 68 years old, my memory isn't as sharp as it used to be!
Mar 18 2018
Mar 17 2018
Jan 22 2018
I successfully printed a dual color 3DBenchy in 3 hours, 39 minutes through OctoPrint with 126.96.36.199. The prime tower fell over about 85% of the way through the print but the ooze shield was 98% successful in protecting the last part of the print.
Yes, I can test 188.8.131.52 as long as you provide a pointer, lol.
Jan 16 2018
An option to try might be to modify the firmware of a printer you do have to "fake" a multiple extruder auto temperature report like @marcio documented in the post referenced above. I created a version of firmware with the fake reporting of a second extruder but the resulting string was still shorter than the actual two extruder string and it did not fail so I'd suggest faking three extruders which should be long enough. I can try that if you would like.
Jan 15 2018
I have opened an issue against OctoPrint (https://github.com/foosel/OctoPrint/issues/2370)
Jan 12 2018
I did a print with your firmware (184.108.40.206) with the delay inserted and it completed successfully.
Jan 11 2018
First you have to have a (repeatable) failure before you can determine if you have a fix! I'll try that firmware next.
I ran two 3DBenchy prints (about 2 hours each) with my "extended auto temperature report" firmware and OctoPrint setup with M155 S1 without a failure.
Jan 9 2018
Success (at least with building and uploading a firmware version)! OctoPrint doesn't mind the longer temperature report so I've started a 3DBenchy and we will see what happens...
One more stupid question... I went to this URL, https://code.alephobjects.com/diffusion/MARLIN/repository/devel/ and I did a git clone of https://code.alephobjects.com/diffusion/MARLIN/marlin.git. If I browse the repository from my browser, Conditionals_LulzBot.h contains:
Stupid question... In Arduino 1.8.3, I do a Sketch, Export compiled Binary and I get two .hex files, Marlin.ino.mega.hex (406 KB) and Marlin.ino.with_bootloader.mega.hex (417 KB). Since neither one of them matches the size of Marlin_TAZ6_SingleExtruder_220.127.116.11_6353ccb.hex (409 KB) I'm not sure which one to use. Can you help?
Can I setup a build environment on my Windows 10 Professional (64-bit)? with the Ubuntu Linux stuff? On a LinuxMint system?
If you set the pin numbers for the second extruder to be the same as the single (first) extruder, could you run that hacked firmware with a single extruder attached?
@marcio : My dual extruder is on its way to Loveland for a warranty repair. Should arrive by end of today. Since I can't get the single extruder to fail, we will have to wait until mine is repaired and returned to me (or, as I mentioned before, you could send me a V3 to test with, rofl).
From day 1 I've had a Raspberry Pi camera installed. Capture of time lapse movies is turned off, however. Nothing else other than OctoPrint is running.
I'm beginning to believe that the problem only occurs with a dual extruder. I had a failure with a dual color 3DBenchy, but the single color 3DBenchy is printing without a problem (so far). The auto temperature report for a dual extruder is significantly longer than the auto temperature report for a single extruder. I've told OctoPrint to set the auto report to 1s instead of the default of 2s.
OK. I'm not completely convinced but I'll look for a single extruder print that fails with OctoPrint using auto temperature reporting and open a git issue against OctoPrint.
I can't attempt "this" print because it was a dual extruder print and my dual extruder has been returned to the factory for a warranty repair. I'll try and find something that fails with a single extruder.
Dec 27 2017
This was initially reported in T1318.
This problem still exists in Marlin 18.104.22.168
I believe the ERROR lines in the attached .zip file may point to the problem.
Dec 26 2017
The print with "M155 S0" completed successfully (in 4 hours, 10 minutes). I loaded firmware 22.214.171.124, enabled auto temp reporting, and the print failed within the first 10 minutes.
I started a print using 126.96.36.199 but I changed the OctoPrint settings to not request auto temperature reports (M155 S0) but instead to poll using M105. This is a 4+ hour print if it goes to the end. I'll load your 188.8.131.52 after it finishes (or fails), set OctoPrint back to auto reports, and let you know how it goes.
The attached firmware didn't work but it changed the symptom just a bit:
Opps... Missed a message.
Are you still creating some firmware for me to test?
The problem is seen on my TAZ 6 with a Dual Extruder V2.
Marlin 184.108.40.206 exhibits the same problem. Is there a way to capture the serial communications when using Cura 2.6.63 connected to the printer via USB? I'd like to try eliminating OctoPrint but I'd like to search the serial communications for the same pattern as seen in the OctoPrint serial.log.
Dec 25 2017
Dec 19 2017
Dec 6 2017
Thanks for the tip about the lighter color!
Yes, I believe that solves the problem.
Nov 18 2017
Nov 16 2017
Nov 13 2017
2.6.45 (Windows) dated 11/7 02:58 also has no title bar. 2.6.45 downloaded on 11/6 13:01 (MDT) has a title bar.
2.6.46 (Windows) also has no title bar.
Add the "M83" line to the Dual Extruder V2 End Gcode after the "G91" line:
After studying the Marlin sources, I believe that the current E value is not "per extruder" but is "global". Therefore switching nozzles appears to require G92 commands to set the current E value for each nozzle. The Gcode generated for the .stl file seems to bear this theory out, so here is my modified Start Gcode for the Dual Extruder V2: