GCode Renderer / Viewer

[UnchartedBull]

Integrate a GCode Renderer to preview the printed file. Ideal solution would be a JavaScript Script, but Python should work as well. If you know a tool or have a selfwritten one at hand, please let me know. Your work will be acknowledged and you will be credited of course.

[hessius]

Could something like this be used?
PrettyGcode viewer
Forums: https://community.octoprint.org/t/wip-prettygcode-viewer/12169
Github: https://github.com/Kragrathea/OctoPrint-PrettyGCode

[UnchartedBull]

That does look good, there is no API though. I'll test it and may use it for OctoDash thanks.

I also can think of doing this: https://github.com/hudbrog/gCodeViewer. Just leaving this here for later.

[hessius]

👍 That looks like a much easier route!

[tiwo85]

How about Octoprint Plugin: Ultimaker Format Package. It generates a thumbnail whe you are uploading a file to Octoprint and store it to /home/pi/.octoprint/data/UltimakerFormatPackage/

[UnchartedBull]

Looks interesting, but I need to upload the ufp file each time, don‘t I? This would exclude all Slic3r users and create lots of files.

[jneilliii]

I second the PrettyGcode option. That is a generic approach and would allow for any slicer. You might not need the entire complexity of what that plugin does, but the underlying framework is utilizing three.js as demonstrated here. Just not sure if the octodash interface is webgl compliant or not? Having the preview available while printing would be nice as well, maybe via a button.

Even with that being a generic approach I do still think having the UFP plugin supported would be nice as well and probably easier to implement because you just have to open a png file stored locally in the path @tiwo85 mentioned. The png filename matches the gcode filename, replacing .ufp.gocde with .png.

[jneilliii]

So I just pushed an update that may make this much easier to implement with the UltimakerFormatPackage plugin. The plugin will now update the file's metadata, which appears you are already pulling from OctoDash. The path I used was refs > resource and is a relative URL to the thumbnail from the octoprint's base url. So for example if the filename is CCR10_Hyperpixel_4.0_Pi_4B_Case.ufp.gcode the URL will be /plugin/UltimakerFormatPackage/thumbnail/CCR10_Hyperpixel_4.0_Pi_4B_Case.png. Prepend that with the base url for OctoPrint and you get the full path to the image to display like http://localhost:5000/plugin/UltimakerFormatPackage/thumbnail/CCR10_Hyperpixel_4.0_Pi_4B_Case.png.

I wish I was more familiar with the angular.js framework, but unfortunately don't have the time to learn, so can't really assist with creating a Pull Request.

[jneilliii]

So I took a little time to try and understand how this works in angular and the REST API of OctoPrint and came to the conclusion that the update I just pushed to the plugin is of no use, because the REST API actually overwrites the refs with internal download links, etc. I was able to hack a solution together though that appears to work with a little tweaking of the file-service component.

It only does it on files that end with .ufp.gcode, which is how they get named when uploaded with my plugin. Submitted PR #464 for review as I'm sure I did something in a non-angular fashion.

Would probably be nice to expand this to the current job screen as well somehow.

[UnchartedBull]

I worked with three.js once and actually liked it. Didn't know PrettyGCode is also utilising this. The ufp support is definitely a nice addition, even if a GCode Renderer is implemented, downloading the png will be faster and most likely will look better.

Having a live animation while printing might also be super neat, although performance might suffer, have to check that once v2 is released. Showing a static image in the current job progress might also not be that easy, since there is not much space left on the screen and replacing the progress indicator might not be beneficial, at least for a static image. If you have any ideas let me know, would be super nice to have that!

Thanks for the PR, I'll review that once I have some spare time to test it, looks good so far though :)

[jneilliii]

since there is not much space left on the screen and replacing the progress indicator might not be beneficial, at least for a static image. If you have any ideas let me know, would be super nice to have that!

My thought was to have a button like a [!WEB] custom action, that would open the image url in the iframe, but the only issue I see is the REST API for job info doesn't return the full path, just the filename. So if the file was in a subfolder the path for the png image wouldn't be correct using the same method I used for the file-service module.

