Options for getting information to third party usage



  • I'm in the middle of new build and just received my new DuetWIFI some days ago. The printer is still not ready, but I'm already thinking about next improvement and tinkering steps… as you are.

    I would like to automate things around the printed according to the print progress and parameters. For example, I'm planning to build a progress bar from leds and an Arduino to show the progress of the ongoing print.

    The question is, is there any easy way to tap into the data from web interface (or printer)? I would need a way to get information to the Arduino/Raspi. I have no problems writing code for it, I just would need to know what is the best way to get the information. I tried looking for documentation and earlier discussions, but I did not find much.



  • You can get a json data structure by sending M408:

    https://duet3d.com/wiki/G-code#M408:_Report_JSON-style_response

    It can be done through wifi (http request), or USB. But I don't know if a more simple serial connection is available…

    I also have plans to make such simple interface, and your led-based progress bar idea is nice!


  • administrators

    If you don't have a PanelDue connected, you can also use the PanelDue port to send the M408 commands and receive the responses. It's standard serial async with 3.3V signals levels, so you will need to level shift it if you use a 5V Arduino. Even if you do have a PanelDue, you could connect the Duet TxD pin to your Arduino as well and have the Arduino snoop on the status responses.



  • Ah, yes, I forgot the Panel Due port! Thanks.



  • Great info everyone! I will definitely share my implementations once I have something working. But first I need to finish my printer build, i guess…



  • I started looking into this already as the actual build is waiting for some parts.

    The M408 gives nice variety of information and I can do the progress bar with fraction_printed. But the plan was also to make a very large 7-segment / led matrix screen that would show information on the print, including as accurate as possible time left.

    I can of course estimate a time left value by measuring the changes in fraction_printed, but I see that there is also timesLeft-parameter. And I would like to combine other parameters to the estimation as well, to potentially make it more accurate. But looks like it is only available when printing from SD card. Is this true? I'm just curious why is that like that?

    I'm especially interested in current layer and total layers information and then also filament used and total filament.

    fraction_printed: the fraction of the file currently being printed that has been read and at least partially processed.
    message: the message to be displayed on the screen (only present if there is a message to display)
    timesLeft: an array of the estimated remaining print times (in seconds) calculated by different methods. These are currently based on the proportion of the file read, the proportion of the total filament consumed, and the proportion of the total layers already printed. Only present if a print from SD card is in progress.



  • As you have discovered, the estimates of time left to complete the print are only that - estimates based on what has already happened then extrapolated to predict the time remaining. However, this all assumes that what has yet to happen gets completed at the same rate as what has already happened, which isn't usually the case.

    IMO, the only way to get an accurate indication of time remaining is to first run a simulation of the gcode file to calculate the time required to print that particular object, then subtract the time elapsed from this. There was a thread on these forums somewhere by someone who had written something which would do this simulation, or least calculate an accurate time to print a given gcode file. So, if you are making a stand alone progress bar type of thing, then you might be better off using this approach, rather than use the DWC estimations.


  • administrators

    Firmware 1.19 allows you run a simulation of printing the file using the M37 command, to get an accurate print time. DWC 1.19.3 makes this function easily available in the GCode Files page. There is also the program referred to in the previous post.

    The reason you only get an estimate when printing from SD card is that if instead you are sending data through USB, the firmware has no idea how much data it is going to receive or how much filament the print is going to consume.



  • @dc42:

    Firmware 1.19 allows you run a simulation of printing the file using the M37 command, to get an accurate print time. DWC 1.19.3 makes this function easily available in the GCode Files page. …...........

    Ohhh - didn't know that. Thanks for pointing it out.



  • @deckingman:

    As you have discovered, the estimates of time left to complete the print are only that - estimates based on what has already happened then extrapolated to predict the time remaining. However, this all assumes that what has yet to happen gets completed at the same rate as what has already happened, which isn't usually the case.

    IMO, the only way to get an accurate indication of time remaining is to first run a simulation of the gcode file to calculate the time required to print that particular object, then subtract the time elapsed from this. There was a thread on these forums somewhere by someone who had written something which would do this simulation, or least calculate an accurate time to print a given gcode file. So, if you are making a stand alone progress bar type of thing, then you might be better off using this approach, rather than use the DWC estimations.

    Looks like it was this: https://www.duet3d.com/forum/thread.php?id=1698&p=1

    I will look into that as well, and I agree, simulation will most likely be the most accurate way of determining the print time. I will have to look into this more deeply. Thanks for the info again!


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.