Display Layer Progress Plugin issue

[spiff72]

What doesn't work?
I have noticed lately that Octoprint is very sluggish - I can see some printer moves are running slower than they should. I ended up switching to printing from the SD card instead. But today I saw a notice in octoprint that the DLP plugin is having some issues.
OllisGit/OctoPrint-DisplayLayerProgress#124
I would like to temporarily disable DLP plugin and Octodash (since it requires DLP), but I don't know how to disable Octodash.

[UnchartedBull]

comment out the last two lines in your ~/.xinitrc and reboot.

So replace:

ratpoison&
octodash

with:

#ratpoison&
#octodash

Once you want OctoDash to work again just remove the # in front.

[spiff72]

Awesome! Thanks!

Have you heard of the issues with DLP?

[spiff72]

And could Octodash actually run with the DLP plugin disabled? I already miss having the display running next the the printer as I am running a test with both disabled.

[UnchartedBull]

Yeah I‘ve just got the notification today. Haven‘t experienced them myself though ... Let‘s see how long it takes him to fix it. I‘ve already started making most of the plugins optional and having the option to disable them, so I might just add a switch to turn DLP off in the future too.

[spiff72]

ok - thanks!

[brgavino]

To add in here - If DLP is disabled, and OctoDash is still running, the pi will be inundated with a cascade of error messages and will slow substantially. This also seems to happen when an API key is incorrectly entered. It looks like the error message thread just keeps churning, and multiple connection attempts are made etc. Just found these both out while installing, then troubleshooting this layer shift issue.

[UnchartedBull]

OctoDash will query the API every x ms (defined in the settings), no matter if the request before returned an error or not. While OctoDash cleans up the data, Webkit will keep the HTTP Error message in the console, which results in an increasing memory footprint, which slows the Pi down. I'm yet to find a way around this error / beahvior. Clearing the console might work, although this could oppress useful information.

[brgavino]

@UnchartedBull Is it possible to implement a backoff timer, to lessen the impact of the errors in the console? Or perhaps a "max error" rate before logging to the console. Which file(s) is this logic currently implemented?

[UnchartedBull]

Basically all http requests are handled in the files with *.service.ts ending. Currently I'm using an RxJs timer, so I don't know, whether they support that.

I just heard in another issue that OctoPrint has the ability to push updates via a WebSocket similar way. This would greatly reduce load on the Pi. I'll definitely have a more detailed look into that, as this would make most of the GET Request (these are the only ones, that are triggered based on a timer) obsolete. https://docs.octoprint.org/en/master/api/push.html

[Protoncek]

Damn... i have layer shifts, too... so i just disabled DLP and of course i've had to disable OctoDash. Does this mean that until they repair DLP i can't use OctoDash at all? I'm so used to it that i can't even print now... can you make OctoDash to work without this plugin?

[UnchartedBull]

https://drive.google.com/open?id=1otL6i0C_2_SrPob7I16oGuVg1xsnt0YU here is a dev build with DLP just commented out. Fanspeed doesn't work and of course there is no layer indication. Otherwise this should work just like 1.4.1.

Did a quick test and the DLP API wasn't queried.

[Protoncek]

Many thanks!
I'm just printing something, it will finish soon and i'll try.
EDIT: it works! Layer info is not shown, as you said. I will try experimenting with M117 command...

BTW... i noticed in the package that localized versions are present (including Slovenian) - how to select language?

[floridaservices]

https://drive.google.com/open?id=1otL6i0C_2_SrPob7I16oGuVg1xsnt0YU here is a dev build with DLP just commented out. Fanspeed doesn't work and of course there is no layer indication. Otherwise this should work just like 1.4.1.

Did a quick test and the DLP API wasn't queried.

Thanks for this, I was missing my OctoDash!

[spiff72]

Can this be installed over top of the current (latest) version?

[Protoncek]

Sure, i installed it like it’s written in wiki under “manual installing”. You just need to run that part where .deb file installation is explained. Of course you must transfer .deb file into your pi first, don’t use wget command...

[Syco54645]

So if I may add something to this, dlp was causing issues on my rpi3. This was actually a development system so had a ton of plugins I didn't need that I was just testing. Anyway even after removing most of the plugins I was still having stalling on circles. by disabling and plugins I found dlp was the culprit and causing stalling (I don't run octodash currently but am investigating using it). I fixed the stalling by changing the CPU governor on the rpi from ondemand to performance. In my experience ondemand governor is not good when you have time sensitive things, it takes too long to ramp up. Anyway I fixed it and posted instructions on Reddit. I highly recommend everyone running octoprint change their governor, regardless of if you are having issues. You should probably add a heatsink and active cooling if you go this route.

