-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does not play nicely with vase mode #131
Comments
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". 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:
|
Printer is an Ender 3 running Marlin 1.1.9 with latest bugfixes. 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.... |
Hi @rlogiacco Because it is just an assumption, please test and give me a feedback. Thx, in advance |
I installed
In the meanwhile I believe my only options will be to disable it while printing in vase mode... |
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. |
Sorry for the late reply, but my printer was in upgrade mode. |
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. |
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... Thanks |
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. |
Sure, no problem! Thanks! |
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. |
Oh, and one machine has a raspberry pi 3 the other has a pi 4. 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. |
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... |
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. |
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. |
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. |
@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. |
I forgot to ask @rlogiacco: do you still have the issue or is there a new one? Do you use the this plugin: https://plugins.octoprint.org/plugins/UltimakerFormatPackage/ ? |
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. 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. |
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. |
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. |
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. |
Why do you not create the queue on startup and keep it all the time? |
Hi, Hopefully you can see this improvement also in your print. Please test and give feedback. |
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. |
Hi @sebadue , I totally agree with your opinion about sending data too often to the GUI. 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? Maybe I missed something. |
@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:
|
@gdachs & @OllisGit: |
@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... |
Hi @gdachs, @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?
|
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. |
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. |
Hi, First, as @rlogiacco suggested, I added a interval timer how ofter the printer display should update. Please so kind and test the new version and give a feedback. Thx, in advance |
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. |
In a way it makes a lot of sense, in another it made me force to disable the plugin.
![photo_2020-04-03_17-57-07](https://user-images.githubusercontent.com/199473/78380705-90bc5680-75d4-11ea-9d00-c314baf28ee3.jpg)
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".
The text was updated successfully, but these errors were encountered: