-
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
print jerk #33
Comments
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). 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. |
Humble I also tried to disable of the log of "sent" commands.. but it seems that this does not impact the performance. |
Obviously thank for the fast answer! :) sometimes i'm a bit direct! |
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. |
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.
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. |
Hi, the model i used is marvin 0.5mm wall, 0.25mm layer 0.5mm nozzle 40mm/s.speed. |
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.
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.
The text was updated successfully, but these errors were encountered: