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

Emulate M20-M32 #10

Open
Wallacoloo opened this issue Sep 26, 2014 · 2 comments
Open

Emulate M20-M32 #10

Wallacoloo opened this issue Sep 26, 2014 · 2 comments

Comments

@Wallacoloo
Copy link
Owner

M.S. via e-mail, reproduced here:

What if we emulated M20-M32 (all of the sdcard functionality) using the filesystem? It would allow the use of the standard octoprint front end, but would allow the firmware to parse, validate, pre-compute acceleration and inverse kinematics, and encode the print as a nice binary stream. All of the IO and trajectory planning overhead should pretty much go away...

The major downside to such a scheme is a somewhat inefficient use of disk space (octoprint already saves things to disk...) but a judicious application of zlib could solve that, at the expense of cpu overhead.

@Wallacoloo
Copy link
Owner Author

Emulating M20-M32 would be fairly trivial. You could even set it to read from the same directory where Octoprint stores its files (~/.octoprint/uploads) to avoid some unnecessary disk usage.

One downside to this is that you no longer have the gcode visualizer that Octoprint provides.

The upside (among others) is that you bypass a fairly significant overhead which Octoprint introduces when streaming gcode to the host - it has its own gcode parser, because it needs to keep track of which coordinate modes you're using in order to allow to manually control the printer correctly - thus, when you command the printer to move a relative distance, Octoprint won't know whether to set the mode back to absolute or relative after the motion is complete. A pretty minor loss, if you ask me.

So yes, I think implementing M20-M32 is a good idea for the immediate performance gains. I'm not sure what the cpu usage of Octoprint gcode streaming is, but I will benchmark it later.

So your idea - is it to pre-process the entire file before even beginning a print? Or to essentially cache the computations to disk in real-time during a print in order to reduce cpu load whenever the part is re-printed?

@Wallacoloo
Copy link
Owner Author

Began implementing M20 today, and somewhat surprisingly, C++ still has no standard interface for listing a directory. Opening and reading files can be done cross-platform. Looks like the best way to do directory iteration is to use the posix interface and just use dirent.h (a posix file interface emulator for Windows, and potentially other OS's?) on other systems. There's also https://github.com/cxong/tinydir/blob/master/tinydir.h

@Wallacoloo Wallacoloo changed the title Emulate M20-M32 in order to pre-compute kinematics Emulate M20-M32 Jan 11, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant