Skip to content
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

print jerk #33

Closed
federicobrianosv opened this issue Oct 10, 2014 · 6 comments
Closed

print jerk #33

federicobrianosv opened this issue Oct 10, 2014 · 6 comments

Comments

@federicobrianosv
Copy link

Great work!
I have a question. I notice that the printing process is not smooth. It often jerk, it looks like the browser is to slow to send the commands to the printer. The problem occurs only on small edge. Do you have any idea about the source of this problem? Of course this is not happening using other application.

@sir-buckyball
Copy link
Owner

The last time this came up, it was because the scrollback history in the command console was too large (chrome spent most of it's time rerendering that). It only became an issue on large files. I thought I had addressed it by lowering it to a limit of 120 (which ran fine on an HP Chromebook11).

0eaaf58

Issue #6 is to make that scrollback configurable, but I haven't gotten around to implementing it yet. It should be fairly easy to do with the latest refactoring (feel free to give it a try).

It's also worth asking if your computer is doing anything else while sending files (eg., playing youtube)? I believe chrome favors the front window in terms of CPU time.

@federicobrianosv
Copy link
Author

Humble
window.setInterval(processCommandQueue, 50);
I lower down from 50 to 5 ms and the jerk goes away. But.. there can be some sort of "collateral" effect?

I also tried to disable of the log of "sent" commands.. but it seems that this does not impact the performance.

@federicobrianosv
Copy link
Author

Obviously thank for the fast answer! :) sometimes i'm a bit direct!

@sir-buckyball
Copy link
Owner

Nice investigation work. It sounds to me like the file you are trying to process is possibly over-specified (eg., it has extremely small command steps which your machine completes in less than 50ms [which while large in CPU time, is very small in mechanical movement time]).

I suspect that setting it to 5ms will be problematic for slower computers unless some update limiting is implemented to restrict how often the command log is updated. That shouldn't be too hard to implement.

If you don't mind sharing your gcode file, it'd be nice to confirm my suspicions.

sir-buckyball added a commit that referenced this issue Oct 11, 2014
Update the command log at most 5 times a second.

The command log internally can be updated very quickly if the connected
machine consumes the commands quickly. If we tried to update the
displayed log that fast, the machine would quickly get bogged down with
rendering and won’t send commands at the rate we need.

This change partially addresses issue #33.
@sir-buckyball
Copy link
Owner

I've just release version 2014.10.10.0 on the chrome web store. Please let me know if that resolves your issues. I was a bit worried about speeding up the interval too much so I only set it to 10ms instead of the 5ms you proposed.

@federicobrianosv
Copy link
Author

Hi, the model i used is marvin 0.5mm wall, 0.25mm layer 0.5mm nozzle 40mm/s.speed.
The generated gcode is around 425Kb
http://www.thingiverse.com/thing:215703

sir-buckyball added a commit that referenced this issue Oct 13, 2014
a better fix for issue #33. The timer interval remains in place to
catch any messages that fell through the crack, but the bulk of the
processing is done in response to message from the serial device.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants