Cancelobject together with PrintTimeGenius

[eyal0]

Twice now I've had users file bugs because Cancelobject and PrintTimeGenius don't work together. This is PrintTimeGenius' fault because I do all the processing ahead of time and I assume that all lines will actually execute.

Is there an API where the PrintTimeGenius plugin could ask Cancelobject which gcode lines are expected to print and which ones aren't? If so, I could use that from PrintTimeGenius to subtract out the cancelled objects when making an estimate.

By the way, how does cancel object current interact with print time estimates? Does it do something special or do estimates get screwy?

I hope that we can solve this together!

[paukstelis]

Hmm...This is an interesting problem. I have PTG installed on at least one system, but I have to admit I haven't looked at it carefully. So PTG does this at the beginning of each print, or is there some processing that happens during a print? Once a print is started, cancelobjects can delineate which blocks of gcode belong to which objects, so I suppose we could expose this via the API. I guess this would require PTG to reprocess after the print is started. Alternatively, PTG could use the @Object tags that get written into modified gcode to parse out individual objects on its own. Not sure which is more straightforward at this point.

[paukstelis]

Actually, I now recall that the object list is exposed with objlist API call. Once you have the object list I suppose it should be possible to determine time for each object and then just subtract if there is a change in the cancel status of an object?

[eyal0]

The way PTG works is, for each file that is uploaded, a simulation is run to see how long it'll take to print. That simulation is able to attach a length of time to each line of gcode. Then we just add them up and we're done.

PTG then attaches that information to the metadata of the gcode file after thinning it out so that it only includes like one timestamp per 60 seconds. That information is stored as a mapping from file position (in bytes) to time remaining (in seconds). PTG then installs an estimator, which is a thing that the OctoPrint API provides for. The estimating function gets the file position as an input and we output the time remaining, interpolating between timestamps as needed.

So what I could do, potentially, is adjust the timestamps so that they would be 1 per minute but also have a timestamp for every Cancelobject comment in there. Then I would need a function that I could run to tell me which lines of gcode will be part of the print and which ones won't. With that info, I could subtract out all the unprinted gcode lines and give an estimate of the time remaining. So either the API would need to report which objects are/aren't printing and PTG would have to scan through the file and find those tags or the API would report which lines are and aren't printing and then PTG just has to do the math.

How does Cancelobject do it? If someone cancels the currently printing object, does it notice it immediately or only when it finally reaches the object tag? To do the former, I guess that you'd have to scan the whole file to find the right lines, which might be kind of slow.

[paukstelis]

Cancel objects looks for @ tags (@object) that are generated from the slicer comments at upload time. When an object is cancelled it gets the cancelled flag (included in the object list over API) so during queue phase of gcode sending everything between that @object tag and the next @object tag is skipped (with the caveat that users can allow specific commands through).

I'll think about it some more.

[eyal0]

Okay. All that makes sense to me. What I wonder is, what if the user is currently printing object "XYZ" and then object "XYZ" is cancelled, in the middle of it's printing. Ah, I guess maybe Cancelobject is constantly keeping track of which is the current object.

Does it hook into some Octoprint hook so that it can see each command before it is sent to the printer and, like, return False on the ones that should be skipped or something? And inject commands as needed?

BTW, what does the print time remaining look like with Cancelobject, without any other plugins. Do either Octoprint or Cancelobject figure it out somehow? Or does it just give screwy numbers for the current print?

[paukstelis]

Yes, it tracks the current object.
It does use the standard gcode sending hook (in the queue phase) and works basically as you describe.

Without PTG, I believe the % gets updated immediately, though I can't say I have paid too much attention to print time remaining. I would suspect that if it is cancelled early it might be somewhat accurate just because it has time to compensate for the cancelled parts, but it probably gets worse as it is cancelled later in the print.