3D GCode Viewer integrated with DWC
-
@PCR Thanks for looking into this. I will start looking at what it takes to make sure that the URL is correct for the SBC version. Hopefully I will have some time today/tomorrow to make the changes to it.
-
Thank you! honestly like your ones more than the one from 3.2
-
made this change to the fork of you!
https://github.com/P-C-R/DuetWebControl/commit/32c2e5279333cae02d4a80a39c5828be06b4ef5d
it works now on the SBC. But i cannot say it its "enough"
-
@PCR That'll work for the SBC but then it will break the SD. I am looking at a way to detect if the DWC is SBC or SD and use that as a parameter in the viewer so both will work.
-
If you could give this a shot and let me know. I added some code that will hopefully help determine if the DWC is SBC or SD and set an appropriate parameter for the viewer.
https://github.com/Sindarius/DuetWebControl/releases/tag/3.1.1-SBCFix
-
not working;(
-
def __init__(self,base_url): self._base_url = base_url try: URL=(f'{self._base_url}'+'/rr_status?type=1') r = self.requests.get(URL,timeout=(2,60)) j = self.json.loads(r.text) _=j['coords'] self.pt = 2 return except: try: URL=(f'{self._base_url}'+'/machine/status') r = self.requests.get(URL,timeout=(2,60)) j = self.json.loads(r.text) _=j['result'] self.pt = 3 return except: print(self._base_url," does not appear to be a RRF2 or RRF3 printer", file=self.sys.stderr) return
This was the logic @Danal code. RIP
-
@PCR I was trying to avoid having to query both paths but that may be unavoidable for now.
-
@PCR https://github.com/Sindarius/DuetWebControl/releases/tag/3.1.1-SBCFixV2
Give this one a go if you get a chance.
-
@Sindarius
like I said in github it is working with the FixV2 on my SBC for me.
many thx for the great work. -
@danym21 I saw your message, thanks for the feedback and I am glad that it going for you guys
-
Works perfectly now as a Plugin in 3.2 ;)))
-
@PCR Once 3.2 is finalized and out in the wild that's the plan. I'll plan to test it in the DWC page itself like an unreleased original version I did. However, there was issues with VueJS trying to attach itself to the viewer's resources which would cause the viewer to be unstable and crash the page and would also limit the max size of model to be viewed.
-
@Sindarius I had some similiar problems with the charts + heightmap but got around it by storing my own stuff in the JS file based on the machine name . Be aware that we'll add multi-machine support at some point and the backend has already been prepared for that.
The new event API from v3.2 should be easier to handle, too.
-
I tested the 3.2 on my 3.1.1 machine but the heightmap did not load. Something with Blabla is null
-
@chrishamm I look forward to the multi-machine support. The problem I ran into was the actual babylon objects were getting sucked into vuejs by whatever mechanisms it uses. then it wanted to start tracking activity on those objects, there are a lot of objects, which ended up crushing the viewer to a crawl. I'll definitely play with it more on top of getting a few other items into it. I'll probably look into trying the Vue-BabylonJS package a try to see if it overcomes the issues I ran into. It would be nice to have the viewer incorporated into the UI like you have the other one.
-
Is it normal that the viewer in 3.2 almost nothing is visable? Just a view black dots.
If I use the same gcode here: https://gcode-preview.web.app/
it became visable
-
@Sindarius In my case it were Three.js geometries that were transformed by Vue so I moved them out of the data scope, which did the job for me. Check out the heightmap and temp chart components for further details.
@smoki3 Yes, the current visualizer in 3.2-pre-b1 doesn't have a pretty front-end yet. At the moment it can be used only to watch live prints.
-
I have a fork of the previous visualizer code that incorporates STL viewing, slicing, and a slick slicer settings / model control component (right now based on Slic3r). Let me know if you’re interested in the code. It’s based on AngularJS and relies on a NodeJS component to integrate with the user’s local slic3r settings and execute the slicer.
The goal is to eventually move it server side (cloud) for saving settings and slicing. Also possible to slice on the PI 4 - early benchmarks showed it performed at ~50% of a top end desktop, which means it can likely outperform a slice from the cloud with network transfer in most conditions.
-
Been a while since I provided an update. I have been working toward getting my viewer converted to a plugin in 3.2. Here's a little sneak peek of where it is at today.