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.

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

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.

Completed through work done in
3288356bf479a4e84e386c4046ae9e4fced01ff8 to cba48f6dcd771ba27ba900186671473a2af74340

Thanks for the screen-shots, those temperature graphs all seem fine.

Hi there and thanks for the detailed bug report!

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.

That seems to have fixed it

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.

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?

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?