https://www.reddit.com/r/octoprint/comments/g9oenz/any_solution_to_stutters_ender_3_with_abl_running/fozg3j3

[spiff72]

I tried upgrading to a Pi4 over the weekend (2GB) and it helped a bit with the stalling, but I still can see it. Do you think your approach above would work on a Pi4?

[spiff72]

To add to my above question - it seems like this would force the CPU to 1.5GHz all the time, right? I would wonder if the temps would run high. I do have a fan hat installed on mine, so I might try it out.

UPDATE: I just tried it on my Pi4 and it indeed helped a lot. I didn't let print finish, but just watched as it printed some areas of my test part and didn't see the stuttering/stalling at all. It also seems to be keeping it's cool (as much as it can as a Pi4) with the fan.

[jalanjarosz]

I setup some scripts to switch between performance while printing and on-demand when not. I’ll pull things together and post it Thanks! James On May 3, 2020, at 7:14 PM, spiff72 <[email protected]> wrote:  To add to my above question - it seems like this would force the CPU to 1.5GHz all the time, right? I would wonder if the temps would run high. I do have a fan hat installed on mine, so I might try it out. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#584 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJYADF3LLGBIHBJ4IKFHLVTRPX3DPANCNFSM4MNLB67Q>.

[Syco54645]

To add to my above question - it seems like this would force the CPU to 1.5GHz all the time, right? I would wonder if the temps would run high. I do have a fan hat installed on mine, so I might try it out.

UPDATE: I just tried it on my Pi4 and it indeed helped a lot. I didn't let print finish, but just watched as it printed some areas of my test part and didn't see the stuttering/stalling at all. It also seems to be keeping it's cool (as much as it can as a Pi4) with the fan.

Temps should be safe using active cooling. I find this to be a good test for stalling. I have also sliced benchy to just get the roof up. Circles cause major issues.

I setup some scripts to switch between performance while printing and on-demand when not. I’ll pull things together and post it Thanks! James On May 3, 2020, at 7:14 PM, spiff72 [email protected] wrote:  To add to my above question - it seems like this would force the CPU to 1.5GHz all the time, right? I would wonder if the temps would run high. I do have a fan hat installed on mine, so I might try it out. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#584 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJYADF3LLGBIHBJ4IKFHLVTRPX3DPANCNFSM4MNLB67Q.

Scripts would be super useful and am curious to see what you come up with. I really do not mind running my pi at 100% all the time but it is a waste of power.

[Protoncek]

I have Rpi4 and i have layer shifts, so i doubt that it's Rpi's cause. Pi4 has more than enough power to run octoprint, in fact CPU usage never gets over 10% or so.

[Syco54645]

I have Rpi4 and i have layer shifts, so i doubt that it's Rpi's cause. Pi4 has more than enough power to run octoprint, in fact CPU usage never gets over 10% or so.

The layer shifts were happening due to DLP plugin on certain printers.

[spiff72]

I have Rpi4 and i have layer shifts, so i doubt that it's Rpi's cause. Pi4 has more than enough power to run octoprint, in fact CPU usage never gets over 10% or so.

I find my Pi4 CPU usage can get as high as 25-30% (as reported by the Dashboard plugin) during some print moves (very short, movements in quick succession).

[jalanjarosz]

Modifying CPU performance via scripts -

Here is a good method that you can modify CPU from the default of "ondemand" to "performance" and back again during printing.

1. Install "Action Commands" plugin
2. Configure "Action Commands" plugin with the following:
   a) action: performance_cpu type: system command: echo "performance" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
   b) action: ondemand_cpu type: system command: echo "ondemand" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
   c) action: powersave_cpu type: system command: echo "powersave" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
3. Configure Linux with the following:

cd /etc/sudoers.d
sudo vi octoprint-cpu

You can use nano as well, and add in the following line:

pi ALL=NOPASSWD: /usr/bin/tee

Save and exit.
This will allow the "pi" user to change the CPU speed without a password.

4. KLIPPER FW CONFIG OPTION:

# Enable the "M118" and "RESPOND" extended commands.
[respond]
default_type = command

Restart octoprint service or reboot SBC/Computer.

5. Test by entering the following:
   Klipper: M118 action:performance_cpu
   Marlin: M118 // action:performance_cpu
   CPU should now be set to MAX speed.
   Klipper: M118 action:ondemand_cpu
   Marlin: M118 // action:ondemand_cpu
   CPU should be set to the default mode.

(Updated to add in Klipper and Marlin M118 G-Code requirements)

You can use the Action Command M118 codes in your slicers START/END G-Code.

[spiff72]

