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.