Add object specific comments before gcode blocks

[shocksofmighty]

Not sure how easy this would be to implement, but It could be very useful to add some object-specific flag before each block of gcode, similar to what already happens when processes are switched. This might allow some printer control software that parses gcode (octoprint) to cancel specific objects in a print if that object has failed, but other objects in the gcode are printing normally.

[arhi]

viewtopic.php?f=23&t=9841

[shocksofmighty]

Yes, that would be even nicer. Right now, you can sort of get the same effect if you just use unique process for each object. I've done basic testing with a modified OctoPrint and you can indeed skip all objects related to that process.

[arhi]

that's actually not a bad idea to copy process and attach each process to one object ... lot of manual labor but doable...
you already have a working plugin for octoprint?

[shocksofmighty]

No. I just made some modifications to src/util/comm.py of octoprint to demonstrate that it can work. I don't quite have the skills to do a full-blow plugin. There is a thread on the octoprint forum where it is being discussed.

[arhi]

interesting, I wanted to make plugin (should be rather simple) but the problem is that "what's the point" if s3d is not generating the data

[shocksofmighty]

I think the point would be that the plugin could be made to work now for processes. This would still be very useful if you were doing sequential printing for example. You could just skip to the next process. The other thing would be that it can be made customizable (at least by allow the user to define the regex that it matches for the process/object) so that if/when S3D adds object specific comments the plugin will be ready to go.

I actually spent some time thinking about it and have a pretty clear idea of how to get it to work as a pure OctoPrint plugin (no changes needed to octoprint itself). However, my python is not very good, and my js is even worse! If you have any interest on working on it together, let me know.

[arhi]

I think the point would be that the plugin could be made to work now for processes.

that would require that for every multipart print one have to manually create as many processes and export like that every time, too much work that noone is really going to do every time and that's only way it would work ... I doubt anyone will do that.. I certainly am not going to ... that's why investing time in plugin that one would not use is not very inspiring ... on top of that, if any slicer implements this feature it'll probbly be different then current s3d processes so all that work would probbly be for nothing and will have to be redone... hence waiting for proper implementation.

What's important, that the octopring thread mentioned, is that resseting extruder extrusion to zero before every "block" is very important...

I actually spent some time thinking about it and have a pretty clear idea of how to get it to work as a pure OctoPrint plugin (no changes needed to octoprint itself). However, my python is not very good, and my js is even worse! If you have any interest on working on it together, let me know.

python disgust me so I try not to use it unless I really have to, that's why I'm delaying work on that plugin as long as possible

[shocksofmighty]

I think it would likely get reasonable use. I generally don't print more than 5 models at a time. Setting up 5 process for each model takes maybe 2 minutes, which is nothing compared to time wasted due to one object failing. Again, in the case of sequential prints it would save tons of time.

I think I can do all the python and just show it can work by nipping bits and pieces from other plugins. Probably only a few days work to get it to that point.

[arhi]

I think it would likely get reasonable use

I'm kinda selfish with my time, trying to spend more of it with kids while they are small as later on they will not want to spend time with me... so I'm more talking about "reasonable use by me" not by "everyone else" .. I rarely do process by part, if I need that I'd rather put each part in a separate job and run them in parallel on different printers than cram them on same plate on one printer.. the time when I do "full plate of parts" is when they are all more/less the same and when quality is not too big of an issue and that's where this type of work is really needed (canceling one part from a tray of parts) ... preparing that tray with one process per part is more work then I want to put in, I'd rather tweak slic3r to generate this data for me as I'm using it more then s3d anyhow

I think I can do all the python and just show it can work by nipping bits and pieces from other plugins. Probably only a few days work to get it to that point.

it's not just python, you need some js too, if the thing is to be very useful some g-code visualization needs to be borrowed from the g-code visualizer and some display of parts should be there and... thinking about it now, I think g-code visualizer plugin would be the starting point, fork that one and make a version that can display objects and allow for canceling them