@CorvoConV in the current firmware version of the Paneldue there is a setting hide heaters.
so for me, at least in tool two, there is only one temperature in the display

So after some research.... and a quick look at the PrintEye code by @EasyTarget

https://forum.duet3d.com/post/110578

I think I have a plan based on the Json unpacking in PrintEye, to extract the following data:

extr: the positions of the extruders
efactor: the current extrusion factors (see M221 command), one value per extruder

Then sending a M221 to tune the extrusion factor after a user defined position delay based on filament path length between the sensor and the extruder melt zone.

The only kink is I'm not sure how to send a value to the Arduino to set the filament path length between the sensor and the extruder melt zone. I may have to hard code this to start with, or add a local display to set the value.

Does anyone know if I can add user defined elements to the json package sent to the Arduino as a response to M408? My thoughts are set a value for the filament path delta for each extruder with a user defined G/MCode (?) in the config.g.

I need to do some prototyping and merge it with Thomas Sanladerer's code and I possibly have a way forward!

https://www.printables.com/model/57154-infiDANK
https://www.youtube.com/watch?v=RYgdLPe_T0c

Multiple extruders needs a little thinking but I guess I could just connect multiple sensors to the one Arduino.

Also passthrough for the PanelDue, but I could use the code by @dc42 for the CNC pendant to sort that.

Will report back as and when I make progress! Another project to add to the list 🙂

Cheers
Barry M

@droftarts yes Ultimate Duet Menu System works

Apparently not. I was also starting to wonder if I had the right file so I opened up the chassis I printed for the PanelDue and discovered a V3 board inside. I re-flashed the V3 file and now it works.

Thanks for the response.

Finally it worked. 😄
I found the solution here: https://forum.duet3d.com/post/227278
Regards, you can close the thread.

@Phaedrux I've got a 3-zone pellet extruder, and two dual-heater filament heads. The pellet extruder needs individual temperature control, however, the secondary heaters/thermistors on the filament heads are ran at the same temperatures. Is it possible to only combine the filament heads but leave the temperature control on the pellet extruder separate?

@T3P3Tony said in PanelDue designations:

@arhi its an option for a display controller thats on the market. These chips sit between the PanelDue or other controller and the LCD screen itself.

cool, so duet has nothing to do with that design it's just a type of LCD .. clear

(I'm rather inexperienced with all the cpld/fpga stuff .. I learned it and do use them in my projects from time to time but even after years I'd not call myself even a junior in that field due to really low number of projects I used them in ... so wherever I see interesting application of them I try to get as much data as I can so I learn / gain some new ideas)

@droftarts ok sir.. Definitely will soon post the responses.. Thank you so much for the help.

@gnydick Does it do the same thing if you remove the case and leave it for a while? I had a similar issue at one point and it turned out that the case was causing a problem with the zebra strip that is used to connect to the display.

@jay_s_uk It solved (workaround) by removing '--no-warn-rwx-segments' option from build.make file in build folder ;).
I hoop for a better solution.
Thanks

Please send an email to warranty@duet3d.com and CC your reseller. Include a link to this forum thread and the details of your original purchase. You'll receive a reply with a form to fill out.

@chrishamm Sorry for the delay in our response on this- we let it slip. This primarily occurs when the machine is homing and the e-stop is pressed. It is easily repeatable on our machines running 3.4.4 with a SBC and the stock PanelDue firmware 3.4.1.

We have some time to further research, but so far nothing in our homing scripts has been identified as the issue. To reproduce, all we have to do is press the e-stop button while the gantry is homing in X or Y direction (haven't tested Z yet). Thanks

@dc42 topic done. It was really deceptive because so much is missing from the macros

@Exerqtor I'll mark this as solved but feel free to revert it if the problem occurs again.

@oozeBot said in PanelDue IP address display issue (3.3/3.4-pre1):

@mfs12 @mfs12 @T3P3Tony

This is surprising now that the PanelDue has been updated to work with the ObjectModel, but you are right.. after some testing, my assumption of what is passed to the PanelDue was incorrect.

We recently made the decision to build our own version of the PanelDue firmware (that we will keep in parity with the latest official releases). One of the changes was to add in the Global object. So to "fix" the issue, we added a global variable that contains the SBC's IP and are populating the field on the PanelDue with it.. It's not elegant, but it works.

Where can I find your PanelDue firmware?

@Phaedrux just reporting back that it was definitely the issue. Once I drilled the holes out in the case and re-mounted the PanelDue, the issue was fixed. Thanks!

On the SBC side of the house. I had an idea to write a X Window app that is basically the PD layout. People may argue why not just run DWC? But in my mind this app would basically be the PD and screen for the SBC at the same time. and not connect via network but direct to OS&DSF. Basically klipper screen concept for RRF+SBC makes obtaining a touchscreen for your RRF printer really easy hardware wise.

I think this a great idea but lack the skill to actually make it haha. I'm useless that way 🙂

@dc42 Thank you!

@oozeBot File-dependent M-codes are already sent back to DSF because DSF needs to handle or intercept them:

// Pass file- and system-related commands to the SBC service if they came from somewhere else. // They will be passed back to us via a binary buffer or separate SPI message if necessary. if ( reprap.UsingSbcInterface() && reprap.GetSbcInterface().IsConnected() && !gb.IsBinary() && ( code == 0 || code == 1 || code == 20 || code == 21 || code == 22 || code == 23 || code == 24 || code == 26 || code == 27 || code == 28 || code == 30 || code == 32 || code == 36 || code == 37 || code == 38 || code == 39 || code == 112 || code == 470 || code == 471 || code == 503 || code == 505 || code == 540 || code == 550 || code == 552 || code == 586 || (code >= 587 && code <= 589) || code == 703 || code == 905 || code == 929 || code == 997 || code == 999 ) ) { gb.SendToSbc(); return false; }

I've just added some new code that makes sure unknown G/M-codes are sent back to DSF before the default action is attempted (i.e. execute Mxxx.g or report an error if that fails).

@justus2342 first check that the problem isn't caused by the face of the display being screwed too tightly to the enclosure.

It's possible to replace the touch membrane. If you use the Search facility in this forum to search for "membrane" then you may find some suggestions.