Cuq

You can delete the folder of the plugin one by one to find the faulty plugin . In Users\AppData\Roaming\cura\5.X\plugins Or look in the Log File if a message gives you a clue on the issue.

I understand the difference between : Support Placement : Everywhere + Rest placement : Force Only BuildPlate & Support Placement : Touching BuildPlate But Force Only BuildPlate Should be define as Use BuildPlate as possible Note : Cura Alpha 5.4

Oui de mettre ton cas/exemple en pièce jointe ... Parce que sinon ca marche.

https://marlinfw.org/docs/gcode/G004.html G04 S60

Please give more informations (Cura release/Script release, Printer, Sample Cura project) .

Most of the time it takes 10 days from submission to potential validation. But it can take much longer. In some cases I've had over a month, depending on resources and the versions of Cura being finalized. At the moment, we're talking about a month.

Theoretically it's possible, but there are several messages here from users who are experiencing problems with pellet extruders. The main difference on these machines is that it's not possible to manage wire retract to avoid oozing. So the question is often how to manage this non-retract. I've seen several requests about the possibility of managing G0, with a systematic Z hop or different speeds or combine with Zhop. It's up to you to see what you need to use this type of printer.

Plugin DotGWriter ? https://github.com/TheGeb/FlashForge-Creator-Pro-2-Cura/tree/main/plugin source code/DotGWriter

Well, it depends: If we talk about printing order, there are two different needs. One is often in One at Time mode where you want to control the order and position of the part to avoid collisions with the Z axis or displacements for part with similar size. In this case we can solve the problem. In the second case, we want to have a specific order, for example, to make the small parts first because they do not interfere with the printing process and then launch the largest part at the end of the printing process. In this case it's more complicated because the order of the list will define the printing order. In this case one of the solutions (of Workaround if you prefer) is to save the models to be made first in a project (3mf file) and the others in a second project. Then you open the 3mf file of the parts to be print at the end, and import in this project the first element as model. In this way your modifications, support and other specific parameters defined for every models are preserved and the order is defined. I rarely use the One At Time mode, but if I had this problem and had to reorganize my objects oftently, I think a Macro or a Plugin could automate this process.

In version 5.3 (maybe it has changed since the previous versions), the printing order is different if you are in the mode : All At Once or One at a Time In the One At Time mode, Cura uses the reverse order of the objects list to print the parts. In this mode you can define the position of the parts on the bed to organize the printing according to the position you want. In the All at Once mode, it starts (for a square bed) from the first part in front of the bed on the Left and the following order will be based on the shortest distance between the parts. In this case it is difficult to define an order of printing except to arrange the parts with a distance which imposes the order of creation. But it is very complicated.

Use a modification cube, with 0% infill, 0 contour . You will have no print inside this cube and the layers before the cube will be considered as top layers.

You are right ... files are not supposed to be necessarily store in a folder by printer reference. They can be in the same directory by definition type (quality, variant , extruder ... ) so name must be uniq

For me there is no problem just a misunderstanding of the concept of origin and origin offset on CNC machine. By using the origin setting in the center of the bed in Cura the problem should not exist. But since I still didn't really understand what was wrong with the Cura coordinate system question, maybe I have a wrong idea of the problem.

You can try with : node.getWorldTransformation().getData() But not sure you get what you want . In this case it's the Transformation comming from the 3mf file, With a Stl As you have notice it will gives you : [1. 0. 0. 0.] [0. 1. 0. (height/2)] [0. 0. 1. 0.] [0. 0. 0. 1.] You can Also Try SuperSlicer As Free Source Code . It already integrate a Slicer + an integrated Function to generate the milling Toolpath : Again not exactly your request but a good start for this type of project with some interesting option like the milling_extra_size to add some material to the shape to be sure to get enough material to be milled ..

https://github.com/Ultimaker/Cura/wiki/Profiles-&-Settings And you can use the Profile analyser plugin to analyse how the settings are defined and at witch level in your current configuration

In 4.X Nozzle Diameter had a very small influence on the final result. With the version 5.X there are a few more parameters that depend on this value. See another post : To get the Printer Settings you need to Install the Printer settings Plugin.

As you have change via the menu the nozzle diameter is now correct in the "Printer Settings".

Don't see the problem. You just need to create a mypredator.def.json and mypredator_extruder_0.json files in your local folders and rename the name into "My Anycubic Predator" Don't forget to create in your local Quality folder the mypredator_*.inst.cfg files.

Yes wait for 5.4 and cross your finger that a certain web site doesn't overload the UltiMaker developpement team.

Don't really understand why you not simply create your own predator.def.json file in your local user definition folder as it should be and not try to mess the configuration by duplicating the files in your local configuration. With a unique name you will be sure to avoid all the problem. I m working like that and doesn't have any issue from 4. To 5.3 (except with the issue of this 5.3 alpha sharing the same folder as the 5.3 )

In cura you have a difference of Zoom between the Orthographic View and the Prespective View .. The Zoom in Perspective Mode is more limited ... Could be the origin of this issue ?

Level your bed, if you have change the Nozzle the distance nozzle / bed have change.

Not so Easy .. You can eventually get rid of the movements in the part by using a Custom Support. But if you re-enable the Z Hop all the movements in the part will come back. The only solution would be to use a post-processing script to add Z Hop to these movements. (https://github.com/5axes/Cura-Postprocessing-Scripts/blob/master/ZMoveG0.py)

As the Code is correct, certainly an issue with Creality machine and Code M117 ask @GregValiant.