Duet Buddy - a proof of concept remote monitor

richardmckenna

I did something!

I added a battery level indicator and the printer name. Strangely the M5Stack API only returns the battery level in increments of 25, not sure if there is a way to get round this by skipping the M5Stack API method and going straight to requesting it from the I2C. Will have to look into it more, but from what I can discern from the basic docs and the Chinese datasheet for the IP5306 it only returns 1 of 4 values depending on the voltage range.

This is the current method in the API:

// Return percentage * 100
int8_t POWER::getBatteryLevel() {
  uint8_t data;
  if (M5.I2C.readByte(IP5306_ADDR, IP5306_REG_READ3, &data) == true) {
    switch (data & 0xF0) {
      case 0x00:
        return 100;
      case 0x80:
        return 75;
      case 0xC0:
        return 50;
      case 0xE0:
        return 25;
      default:
        return 0;
    }
  }
  return -1;
}

I also don't quite know what is happening with the switch statement and data & 0xF0but that's just my lack of C++ knowledge and IC programming. So if someone can educate me that would be great

I'm going to try adding the charging status as well for when it is plugged in and maybe tweak the layout a bit, then if someone can test it, I'll create a pull request to Zapta's original

zapta

@richardmckenna, very nice!

The IP5306 seems to have only 25% increments for the LEDs and possibly the IP5306_I2C has the same resolution but with I2C interface instead of LEDs. Hard to find information about the IP5306_I2C.

M5Stack Schematic
http://community.m5stack.com/assets/uploads/files/1515402963959-97994060-2969-49dc-ad9c-7b3887d95a17-image.png

IP5306 (non I2C) Datasheet
https://datasheet.lcsc.com/szlcsc/1809201029_INJOINIC-IP5306_C181692.pdf

The expression (data & 0xF0) returns the 8 bit value of 'data' with the four right bits forces to '0'.

BTW, the two temperature fields in your picture seems to have extra characters. Is it intentional?

richardmckenna

@zapta said in Duet Buddy - a proof of concept remote monitor:

@richardmckenna, very nice!

The IP5306 seems to have only 25% increments for the LEDs and possibly the IP5306_I2C has the same resolution but with I2C interface instead of LEDs. Hard to find information about the IP5306_I2C.

Yeah that is all I could find. Oh well 25% increments are better than nothing. I’ve added a charging status now as well so when it is plugged in it shows “Charging” and when full “Charged”.

BTW, the two temperature fields in your picture seems to have extra characters. Is it intentional?

That was me trying to find the degrees symbol only to discover it doesn’t exist in the included font. It seems to be standard ASCII with only some of the extended ASCII characters. I’ve given up on that and removed them.

zapta

@richardmckenna, how did you implement the 'Kossel Max' title? Is it hard coded in your arduino code? One option is to add a title field to the config file on the SD card.

Or, anybody knows if it's possible to query the printer name from the printer using a HTTP request?

richardmckenna

@zapta I added an extra field to the json file and parsed it like the others. Didn’t even think about pulling from the duet, I will explore that possibility.

The reason behind me wanting the name displayed was that I’m thinking about the best way of adding multiple machines to it. So having an array of machine objects defined in the json. Then you can navigate between the different machines with the left and right buttons.

richardmckenna

@zapta The printer name is available through /rr_status?type=2 so should be easy enough to do an initial call to that to get the name and other info about the printer.

dc42

In the forthcoming RRF 3.01-RC2 it's also available via M409 K"network.name".

zapta

@richardmckenna, if type=2 has also the other relevant information we can just switch to it instead of type=3.

Does it require changes in the duet response json parser?

zapta

@dc42 said in Duet Buddy - a proof of concept remote monitor:

In the forthcoming RRF 3.01-RC2 it's also available via M409 K"network.name".

Thanks for the info. This require posting gcode to the duet, right? What is a reasonable and simple way of doing it?

Once we figure this out it will be useful for other functionality such as pressure-advance up/down buttons for interactive experimentation.

richardmckenna

@zapta type 1,2 and 3 all seem to share some information but unfortunately not all the bits we are are looking at.

status-type-1.json
status-type-2.json
status-type-3.json

So I think it would need a single call to 2, to get the name and repeated calls to 3 as it currently does.

the duet parser will need tweaking as it only looks for:

char state_char;
float progress_percents;
float z_height;
float temp1;
float temp2;

But that's straight forward. And if the JSON config file is changed just to have the IP, the rest of the URL can be provided by the code depending on which call it is doing.

I will continue to have a play with it, see what I can do.

You can see my updated battery code in my fork here https://github.com/richard-mckenna/misc/tree/master/duet3d_buddy/arduino

Would you be able to separate Duet Buddy into it's own git repo?

zapta

Hi Richard, I create a separate duet_buddy repository here https://github.com/zapta/duet_buddy

If you will send me your github id I can add you as a contributor.

richardmckenna

@zapta excellent thanks. GitHub id is just "richard-mckenna".

zapta

@richardmckenna, sent you an invite via github.

Please feel free to touch anything, including the project page and documentation files.

DK90

This post is deleted!

PastThePoint

I know I am late to the party, but did this ever get figured out for the Duet 3's? Mine just keeps saying "Bad response from duet"??

PastThePoint

@pastthepoint @zapta

PastThePoint

@pastthepoint I'm an idiot. I'm running a Duet 3 w/ SBC. I don't know if it means this will not work or changes need to be made.

zapta

@pastthepoint, this one will require code changes to support Duet3 which has a different HTTP/Json format.

I believe that this one, which is newer, works with Duet 3 but didn't try it myself. https://forum.duet3d.com/topic/15198/reppanel-a-diy-alternative-to-the-paneldue-with-wifi-support

richardmckenna

@pastthepoint @zapta I’ve rewritten this recently (I know it’s taken me a while to get round to it) and it works with duet3. I don’t use an SBC so can’t confirm if it works. Not sure what the difference, if any is with the returned json between duet3 in standalone mode and with an SBC. I can share the code tomorrow.

zapta

@richardmckenna, do you want to send a github pull request with the changes? Or you can get write access if you don't have it already.