Does this only work with Klipper (which I am not familiar with)? Or is that Klipper section specific to Klipper firmware only and not needed for other firmwares?

I gather that the changes shown above to the start/end gcodes in the slicer would accomplish the governor changes automatically.

I actually considered using the scripts above and adding them as system commands in octoprint (where i placed a bunch of commands for turning the light and printer on/off, and adjusting camera focus. But I know I will inevitably forget to do this.

[Syco54645]

Modifying CPU performance via scripts -

Here is a good method that you can modify CPU from the default of "ondemand" to "performance" and back again during printing.

1. Install "Action Commands" plugin
2. Configure "Action Commands" plugin with the following:
   a) action: performance_cpu type: system command: echo "performance" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
   b) action: ondemand_cpu type: system command: echo "ondemand" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
   c) action: powersave_cpu type: system command: echo "powersave" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
3. Configure Linux with the following:

cd /etc/sudoers.d
sudo vi octoprint-cpu

You can use nano as well, and add in the following line:

pi ALL=NOPASSWD: /usr/bin/tee

Save and exit.
This will allow the "pi" user to change the CPU speed without a password.

1. KLIPPER FW CONFIG OPTION:

# Enable the "M118" and "RESPOND" extended commands.
[respond]
default_type = command

Restart octoprint service or reboot SBC/Computer.

1. Test by entering the following:
   M118 action:performance_cpu
   CPU should now be set to MAX speed.
   M118 action:ondemand_cpu
   CPU should be set to the default mode.

You can use the Action Command M118 codes in your slicers START/END G-Code.

Nice work. I am in the middle of a print so am unable to check right now but does the echo "performance" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor affect all cores or only 0? I tested on my desktop (running Debian) and according to cpufreq only the first core was affected. On my desktop changing the command to echo "performance" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor will affect all.

[jalanjarosz]

@Syco54645, I checked the other three cores of my Pi 3B+ and the setting seems to be across all cores. I’ll double check my TinkerBoard running Armbian to confirm.

[jalanjarosz]

@spiff72 ,
You can do this with Marlin too.
My A8 is Marlin and I have to use commands like:

M118 // action:ONDEMAND_CPU

Only difference is Marlin I had to add in the extra // characters. ( I updated my original post to include the Klipper/Marlin differences).

Klipper FW needs an extra config option in order to enable the M118 G-Code and that adds in the // characters.

@Syco54645,
I confirmed, running the single command extends the setting across ALL cores:

pi@octopi:/sys/devices/system/cpu $ cat cpu0/cpufreq/scaling_governor
performance
pi@octopi:/sys/devices/system/cpu $ cat cpu1/cpufreq/scaling_governor
performance
pi@octopi:/sys/devices/system/cpu $ cat cpu2/cpufreq/scaling_governor
performance
pi@octopi:/sys/devices/system/cpu $ cat cpu3/cpufreq/scaling_governor
performance

[Protoncek]

Nope. I just tried it and going back to "special" temporary version.

[floridaservices]

Nope. I just tried it and going back to "special" temporary version.

Thanks for this update, I will have to stay on the dev version

[Morcegolas]

Nope. I just tried it and going back to "special" temporary version.

Thanks, I’ll stay in this version too, with my Prusa having layers shifting I don’t have another option.

[UnchartedBull]

https://drive.google.com/open?id=1r2mOpJoMfVI0cdfyzOaTNxkRfLdYN7Ny here is v1.5.0 without DLP. Let me know if it works.

[Protoncek]

It works, thanks!
I only wish that OllisGit will find error in his DLP plugin soon...

[xrrkrrkx]

might be wrong here as i am soooo very new to all of this. (btw, OctoDash is fantastic!! it completely changes the whole 3d printing experience, at least for me)

i have 1.5 installed. i go to plug ins and there is a grey box filling in the tick box for DLP, BUT it is not changeable. I go to OctoPrint & it is enabled. I disable it from OctoPrint plug in manager & then OctoDash goes nuts.

Am I missing something?

please help, thanks!

[Protoncek]

You can't disable DLP in OctoDash. If you intend to work without it you must manually install above "hacked" version. For that you must transfer above file from google drive onto your PC, then putty into your octoprint, transfer file there and run:

sudo dpkg -i octodash_1.5.0_armv7l.deb

[johnrbussard]

Modifying CPU performance via scripts -

Thank you so much for this! Changing the cpu governor was the final step (along with increased marlin buffers, and updates to DLP) that I needed to get my octoprint quality to be as good as from the sd card.

[UnchartedBull]

Since the issue seems to be resolved, I'm going to close this issue. I'll leave 1.5 without DLP in here. Further releases will have DLP mandatory again (until I find a good way to make DLP optional)

