Does not play nicely with vase mode

[rlogiacco]

In a way it makes a lot of sense, in another it made me force to disable the plugin. When printing in vase mode the continuous change in height saturates the CPU of my Pi3 which can't cope with high detail code: the effect is the printer stutters between commands and filament extrusion becomes inconsistent. The more details, the more surface roughness. Issue was completely gone once the plugin got disabled.

I don't blame the plugin by itself, I know this is a consequence of the limited processing power of my octoprint server, but may be this should be better communicated or a warning issued when the Z changes are "continuos"... don't know, just wanted to report it here as it was painful to "debug".

[OllisGit]

Thx, for reporting this issue!

Because I only have one printer and not a print farm with multiple printer-versions, it is necessary to receive such feedback from the community....and yes, it is a free open source tool done by a one-man-show and you are kind-of the "beta-tester". If no one reports the issue, I can't create a "warning" ;-)

But in the past I already added a "warning", because I received a couple of similar issues in a short time. https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/releases/tag/1.16.0

Back to your issue:

• What printer do you use?
• Version of DLP, OP and Python?
• If possible, please attach the original sliced g-code from the slicer and also the upload g-code downloaded from OctoPrint-Menu.

[rlogiacco]

Printer is an Ender 3 running Marlin 1.1.9 with latest bugfixes. Octoprint running is version 1.4.0, DisplayLayerProgress was 1.18.1 and Python 2.7

I don't have the original code from the slicer because I usually slice and send directly to the printer, but the attached one is the file downloaded from octoprint: if you want I can re slice the file, I'm not sure I didn't change my settings in the meanwhile....

isogrid-wastebasket_small.zip

[OllisGit]

Hi @rlogiacco in the newest release 1.19.0 I changed the behaviour (switching to async) of processing the gcode during print. I think this was your issue, because the gcode was not send fast enough to the printer.

Because it is just an assumption, please test and give me a feedback.

Thx, in advance Olli

[rlogiacco]

I installed 1.19.1 and sadly no, that didn't change the result quality, not even partially. I believe the Pi3 doesn't have enough processing power to even scratch what would be required by this. I can think of a few options:

• if you can somehow identify the Z is changing very often during the initial code analysis you can disable the plugin events for those files
• or you can limit the frequency of Z changes processed by the plugin to no more than 1 every x seconds
• or you can avoid updating unless the Z change is above a specific (0.04 mm ?)lower limit

In the meanwhile I believe my only options will be to disable it while printing in vase mode...

[OllisGit]

Hi @rlogiacco,

last idea: Try latest development version https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/releases/download/1.20.1dev/master.zip

This version use queing-hook and is not interfering the communication between OP and Printer. The values in the display are now a little bit behind.

[rlogiacco]

Sorry for the late reply, but my printer was in upgrade mode. I've installed the dev version, but I didn't notice any visible improvement, the printer still jumps from one line to the other like my old granpa who suffered of the Parkinson's desease. I truly believe the best option is to disable the plugin processing when it's unable to determine the line height, which is the warning I'm getting on every "vase mode" file.

[NCBob]

Just wanted to leave some feedback. I do have multiple printers with a little bit of variety in terms of the Raspberry Pi's I'm running a few Pi 4's and a few Pi 3's.

I've lately been printing some items in Vase Mode and haven't had any issues like what's been described here.

The printers are Ender 3's all updated with SKR V1.3 boards running Marlin 2.0 and that might be why it's able to keep up with the continuous Z changes. I also run UBL on them all so the Z is constantly moving even on regular prints, but it might not be an issue when it's a bed leveling Z adjustment.

[rlogiacco]

This is weird: I’m using Marlin 1 (latest) with a MKS GEN-L (8 bit cpu) but the difference in print quality is impressive when going base mode with the plugin enabled vs plugin disabled... Please note the artifacts do not appear unless the surface of the vase is pretty elaborate: if there aren’t much directional changes then for me there is no artifact whatsoever (like for common lo-poly skulls or non curly vases), but for models with a lot of directional changes the plugin seems to really make a difference. Can you share an elaborate model printing nice on your printer in vase mode with the plugin enabled? Printing the same model might help me debug the issue and solve it in case it’s on my side (sliver settings, hardware, etc...)

Thanks

[NCBob]

I think it would probably be better if you shared a model that you're printing in vase made that you have the layer shift on. It would be possible I don't have a model that could cause the layer shift. I'll then throw it on a couple of my printers with different combinations of motherboards and raspberry pi's and see what happens. I'll also go through and post what plug ins I've got installed.

