IMPORTANT! Problem with Dual V3 and/or new Cura

I installed the new Dual Extruder V3 and Cura 2.6.52 yesterday. I had a couple of issues I’ll list later. The most critical issue is that either the firmware or the software is screwing up and will jam the head. I haven’t found any specific reason for it and am not able to reproduce on demand, but it will reproduce itself when I’m not paying attention.

First, I printed the test gears per the instructions without any problems. I then load esun PLA+ in the left and esun PVA in the right. I printed a job without any issues ( except the ones trying to find the correct settings, which I’m not going to get into right now). After the job finished I cleared the bed and loaded the next file. I walked away and heard a bad grinding noise. Ran back and shut off the machine. The nozzle had decided to perform a clean right on the Z axis mini toggle extension, which jammed the nozzles into the extension and pushed it to the left (away from the bed). I noticed that when you install the extension holder properly you can see slots in the lower cable mount so I put a couple of small wire ties through the slots and around the cable holder to keep the extension holder pressed against the bed.

I started the job and didn’t have any problems. After that I started another job and walked away. Heard a nasty sound again and found the nozzles trying to wipe beyond the new extended wiper pad. In other words, when the job starts, the nozzles should move to the beginning of the pad and then wipe along the length of it. For some reason the nozzles had moved to the middle of the pad to start and was moving across the plastic pad holder at the end. Got everything set back up and restarted the job. It started to jam again on the z axis extension holder. This time I figured I’d shut off everything, restart, home the machine, and restart the job. After that it printed fine.

I then started the next print job. This time I figured that even thought the machine was still on and connected I would home the axis before beginning, just in case it was losing it’s position. I then started the job. After heating the print heads to begin a wipe, instead of moving along the y axis to the pad, it immediately moved down (z-) and start wiping into the z axis extension, which broke the extension holder after pulling the metal extension out of the holder. I stopped everything, then restarted. This time I started the job with my finger on the power button just in case. The print job started fine. I’ll have to print another extension holder.

So, something is causing the firmware or software to lose track of where it is and what it’s doing. That means I have to start every job with my finger on the power button just in case. So far it’s either jammed against the z axis extension holder, or against the extended wiper pad.

For those other issues I had. The Dual V3 backplate is too short. When I installed it and seated it in the mount, the screw couldn’t be installed since the screw slot was too low. I raised the head and installed the screw but it’s not mounted firmly against the holder at the bottom. I’ll have to extend the screw slot for it to seat properly.

I also have a problem installing and removing filament. To install I cut the filament end at an angle then play with it until it goes in properly. It’s annoying, but it works. To remove it I heat the nozzles up and use extract command. The instructions say to turn the gears by hand but that only works if you turn the motors off. The new idler springs aren’t easy to use so it’s a bit easier to use extrude and retract to move the filament once it’s inserted far enough for the hobbed screw to catch.

The new Cura has a LOT of options, which can be extremely confusing for a newbie like me. I also haven’t figured out how to add a new material profile since the new profiles are xml instead of ini now and I haven’t found any decent instructions yet which tell me how to create my own materials. I have to just alter the profiles which are already there. (There is a “create” button under materials but when I push it nothing happens. Does this mean I have to make changes to a current material and then create? I have no clue and haven’t had time to play yet.)

This almost sounds like the missing commands issue I was seeing. If you miss a relative to absolute command for example I could see some of this occurring. Are you printing over USB, from the SD card, octoprint, or something else?

I’m glad you posted your issues. I hope they get addressed by Lulzbot quickly.
I was going to buy the v3 dual head and modular print bed system for Taz 6, but now I think i’ll wait for the bugs to be worked out. I had a hard time with the flexydually.

Printing is through USB from Windows 7, HP laptop. This is the same laptop I used for the previous version of Cura, and through Vectric Aspire to a CNC Shark Pro Plus, and through Mach 3 to an Ethernet Smoothstepper to a custom CNC 7x14 mini lathe. Not at the same time obviously. :slight_smile: The only thing this laptop isn’t controlling is my CNC milling machine which has a dedicated Windows XP system, since I’m too lazy to upgrade it right now.

I just kicked off another print job this morning. I loaded the file, turned on the Taz, "Connect"ed it. “Home All”. Started the print. Everything appears to be working fine at the moment. Just using one extruder at the moment. Will try both again on a later print job.

Another update. Last job printed fine. I then changed filament to ABS in 1 and none in 2. I loaded the z axis extension mount file (the one that got broken from the previous crashes). Then I homed the printer “Home All”. Then I clicked “Start Print”. The printer homed again including z axis, then raised it’s temp to 175. It immediately went forward just enough to miss the metal part of the z axis extension then did a down (-z) into the mount breaking it even more. I turned off the system, turned it on, raised the z axis, homed it again. disconnected Cura, then connected again, then homed the system again, then started the print again. This time when temp got to 175 it went straight down into the metal extension hard enough to start bending the bed y axis travel rods. Turned off the printer, redid everything, again, then started the print job again, and it did the wipe properly and started the print job. There is no reason that I can find that the printer should be doing what it’s doing. I do the same thing every time to get ready to print. Looks like I going to have to go back to single extruder and old version of Cura. I’m concerned that something else might get broken worse if this continues.

