Jittering when plugin enabled #62
Comments
|
I dunno why this is happening anymore. I removed all the processing while printing so it shouldn't be slowing down yet somehow it still is. So strange! Can you send the log files? Are you trying to analyze files while printing? There is a setting for that and perhaps you need to leave it off. |
|
Im observing the same issue. I just updated PTG from 1.1.1 to 1.1.3. Suddly lots of jittering and short stops during the print. I disabled the plugin and started the same gcode file again -> way better print quality and no more jittering. I will try to get a log file for the two prints once the one with the disabled plugin is finished and see if theres something interesting in it. |
|
Confirming sbombay's comment - I had a print last night that were basically two upright cylinders and they had blobs/zits everywhere, and I noticed that the motion was not smooth around the entire circle but jerky/stuttery as described in this issue. I did make sure the 'analyze files while printing' was unchecked and presumably off. I had freshly updated to 1.1.3 via Octoprint's built in updater just before that print. |
|
To follow up on this. I checked the log files but theres nothing suspecious in them.. No errors, warning or anything. To show how severe this problem is, here you can see the print time of the same gcode file with and without PTG 1.1.3 enabled.
|
|
I wanted to get into detail on this so I checked several versions (1.1.3, 1.1.1, 1.0.9, 1.0.7, 1.0.6 and 1.0.1). On all versions, I observed the same jittering. Therefore I moved back to version 1.1.3 and enabled debug logs for PTG to see if the analyzer is running while printing and if theres more details in the logs. However, suddenly the stuttering was gone! I uploaded a new .gcode file by drag&drop and using the CURA api to see if I can make it running, but still no stuttering. Everything suddenly works as intended. Kinda dissatisfying.. On a side note: I usually start my jobs through the CURA api so maybe there is an issue with PTG not recognizing this correctly and not aborting when the print starts? Just a thought.. |
|
@danijoo, from my experience when gcode being sent using Cura's API, PTG does not have enough time to do its calculations before printing starts. double check that you see the gold-star before printing starts cause if not, then this might be the reason you don't get jitters, e.g. it's not that it works better - it does not work at all. |
|
@Thisismydigitalself okay, that is a good hint! There are two things that happen a lot while printing:
So I need to make the progress calculation faster. I'm sure I'll find something. I'll take a look soon and prepare a new release. Thanks to everyone for the help! |
|
It would help if I knew this: is the jittering a once-per-minute kind of thing or is it all the time? I mean, does it feel like the printer is just always in slomo or does it sppear that the printer is running smoothly for a while and then running poorly and then recovers? Any characterization of it would help. Someone uploaded a video once but I sadly can no longer access that video from the download site, maybe because it was too old. |
|
Its a once every few seconds thing - once every 2 seconds seems right. The
printer can be going in a constant angular velocity around a circle and
then just hiccups causing a blob. Then it recovers and goes around the
circle again. This has led to a weird z-seam-like effect but doesn't seem
like a real z-seam is in multiple places, inside and outside.
Here's a imperfect video I took yesterday that doesn't show the problem
really well, I took the video to demonstrate other issues (I have
unrelated problems with stepper motors causing the automatic bed level
sensor to trigger in midair). The object is this one
https://www.thingiverse.com/thing:951058
https://photos.app.goo.gl/Hpmxu3Fxvy4JRBVSA
I believe that one can replicate by printing a cylinder approx. 3.5cm+ in
diameter, and watch the printer go around. Vase mode should highlight this
even better.
…On Wed, Aug 8, 2018 at 9:41 PM Eyal ***@***.***> wrote:
It would help if I knew this: is the jittering a once-per-minute kind of
thing or is it all the time? I mean, does it feel like the printer is just
always in slomo or does it sppear that the printer is running smoothly for
a while and then running poorly and then recovers? Any characterization of
it would help. Someone uploaded a video once but I sadly can no longer
access that video from the download site, maybe because it was too old.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#62 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGZZtyPHql-_MN4fHKeSkKP7UA0IEeYHks5uO72BgaJpZM4VqzWe>
.
|
|
@eyal0 I was the one to upload two video files which you missed your 3 days window to download. With_PTG: https://expirebox.com/download/8de351ff5a64016f527e1b61fdf7fe02.html |
|
I looked at Thisismydigitalself's video and that's exactly bang on what I
was seeing happening on my first layers also!
…On Wed, Aug 8, 2018 at 10:37 PM Thisismydigitalself < ***@***.***> wrote:
@eyal0 <https://github.com/eyal0> I was the one to upload two video files
which you missed your 3 days window to download.
here they are again. links will expire in 3 days.
With_PTG:
https://expirebox.com/download/8de351ff5a64016f527e1b61fdf7fe02.html
Without_PTG:
https://expirebox.com/download/3b5eb6d96551ce49b9b3dd6d2fe2ddfc.html
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#62 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGZZt_vjsEOYsq9EO0wsbyAgiQY-x-Dyks5uO8qAgaJpZM4VqzWe>
.
|
|
@talldonkey @Thisismydigitalself I can confirm all of that! As a workaround, it might help to disable "Automatically start print job after uploading" in cura OP settings and start it manually from octoprint ui once you have the star |
|
@danijoo, nice workaround only if you want to load PTG. the purpose of this thread is to show there is an issue after PTG is loaded in the form of jitters all over the place. no matter how you load PTG - seeing the gold-star means troubles. |
|
I'm sorry that the gold star means trouble. It's supposed to mean happiness! I've tried 3 things:
By the way, do you have debugging on? |
|
@Thisismydigitalself Could you try two things for me? First, turn off debugging if you turned it on. The instructions are in the settings. Then try printing that same thing that you usually print to see if debugging output was the cause of the slowness. I added a warning in the settings about it now. I want to know if most of the problem was caused by debugging. In that case, the warning should help. Second, try this new version that is a little more streamlined around the time estimation code. I hope that it'll be better! https://github.com/eyal0/OctoPrint-PrintTimeGenius/archive/dev.zip Let me know. If that does't do it then I'll figure out how to run a profiler and really measure where the CPU is wasting so much time! |
|
It wasn't debug mode for me. I only turned it on after I see the lags.
…---- On Thu, 09 Aug 2018 22:04:12 +0200 notifications@github.com wrote ----
@Thisismydigitalself Could you try two things for me?
First, turn off debugging if you turned it on. The instructions are in the settings. Then try printing that same thing that you usually print to see if debugging output was the cause of the slowness. I added a warning in the settings about it now.
Second, try this new version that is a little more streamlined around the time estimation code. I hope that it'll be better!
https://github.com/eyal0/OctoPrint-PrintTimeGenius/archive/dev.zip
Let me know. If that does't do it then I'll figure out how to run a profiler and really measure where the CPU is wasting so much time!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@danijoo Okay. Well, let me know if you are able to install the link above and try it. Thanks! |
Eyal, Please accept my sincere apologies. never meant to sound negative but more like informative. all of us here wants PTG to shine and to make us happy! I will try your updated dev version and report back. please note that even a small unnecessary hiccup that will take place every 60 sec instead of 2 sec is not something I personally will take lightly. Thank you. |
|
I don't want any hiccups, not even every 60 seconds. I hope that with these changes I have eliminated both! I have reduced the processing to a real minimum, I think. If not, then I'll use a profiler to identify which lines are the worst offenders and try to fix those. But I don't see much space left for optimization. We'll consider the problem solved when actual print time both with and without are the same. I'm eager to here about your test results! Don't forget to turn off debugging if it is on. |
|
My first impressions from dev 1.1.3 needs no words so instead I captured your gold-star in action: looks promising. |
|
Just started a 3 hours print with 1.1.3 dev and gold-star'd g-code. |
|
Now I just wish I knew which change it was that fixed the problem! Probably it was saving the progress map locally. I used to fetch it from the metadata each time and I suspect that behind the scenes that was causing a read from the memory card each time. I'll make a new version soon. |
|
When I started this print I was prompted that print will take 2.5 hours. i am now 2.5 hours in and still got 40 minutes to go - progress bar reads 80% done. BTW, How can PTG calculate estimated print time without taking into consideration firmware acceleration & jerk settings? |
|
It does take acceleration and jerk into account! If you look in the PTG debug output, you can see where the input to marlin-calc includes mcodes 200-205. Those are jerk and acceleration among other things. |
|
After your print, look at the advanced settings and.compare the estimated printing time to the actual. Look at the part that doesn't include heating up or cooling down because those are nigh impossible to predict. Let me know if you're seeing estimates that are way off before compensation. Also, now that there is no jitter, the compensation values might be bad because PTG is assuming jitter! You can delete old print history and then hit save. If you copy paste that print history table here, I can take a look and see if anything looks wrong. |
|
Is this of any help?
And, to my question: I do not use my slicer's Acc & Jerk. i set it in my printer's Firmware so how can these be calculated by PTG? |
|
When your printer starts up, OctoPrint sends an M503 command to it. The printer responds by outputting all the firmware settings. PTG scans each line that comes out of the printer and saves the relevant settings, like M200-M205 and M92. PTG gives those to marlin-calc when it runs. To check if it's working, download the PTG logs and look for the call to marlin-calc. You should see your settings there. Let me know if they don't match the output of M503. Your first print shows that it spent 10512.1 seconds extruding. The prediction was 9637.7 seconds. The second print says 11376.5 vs 10357.5. That's about 9% difference each time. It's consistently 9% so the compensation ought to get pretty good answers. We see that most recent print, after compensation, predicted 10637.2. Compared to 10578.2, that's an error of 0.5%. That's pretty great, I think! Still, I would not expect a 9% error each time. Two possibilities that I can think of:
Good luck! |
|
Thank you for your elaborated reply. i think i am starting to understand how Genius your PTG really is. i will do some homework and come back with more information for you. Line 7: Line 6364: ... I don't want to dump my smoothie settings now as i don't trust the system to be robust and predictable while i am in the middle of yet another 3 hours print. i will check those later. |
|
Oh no, bummer, why "disabled"? That means that it didn't run marlin-calc. Even if you're using Smoothieware, you should still run marlin-calc because it's better than nothing. Just hit the reset Analyzers button and that will put everything back in order. The log line for marlin-calc actually spans multiple lines. That's why the Sorry that I forgot that you're using Smoothieware. I can't keep track of all the bugs! Someone made a smoothieware simulator called gcodestat. He claims that it's accurate down to, like, just seconds. I have considered adding it and I even have an issue open for it but it would be a good bit of work and I want to really make sure that it's a good idea first. That means that I need someone to run gcodestat on a file that has been printed and show that the estimate is so much better than the one marlin-calc is providing. Show me that and I'll be convinced that adding gcodestat is a good idea. So, how do we prove that gcodestat is any good? Download and run it on some gcode files and see how it does compared to the actual printer. I already have experience running gcodestat so if you don't want to do it, just send a gcode file here and I can run gcodestat and give you the result. For example, the one that took 10578.2 seconds or the one that took 11427.9 seconds. For accurate results, I'd need all the stuff that gcodestat asks for like jerk and acceleration and junction deviation and stuff. If you send me the output of M503, I can pull those out of there, I think, and use them. Or run gcodestat yourself and let me know how close it is. Up to you! If we find that gcodestat is awesome for Smoothieware then my next steps are:
|
|
Also, if you can't M503 right now, the M503 output was sent to marlin-calc and recorded in the log, so you can just get the rest of those "Running marlin-calc" lines and that'll work. M204 S500... what's the rest? Or, if you modified the firmware yourself, maybe you have it in some file there? Good luck! |
|
Hello again, After 10 hours prints i had some time to look a bit deeper (and also updated to latest 1.1.4). I Sent M503 manually. first thing to notice is that the Acceleration (M204) in PTG log is different than that of my firmware and M92 which is nowhere to be found. My firmware acceleration is set to 750 and in PTG log file reads S500. i can look for other settings but it seems there is an issue here. i can check the rest later today. Correct me if I'm wrong but it seem that PTG does not work in my case. BTW: what mechanism sends M503 before printing? i don't see it in OctoPrint nor in your plug settings. does this happens behind the scenes during connection? My M503 dump below (M200 set to 0 but not found in PTG log): Recv: |
|
Okay. First, I want to move this to a new issue because I feel like the jittering has been solved. I don't want people to come here and think that there is still an issue. So I'll open a new issue: #66 I'll write more there. |
Before reporting, check if your problem is here:
https://github.com/eyal0/OctoPrint-PrintTimeGenius/wiki/Common-problems
Please fill this out:
OctoPrint Version: 1.3.9
PrintTimeGenius Version (if you know):
latest as of 2 days ago
What did you try:
What happenned:
print head stops for milliseconds randomly, especially printing curves leaving blobs.
Had this happen on 2 printers. Deleted plugin and no more jittering or blobs with same gcode.
See OctoPrint forums/Get Help. Search for plugin name.
Others also seeing same issue. Mods reference known bug with this plugin.
What did you expect to happen:
If relevant, upload the PrintTimeGenius log and any problematic gcode files (you might need to rename them).
The text was updated successfully, but these errors were encountered: