LegacyCura
LegacyCura copied to clipboard
daid
addition features
Good afternoon! I would like to offer add slicer (and in UM firmware) additional opportunity. - namely in the G-CODE distinguish between objects and / or layers of tags, i.e. additional codes. in the most piercing track these tags, and only for certain tags such as disable or enable printing. Let me explain. printed immediately 3 large object. It prints 50% for 8 hours. suddenly produced a defect that clearly is not acceptable in a single object, but 2 other object - normal. Stop printing? All three lost. Continue? whereas on 1 piece plastic will be spent in vain and spoiled with an extra plastic parts can prevent printing 2 other objects. Using tags and special codes can give the team that the item is tagged with OBJECT_1 ignore, not print - then it will save both time and plastic. The same commands can be specified for example - stop printing support in the printing process, if the operator considers that it is in principle at this stage and until the end of the press do not need .... Well, do tags can then be used in the visualization of what is being printed - supporting, object_1 etc.
Not that easy!
Deleting segments of g-code on the fly will cause the nozzle to be in a different spot: The starting point of the deleted segment rather than the ending point. In other words, there is a gap.
Since a g-code extrude command only specifies the end of a move, the firmware would move the nozzle towards the endpoint from whatever unknown starting point the nozzle ended up. This could make the nozzle move right through the object, leaving a string in its wake and creating seams at every wall it hits. Of course, the path optimisation is also askew.
Support is not created per object. If you were to place two objects close to each other, it merges the support of the two (rather than making a useless gap between the two pieces of support). If you were to disable one object, the support of that object would still get printed. Unless you've set support to be buildplate-only, that support could be leaning on the object you're not printing, meaning it'll create spaghetti.
I'd wager that the first problem (gaps in the path) can be solved by inserting extra travel moves and perhaps a z-hop, but I see no solution for support hanging in mid-air. The firmware doesn't have the processing power to generate new support in place of the mesh.
Will never happen for the UM2 line of printers. (We talked about this about 1.5 year ago, and that's what we decided with the experts)