Early adopters… Thanks for you service.

Lulzbot should cover your expenses, for beta testing :smiley:

Hello JohnMGray,

We do apologize about the troubles you are having and appreciate your feedback. Please reach out to our tech support team at or +1 970-377-1111 for help with the New V3 tool head.

Latest update. I’ve narrowed it down to Marlin firmware version Unfortunately that’s the firmware which is needed to run the Dual Extruder V3. The basic problem is that when I first turn on the printer and run a print job, it appears to run fine. If I start a second print job it screws up within the first 35 or so lines of the start file gcode, but not always exactly the same spot. It doesn’t matter if the first job completed successfully or was cancelled, or if I home the printer before the second job or not, or if I use Cura or the SD card directly.

As a temp fix I’m going to try a few print jobs today by turning off the printer between jobs so memory gets cleared. I’ll give you all an update.

OK, temporary fix if you have this problem. Turn off the printer and turn back on between print jobs. If using Cura, then “Disconnect”, turn off printer, turn on printer, “Connect”. It should start the next print job without crashing.

The development site has been busy, quite a few fw revisions. There is a that is up now. I’ll try whatever the latest is this weekend. I may end up modifying it for a filament sensor given the load difficulty until I have time to figure out how I want to modify it to help that.

I just had an interesting conversation with someone at Aleph Objects / Lulzbot tech support (I won’t mention any names). First off, let’s see their response email for all my troubleshooting so far…

I am glad that restarting between prints seems to be working. We will be taking a look at this issue for our next version of Cura.

As an aside Cura LE does have some problems if the cache is not cleared, and it sounds like this issue may be related to the cache. Instructions on clearing the cache can be found here: under “Upgrading from Beta Cura Lulzbot Edition?”

Just so people don’t think I’m being too hard on their tech support… I’m a retired Senior Systems, Software, and Security Engineer / I.T. Manager with over 40 years of software, hardware and security engineering experience (including Honeywell mainframes, various midrange servers (Unix, Windows, and others), PCs, and embedded systems (including assembly language coding)), teaching college accredited Computer Science courses to the U.S. Department of Defense (I’m retired Air Force information technology), and experience working tech support issues for both large and small(er) companies such as IBM. I understand what tech support people do, and don’t, know.

Up to this point their tech support and I have been going back and forth with emails, which have been less than helpful on their part, but which is expected of someone at Level 1 tech support.

So, I called tech support about the last email for two reasons: the idea that clearing the Windows cache would help when I specifically said that I confirmed the problem when using just an SD Card (which means no computer attached), and that they would suggest that turning the printer off after every print was an acceptable solution, especially for production shops which run many customer print jobs.

I’m not going to relay the complete conversation word for word here’s some of the things discussed.

Their team is looking at the issue… (Great!)

They’ll see about getting a fix for the next Cura release… (This isn’t a feature request, this is a bug which caused damage to part of my printer, and they don’t consider it a priority?)

The tech support person still strongly believes that the Windows cache is related to the issue… (Really? How? Especially when I confirmed it happens with no computer attached when using only the SD card. I would believe it if Cura was corrupting the gcode being written to the SD Card with “hidden” characters, but considering the first job always prints OK this is not likely the issue.)

They didn’t realize that I had tested it with the SD card with the computer detached… (I thought I made it clear in my emails with tech support, but sometimes I assume people know what I’m talking about or ask me questions if they don’t.)

It can’t be a memory issue since there’s no memory to be corrupted / cleared in the printer… (Really? Never mind the fact that there isn’t a microprocessor / microcontroller in the world that doesn’t need memory or other “temporary” storage if it uses any type of variables or other data that isn’t hard coded (such as custom printer settings or gcode to process), the Rambo card is based on the Atmega 2560 which has 256KB ISP flash memory, 8KB SRAM, 4KB EEPROM and Atmega 32u2 which has 32KB flash, 1K SRAM, 1K EEPROM. )

I’m the only one that has reported this problem… (Yes, I’m the only one who has reported this specific problem… out of a number of people who have reported problems so far with the new Cura/firmware… out of the few people who have purchased the Dual Extruder V3 and which required the new Cura and firmware so far. And if I’m the only one who has the problem then I guess my solution is to return my printer for repair / replacement, or return the Extruder for a refund since it won’t work properly for me?) (NOTE: Tech support had nothing to say when I talked about returning the Extruder.)

