Posts made by Googliola

@titusou Thanks for pointing that out. I still think that this is not an acceptable solution. Why would I need to rewire my heaters just to get things right on the panel? Wiring is complex anyway, so I tried to simplify it by using Duex5 for all my heaters (except bed of course). So, still, I think PanelDue is an inferior solution to any wifi enabled touch screen device out there. And I cannot recommend to buy it - except for simple default setups, which is not what Duet boards are made for, right?

I won't keep banging my head on the same spot regarding this issue, but still hope that this will be fixed soon. Or then I just toss it and replace it with wifi touch.

@dc42 could you or anyone familiar with panelDue firmware try to fix this, please? I made a similar request on github issues earlier (and not so friendly - sorry about that) but got no reply. It seems that the firmware has not been updated much for almost 1 year, despite its flaws.
If you don't intend to continue development / support then I would at least ask you to let us know and discontinue production / sales. If I had known, I would have invested in another wifi-enabled touchscreen in order to at least have DWC.

This is what is displayed on my 7"panel running 1.23.2 firmware:

Only heater 0 is configured, touch screen does not work (need to press buttons in column heater1 to actually edit value of corresponding column.....)

Setup in config.g:

; Heaters
M307 H0 B0 S1.00                                   ; Disable bang-bang mode for the bed heater and set PWM limit
M305 P0 T100000 B4138 C0 R4700                     ; Set thermistor + ADC parameters for heater 0
M143 H0 S120                                       ; Set temperature limit for heater 0 to 120C
; Disable Heater 1 and 2 (not used)
M307 H1 A-1 C-1 D-1 ;
M307 H2 A-1 C-1 D-1 ;
M305 P3 S"DueX Heater 0" T100000 B4138 C0 R4700 X3                ; Set thermistor + ADC parameters for heater 1 and remap it to channel 3
M143 H3 S280                                       ; Set temperature limit for heater 1 to 280C
M307 H3 A595.1 C124.8 D7.8 B0								 ; Set PID values
M305 P4 S"DueX Heater 1" T100000 B4138 C0 R4700 X4                  ; Set thermistor + ADC parameters for heater 2 and remap it to channel 4
M143 H4 S280                                       ; Set temperature limit for heater 2 to 280C
; M307 H4 A C D B0								 ; Set PID values
M305 P5 S"DueX Heater 2" T100000 B4138 C0 R4700 X5                  ; Set thermistor + ADC parameters for heater 3 and remap it to channel 5
M143 H5 S280                                       ; Set temperature limit for heater 3 to 280C
; M307 H5 A C D B0								 ; Set PID values
M305 P6 S"DueX Heater 3" T100000 B4138 C0 R4700 X6                  ; Set thermistor + ADC parameters for heater 4 and remap it to channel 6
M143 H6 S280                                       ; Set temperature limit for heater 4 to 280C
; M307 H6 A C D B0								 ; Set PID values
M305 P7 S"DueX Heater 4" T100000 B4138 C0 R4700 X7                  ; Set thermistor + ADC parameters for heater 5 and remap it to channel 7
M143 H7 S280                                       ; Set temperature limit for heater 5 to 280C
; M307 H7 A C D B0								 ; Set PID values

PS: How does it work on E3D toolchanger?? Do things work on Duet3 / PanelDue the way they are supposed or is no / another display used for E3D?

@dc42 said in Use 5v from diffrent source for optical endstops? on duetwifi:

l component. The picture is a little out of focus, so I can't read the label on it - what is it? Can you measure its value with a multimeter?

Hmmm, when I connected them 18 months ago, they did not work...now they do?! Probably my fault. So just for future reference: Optical endstops V1.1 from Trianglelabs are 3.3V tolerant. Yeeeha.
@dc42 thanks for your support (R1 is 470, R6 is 750, all the other 10k Ohm)
@mrehorstdmd thanks for your input as well. On a sidenote: your (coreXY) blog posts are tremendously helpful. So thanks for that too!

The board I have is the Duet2Wifi v1.02 and the endstops are most likely 5v (see pic), so no luck with that combo. I read somewhere in this forum that it is possible to convert them to 3.3v by adding a resistor. My know-how for these things is close to zero, so could anyone point me to right resistor and what Ohm I need to add (on top of SMD resistor)?

@dc42 Haven't had much time lately to follow up on my feature request. With holidays ahead, this will change soon

Just been wondering how the object model is coming along and if you could make a statement about when / what version it will be implemented.
Thanks in advance

@fallenhorseman Glad I could help.

Note to all guys: Yeah 4k7Ohm Pullup to 5V is resolving that issues

