Cuq

Could be done with a postprocessing Script, or a script .

Yes sorry, As it is not anymore compatible I've removed it from the Marketplace.

For your information, the HMTLCuraSettings plugin is no longer compatible with Cura version 5.7. [Edit]: Remove the link to the plugin on the marketplace.

https://marketplace.ultimaker.com/app/cura/plugins/5axes/CuraSlowZ

The added function "simply" changes the order of the pieces in One at time mode. So that's what you could already do by adding parts in a specific order. The function is there to change the order in the item list. So don't expect a big automatic option. In future, it shouldn't be too difficult to add sorting by part height or position of parts on the print plate, for example. EDIT Note : If you just have 2 or 3 parts to print it's a good solution. If you need to set the order for more than 5 parts it's not an easy process.

@GregValiant 🤣 Even more, if you consider that in addition to selection by user order, you can also sort by object position or Z Size.

A PR have been merged last month to solved this problem : https://github.com/Ultimaker/Cura/pull/17893 But haven't seen yet this function in the existing alpha or beta.

100% agree and most of them are the same people who say "I want this option right away, it's indispensable", and then forget all about it 2 days later. BUT (There's always a but ! ) What's remarkable in this case (as in the case of Arc Overhang Support) it's the contribution of a Free software and I realy speak about a Free Software and not just an Open Source software. A guy comes up with an idea, and with a little postprocessing macro, he can start creating and testing the concept. A developer finds the idea interesting, and decides to take it further, without a hierarchy vetoing it because it's not on the list of planned developments, or because it's in line with the company's objectives, or because the code is likely to pose maintainability problems. etc etc etc.... As a result, a community of well-informed users got to grips with the proto, carried out tests, proposed recommendations on different geometries and printers, and finally developed the subject in record time. As with any development, there's no guarantee that the result will be a success. It's the same in any industrial or software development company. But compared to a classic scheme, the speed of development of the technique and the consideration of different printer users brings a faster solution than a commercial company structure can achieve. And if you don't offer the possibility of integrating technologies still in the development phase, then you can't benefit from the agility that can be found today with certain Slicers.

Not agree ! From the start, I thought that the "Arc Overhang Support" option had no future on the actual concept (too complicated, not very good results, etc.). Here, I think the subject is promising, there's still some work to be done, cases to be dealt with, perhaps, as @nallath said, flow management by print speed for the problem of bowden-type extruders. But for me it's of real interest. In the case of the "Arc Overhang Support" a great part of the initial noise comes from CncKitchen. I love his videos, he has a big audience and compared to other Youtubers a real scientific and technical approach. But unfortunately many of the ideas presented are often too complex to see any real application in slicers.

Yes you are right that's why the latest integration features an option that activates the "scarf joint seam" mode only on smooth contour. This option is currently only available in OrcaSlicer, and the latest discussions on the ongoing development are on the Github of this slicer : https://github.com/SoftFever/OrcaSlicer/pull/4317 What's interesting is that the idea started from a user, who initially posted his idea on the Prusa and Ultimaker github sites, and then wrote a macro for a POC. And then the developers who contribute to OrcaSlicer quickly integrated the concept with rapid user feedback. For the moment, the function has not yet reached full maturity, but it should be present in the next version of Orca.

Agree a postprocessing script can do this job. But what happen's if you have have two or more parts on the bed ? And if you have some inner boundaries in your models ?

No you can't print an Honeycomb pattern verticaly with the Cura Master. should ask as improvement to @burtoogle https://github.com/smartavionics/Cura/issues

Is it just me, or is the problem only that in version 5.6 the Travels option has been inadvertently checked ?

https://en.fss.flashforge.com/10000/software/a42243ba68cb81dc8afd7b7fb3e71dcf.pdf

Potential duplicate discussion :

It's a bug. Already reported several Times by different users. First Layer Wallspeed too fast #17594 #17389 #17010 You can have some Walls on the initial layer not printed at initial layer speed

First Layer Wallspeed too fast #17594 #17389 #17010

Because 2.0 is the default value and there is no definition of the retraction in the second profile. So open it doesn't change the value ?

Cura Master 4.20 feature

Exactly. You can only see the result, not the parameters. But you can also import the GCode as a profile, allowing you to recreate the configuration used and analyze the GCode if necessary.

your Gcode is not the same as the Gcode produced by the cura project ... This is your machine configuration and we have the correct parameter definition. Your sample Gcode ... Without any header command and the code generate with your sample project but I have absolutly no idea why your GCode is not correct ... Should be.

Plugin Printer Settings : https://marketplace.ultimaker.com/app/cura/plugins/fieldofview/PrinterSettingsPlugin

What a nice report .... And good news your issue is very easy to solved In the 5.6 release the Diameter of the wire is define at 2.85 mm and not 1.75 so as result you end up with half as much flow as you need, hence the look of the part.

I had the same thought as @fieldOfView about the possibility of a pseudo-plugin that would simply make one or more scripts available (my Calibration Shape plugin already does this). But I'm not sure the Ultimaker team would agree. In addition, there are three other drawbacks: - One, if the script stays in the plugin's Script folder, it's harder to know where it comes from in the event of a debugging request. - Two, many users already confuse Script with Plugin. They call a plugin a post-processing script or a script a plugin. Bringing them all together in the marketplace could only generate even more confusion. - And finally Three, as a heavy script user myself, I realize that this solution isn't very beneficial in the end. Scripts (but the same goes for plugins) are often, for the most popular ones, nothing more than temporary patches to fill a lack in the software. As the plugin or script more or less fulfills the function requested, they become standard functions without meeting the need 100%. In other slicers, if I look at all my scripts and practically all my plugins, the function exists natively in the software, and often much more efficiently. In the final analysis, scripting and plug-ins are Cura's strong point, but they become its weakness over time.

Not exactly right. If your scripts are located in the app roaming User script folder , then when you install a new release they are automaticaly copied in the new user configuration folder. No need to manually move them.