"Print Sequence" "Once at a Time" makes irritating moves at Layer 134 and 147

[ShakieVan]

I tried to print the parts once after another. But at some layers there are some wired moves and all parts at once visible.

CURA 4.3.0 Windows 10 64Bit

"Artillery Sidewinder X1" I can't attach a zip file. it always says "Something went really wrong, and we can’t process that file."

• Set the parts
• Set to "Once at a Time"
• Slice
• show the layers mentioned above

Actual Results wired moves visible

Expected results normal moves

Additional Information

[Ghostkeeper]

I can't attach a zip file. it always says "Something went really wrong, and we can’t process that file."

I've had this with Github before because I have a browser plug-in that blocks connections to different domains by default. Github uploads to Amazon AWS.

[Ghostkeeper]

I think this bug here might be a regression of the old "moves to 0,0" bug that we've had in the past. I can't find the issue any more though among our 4.000 closed tickets...

Do you have a log file of Cura for us?

[ShakieVan]

Ohh, you are right... with chrome (and no plugins) it works. Here is the cura config.

The log is following (if I find where it is) ;)

Once_at_a_Time.zip

[ShakieVan]

Where to find the log file?

[Ghostkeeper]

Instructions to find the log file are here: https://github.com/Ultimaker/Cura#logging-issues For you it'll be at C:\Users\<Shakie>\AppData\roaming\cura.

I can't use that 3MF file of yours since you seem to have installed a printer called Artillery Sidewinder (or somesuch) that is not by default in Cura. I don't have the mod files that you installed.

[ShakieVan]

cura.log Artillery_Cura_Profiles_v2.1.zip

[Ghostkeeper]

Hmm, that's weird. If I load that zip file for Artillery profiles then I can load your 3MF file. But I'm not seeing any irritating moves anywhere. Here's a screenshot:

There is only one line from the origin. This is the travel move from the starting location to the first object.

Maybe it was a rendering glitch? Does the problem also exhibit in the g-code or is it only in the layer view?

[Lieste]

I am not the OP, but I saw a BL touch probe casualty during unsupervised printing this evening. It was the third of three parts, and during the brim printing of this third part a large travel move was made through an existing printed object, displacing the entire glass bed of an Ender 5 Plus around 1cm, and folding the probe completely along the bottom of the probe housing. The part completed printing with a displaced second half of the brim, because of the displaced bed position.

The direction of the move isn't something I know yet, but the bed movement was a rotation and shift away from the right rear towards counter-clockwise and towards the front left. (I have to wait for the current print task to complete to inspect the executed g-code, but something akin to the OP's report looks probable).

I will update with images/files once I have been able to check the requested movements.

[Lieste]

I didn't see the erroneous moves in the g-code, but on slicing another set of models (2 x A9 cruiser tanks at 1:72), I get all parts printed, then a set of back and forth movements near the end of the project from the right rear, through the centre of the print to the front left, through the middle model on the bed...

Layer 1032-1049+ all show this error... but the 'bad' pathing isn't shown on the all-layers view, only when looked at layer per layer. The model printed first is the one which 'jumps' on the bed. Perhaps ensuring that this is the one at the front left, rather than right rear would reduce the risk to the printer as a minimum effort to resolve this?

Can't get the files to upload into this post. But the LOG file seems to have a line reporting a WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [398]: file:///C:/Program Files/Ultimaker Cura 4.5/resources/qml/ActionButton.qml:79:9: QML Label: Binding loop detected for property "width" INFO - [MainThread] SimulationView.SimulationView.calculateMaxLayers [401]: Min thickness can't be calculated because all the values are zero

Plus two Deprecation warnings I can see.

C:\Program Files\Ultimaker Cura 4.5\plugins\CuraEngineBackend\ProcessSlicedLayersJob.py:139: DeprecationWarning: The binary mode of fromstring is deprecated, as it behaves surprisingly on unicode inputs. Use frombuffer instead line_types = numpy.fromstring(polygon.line_type, dtype = "u1") # Convert bytearray to numpy array

C:\Program Files\Ultimaker Cura 4.5\plugins\SliceInfoPlugin\SliceInfo.py:150: DeprecationWarning: <function GlobalStack.extruders at 0x0000014B7E56E510> is deprecated (since 4.4): Please use extruderList instead. extruders = list(global_stack.extruders.values())

I note that I sliced this project (53.53... seconds) but between slicing and saving the project for forwarding there is a second small slicing recorded that I don't recall requesting and isn't consistent with the project size and the time it takes... of 5.14 seconds. Immediately before the info message shown above.

[Ghostkeeper]

Those warnings are quite common (sadly) but harmless:

• The QML binding loop means that some width in one of the buttons got set to 0.
• The calculateMaxLayers is a transient warning about a calculation being done on layer view before there is a layer view.
• The numpy array is something we wrote before they deprecated it. It still functions fine as far as I've seen.
• The extruderList is something we deprecated but didn't fix throughout our own code base everywhere. It still functions correctly but is more verbose than necessary.

I don't know what that extra slice that you saw could be. Cura restarts CuraEngine in the background after every slice, but then you shouldn't see a total slice duration since it doesn't actually slice yet.

The order should be optimised according to the information that Cura has about your print head's shape. Is the print head shape correct in your printer's definition files? What printer is it?

[Lieste]

The spurious travel moves/extrusions only showed when in a subset of the layer view, they don't show (unlike all other moves/extrusions) when the entire stack is displayed. If looking for examples of this make sure to do so by traversing a single layer through the stack of layers, not just looking at the whole print.

My Head definitions are correct (to within a mm or so of the measured values) as far as I know, and the printer is an Ender 5 Plus (where I added the measured values as by default they are all zero). Gantry height is 25mm, and the others give a border within Cura which looks to be appropriate in scale to the head bulk.

What happens in the print is that one object placed on the bed is linked to the front left corner and will travel to it regardless of whatever else is on the bed already. I was able to move the model which I mention above and swap it for it's copy, and the travel moves still originate from the same model, but in a way which only self-intersects, rather than striking other models.

I should look into uploading the project and log file for examination, but this is also something I can generate and/or find on each attempt to use print one at a time. I am currently not attempting to print in this mode as it is broken in a way which endangers the printer physically (the BL touch casualty was repairable, but it could have broken while being straightened).

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.