Duet Web Control 1.17 RC
-
Can someone provide a step by step for creating filaments and assigning them to tools? I was able to create a PLA and ABS but cant figure out how to assign to a tool. I am using Duetwifi with the latest version of DWC and Firmware.
Anyone know how to do this? Is there any documentation? Is it a firmware/config thing?
There is a down arrow next to each Tool. Click on that and you will see "Load Filament".
If you select that you will be shown a list of possible Filaments to choose from.
If a Filament is already loaded to the Tool when you click the down arrow you will see options to "Change Filament" or "Unload Filament".
Frederick
Thank you Frederick, That worked great
-
Hi,
First things first: GREAT JOB -> NICE ; rinse and repeat (as long as you can take it ;-))!!!I had this strong tendency to create a conky plugin for my printer so that I have it always insight on my desktop (I believe linux users only might be interrested in that).
So I gave the API a try and voila I get answers to my request. Whoooheee !!! Then I thought that a M408S0 will be a great addition to my findings and -> stuck/stop/end of story.
which brings me to the ultimate question -> why do I not get a response from gcode I submit to webcontrol via curl? I only get {"buff":250}. I looked it up in the communication of the https://github.com/chrishamm/DuetWebControl/blob/dev/core/js/comm.js and voila here is the problem @ the end of the file in the function```
[[language]]
function sendGCode(gcode, fromInput) {
if (gcode == "") {
return;
}
lastSentGCode = gcode;// Although rr_gcode gives us a JSON response, it doesn't provide any useful values for DWC. // We only need to worry about an AJAX error event, which is handled by the global AJAX error callback. $.ajax(ajaxPrefix + "rr_gcode?gcode=" + encodeURIComponent(gcode), { dataType: "json" });
Why is it not possible to return whatever the firmware sends back? Interresting thing: when I submit a M408S0, I get the response on my Gcode Console in the webinterface?!?! Please could you explain why and if it would be possible to reroute it to a request? thanks and all the best from duetino
-
This is all to do with the way that gcodes are buffered by the firmware, and the fact that some gcodes (e.g. G28, G32) take too long to execute so DWC would time out if it had to wait for a response. The most common gcodes don't generate any response at all unless an error occurs. There is a separate rr_ command to get recent responses.
-
Please could you explain why and if it would be possible to reroute it to a request?
Yeah, unfortunately, the way G-code request/result is handled in RRF is kind of broken, and isn't suitable for programmatic usage. You would need to poll [c]rr_command[/c] and hope you're getting the correct response. If several clients are polling it, they will often get each other's responses. You can reproduce it pretty easily by having two browser windows connected to the same DWC instance and using the console.
One dangerous thing about the web interface is that it applies the AJAX retry count to all XHR requests. This means that DWC will resubmit G-code requests if they fail to return a response, even if the G-code was actually run on your printer. So if your retry count is 2, moving the head down 100 mm can, in unfavourable circumstances, actually move it down 300 mm.
-
Tom, that is a issue I was not aware of. Do you have suggestions on how to fix it (preferably without breaking old versions of either RRF or DWC?). I hope Christian will see this thread and add his input.
-
Please could you explain why and if it would be possible to reroute it to a request?
One dangerous thing about the web interface is that it applies the AJAX retry count to all XHR requests. This means that DWC will resubmit G-code requests if they fail to return a response, even if the G-code was actually run on your printer. So if your retry count is 2, moving the head down 100 mm can, in unfavourable circumstances, actually move it down 300 mm.
If you are sure that's true, please log it as an issue in the DWC github repo. Retries make sense for status requests, but not for commands.
-
If you are sure that's true, please log it as an issue in the DWC github repo. Retries make sense for status requests, but not for commands.
Done. https://github.com/chrishamm/DuetWebControl/issues/58
I just reproduced it by using a network link conditioner to simulate bad network conditions.