[Protoncek]

Well, for info: since prusa released final version of 3.9.0 FW and DLP was also updated at appr. the same time now i use “normal” octodash with DLP enabled and i didn’t have any layer shifts so far. Crossing my fingers...

[spawnrider]

I still having layer shifting with 3.9.0 FW on prusa on my Pi3 with Octodash / DLP :(

[mdaneman]

I have to add that I too see occasional layer shifts with Prusa FW 3.9.0 and the latest DLP. It’s not as frequent as with the previous DLP version, but still happens. I disabled DLP until this is addressed.

[UnchartedBull]

Ok since the issues didn't seem to be resolved fully:

After the release of v2 I'll work on issue #595. This involves some major rewrites of almost every service that somehow interacts with OctoPrint. The upside of this is, that this makes DLP optionally, since OctoPrint does support sending the current height via the push update. This will probably take some time, since I have lots of other stuff at hand currently. Will try todo this for v2.1.0 though.

[pilotw7]

Is there a build of 2.0.0 yet that is "hacked" to not have DLP? or is the 1.5.0. build the only option still?

[Protoncek]

Because of my own stupipdity (i messed too much in Linux) i've had to rebuild my Octoprint from scratch. I've had no (or veeery few) shifts before. Well, after rebuild it started... first print: one shift at appr.10mm, second shift at appr.40mm (stats said i've had 6 crashes!). Second print: first shift at appr.8mm. I clearly heard "bump" when it happened (i was 1m from printer). Printer clearly missed that bump and didn't go into re-homing procedure. Then i did some investigation and fpound out that metal rod, which holds bearing for Y side of printer runs veeery near (too near) of a frame and it hits if i just press on the table slightly. Then i raised my table for 1mm and had no shifts. Could this be really an issue here? Those who have prusa please check out the distance of that metal rod on your printer. Picture is attached, although not good quality (it's dark under there...).

[UnchartedBull]

Sorry for the wait. Here is v2.0.0 without DLP: https://drive.google.com/file/d/1-OcUZOLr9zrxfd5P9Ybi81zIekI15GaW. If something doesn't work feel free to comment here :)

[Daghis]

Thanks for providing that file. I wanted to give you feedback from when I tried it.

This is how the installation went for me:

pi@mk3s:~ $ sudo dpkg -i octodash_2.0.0_armv7l.deb 
[sudo] password for pi: 
(Reading database ... 62951 files and directories currently installed.)
Preparing to unpack octodash_2.0.0_armv7l.deb ...
Unpacking octodash (2.0.0) over (1.5.0) ...
Setting up octodash (2.0.0) ...
/var/lib/dpkg/info/octodash.postinst: line 10: update-desktop-database: command not found
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for mime-support (3.62) ...
pi@mk3s:~ $

It seems to be working fine (no error pop-ups). The percent indicator is updating, but it does say "Layer -- of ?". I assume that's expected given the removal of the DLP dependency.

[Protoncek]

Without DLP you loose layer info as well as some other data, yes.
But, i’m seriously beginning to doubt into DLP’s fault. Nothing is really happening in this regard for some time now, because quite some guys had layer shift even with DLP disabled.
I have no shifts (with DLP enabled) since i raised my bed and it doesn’t bump into frame anymore.

[spiff72]

If any of you have Prusa printers, do you have crash detection turned on or off? I have had this turned off for quite a while and still use DLP with no shifts.

[Daghis]

My own experience, for what it may matter:

• My Prusa i3 MK3S does have crash detection enabled.
• With DLP and OctoDash enabled, I had many unexplained layer shifts. (I'm not suggesting that OctoDash was involved, just that it was part of the picture at the moment.)
• With DLP disabled (still installed, just turned off in the list of plugins), and with OctoDash still enabled, no more problems with layer shifts, but I did get the frequent pop-up errors on the touchscreen (as expected).

[UnchartedBull]

With DLP disabled you will loose Layer and Fan Information. If one day the push updates are implemented in OctoDash the layers will be replaced with Z-Height, if DLP is disabled.

[Kawuezel]

Hi,

I just wanted to know if in version 2.1 or 2.2 there is the option to disable DLP?

Thanks

[UnchartedBull]

jneilliii has a No-DLP version on his fork: https://github.com/jneilliii/OctoDash. For 2.1.1 the custom version is still needed, once v2.2 is ready you should be able to disable DLP from the UI.

[pilotw7]

How do you download the version from his fork? From the looks of it the page looks identical to yours with the same link

[UnchartedBull]

just wget <link from release page> and then sudo dpkg -i <downloaded file>

Or execute his update script. He updated the links there