Funnily, I dont need a pullup between 5V and the PWM of the FAN, but I need one between GND and Z-Probe (as you can barely see in my picture . I use the 'old' version of BLTouch which is not 3.3V 'tolerant'. Am I missing something or is that a typo on your side?

@core3d-tech In case you have missed the discussion about variables I kicked off a while ago.

dc42 posted a first draft of the intended implementation here , I haven't had proper time to comment on yet ;-(

@dc42 maybe it's a minor bug, but it does not work as you said. Could you please have a look into it.

@dc42 @claustro
M557 X15:325 Y-15:270 P3 (in config.g)
resulting in
Error: M557: Error: M557 P parameter is no longer supported. Use a bed.g file instead.

Seems like a bug to me. Or what am I missing? (It worked just fine with S parameter, but defining the number of probing points is so much handier...)

This is by far the best set of instructions for the procedure:
https://betrue3d.dk/paneldue-update-firmware/

@dc42 From a user perspective, the terminology would cause confusion and additional and maintained documentation , but then the question is how much you weigh user-friendliness.
If I were in your shoes, I would probably stick to ease and coherence with known / documented guidelines. You might open Pandora box here. People might argue that common (Fanuc) standards are 'better'. Comes down to taste at the end of the day really...

That will be possible, because all configuration variables will be included in the object model

@dc42 how would you refer to the (M558) A param value in that case?

• M558. A
  or
• parentObject.[otherObject].value

While the first is self-explanatory, the other might adhere to the OM, but would complicate things for the user and documentation (but maybe much easier to develop??)
I think using a Gcode is more user-friendly overall.
Again, I don't know much about the consequences in terms of the code or the HW restrictions (cpu, ram, performance etc.)

@dc42 I haven't had time to properly review your proposal yet - will do over the weekend. First of all: Wooooohooo, you are the most responsive dev I have met so far. Big up for your effort!!!! And in contrast to (an-)other dev of hard- & firmware, you are super friendly and quick at solving customer needs! I feel like I found the right place to base my printer kit on!

At first sight, I would kind of stick to the Gcode-everywhere paradigm, when it come to the simplest of all - setting and reading a variable. But as I can't read your mind but suspect that the RRF object model you have in mind is separate from the Gcode processor (or for any number of another reasons), the var approach seems to be unnecessarily stray from your paradigm.

Maybe M123 Kkeyname Vvalue is a better approach? Where KeyName could be retrieved by just adding a designator like @ or $?
Also, M123 could be extend by the data-type such as M123 KmyInt V3.1412 Dfloat would be reflected?

On another page, but related: In terms of usability of a specific product (like the e3d tool-changing printer), it would be tremendeously helpful to be able to read the current setting of commands like M558, M584 and the like by issueing a M558 A? (and get the value of A back) or M558? to get the values of all parameters back (either as string or as a named array - preference for the latter of course )

One major use-case is the way you could set your z-probe offset with G31 Z$measuredZmean
The way I do it now is by running @Phaedrux script he provided here but with the above suggestion, there would be no need to read the mean value in the console - just get the mean value, store the value by M123 KtriggerHeight VmeasuredZmean and set triggerHeight value by G31 Z$measuredZmean
Except for the paper-trick, no further manual action would be required....

Or think about how endstops could be used (again for tool-changing) if I had a simple microswitch, I could retrieve the state of and them take according action - like if T1 parked or is a tool loaded.

@dc42 I think, it's the other way round. I split z to Z and U and hide the latter (P3) by

M584 X0 Y1 Z2:3 U3 E5:6:7:8:9 P3

Or maybe the U3 is messing things up?

Sidenote: hiding axis(es?) is causing trouble elsewhere too. Can't find the post right now, but I know someone else mentioned it. Will post back ASAIK.

@dc42 Yes, running the combined firmware

@Moriquendi : good question. My z-probe (BLTouch) readings are not as good as I wish. I started a few tests to measure repeatability and a request to change M558 behaviour

My coreXY has dual Z-axis (U being the virtual 2nd axis) and 5 extruders. Somehow they get all mixed up in the DWC machine properties as you can tell from the speed / acc etc.:

Using latest FW 2.02RC2

@Phaedrux Thanks for the link. Indeed a simple and nice workaround. Unfortunately, I'm a Windows (8.1) and not a Linux person. But I starred the project and will check back.

@Phaedrux your macro is quite nice. I adapted it to my needs but I am a little confused:
Considering "my" way to measure repeatability (see above) what is the benefit from

• moving the probe away by X40 Y-40 at the end of each round of probing and
• lowering the bed to Z10 before probing - in addition to dive height?

@dc42

While

C0 (default) / C1 : disable / enable logging for all content from the console

would log everything that is sent to the DWC console (just like the button on the GCode console to download the entire log)

D0-14:
a. enable debugging: M111 S1 P[D value]
b. disable (0) / enable (1-14) logging of the debugging infos as set
c. use D3:4:12 (see M111 extension below)

would add more info to the log according to the state of M111 (or is the debug info exclusive to a USB connection?)
EDIT: Debug output goes only to USB. Is that still valid?

Meshbed probing is already nicely covered by DWC, but if it comes at little additional effort, that would be helping in the log as well. Again, logs are essential for any kind of testing....