- User Since
- Jun 9 2015, 1:10 PM (98 w, 1 d)
Jan 11 2017
Aha! So there the geometry of this model needs fixing. The face at the bottom of the inner hexagon is pointing the wrong direction (up instead of down). Cura does not make this obviously apparent, but here is how to tell. This surface appears red when using the overhang view, meaning that it is upside down.
Jan 10 2017
Sorry for my mis-diagnosis. I clearly do not understand what the real problem is. Could you describe in more detail? Is there a tangible or recent example that you can explain?
Yeah, go ahead and post the .stl. It would also help to have a photo of the printed part, so we can easily see the discrepancy. You can upload files/pictures by dragging them into the comment text box on this page.
Hey, no worries! Thanks for actually reporting back on the root cause. Hopefully your post saves someone lots of headache in the future :)
At this point I'd suggest using the same version of Cura on both systems. You are certainly allowed to use Cura v19.12, but newer versions fix a multitude of issues and have significantly improved profiles. FYI v21.03 was just released last week.
Yes, you have made it to the right place.
For this type of problem I recommend that you contact our support department directly as they will have a much faster response time. Phone and email contacts are listed in the right side column of this page https://www.lulzbot.com/support
Jan 9 2017
The basic conversion has already been done for one material (Polylite PLA) https://code.alephobjects.com/source/Cura2/browse/master/resources/quality/lulzbot_taz6/taz6-pla.inst.cfg It prints at comparable or slightly better quality than the existing Legacy Cura profiles, tested on Mini and TAZ 6.
Jan 5 2017
Jan 4 2017
Thanks for the screen-shots, those temperature graphs all seem fine.
Jan 3 2017
Hi there and thanks for the detailed bug report!
Dec 30 2016
Since you are running a TAZ, I would recommend running print jobs via SD card. Though not as convenient as direct USB, it should be more reliable and side step this immediate issue.
Dec 29 2016
That seems to have fixed it
Dec 28 2016
Dec 27 2016
Sounds reasonable to me, going to mark this task complete.
I'll need to get a few more details to help figure out exactly what the problem is. Could you provide the following information?
Let's go for the statically linked option.
OK, going to abandon this feature due to being unfeasible.
Dec 23 2016
Can you explain a bit more why you think OS protection is not needed?
If we ignore this item, is there anything remaining to do for this task?
CJ, do you experience this in your test environment? Any ideas?
Hmm, this is starting to look unattainable.
Do you have any other ideas or options to try?
Dec 22 2016
Dec 20 2016
Try some more experimentation and see what you can figure out...
You might simplify things and prototype a little script. Something like this:
device = '/dev/ttyACM0' put lock on device connect to device wait indefinitely
Then invoke it from two different terminals to test what happens.
Would it be possible to do something like this?