I won’t continue with the rest of it, but since I don’t have a lot of experience with the Atmega / Rambo card, is there any pointers / suggestions people can give me with the development environment / software for the Rambo card? It looks like I’ll have to fix the problem myself.

It seems to be a buffering issue with the firmware itself. It takes commands from a serial string, or the sd card into an internal buffer in marlin. When it clears that buffer executing commands, it requests more. For a first step. I plan to try the latest devel firmware this weekend to see if it helps. I was slicing with Simplify3D so this eliminates all cura issues. If it dosnt, ill compare the buffer code to marlin 1.1.6-bugfix and see if a diff shows anything.

Its worth noting there is a new release candidate firmware as of today. so it would seam they are working on the issues in the firmware pretty heavily, even if the support guy dosnt know it.

I think I narrowed the issue down so far. Comments are appreciated especially if I’m barking up the wrong tree, or have a suggestion of which part of the source code I need to concentrate on.

The problem area is related to the symptoms. Cycle power on, the first print job works fine, the subsequent jobs crash. Cycle power off and on and the first print job runs fine again. That leads me to volatile memory (SRAM) which is cleared on power off. The subsequent jobs start but then fail points to something like a memory leak / buffer overrun, full memory, etc. Maybe someone used the heap instead of the stack, such as calling a malloc and not freeing it between jobs (which is why it’s recommended to use the stack which will free itself when no longer needed).

Or it just could be a bad MCU which means a printer repair, but if that’s the case why did it work with the previous firmware?

silent_ninja1 we just submitted our replies at the same time. :smiley:

Were both looking at the same area really as to whats causing it. I was chasing around some of the buffer functions for my cr10s5 firmware last week, adding action commands on m600 to pause octoprint from the printer side so its still a bit fresh in memory.

Still need to modify some of the cad files to ease that filament load though… And I may need cleaning filament now that an atomic pull is pretty much impossible.

I had to use cleaning filament the other day to clear baked in PVA (support filament) from extruder 2. I’m glad I had it on hand.

Good news. Update from Lulzbot support…

[I wanted to update you on this issue. Our software team was able to replicate this issue and is currently looking into it.]

I took the plunge with the Dual V3 on my TAZ5. Overall its working fine… I’m sure AO has put a lot of effort into the instructions on OHAI (seems to be more graphics and gifs). I’m sure a lot of the improvements are through feedback of the community (a big THANKS!). The firmware seems super buggy, and there are some mods required for the TAZ5 (original Juniper) x-carriage guide.

No issues with feeding the filament into the extruder. I try to make sure the angle portion of the chisel tip is pointed up… which positions the tip in the middle of the channel to slip through the extruder.

Also learned to use the gears to move the filament. Get the filament into the idler then let it clamp down and use the gears to move the filament. Make sure to turn “Motors off” if swapping mid-print.

No issues with the level of the nozzles. I used the right z-lead screw to fine tune T1… clockwise to raise.

The firmware is my biggest headache so far, specifically communicating with Octoprint. The basic problem is generating “Unhandled Errors” which stops the print in place. The unreliability of the communications is hazardous… it leaves the nozzle on the part, extruders at temp and bed on. Kills the “remote” aspect of trying to print with Octoprint.

The 1.1.5.xx firmware seems to be locked at 250000 baud… previously I used 115200. That was the initial headache… And I think its

Version which is the “Automatic” flash software in Cura 2 seems to work best after trying the… I even tried my hand at using DualExtruder V2 firmware (see below). I’ve tried different settings in Octoprint and S3D… Just got through a successful 15min print, going to try a second consecutive print for reassurance. Its going to be hard to trust this setup until I can get to the reliability of the Dual V2.

Using the DualExtruder V2 firmware was interesting an experiment, here’s what I found:

  • T1 and T0 are reversed
  • Extrusion is reversed also… A negative extrusion length was required to extrude onto the bed.
    The reverse extrusion was the deal breaker… There might be a way to reverse the extrusion through gcode/slicer, I didn’t keep the firmware on long enough to explore.

Lastly, my TAZ5 X-carriage guide didn’t have the cut-out to accommodate the end-stop sensor on the toolhead. So print the v2 of this x-carriage guide ahead of time… or I had to replace the last M3 socket cap with a M3 button cap, and “fitted” the toolhead on to print the v2 x-carriage guide. It worked, but I managed to strip one of the inserts in my x-carriage… its fine, but once I’ll need to replace once the kinks are worked out of this extruder.

Hope that helps!

Just a quick follow-up regarding the OctoPrint “Unhandled Error Messages”.

Enabling the “Simulate an additional OK for resend requests” seems to increase the reliability of printing. I was able to get through a 3hr print last night… re-trying the same print currently.

Once I get the x-carriage reprinted, I’ll try some dual extrusion prints… right now its either T0 or T1. Anyone have tips on tuning the offsets? I’m thinking its just an X-offset of -13mm.