A fairly large change to the code.
-
So... I wouldn't know how to search for this, so I'll just blurt it out... :
The problem I'm trying to fix is that when I'm printing a large collection of things on the bed at once, sometimes one item comes unstuck. Now... sometimes, if it's small, it's good enough just to remove it and let the printer just dump filament in it's place. But if the object is larger, this is both wasteful and risking damaging other items in the print.
So... I propose a new M-code. To "set the object reference number." After such a code, all actions are deemed to be part of that object number until another object reference is given. The default should probably be a '0' (zero) object that is in effect when no object is given and the M-command setting the object reference to zero ... resumes this initial state.
Obviously, this would require slicer support... but nobody can really test it until a printer's code could use it.
The idea would be that I could display the object numbers in the slicer such that ... when I have to remove an object, I can sent the printer a command to stop printing any commands associated with object "n" ....
Thoughts?
-
This was already discussed: https://forum.duet3d.com/topic/6299/cancel-individual-part-s
-
@zbeeble There was a discussion already some weeks ago about deleting print parts. I cannot find it, maybe you can search a bit. One good proposal was to label the objects with tool numbers and then delete it and exclude from printing.
LOL Obeliks, one minute faster
-
@joergs5 said in A fairly large change to the code.:
@zbeeble There was a discussion already some weeks ago about deleting print parts. I cannot find it, maybe you can search a bit. One good proposal was to label the objects with tool numbers and then delete it and exclude from printing.
LOL Obeliks, one minute faster... yeah... I would say that if that was the answer, I'm glad I posted. One serious problem is that I'm talking about a print where there's (say) 30 odd pieces on the board. I'm definitely asking for a modification to the G code standard and the programming of the printer to implement it.
It seems to me that the Duet has made many "by fiat" changes to the G code ... given how extensively it uses it. This is easily a compatible change. Who do we need to ask to allocate a new code for this purpose? I'd even think about diving into the duet code to add this feature.
obviously, as-I-said, slicers would then need modification. That's a different fight for me... but I relish it. I believe this feature is useful.
-
@zbeeble It's not really a change to the gcode standard that's needed. It's more about firmware because as things are, multiple part prints still exist as a single gcode file. The firmware needs to know which sections of that file would be associated with different parts which was why I suggested using existing slicer features for multipart printing to put tool numbers in the file. These would at least act as flags which could be used for perhaps some sort of post processing to insert a new "M" code to denote each numbered part. However, I would think it would be a lot of effort and a "big ask" to have the firmware written such that mid print, you could stop printing say object number 27 of 30. Extra positional commands would somehow have to be run to move the tool head from the last part of object number 27 to the first part of object number 30 which might not be easy to calculate. Also, what would you do if the part failed because the part had become detached from the bed? The chances are high that the print head would collide with this now raised part so you'd somehow have to do a Z hop over it. I think what you are asking for is a very big ask in terms of firmware changes. But hey, I don't write the firmware so why do I care?
-
Wow. I really thought this forum would connect me to people who knew the code and/or the standardization process of gcode. Here's the thing. I've read the code. I've read the gcode output of several slicers. I've read through the gcode standard (insofar as the duet3d page documents it). I understand how it works.
And with that understanding, I made a proposal. A code that would specify, as it's argument, the current "part number" ... with the default (code never given) being part number 0. Obviously, slicers have to introduce this code for it to be useful, but this is another battle. A second code, to be given at runtime (we already have runtime inserted codes ... like the z microstep) would enable or disable and object by number. You could have the slicer overlay the part numbers on it's display, should you need them or the printer could put the current part number on the interface like it puts the X, Y and Z values.
Now ... as to the last part of your argument, most slicers use absolute references for at least X and Y. So... no extra movement commands required. Generally, if this is happened, and I'm there to notice, I'm there to remove the offending part. In my original post, I mentioned that I often remove the part and the printer just continues to dump filament into the area, but this usually "sorta" works out, save the mess and the waste.
If the situation is, as you say, far more complex, then there's nothing to be done. It's dead print. You're no worse off than before.
But if you sit and think about this feature request, it means that you could exchange g-code files with parameters. At least for similar printers. It means, say, that you could slice once, and then enable and disable optional parts of a print on the fly.
Anyways... to be clear, I intend to look into each of these two things and hints on how to move forward would be welcomed just as nay sayings may be ignored.
thing A - how is GCode standardised. How do I add a code or two?
thing B - is anyone else interested, or am I on my own modifying and submitting patches for duet3D code?
-
@zbeeble G-Code has no standadization organisation, as far as I know. Historically it is used by CNC and later adopted and augmented for 3d printing. So everyone added this and that commands and parameters. One could argue if it's in the documentation of the https://reprap.org/wiki/G-code, it becomes a standard, but this is of course not true. If you look into details, you will see that the different firmwares have different implementations. If you have a new Z probe sensor, you are free to add a new parameter.
So to answer your question: you can add code for yourself, or you can try to "standardize" by a common agreement inside the reprap community. But it will not be implemented in all firmware/slicers, nobody is forced to do so.
And the second question: of course there is a lot of interest, and there was already some discussion like in the other thread.
-
@zbeeble for your question of submitting patches:
you have two options: dc42 David makes changes to Duet code available for all. But he has a long list of change requests and follows his priorities. If your change request has low priority, you will have to wait.
The second option is to fork his code on Github and change the code yourself. Then you can use it and optionally give your code to the community by committing the change to the dc42 base. David has to accept the change to be committed.
If you are frustrated that nobody started yet, it may be because it is not finally discussed how the change should be implemented: is the best place the slicer, the firmware, and how should it be done? And then: is it important enough for someone to write code?
-
I would love to get agreement on standardising future changes to GCodes used for 3D printing. Several years ago, someone (possibly Adrian Bowyer) tried to promote standardisation by creating wiki page https://reprap.org/wiki/G-code. the introduction not this page says:
As many different firmwares exist and their developers tend to implement new features without discussing strategies or looking what others did before them, a lot of different sub-flavours for the 3D-Printer specific codes developed over the years. This particular page is the master page for RepRap. Nowhere in here should the same code be used for two different things; there are always more numbers to use... The rule is: add your new code here, then implement it.
Unfortunately human nature being what it is, the best procedures aren't always followed, so some multiple uses of the same code exist. The rule which should be followed is that later appearances of a code on this page (later than the original use of a code), are deprecated and should be changed, unless there is a good technical reason (like the general G-Code standard) why a later instance should be preferred. Note that the key date is appearance here, not date of implementation.
Both we and the Smoothieware developers follow this practice, and we also take account of the meanings of GCodes in the NIST standard for CNC machines. I always document new codes at reprap.org before I add them to the Duet3d GCodes wiki page.
Unfortunately the Marlin developers seem to behave as if there are no other firmwares for 3D printers, because they allocate new codes with total disregard for the reprap.org wiki page, and either don't document them on that page or do it very late. One of them even complained at me for documenting RepRapFirmware GCodes on that page. So if we are to achieve any sort of GCode standardisation, you need to persuade the Marlin developers to be good RepRap citizens first.
The particular feature you are asking for would need to be used by slicers in order to be useful. So your first challenge is to get at least two providers of slicing software to generate the new code. AFAIK there is no forum where developers of slicers exchange ideas. Perhaps there should be.
-
dc42: firstly, so far on this forum, I really look forward to your replies to my post. Full of information and straight forward.
So... standardization is a dog's breakfast that I can't solve, but I can at least be a "good citizen" by following your lead. That is good news. I'd be willing to participate in a standardization process, but I'm not the willing to lead the charge on that hill.
As for slicers, Cura looks like a plugin can do the job. I'm pretty sure I can make slic3r do it, too. I did say, in my original post, that fighting the slic3r war would be be my job. Are you saying that you don't want to consider any changes until there's slic3r support? My response would be a request that the potential new code be treated as a no-op. This will make it easier to test the slicers and whatnot.
On the actual way-this-works, I've given a fair amount of thought to it. Realizing that the mover is more important in these things, I can start by coding things up. But I'd actually like to incorporate anyone's suggestions as neither do I wish to work in a vacuum.
Of the suggestions I've read so far, using the tool number seems a limited idea. It would complicate the situation where you actually use multiple tools (then you'd need multiples of multiple tools) and it seems more like a "hack" than a solution.
Thinking of my proposed solution, it can be achieved by one code with two variants. One to "set" the object (put in the code by the slicer) and one to set the exclude list for objects (injected into the stream by the printer console). At this point, I'm not discussing the interface that might appear on the web interface, but just assuming that it is something that can be entered on the console during a "pause"
So... to facilitate discussion, are there people who need more details? Are there obvious flaws in my implementation?
-
I can see a couple of potential issues:
- If the parts are being printed using multiple tools, the GCode might do something like this:
T0 - print part of object 0 - T1 - print more of object 0 - print part of object 1 - T0 - print more of object 1...
So the firmware couldn't just ignore all GCode that relates to an object being skipped, because it might contain tool changes, fan speed changes, temperature changes etc. that are expected to be carried across to the next object. We'd need to think carefully about what GCode commands we might need to execute in the middle of a block that we are otherwise skipping.
- If your parts end up with small towers at the top, then the slicer may have enforced a minimum layer time to help with print cooling. If the firmware is skipping one or more parts then that minimum time would not be enforced.
Neither of these is a show-stopper.
-
I believe there is an octoprint plugin that does something similar to this already, how does that work?
That could be a good start point for what is important or not.
