ESP8266 Color Touchscreen Print Monitor
-
I've been working on a little print monitor using an ESP8266 and a 2.4" color touchscreen display to monitor up to four printers (see pictures). Three of my printers are Marlin with OctoPrint, and my newest is a Duet-based machine. This is solely a monitor - it does not perform any control. I'll be posting the whole thing to github when it is slightly less of a shambles.
I'm just beginning to add Duet support and I have a couple of questions on the use of rr_connect / rr_disconnect.
First, do I need to use them at all? I can run curl commands against my printer without first performing an rr_connect.
If I should use them, should I perform an rr_connect followed by rr_status / rr_fileinfo and then an rr_disconnect every time I want to poll status? If not, when should they be used?
Input is appreciated.
Joe
-
@bitsplusatoms said in ESP8266 Color Touchscreen Print Monitor:
I'll be posting the whole thing to github when it is slightly less of a shambles.
if you search for rr_disconnect you'll get some background while waiting for the details, all i remember of the top of my head is its been recommended
-
@danal has working code. May be useful for you as an example. Notice the different handling of Duet2 and Duet3.
-
this is going in a similar direction
https://forum.duet3d.com/topic/14134/duet-buddy-a-proof-of-concept-remote-monitor
-
@zapta said in ESP8266 Color Touchscreen Print Monitor:
@danal has working code. May be useful for you as an example. Notice the different handling of Duet2 and Duet3.
Yeah, I decided to "abstract" the 2 to 3 differences for other scripts. This has worked out pretty well. See https://github.com/DanalEstes/DuetWebAPI/blob/master/DuetWebAPI.py for the abstraction. Even if you don't know any python, it is straightforward to read if you just assume it does what it seems (like json.loads is probably a json parser. It is).
-
@bitsplusatoms said in ESP8266 Color Touchscreen Print Monitor:
If I should use them, should I perform an rr_connect followed by rr_status / rr_fileinfo and then an rr_disconnect every time I want to poll status? If not, when should they be used?
If you are polling or sending commands frequently, use rr_connect at the start and after a network error, and do not use rr_disconnect. If you are polling less than once every few seconds, use rr_connect and rr_disconnect around each poll.
-
@dc42 Thank you. That’s exactly what I needed to know. I will be polling every 10 seconds during a print and once a minute while idle (to determine whether a new print has started).
-
@tobias_munich Thank you for the pointer. I found this project previously but wasn’t able to answer my question based on it. I should have mentioned that.
-
@Danal This is great. Your code will be a nice reference for me. Thank you.
-
@dc42 One more question... I've been looking at the DWC code so I think I know the answer, but I want to be sure.
It does not appear that there is a way to determine solely through a single invocation of rr_status or rr_fileinfo that a print has completed. That is, after a print has completed, rr_fileinfo will return { "err" : 1 } and rr_status will report { "status" : "I"} and no indication that a prior print has completed.
It appears that the client code must notice that a transition has occurred from a printing state to an idle state and make a presumption about completion.
In other words, there is no concept of a "Completed" state other than in the eye of the client.
TIA,
Joe -
More to do, but progress. In the first image (the overview screen) the machine labeled UXL is a Duet3D based machine. The others are Marlin/OctoPrint.
-
@bitsplusatoms said in ESP8266 Color Touchscreen Print Monitor:
It appears that the client code must notice that a transition has occurred from a printing state to an idle state and make a presumption about completion.
Correct. You can also use the 'job' field of the object model to track print progress.
-
@dc42 Thank you. I've spent a little time on it this weekend and think I have a reasonable approach in place for state transitions and time estimates using the "timesLeft" data.
-
It's getting there. All the code is on github but it is labeled as a work-in-progress. The models for the enclosure (2 variants) should be on thingiverse this weekend.
I have asked a friend to try to follow the documentation and build one of these from scratch. Once he has either reported success or alerted me to problems in the documentation, code, dependencies, or whatever else, I'll fix/update it.