Jump to content

Cuq

Expert
  • Posts

    675
  • Joined

  • Last visited

  • Days Won

    18

Posts posted by Cuq

  1. 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.

     

     

    image.thumb.png.4d803c884e0c9756c914bf6bb5114c79.png

     

    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.

    • Like 1
  2. 51 minutes ago, Dustin said:

    Too many people see these videos and consider it as "this feature is tested, proven and completed it just needs added to the slicer" when it very much is not majority of the time.

     

    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.

    • Like 2
  3. 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. 

     

    • Like 2
  4. 2 hours ago, GregValiant said:

    There is a feature request (#17713) and there has been much discussion.

    From reading here and there my impression is that it appears to work well when the Z-seam is on a curve and not at all when the Z-seam is on a corner.

    Maybe @Cuq can comment?

     

    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.  

  5. 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. 

    image.thumb.png.75266f200b78f56d7d4c2509d1ead304.png

     

    Your sample Gcode ... Without any header command

    image.png.9f2270635fa70da45ad4c8e5bc1f2c17.png

     

    and the code generate with your sample project 

     

    image.thumb.png.f301f9dfab42a416118127aa46a52eac.png

     

    but I have absolutly no idea why your GCode is not correct ... Should be.

     

  6. 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.

     

    image.png.8a221784fec4946c43b40a1c82092ac3.png

    • Like 1
  7. 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.

    • Like 1
×
×
  • Create New...