@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.
