Summary Information - Filament
Whenever I select the GCODE Summary information (not in the history section) from the main display the filament shown is always PETG. It doesn't seem to matter if I am printing PLA, ABS or TPU, it always shows PETG. I use PRUSA Slicer.
Where is the server picking up this information from?
Secondly, while I really like the "push" notifications, it would be really nice to know which printer has started/paused/done etc. Right now it's a global function, it would be more logical to make it a specific printer function. Save me some walking any way...:-)
Last, when simultaneous printing on my deltas and single cartesian, whenever I upload GCODE the deltas always pause for just under two seconds and then carry on. The cartesian never misses a beat and just keeps printing. Raspberry PI 4, 0.94.2 (0.94.3 caused too many connection issues with all the printers).
Mel
Where is the server picking up this information from?
Secondly, while I really like the "push" notifications, it would be really nice to know which printer has started/paused/done etc. Right now it's a global function, it would be more logical to make it a specific printer function. Save me some walking any way...:-)
Last, when simultaneous printing on my deltas and single cartesian, whenever I upload GCODE the deltas always pause for just under two seconds and then carry on. The cartesian never misses a beat and just keeps printing. Raspberry PI 4, 0.94.2 (0.94.3 caused too many connection issues with all the printers).
Mel
Comments
When you read the message in informer you see the printer name it is for.
The pause is strange. I would understand when uploading blocks sd for a short while but then all printers should have a pause. On the other side it also depends on the number of buffered moves. When you print a curve area any small pause stops printer while linear infill on big objects take longer for buffers to empty. On the other side we always read 5000 lines ahead to prevent just this.
What happens if you upload a small gcode instead that does not block sd card?
Could also be a usb bandwidth problem, also I thought this was solved on pi 4. When you switch delta and cartesian usb port does that change who is stopping?
So what about instead of the generic "Print Finished" title, replace the "Print" with the defined printers name? So I can see "Mixed_Pickle Finished" for example as the header. That should also then show up on my watch.
----
From PRUSA slicer GCODE after the End Code, there's always a complete section that specifies all info. It'd be a simple matter to parse the GCODE for a summary and look for the tag:
; filament_type = PLA
If that matches what's globally in the settings, it should then display that material, cost, etc. PRUSA Slicer also tends to add the material to the filament as well. So "Disaster_V2_0.2mm_PETG_MK3SMMU2S_1H_22M"...
----
The printing pause is strange, I don't remember seeing it at all with the Raspberry Pi3...to test it I left the printer cables in the same USB ports on the PI4:
Delta - USB 2
PRUSA - USB 3
Sent a really small GCODE file to first one printer, then replaced and sent to the other printer. No pauses. Then I swapped the cables:
Delta - USB 3
PRUSA - USB 2
Sent the same file to each printer, again no pauses.
Next I sliced up a huge model and sent that to first one printer (PRUSA) it said it was rendering, then I sent it to the Delta, it was rendering. No pause happened on either printer at this point.
About 20 seconds later, the delta stopped. For just over 2 seconds. Then it carried on. The delta was printing a rectilinear infill, no curves.
I checked the PRUSA and the GCODE had been rendered, the delta was still rendering the image. It was almost like when the image was rendered and being displayed (using the third display option; grid display) it paused the delta but didn't affect the PRUSA.
---
Mel
Could it be when rendering is finished? Then we write the images in 3 resolutions also uploading and starting rendering would make more traffic, so strange that it happens later on. Display will load the new images. You can test with hard reload if that would be a problem.
For informer I have now added printer name:Message - will see how it looks.
I know both Octoprint and Astroprint fail miserably at anything over about 47mm/s speeds on a single delta, especially on anything curved. Repetier Server Pro has never even had a hiccup when running my three deltas at the same time. Until now and it's only been when uploading a large GCODE that has seemed to be the problem.
It felt to me like when the PRUSA was finished rendering its images on that huge GCODE upload, that's about the point in time the delta stalled in printing. I'm just going to keep an eye on it since it's not a big critical thing, just something I need to be aware of.
I'll have a look at Repetier Informer and see how that looks here. Thanks!
Mel