[UnchartedBull]

Ah that would be a problem, but maybe is the something that can be done in OctoPrint. I'll open an issue there once I'm starting working on that to see if they're willing to do that.

Otherwise it would be possible to remember the path from the file selection, this would work only for jobs started from OctoDash though ...

[jneilliii]

So I just found this in the OctoPrint issue tracker. Apparently the path is included the job api request it's just a documentation issue....

OctoPrint/OctoPrint#2210 (comment)

[jneilliii]

Hey @UnchartedBull I noticed the integration of the ufp png files was released in the last update, but was curious about this screenshot shown on the readme. My current install doesn't show the thumbnail, but shows the progress wheel still. Was this part integrated as part of version 1.4.1 or planned for future release?

https://raw.githubusercontent.com/TimonGaebelein/OctoprintDash/master/screenshots/file_loaded.png

[UnchartedBull]

You will only see the image if you load the file (that little blue arrow in the file details) once you start printing it will be replaced by the progress wheel.

[jneilliii]

Ok, gotcha. I was hoping there was a button on the print progress that would allow me to see the thumbnail. Use case: walk up to printer while it's already printing (someone besides you started it) and you want to see what it is.

[mikekscholz]

This is far from being a finished solution, But I've been hacking away at it for a hot minute now. Its more of a gcode previewer, it doesn't have any layer progress yet and now I need to work on dynamically loading the gcode and then setting the camera height and orbit distance based on the size of the model. I'm a bit out of my comfort zone on this so anyone that knows what they're doing that wants to help it would be greatly appreciated. I need to build a repo for it still but here's a live preview gcode previewer its a bit on the heavy side but it still runs smooth on a rpi4 that's running a full desktop environment. Haven't tested a pi3 yet.

[UnchartedBull]

Definitely looks interesting. What rendering process do you currently use, especially interested in the technology (plain HTML Canvas, three.js, ...)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mikekscholz]

Oops I let this go forever... I wish github had better alerts. Its based off of three.js. I modified it to discard the purge lines and all the gcode prior to the layer0 tag, and Ive also hidden the travel moves to get a cleaner render. I’m still trying to get my JavaScript skills up to par to tackle the dynamic loading and camera positioning tho.

[UnchartedBull]

Damn that looks super nice! Also the automatic orbit might be really neat for the file details view. I have 2 more questions:

• Would it be possible to "thicken" the lines, so the objects looks more like a solid. The ideal solution probably would be to do a solid, but that probably is way too much work and totally out of scope. So if we could make it look like a solid, that would be really nice!
• I don't even know, whether that is possible / within your scope. But something to think about is saving a cached version of the preview so it doesn't need to be generated each time. I think that will make loading (at least for the second time and after) a bit faster.

Amazing work nevertheless!

[jneilliii]

Would it be possible to "thicken" the lines

Still think pretty gcode viewer is the way to go here, which has the thick line option.

[mikekscholz]

as it is the green lines are only at 12% opacity, gave the best representation I thought. Because its rendering "one dimensional" lines there isn't really any surface to effect any shading or shadowing. http://mikekscholz.com/labs/gcodesolid.html this has the opacity pumped up to 0.8 and it looks almost flat from most angles. also it would be a lot faster running locally since the gcode file is an 11MB download that you wouldn't have to wait for. edit: Actually pretty gcode viewer looks to be using most of the same threejs libs that I am. Ill have to take a closer look at their code when I have a chance.

[UnchartedBull]

Yeah the other version does look better. There was another plugin released a few days ago which also seems quite promising, although I didn't find an API: https://plugins.octoprint.org/plugins/PrettyGCode/?utm_medium=announcements&utm_source=octoprint&utm_content=1.4.0

[jneilliii]

What kind of API do you need @UnchartedBull? I'm sure @Kragrathea would be open to collaborate.

[UnchartedBull]

