Duet HTTP requests documentation
-
Is this the sort of thing you're looking for? https://github.com/DanalEstes/MultiDuetWebMonitor
Ian
TronXY X5S with Duet 3 MB6HC and Roto toolboard : Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : Polargraph with Duet 2 WiFi
-
And the documentation on individual HTTP requests is here:
-
@jcoelho I am very much interested in the same. I've looked at the one @droftarts mentioned and it's good for simple monitoring but I yearn for something more. There are other commercial options but many of them aren't for duet. I managed to create a simple react component that gets the status responses from the Duet but that's as far as I got! I am very new to web development so I was proud of myself for that
I think what your after can be found here:
https://reprap.org/wiki/RepRap_Firmware_Status_responsesObserving DWC with the network recorder in Chrome also helped a great deal in observing how gcode is sent, i didn't get as far as files.
I have an image in my head of a simple web layout with multiple printers in view showing perhaps only the status and percentage completion. A click on each printer expands the view a little more to show a little more info (temps, maybe fans etc.), a final click opens DWC in a new tab for that printer.
I also like the idea of a smarter print queue using the filament system to decide which printer to send a gcode file to based on it's requirements as soon as a printer is 'ready'. Also status change triggered gcode sending.
This is all very well but I'm probably several years and many headaches away from such a thing! I wish you luck and would love to look at whatever code you produce and maybe, one day, build on it. Please come back and share github links.
-
@littlehobbyshop said in Duet HTTP requests documentation:
I have an image in my head of a simple web layout with multiple printers in view showing perhaps only the status and percentage completion. A click on each printer expands the view a little more to show a little more info (temps, maybe fans etc.), a final click opens DWC in a new tab for that printer.
That is literally what this is: https://github.com/DanalEstes/MultiDuetWebMonitor
-
@droftarts said in Duet HTTP requests documentation:
Is this the sort of thing you're looking for? https://github.com/DanalEstes/MultiDuetWebMonitor
Ian
Yes, something like that. But I'm trying to make a more general interface, that can be integrated with other boards, such as octoprint. That one is stuck to use the duet.
@Danal said in Duet HTTP requests documentation:
And the documentation on individual HTTP requests is here:
Thanks, that can be a starting point, as the endpoints are listed. Still not all response bodies are fully explained.
@littlehobbyshop said in Duet HTTP requests documentation:
@jcoelho I am very much interested in the same. I've looked at the one @droftarts mentioned and it's good for simple monitoring but I yearn for something more. There are other commercial options but many of them aren't for duet. I managed to create a simple react component that gets the status responses from the Duet but that's as far as I got! I am very new to web development so I was proud of myself for that
I think what your after can be found here:
https://reprap.org/wiki/RepRap_Firmware_Status_responsesObserving DWC with the network recorder in Chrome also helped a great deal in observing how gcode is sent, i didn't get as far as files.
I have an image in my head of a simple web layout with multiple printers in view showing perhaps only the status and percentage completion. A click on each printer expands the view a little more to show a little more info (temps, maybe fans etc.), a final click opens DWC in a new tab for that printer.
I also like the idea of a smarter print queue using the filament system to decide which printer to send a gcode file to based on it's requirements as soon as a printer is 'ready'. Also status change triggered gcode sending.
This is all very well but I'm probably several years and many headaches away from such a thing! I wish you luck and would love to look at whatever code you produce and maybe, one day, build on it. Please come back and share github links.
Really happy that you were able to do that as a web developer beginner! Thanks for the url, it really details the body as I wanted. The issue with using the network monitor to view the request/responses is that you only observe some options and not all of them. Sure it's a way to get some information but you can actually be missing a lot of it.
Are you interested in working on something together? I'm beginning a living on software engineer but would love to create something with others and share it. If you want to join me, let me know.@Danal said in Duet HTTP requests documentation:
@littlehobbyshop said in Duet HTTP requests documentation:
I have an image in my head of a simple web layout with multiple printers in view showing perhaps only the status and percentage completion. A click on each printer expands the view a little more to show a little more info (temps, maybe fans etc.), a final click opens DWC in a new tab for that printer.
That is literally what this is: https://github.com/DanalEstes/MultiDuetWebMonitor
Are you the developer of that tool? Are you using it? What is your opinion on it/what made you create it?
-
@jcoelho Yes, I am the developer. I wrote it (really built it out of pieces of the existing DWC) specifically for people who are managing print farms. I know at least a handful are using it, because they have requested small changes (most, but not all, of which have been implemented. Depends on effort required...).
I do not run a farm, so I do not use the tool.
What do I think of it? Is it perfect? No. Does it meet the design intent stated in the readme.md on Github? Yes. Namely, "Arms Length" monitoring by color of multiple printers, a few basic actions, and no intent to have equal function to full DWC. It is important to note that if the operator clicks on the name/IP of a printer, it opens DWC for that printer, in a new tab.
Three thoughts about its future:
-
I am willing to make small changes for anyone who's actually using it.
-
It is open... anyone can fork it and make more changes.
-
It is life limited in that it uses the HTTP interface to Duet/RepRap firmware. In the future, specifically as of Version 3, Duet/RepRap firmware no longer supports that interface and is instead moving to a socket based interface. MultiDuet would have to be re-written at that time. I may or may not, depending on how many people are actually using it and request V3 compatibility.
Delta / Kossel printer fanatic
-
-
@jcoelho said in Duet HTTP requests documentation:
Still not all response bodies are fully explained.
And they never will be. For example, no one is going to document that in this JSON response:
{"status":"I","heaters":[65.0,22.8],"active":[65.0,0.0],"standby":[0.0,0.0],"hstat":[2,2],"pos":[0.000,0.000,615.910],"machine":[0.000,0.000,615.910],"sfactor":100.00,"efactor":[100.00],"babystep":0.000,"tool":0,"probe":"0","fanPercent":[0.0,0.0,100.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0],"fanRPM":0,"homed":[1,1,1],"msgBox.mode":-1,"seq":1,"resp":""}
Heater 0 is at 65.0 degrees and is set to 65.0 with 0.0 standby, and that heater 1 is at 22.0 and set to 0.0, and so on and so forth. That's all "understandable" from the JSON itself.
Perhaps I'm misunderstanding the gap in explanation to which you are referring?
-
@jcoelho said in Duet HTTP requests documentation:
I'm trying to make a more general interface, that can be integrated with other boards, such as octoprint. That one is stuck to use the duet.
That's a great idea. A UI layer that presents status and just a few common controls (pause, cancel, ...), and "pluggable" modules that connect to, and pull status from, Duet V2, Duet V3, Octoprint, Astroprint, and others. An "orchestration" module to tie it all together.
Fantastic idea. And sounds like a fun project.
Were I doing that, I'd "Start from scratch" with a decent HTML5 development framework, develop the UI and orchestration however I wanted, and borrow from the "connector" modules that are out there for DWC, Octoprint, etc. Should result in a good balance of effort v result.
-
@jcoelho said in Duet HTTP requests documentation:
Still not all response bodies are fully explained.
See https://reprap.org/wiki/RepRap_Firmware_Status_responses
@Danal said in Duet HTTP requests documentation:
Were I doing that, I'd "Start from scratch" with a decent HTML5 development framework, develop the UI and orchestration however I wanted, and borrow from the "connector" modules that are out there for DWC, Octoprint, etc. Should result in a good balance of effort v result.
It's surely possible to add more connectors to DWC2 but I cannot maintain any non-Duet connectors. The internal DWC2/DSF model is quite complete so it's just a question of re-ordering/altering the existing UI to get something universal. There is really no need to come up with a new solution. It's prepared for multi-machine use, too, but I haven't got around to finish that part yet.
-
@Danal said in Duet HTTP requests documentation:
@jcoelho Yes, I am the developer. I wrote it (really built it out of pieces of the existing DWC) specifically for people who are managing print farms. I know at least a handful are using it, because they have requested small changes (most, but not all, of which have been implemented. Depends on effort required...).
I do not run a farm, so I do not use the tool.
What do I think of it? Is it perfect? No. Does it meet the design intent stated in the readme.md on Github? Yes. Namely, "Arms Length" monitoring by color of multiple printers, a few basic actions, and no intent to have equal function to full DWC. It is important to note that if the operator clicks on the name/IP of a printer, it opens DWC for that printer, in a new tab.
Three thoughts about its future:
-
I am willing to make small changes for anyone who's actually using it.
-
It is open... anyone can fork it and make more changes.
-
It is life limited in that it uses the HTTP interface to Duet/RepRap firmware. In the future, specifically as of Version 3, Duet/RepRap firmware no longer supports that interface and is instead moving to a socket based interface. MultiDuet would have to be re-written at that time. I may or may not, depending on how many people are actually using it and request V3 compatibility.
I was just curious to hear your opinion on the application. From what I read on the repo, the tool seems simple but able to do it job. I'm happy that is being used by some people and that you are getting feedback on it.
@Danal said in Duet HTTP requests documentation:
@jcoelho said in Duet HTTP requests documentation:
Still not all response bodies are fully explained.
And they never will be. For example, no one is going to document that in this JSON response:
{"status":"I","heaters":[65.0,22.8],"active":[65.0,0.0],"standby":[0.0,0.0],"hstat":[2,2],"pos":[0.000,0.000,615.910],"machine":[0.000,0.000,615.910],"sfactor":100.00,"efactor":[100.00],"babystep":0.000,"tool":0,"probe":"0","fanPercent":[0.0,0.0,100.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0],"fanRPM":0,"homed":[1,1,1],"msgBox.mode":-1,"seq":1,"resp":""}
Heater 0 is at 65.0 degrees and is set to 65.0 with 0.0 standby, and that heater 1 is at 22.0 and set to 0.0, and so on and so forth. That's all "understandable" from the JSON itself.
Perhaps I'm misunderstanding the gap in explanation to which you are referring?
I'm not saying to be THAT specific. But I mean, that "status" key contains a single letter. Not all of them are obvious or can be misleading (read more below). I'm not saying that it should be documented as the example you gave, but something among the likes of "'heaters' - current temperature of the tools" (again, not necessarily this) would be helpful.
@Danal said in Duet HTTP requests documentation:
@jcoelho said in Duet HTTP requests documentation:
I'm trying to make a more general interface, that can be integrated with other boards, such as octoprint. That one is stuck to use the duet.
That's a great idea. A UI layer that presents status and just a few common controls (pause, cancel, ...), and "pluggable" modules that connect to, and pull status from, Duet V2, Duet V3, Octoprint, Astroprint, and others. An "orchestration" module to tie it all together.
Fantastic idea. And sounds like a fun project.
Were I doing that, I'd "Start from scratch" with a decent HTML5 development framework, develop the UI and orchestration however I wanted, and borrow from the "connector" modules that are out there for DWC, Octoprint, etc. Should result in a good balance of effort v result.
Thanks for your feedback on the idea. The idea is pretty much that. A orchestrator which can make the control of a 3D printer transparent for the user, if that's desired. And then develop a module that is able to be the middle man, using the Duet, Octoprint or any other as a provider of information.
That's exactly the idea. Use a framework well known. I have some other ideas (that still need to be polished, such as Filament Usage Management and Print History) that would require some sort of data persistency (probably by adding a centralized backend service or by adding a image to be instaled locally), but that are some ideas for the future
@chrishamm said in Duet HTTP requests documentation:
@jcoelho said in Duet HTTP requests documentation:
Still not all response bodies are fully explained.
See https://reprap.org/wiki/RepRap_Firmware_Status_responses
@Danal said in Duet HTTP requests documentation:
Were I doing that, I'd "Start from scratch" with a decent HTML5 development framework, develop the UI and orchestration however I wanted, and borrow from the "connector" modules that are out there for DWC, Octoprint, etc. Should result in a good balance of effort v result.
It's surely possible to add more connectors to DWC2 but I cannot maintain any non-Duet connectors. The internal DWC2/DSF model is quite complete so it's just a question of re-ordering/altering the existing UI to get something universal. There is really no need to come up with a new solution. It's prepared for multi-machine use, too, but I haven't got around to finish that part yet.
Thanks for that URL. That's exactly what I was talking about previously in this reply. The "STATE" explation is a pretty good example of what I was looking for.
I had no idea that DWC (Not sure that DSF means) was able to control multiple multiple printers (or that it was prepared for it). I totally understand that you cannot maintain any controller besides Duet.Let me just say I'm not trying to replace DWC by any means! I think that DWC is well built and working well.
My idea cames for the fact that not all my printers are using a Duet controller and since I enjoy developing I thought it was a nice project for the weekends.
-
-
@jcoelho said in Duet HTTP requests documentation:
Really happy that you were able to do that as a web developer beginner! Thanks for the url, it really details the body as I wanted. The issue with using the network monitor to view the request/responses is that you only observe some options and not all of them. Sure it's a way to get some information but you can actually be missing a lot of it.
Are you interested in working on something together? I'm beginning a living on software engineer but would love to create something with others and share it. If you want to join me, let me know.That would be great as long as you can tolerate a beginner! Not sure how much use I would be. I am on github, same username.
