I'm working on that but I'm struggling a bit. I haven't yet figured out how get the webcam view from the Control tab to play nice with my viewModel. This may take a while to fix.
Thank you for all of your hard work 
This can be tricky because OctoPrint embeds a lot of code to stop the stream so it doesn't consume resources when the tab is not enabled. If you look at one of my plugins at the lines here and here it may help.
Edit: You may also find some useful hints in @quanticchaos plugin over here.
1 Like
Thanks. I have been running into many different problems today and this may explain some of them. I will give it another try this weekend.
Yeah, the Webcamtab plugin is really clean, but because it moves the webcam from the control tab it overwrites some of the controlViewModel's internal functions and will break the standard webcam view on the control tab if I'm not mistaken. The hack I used in the ConsolidateTempControl plugin (actually @foosel's hack) tricks the system by making it think you've switched to the control tab by calling it's onTabChange event and then reverting the internal selectedTab variable back to yours after making that call.
That's interesting but too advanced for me. When I began to make my plugin I tried to use Lohrmann's approach but I made a clone of the hole div so it was possible to have both.
Thanks guys! That did the trick without breaking the control tab and now it works in Safari too. The webcam seems to be working as expected now so I'll wrap up a few other modifications and will likely push 1.3.0 this weekend.
1 Like
Here is a mockup of what I would like to do next:
A layer progress indicator (circle or bar, just like the total progress). The info seems to be available since the GCode viewer can display layer progress (when sync is enabled). I've been looking at the gcode.js viewModel, but I can't figure out how to get the percentage. Any ideas?
1 Like
You have the total layer and the current layer value. Just calculate the progress by your plugin.
If you grab that information from an other "source" it could by the "wrong" value, because in some cases the gcode-viewer shows other values for current layer then the DisplayLayerProgress-Plugin.
The reason is, that the plugin use the slicer information and the javascript gcode-viewer calculate the layer information out of the gcode-code.
I realise that my question was a bit vague and I'm not sure that we're talking about the same thing. Maybe you are thinking about current layer/layers? What I'm after is the progress of commands within the current layer. The GCode Viewer tab can display this in the gcode_command_slider (the horizontal slider) when "Sync with job progress" is enabled. I guess this is calculated as (Number of Commands sent to printer) of (Total number of commands in layer).
The webcam is working great on my dashboard plugin (latest version) install now - many thanks indeed!
1 Like
Hi again! I could need some pointers regarding context menus. I tried knockout.contextmenu this weekend but I couldn't get it to work. Is there a go-to framework that plays nice with knockout that I'm unaware of?
I've never worked with context menus before, would lean towards bootstrap popovers, and possibly incorporating this to make it knockout friendly. I've used that knockout-bootstrap library for my TPLinkSmartplug plugin, but can't remember what exactly I was using it for at the moment. The site's docs are currently 404 but there are examples in the repo.
I just looked at the contextmenu knockout plugin and was curious what the issues you ran into? It seems like a pretty straight-forward tool.
There's this in OctoPrint's source that I also just wanted to link you a usage example for but apparently it currently doesn't get used inside core 
@jneilliii @foosel Can the problem I ran into with knockout.contextmenu be related to the fact that it uses the same custom binding identifier "contextMenu" as the currently unused one in core?
Edit: Yep. That was it. I don't know if there's a better way (namespaces?) but changing the bindinghandler worked.
1 Like
Hmm. I'm a bit puzzled. I just received the following issue: This implies that I somehow managed to interfere with the gcode. I have added the following to the plugin from v1.6.0 to keep track of the used filament:
__plugin_hooks__ = {
"octoprint.plugin.softwareupdate.check_config": __plugin_implementation__.get_update_information,
"octoprint.comm.protocol.gcode.queued": __plugin_implementation__.process_gcode
}
def process_gcode(self, comm_instance, phase, cmd, cmd_type, gcode, *args, **kwargs):
if not gcode:
return
if gcode in ("G0", "G1"):
CmdDict = dict ((x,float(y)) for d,x,y in (re.split('([A-Z])', i) for i in cmd.upper().split()))
if "E" in CmdDict:
e = float(CmdDict["E"]) / 1000 #in meters
self.extruded_filament = round(e,2)
return
else:
return
From the documentation: "queued: This phase is triggered just after the command was added to the send queue of the communication layer. No manipulation is possible here anymore (returned values will be ignored)."
Can you guys see how This could potentially interfere with the printer communication and cause the issue described above?
Edit: Overrunning Limit Switches? That implies that the machine is not homed. Could the above interfere with the gCode scripts in Octoprint if those are used to home before printing?
I'm not super sure in regard to python syntax, but shouldn't it be if gcode in ["G0", "G1"]:?
1 Like
@Stefan_Cohen, sorry to rattle an old thread, but do you have any workarounds for the issues with the DisplayLayerProgress plugin.
At the moment the plugin fails to load which breaks the Dashboard plugin.
Don't know if it's related to the rest of the system but I'm running: -
OctoPrint version : 1.4.0rc4
OctoPi version : 0.17.0
Thanks for any input...
Andy B.
Hi @andy-b,
what issue do you mean exactly? Maybe it is already located in the DLP-Issue tracker: https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/issues
If you couldn"t find your related topic, just create a new issue and I will try to help you.
Bye
Olli