I opened an issue over in their repository, which got shot down fairly quickly. There is also no LICENSE present, which means I can't do it myself, since it technically would be copyright infringement. So yeah that idea with the plugin would be super nice, but is of the table I think.

[Kragrathea]

I guess I don't understand the request. What exactly do you need an "API" for? I embedded OctoDash* in PrettyGCode with just some CSS tricks. No reason OctoDash couldn't do the same.

And there is a License somewhere. Probably on the OctoPrint plugin page. Feel free to do whatever you want.

EDIT:Sorry I confused this plugin with OctoDashboard. But I am still unclear why an API is needed.

[jneilliii]

OctoDash is not the same thing as OctoPrint-Dashboard plugin. It's a separate web interface that runs on a pi that connects to OctoPrint for it's data and allows control from a touch screen, etc. It's really cool.

[UnchartedBull]

Well the API would just make it more convenient, another option is to pull the file and just copy over your GCode renderer and let everything run twice on the Pi. I thought, that if the preprocessed data can be send via an API the calculation only needs to be done once. I'll have a look at the generic plugin license from OctoPrint and might work on this myself if I got the time. I was just confused by the GitHub no license header.

[jneilliii]

So this a js client implementation for the gcode rendering, you're not actually running things on the pi when accessing it via the web interface, you're just downloading the file. The pretty gcode tab is downloading the file to the client basically and rendering it in the browser. So your approach of integrating the same code into it's own view in OctoDash seems appropriate.

[UnchartedBull]

Ok then the API isn't needed I guess. Sorry for the confusion here, I'll have a look at that :)

@Kragrathea let me know if there is any LICENSE file / copyright / mention you want me to copy over if I choose to go that path.

[jneilliii]

It appears the license is AGPLv3 based on what's listed on the plugin repo (right side).

https://plugins.octoprint.org/plugins/PrettyGCode/

[Kragrathea]

I am starting to have some performance issues with PrettyGCode in OctoPrints web interface. As a result I am considering splitting out the viewer part. How would a 3d gcode viewer actually intergrade into OctoDash? I know pretty much nothing about OD I am afraid...

[UnchartedBull]

In a nutshell OctoDash is nothing more than your average Angular app. You can install any packages from npmjs (even the ones using node) and you also have full access to the terminal (as the Pi user) plus a node.js enviornment. My main idea here is to replace the preview generated by PrusaSlicer / Cura with a GCode Render. Would be in those two places:

https://github.com/UnchartedBull/OctoDash/blob/master/screenshots/file_details.png

I don't seem to have a screenshot for printing and having the preview open, but basically the circular progress bar is replaced by the preview on click: https://github.com/UnchartedBull/OctoDash/blob/master/screenshots/job.png

I might be getting ahead of myself here but if a full 3D render is available it might be nice to have the option to click on the render, which will then resize to full screen and unlock controls to "inspect" the model. Also having the render in the printing section follow the actual print progress might be super neat as well (already printed parts are drawn in a random / defined color, parts that are to be printed are drawn with like 30% opacity and grey).

I really don't know whether that is even possible and I can't imagine how much work that would be. Just dumping ideas here for now. If you want to follow-up on this let me know :). It doesn't need to do all that fancy stuff, just rendering the GCode in a nice way is more than enough already!

Thanks for the interest!

EDIT: How would it integrate: Well you'd have a blank div / p / canvas whatever you like and a corresponding JS file. Then there would be an Angular Service taking care of retrieving the data from OctoPrint.

[Kragrathea]

After giving it some thought I think the approach I am going to use is to write PGC to directly use the OctoPrint push API and render to a plain HTML window. This will give me total control of the "message pump" without having to worry about OctoPrints or any other apps UI needs.

Inside OctoPrints UI the new plugin will just make the old 3d render canvas an iFrame pointed at my new PGC page. It should more or less behave the same.

If I do that then OctoDash could include the PGC rendered window the same way via iFrame.

Don't know when I will get around to this however...