I have a separate heatsink cooling fan for all my extruders
M106 C"Heatsink fan T0" P3 H3 T50:100
and I would like to see them in DWC. Problem is that as soon as I enable thermostatic mode with Hn, the fan wont be added to list of fans. I am aware that I cannot control the fan in thermostatic mode, but it would be handy to check if the fans are running correctly.
It would be very handy to define variables in e.g. config.g for bed center, default speed, acc, jerk, pin for probe etc. Right now, changing bed center has to be done in many different places which makes things error-prone. I can think of multiple use cases.
Suggestion:
@phaedrux said in Make use of variables:
There are some examples of config file sets that put a lot of work into parameterizing the whole thing, making system state switches by calling macros. This can be tedious to troubleshoot as you have to chase down the issues between macros to see how the system state is being altered through each step of the way. But it does allow for keeping sets of configuration variables in one place to edit, and then apply everywhere the macro is called.
Having $variables defined in one place would let macros become a lot more readable and you could refer back to the single variable definition file to see what is what. Currently the state of a gcode is always explicitly defined when it's called.
That's one reason to have variables. Less effort, more control over system state (as it is defined in one place). and better readability.
I'd be curious to see if people would find that more difficult or less difficult than it is now. And beyond the initial setup of the machine, you're not really editing those variables very often.
Well, having many parametrised macros is certainly quite messy the bigger the number. And if someone does not like to use variables then they could still use the existing approach.
A facility to make this possible is already planned!
@dc42 can't wait to use it. Bedcenter is just an example, where it variables would be helpful. Running a z-probe repeatabilty test would be much easier to implement too. Let's assume I want to repeat the test in other places than bedcenter (to spot a mechanical issue). Again, I would need to create yet another macro to set the location of the probing to take place. With vars, one could
; StartProbeLocationMacro.g:
Set probing location coords $X $Y at bedcenter
Run repeatProbe.g and record results in log file
Set probing location coords $X $Y at front left
Run repeatProbe.g
Set probing location coords $X $Y at front right
......
Reset probing location to default state $defaultBedCenterX $defaultBedCenterY
; StartProbeSpeedMacro.g:
Set probing feedrate, speed, height
Run repeatProbe.g
Change probing parameter
Run repeatProbe.g
....
Reset probing params to default state
This does seem like something that is more useful for a machine that is in development
@SupraGuy Absolutely. Either to setup and fine tune the configuration during development, but also to perform quality control upon setup of a new machine or to run maintenance tests.
As for the changes in the slicer as you pointed out:
G1 BED_X_CENTRE BED_Y_CENTRE 5.0
M280 PBL_TOUCH_PIN I1 S10
Hmmm, true. I don't see a use case for that - yet. Both lines are likely to bo into the start or end code scripts. Plus, that could just as well be done with macros containing the variables. But then how can you instruct your slicer to run a macro (apart from onstart, onlayerchange etc events)
As for the #define statements, I think the "gcode everywhere" approach is a MUCH better fit, due to adherence to coding standards and coherence.
I think it is important to point out that the value of the variables can be altered by
Mxx0 Kkeyname VNewValue
Thanks everyone for your input!
@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 ;-(
This is by far the best set of instructions for the procedure:
https://betrue3d.dk/paneldue-update-firmware/
@phaedrux said in Extend M929 logging capabilities:
On newer versions of the DWC there is a button on the Gcode console to download the entire log as a txt or csv file. Does that satisfy what you're after?
Nope. That's what I ended up doing. But I would love to be able to run a few automated test at night, collect the data and then analyse the results. As a former software tester, I would love to be able to automate some tests. Plus, it should be fairly easy to implement - at least the M929 C1
@OBELIKS Thanks,I know I can use macros, but my suggestion is a different animal. Consider this case:
I setup my BLTouch on fan2, which is pin 22. If I now want to switch to another fan, I have to edit deploy probe.g, retractprobe.g and some macros for testing / resetting the probe. With global variables (or constants) that could be achieved in one place.
Another case is the bed center coordinates: There are numerous references to them, so I have to keep track of them in every single macro and config. Way easier to keep things clean with variables. There is a ton of other cases I can think of.
Gcode is several decades old and extending it is a small step towards a modern(?) programming language. Basic arithmetic calculations would be another step...
I'm afraid that is not possible. Or how would you suggest to just change the pin parameter in
M280 P22 I1 S10 ;deployprobe.g
without affecting the others? This does not just set the pin, but makes the servo move.
@obeliks please stop replying. No offense, but it cannot be done the way you think. M28 / M29 are NOT helping either.
Would please someone else try to make a better point than I did. I know for a fact that it can't be achieved with "static" code. Unless you want to maintain a ton of macros - which is exactly what I want to avoid.
Thanks for the link. While loops and arithmetics are probably difficult to implement, I doubt that variables are hard to process. Why not 'just' do a search / replace if the first letter after the parameter is an @ or #? Is the storage of key / value pairs the tricky part? Or limited CPU resources or performance issues?
I'm not familiar with RepRap dev (yet), but if someone @dc42 could point me to a good entry point, I would be willing to look into it.
@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)?
![IMG_20200306_103533[1].jpg](/assets/uploads/files/1583488092969-img_20200306_103533-1-resized.jpg)
@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/