[rlogiacco]

Sure, no problem! Here (https://www.thingiverse.com/thing:3448156) is one of the things displayed in the picture above: that print is the 0.8 version scaled down to 50% and sliced with Cura, then sent to my RPi 3 running Octopi driving an Ender 3 featuring a 0.4mm nozzle.

Thanks!

[NCBob]

It's printing on two of my printers and as of right now it's not having any issues. Once it completes I'll post the pictures and I'll also get a list of the plug-ins I'm using.

[NCBob]

well first one is done. Second one is almost done and they both look flawless. I'll post my other plugins that are installed and I don't have linear advance enabled.

[NCBob]

Oh, and one machine has a raspberry pi 3 the other has a pi 4. Here are the plugins I have installed (I always install the same plug ins on all my printers) Action Command Prompt BLTouch plugin Bed visualizer Better Heater timeout Dashboard DisplayLayerProgress Plugin Friendly neighborhood beeper Preheat button Sidebar webcam

And I use simplify3d for all my slicing. I also don't get any warning about printing in Vase mode like you described. What slicer are you using, I can give that a try and see if it makes a difference.

[rlogiacco]

I'm using Cura for Windows, latest version currently available. I have many more plugins than you have, can't get a list atm as I don't have remote access to octopi.

Regarding the warning, when I start a print sliced in vase mode I get a notification stating it is impossible to determine the layer height from the file and it advises to check the slicer settings...

[NCBob]

I'll give cura a try in Vase Mode, and BTW it did print fine on both my enders with both a Raspberry PI 3b+ and a Raspberry pi 4

If you could try something else, enable the DLP plugin, and then try disabling all your other plugins and see if you still have issues. If you don't then try enabling your plugins one at a time until it starts showing artifacts. It might be that a combination of DLP and another plugin is causing the issue.

I'll let you know the results of using Cura, I'll have to play around to get some good settings for it before I try the vase mode, but I'll let you know the results.

[NCBob]

Ok, I've been printing PPE stuff and I just switched my printer to add filament runout sensor hooked up to the pi. I started getting zits on my prints. I disabled a bunch of plugins and it's working fine now, this is one of my printers that I have a PI 3b instead of a Pi 3B+ or Pi4. I can print the same gcode file from and sd card with no problem.

I'm going to replace the Pi with a Pi 4 and see if it still has the same problems. It may just be the combination of plugins is causing the delays and pauses in the print.

As soon as I change it tonight and test it I'll post my results.

It might just be a combination of firmware, plugins that is causing the pi to not be able to send the code fast enough.

[NCBob]

Ok, I replaced the Pi3b with a Pi4 with the same plugins and still had stuttering. Turns out it wasn't DLP and probably not just the pi3b (although the stuttering was much less with the pi4) it was the filament runout sensor I was using connected to the GPIO pins. When I uninstalled that and hooked it up directly to the board and did the filament sensing in the firmware it's printing perfectly again.

Note, when I did the first vase print above I did not have the plugin for filament sensing installed. Now everything is running like I expected.

[OllisGit]

@NCBob great that you could solve the Problem!!! And of course that DLP wasn't the main reason.

@rlogiacco THX, for the support!!!

Instead of disabling the whole plugin, you can also disable the Printer-Display communication in the plugin-settings. This prevents that my Plugin sends additional M117 GCode messages during the print, that (maybe) slow down the data-transfer rate during OP and the printer.

[OllisGit]

I forgot to ask @rlogiacco: do you still have the issue or is there a new one? You mentioned, that after uploading from Cura to OP a popup appears that no layer indicator is found, right?

Do you use the this plugin: https://plugins.octoprint.org/plugins/UltimakerFormatPackage/ ?

[rlogiacco]

OK lads, sorry for not answering, my printer is down for maintenance and I didn't have the opportunity to run any test.

If it's not a problem I ask you to leave this open for a couple of weeks until I receive the replacement parts and I can run some tests. I'm once again remote to my printer at the moment of writing and I'm unable to report the list of installed plugins, but I can tell you it's quite long, so I would perfectly understand it might be CPU starving effect caused by multiple plugins. I'm not pointing my finger at this plugin for a specific reason other than that disabling it fixes the problem, but I had the feeling it was a computational power limitation since my first post.

In other words, while I do appreciate all the effort in trying to solve this, I'm still convinced the optimal solution is to reduce or prevent processing on vase mode prints: I don't think there's much value for having a periodic update in such case.

[OllisGit]

Hi @rlogiacco , thanks for the feedback! Take your time and come back if you have more informations. i

[hannemann]

In the meantime i confirm the extrusion inconsitencies printing high detailed models in vase mode as soon as DisplayLayerProgress 1.21.0 is enabled.

OP 1.4.0, Printer is Anet A6 with SKR 1.4 Turbo, Pi is 3B.

First I tried disabling the features of the plugin but even with all checkboxes unticked the movement stops every few mm leaving blobs behind.

[sddev0]

I can confirm the issue. In your code I can see the behavior that each Z change, parsed from sent G-Code, triggers an progress update. That puts a lot of load onto the CPU in vase mode.

The plugin documentation states „Make sure to not perform any computationally expensive or otherwise long running actions within these handlers as you will effectively block the send loop, causing the communication with the printer to stall. This includes I/O of any kind.“ for all gcode hooks (sent, sending, etc.). Maybe it’s better to only collect data on each gcode line but trigger actions out of these hooks.

[OllisGit]

Hi @sebadue , thank for your feedback! Please look a little bit deeper into the implementation. The processing is not directly done in the hook, instead I put the current gcode in a queue and that queue is processed in a separate thread. The hook should not be blocked...maybe there is an issue I can't see.

[gdachs]

I suffer from the same issue. I tried to print this vase. I use DisplayLayerProgress version 1.21.0 in OctoPrint version 1.4.0 on Ubuntu 18.04 on an Odroid C2. The Odroid C2 is known for being way faster than a RPi 3b+. The printer uses a SKR V1.3 with Klipper firmware. I use a filament sensor too, but because the problem is not there if I disable the plugin, I don't believe that the sensor is a problem. When the problem starts the print head doesn't move anymore for around 1 second, and continues then till the next stop. To the same time one of the octoprint processes has up to 120% cpu. If I print this vase without this plugin, no process goes ever over 30% cpu. I assume the fact that Klipper can process gcodes faster than Marlin might make it worse, because the gcode queue of Klipper will run empty faster than that of Marlin.

[sddev0]

My observations are similar. In codeline 450 the updateDisplay-method is called on each and every z-change. For regular „layered“ prints this can be okay, but continuous/vase mode prints are characterized by a constant changing z-coordinate on each move. Even if the actual workload is dispatched to a seperate working queue, the total load seems to exceed the allocable CPU resources of the pi. Maybe a throttling could improve the situation: update on change but max. one time in n seconds. That high refresh rate is not beneficial to the user.

[OllisGit]

hmmm...unfortunately I can't reproduce the error on my ANET E10, RPi 3b+ (OP 1.3.10) printing the vase (sliced with cura with "spiral-option") The max cpu usage is 25% during the print.

One idea in my mind is, that there is maybe an issue how I implement the queue. Because if the queue is empty and a new command is receiving a new Thread is created. So, if processing of one command is fast the queue is already empty if a new command received and a new Thread is created. If I increase the lifetime of the queue, then I can reduce the amount of creating new threads.

I will check this.

[gdachs]

I sliced it with PrusaSlicer, but I don't believe that this is an issue. I could provide the .gcode file, but it contains some Klipper macros and will not work without changes in Marlin. If you are right with your idea, then I might suffer from that problem more than you, as the queue might get more often empty because of the speed of Klipper.

[gdachs]

Only to make it clear. As long as the bottom layers are printed everything is okay. It starts to stutter when the wall is around 10 mm. In the photo you have posted you are not high enough, but it is not clear to see.

[gdachs]

Why do you not create the queue on startup and keep it all the time?

[OllisGit]

Hi, I did some improvements in the newest release 1.22.0. Now the Threadcount is drastically reduced.

Hopefully you can see this improvement also in your print.

Please test and give feedback. Thx, Olli

[sddev0]

I will test it this weekend. But to say this clearly: I see a problem with refreshing so often. It‘s not only the thread in DisplayLayerProgress. With each call in vase mode an event is fired which may be handled by other plugins (e.g. OctoDash), the GUI is updated several ten times a second etc. Flooding the event system is not a good behavior in my opinion.

[OllisGit]

Hi @sebadue ,

I totally agree with your opinion about sending data too often to the GUI. Thats the reason why I only send messages to the UI if the message was really changed (independent from the fired event).

E.g. you defined a display-pattern which includes only layer-information. The progress-changed event was fired and processed by DLP, but the Layer is not changed so there is no traffic to the frontend.

I don't agree with your sentence "updated several ten times a second". Which events should cause this behaviour? Vase-Sample: Printing one single layer takes 3-5 seconds (on my printer). In that timeframe nothing is updated in the ui, because nothing relevant is changed, maybe the progress increased once. After that, a single Layer/Z-Change event is fired....but thats all. -> 1-3 events per layer, per 3 seconds

Maybe I missed something.

[gdachs]

@sebadue it looks like that the events are not fired on every change of Z height, that would be a problem in vase mode. Layer change and Z height change are not the same. Look at this snippet from the Julia vase gcode:

;BEFORE_LAYER_CHANGE
;1.3
G1 Z1.100 F7800.000
;AFTER_LAYER_CHANGE
;1.3
G1 F1800.000
G1 Z1.102 X144.483 Y187.260 E270.43385
G1 Z1.103 X143.829 Y186.595 E270.46543
G1 Z1.104 X143.234 Y185.928 E270.49566
G1 Z1.105 X142.992 Y185.607 E270.50929
G1 Z1.105 X142.739 Y185.312 E270.52242``` 

[sddev0]

@gdachs & @OllisGit: What I read from the source code is that there is a regex ("Z_HEIGHT_EXPRESSION") which every single gcode line is checked against, when it is "sending" to the printer. It matches all G0 and G1 codes which contain a "Z" value. If that expression matches, the _updateDisplay() method is called which includes event propagation etc. (codeline 441 - 451). On your example all five "G1"-lines match as they contain a Z coordinate and this leads to an update of z-height with the reason "UPDATE_DISPLAY_REASON_HEIGHT_CHANGED". In the updateDisplay that even triggers sending an M117 to the printer, if configured. In vase mode each and every move changes the z-height. That is no "layer"-oriented process, even though some slicers count a layer on each full revolution. What I want to say is in vase mode each G1 move calls the update function, which is rather "expensive", because of the inherent and explicit height change. Layer change is another topic which seems not to be involved into our performance issue, as it does not happen more often than in conventional mode.

[gdachs]

@sebadue sorry, you are right. I have thought falsely that the pattern that is used would only match BEFORE_LAYER_CHANGE. That means for me that it makes not very much sense to test the new version. I had used OctoDash and the DashBoard plugin before I disabled this plugin. Not sure what to do now? I don't print vases very often, hmm...

[OllisGit]

Hi @gdachs, between Version 1.21.0 and 1.22.0 there is a huge improvement, because the Thread-Ressource is reused instead of creating thousand of new threads. So the memory/cpu consumption is reduced....and if no one with the issue could re-test the new version, then I am not able to improve the behaviour!

@sebadue correct, each gcode is analysed, but already mentioned not in the same thread that OP use for sending the gcode to the printer, so sending should not be blocked. Also, ONLY if values were changed a message is sent to the display or to the eventbus. E.g. if you want to display the z value, then on each change the display is changed as well.

But it looks like that this approach is not enough. What kind of "support/fix" could I implement?

• As suggested from you: Don't analyse the gcode for a couple of n-seconds.
• Add a disable-button in OP-GUI to totally disable the gcode-analyse during print (prevent disable plugin and server restart)
• .... any other suggestion?

[rlogiacco]

My advise is to add a timer (5 sec?) and check if that time has passed since last z-update: If not, then do not send any notification or event. Normal files will never be affected, vase mode files will still get updates, but at an acceptable rate. If you also make that value configurable you get a safe next against slow processing and enable fast boards to lower it as needed.

[stale[bot]]

This issue has been automatically marked for closing, because it has not had activity in 30 days. It will be closed if no further activity occurs in 10 days.

[krystiancharubin]

After a few hours of searching why my vase mode print quality is bad, I finally found this thread. Like other after completely disabling DLP print quality is perfect. Left: DLP Enabled Right: DLP Disabled

[OllisGit]

Hi, the new version 1.24.0 has some improvements that could help printing in vase-mode.

First, as @rlogiacco suggested, I added a interval timer how ofter the printer display should update. The second improvement reading plugin settings from OP, this is now much faster. Thx, @gdombiak!

Please so kind and test the new version and give a feedback.

Thx, in advance Olli.

[stale[bot]]

This issue has been automatically marked for closing, because it has not had activity in 30 days. It will be closed if no further activity occurs in 10 days.