You're totally right. I missed that fact, sorry for the confusion. It's the GCodeThumbs plugin that is giving that error. I had forked it and was playing around with adding a tab for it and making it interactive in a tab, which was just prior to the release of your plugin.
Hey. Thanks for this. It's pretty awesome. I have a question. Is it possible to allow the camera to see the underside of the model? It looks like it won't let you go too far below the plane of the bed. A lot of times I want to see the underneath of the model to make sure the GCODE is doing the right stuff under it.
The mirror feature is (in part) to allow you to see the underside of the gcode. For viewing the very bottom layers I use the slider to go all the way down. I admit it isn't perfect.
I prefer the camera to stay above the build plate. But I am willing to consider an option if it doesn't clutter up the UI too much. Maybe if mirror is off it allows the camera to go below.
Looks Great, and performance is really good running on Pi 3B+.
I'm currently testing it using the Dry Run plugin and it's working well, except that the display is lagging quite a bit behind the actual print progress.Also, there are no visible lines being drawn, but maybe that's because of how the Dry Run plugin works? I'll try again with a "real" print sometime soon.
nb. This is using S3D for slicing.
I will have to try it with Dry Run. I had never heard of it.
The lagging could be in part the way I handle syncing. It more based on when the command was sent to the printer than what it is actually doing. And even then it isn't as accurate as it could be.
S3D should work fine, but it may not have all the colors for stuff like supports hooked up yet.
Just insert M111 S8 to the beginning of the GCODE file. (http://marlinfw.org/docs/gcode/M111.html)
1 Like
It would seem there is both a plugin and a Marlin debug mode called Dry Run.
For my testing I have been using the Virtual printer you can turn on in OctoPrint.
Hey, that's cool! I never heard of that M111 command before. I'll try it. Thanks!
I'll also have to look for the Virtual printer option. I haven't seen it. It's a plugin?
Update: I could not find any virtual printer option in my octoprint. Where do I find it? I couldn't find a plugin with that name and it doesn't appear in my octoprint gui.
Update2: Tried M111 S8 at the beginning of my gcode. It started heating the bed so I assumed it hadn't worked. Does it only prevent extrusion but still head the bed and nozzle?
1 Like
It should not heat.
Are you using Marlin or Reptier firmware? According to this: https://reprap.org/wiki/G-code#M111:_Set_Debug_Level, Repetier uses M111 in another way.
Using Marlin - Firmware is TH3D Universal firmware, latest version.
I have now tested again using M111 S8 and, even though bed and nozzle are fully heated, the gcode viewer is working perfectly, using narrow or thick lines.
Shame about the heating but in the majority of cases I'll be using this plugin during a real print, viewed remotely through the browser.
The virutal printer is a debugging option in OctoPrint. Here is how to set it up. It works really slick.
https://docs.octoprint.org/en/master/development/virtual_printer.html
Thanks. I set up the virtual printer.
Started out great but when I shift the viewpoint round on the gCode viewer the browser octoprint session dies. No error shown but just closes the Octoprint session. If I start it up again it reloads to the virtual printer again. It's still printing to the virtual printer and is working fine. Just dies if I move the viewer viewpoint around too much. Not a major problem but thought you might want the feedback.
Could you try to repeat that with the developer console open in your browser? F12 in most cases. See if there is any errors in the Console log.
The problem seems to be related to the use of the Right mouse click action. With a long right click, it seems to lock and the display moves as if the button is still held down. It has always been during such orientation moves that the problem happens. A few times it has just exited the PrettyGcode window but not crashed the browser. Other times it can crash the browser.
All I got from the console log was...
Create PrettyGCode View Model
packed_core.js?8c230bbf:15624 Starting dependency resolution...
packed_core.js?8c230bbf:15734 ... dependency resolution done
packed_core.js?8c230bbf:16016 Initial application setup done, connecting to server...
packed_core.js?8c230bbf:13728 Connected to the server
packed_core.js?8c230bbf:15994 Finalizing application startup
packed_core.js?8c230bbf:15875 Going to bind 61 view models...
packed_core.js?8c230bbf:15928 Did not bind view model UsageViewModel to target #wizard_plugin_tracking since it does not exist
packed_core.js?8c230bbf:15928 Did not bind view model SoftwareUpdateViewModel to target #softwareupdate_confirmation_dialog since it does not exist
packed_core.js?8c230bbf:15928 Did not bind view model SoftwareUpdateViewModel to target #wizard_plugin_softwareupdate since it does not exist
packed_core.js?8c230bbf:15928 Did not bind view model bedlevelvisualizerViewModel to target #wizard_plugin_bedlevelvisualizer since it does not exist
packed_plugins.js?c9de1cf9:9796 onBeforeBinding: settings= Object
packed_core.js?8c230bbf:2475 User pi logged in
packed_core.js?8c230bbf:15967 ... binding done
packed_core.js?8c230bbf:15979 Application startup complete
packed_plugins.js?c9de1cf9:10049 ExcludeRegionPlugin:: excludedRegions updated, redrawing GCODE viewer: excludedRegions= Array(0)
packed_plugins.js?c9de1cf9:19131 Array(2)
packed_plugins.js?c9de1cf9:22183 OBJLoader: 48.4951171875ms
packed_libs.js?ea9fbc9a:14720 Uncaught TypeError: Cannot read property 'find' of null
at Modal.hideModal (packed_libs.js?ea9fbc9a:14720)
at Modal.hide (packed_libs.js?ea9fbc9a:14600)
at HTMLAnchorElement.proxy (packed_libs.js?ea9fbc9a:10269)
at HTMLDivElement.dispatch (packed_libs.js?ea9fbc9a:5184)
at HTMLDivElement.elemData.handle (packed_libs.js?ea9fbc9a:4992)
Not sure if this helps.
So, I cleared the console log and didn't get any more entries, which is wierd, but I enabled the console sidebar and noticed the following - they are coming up all the time.
[Violation] 'message' handler took 175ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 196ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 229ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 157ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 199ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 151ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 161ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 210ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 175ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 170ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 179ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 214ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 157ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 203ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 152ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 221ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 228ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 189ms
packed_libs.js?ea9fbc9a:25370 [Violation] 'message' handler took 211ms
packed_plugins.js?c9de1cf9:19930 [Violation] 'requestAnimationFrame' handler took 69ms
Often a right mouse click does nothing if I click and drag, but then it seems to lock and the display moves until I do a second right mouse click. It seems odd that I can't just hold the right mouse button and drag.
On some occasions I find that the PrettyGcode window closes and a new browser windows opens at the default start page. It's like the mouse actions are being seen as a browser shortcut button.
I'm going to try this with a different browser. (I use Vivaldi, based on Chrome engine)
OK, Solved. I used Chrome and everything was fine, including right-click and drag.
Must be something odd with Vivaldi.
I think you can forget about this problem - it's a browser issue.
Later, that same day.............
I have a 'real' print running now. I noticed that when fat lines is turned off the entire first layer is show completed, while the nozzle position follows the GCode correctly. When fat lines is turned on it shows the layer building up as I would expect. Is it normal to show a completed layer immediately when fat lines option is off?
Also, if you don't mind, it would be nice to have a config page to enable customization of the colors used. That way it could be made to match the colors used by the slicer.
Even later the same day.............
Found out what the problem was. Vivaldi can use gestures to perform actions, and the right mouse button dragged down is the gesture for a new tab.
As I don't use gestures I turned them off and the problem is fixed. I hope this help anyone else with problems using Vivaldi.
Thanks Al_Wilson. I am glad you figured out the problem. I had not heard of the Vivaldi browser and would have never figured that out. 
I am working on changing how the sync happens now and it will hopefully fix that bug you are seeing with fat lines.
I am trying to avoid cluttering up the UI with too many options, and a color selection ui would be a big one. But if you can give me a gcode file for your slicer that has all the different line types (inner, outer, fill, support, etc) and the colors (rgb or html colors) that match what the slicer shows I will add them directly to the code. Thats how I handle the Cura colors I am displaying now.
Currently I detect Cura, Simplify3d and Prusa lines types. But only display colors in Cura style. Simplify3Ds native preview just colors by speed as far as I can tell, and I am not sure what Prusa does.
What other slicers are people using?
S3D can display by speed but the display type is selected by drop-down and the option allows colors by feature type.
I have also uploaded gcode that will show how S3D adds commented labels to indicate the start of each feature type.
Wire Borer Collett v2.stl (48.9 KB)
Not every feature type exists in the small gcode, but the format is the same - use the wording shown on the clip but it is all lower case in the gcode.
That color chart is great. I didn't know Simplify3d had that. But the file you uploaded is a stl and not gcode.
I will try to merge those extra line S3d types into the current colors. But I want to default to Cura colors when the types exist in the both. So green for "outer" rather than S3Ds blue. But stuff like the orange for Infill will be the same.
Damn, I didn't notice that I uploaded the wrong file. Just tried again with the gcode but the file size is too big. Here's a smaller one...CCR10_hangclock.gcode (481.9 KB)
No worries about colors - I just thought a config option would be cool but I can see it would be a pain to implement.