3D GCode Viewer integrated with DWC
-
@Sindarius
Are there known issues with the latest version on a maestro?
Cant't get it working anymore. (RRF 3.2_b4 +0.11.1)
The previous versions of fw and plugin worked. (guess RRF 3.2_b2 +0.6.5) -
@DIY-O-Sphere I pulled down and installed the 3.2-beta4 that is on GitHub, I normally run my own build, and was able to install my plugin without any problems. Make sure you are pulling the latest version of my plugin from the github releases page https://github.com/Sindarius/DWC_GCodeViewer_Plugin/releases. I don't believe the firmware version itself should have any play since the plugin is a javascript solution that runs in DWC itself.
Just double check the following to make sure you are on the latest
-
@Sindarius
After de-energising and powering up everything is working now....
A simple sw-reset after the update was not enough..... -
-
-
@PCR I’ll take a look at the file. Those are some impressive arcs
-
no rush
was more like a little note -
@PCR This probably looks better.
-
G3 fix is in RC2
https://github.com/Duet3D/DuetWebControl/releases/tag/3.2.0-rc2
-
A small thing that I catched:
On all 3-d-software I am aware of, if a cartesian-csys-system is used -> x-y-z are coloured in r-g-b,
e.g. "sol...orks" here:
e.g. "rh...-3d":
e.g. "sim....y-3D":
e.g. or the height-map within "DWC":
but here it is r-b-g:
Before I forget: Thanks for you cool work!
-
@LB Since it is cosmetic I’ll work the change into 3.3
-
Cool plugin!
I'm trying it out on a Duet Maestro on DWC/RRF 3.2 RC2
Seeing some weirdness on one file. With "spread lines" enabled, everything looks good:
But with it disabled, some weirdness:
-
Cool
- looking forward!Another small thing that´s related to it:
When within "settingS" choosing "volume" (instead of "bed") the wireframe is by default blue, and since 1 of the axis is also blue it might be a unlucky default colour for the wireframe of the print-volume regarding the default-csys-colouring:
If the default would be a slightly transparent white (I know transparency is not there yet so to show what I mean I picked a greyish tone), you could better see the the csys:
I know this is a field where opinions might easily differ, so it is maybe just something to think about
Thanks for all your work,
cheers! -
@CCS86 if you could share your file that would help me to look at it.
-
@LB volume is an odd duck because I had to do some things to make something work for delta beds. Transparency is always a pain heh
-
reliable results with (alpha + all-of-the-webbrowsers-out-there)=oxymoron
-
@Sindarius said in 3D GCode Viewer integrated with DWC:
@CCS86 if you could share your file that would help me to look at it.
Sure thing.
-
@CCS86 Thanks for the file. I managed to take a look at it and the line that is tripping up the viewer is in your ending gcode trips up the viewer into thinking the last layer height should be 5mm tall which causes it to freak out.
G1 Z5 E-3 F4000I commented out that line and got this
This is not an issue with your gcode but an issue with how the viewer not appreciating a retract and z travel in the same line. I'll look at getting a fix in for 3.3
Also because line rendering does not care about layer height doing forced line rendering showed the correct results.
Either way thank you for sharing your file and I'll get this resolved.
Thanks!
-
Awesome, glad it helped!
-
*is printing a multi part file...
One of the parts as apparently on a blob of oil or some nonsense, is going to fail and probably ruin the whole print.
Pause print. Sigh.
Remember that the g-code viewer has a cancel part function.
upload version 3.2 of DWC.
enable Gcode Viewer plugin.
cancel the failing part.RESUME PRINT!
ALL. OF. THE. WINNING.
Like seriously, epic epic feature to have.
Isolate, substitute, verify.
