Variable confusion in M command.
-
You are wrong here. I initialize the variables in the config,g. The start gcode from the slicer starts a macro, which starts a other macro with starts the next macro and that one reports the problem.
And you see that the macro contains two variables:
The error report is only about the first variable, the 2nd seems to be OK, at least form the error message.
-
@dc42 My reply was wrong; Standalone
P.s.: Would it make sense to drive a 5+ in SBC?
-
This post is deleted! -
P.s.: Would it make sense to drive a 5+ in SBC?
That was not very serious. I was in troll mode...
-
@Chriss have you try looking at global variables in the Object Model browser in DWC, to see whether those global variables exist?
-
@Chriss Yes I see them, you can see the screenshot in my initial post. And I would expect a complain if the variable does not exist and I use the command via telnet or the DWC.
One more observation: I have the feeling that I see the error since I have upgraded the display (!!!) to 3.4rc3. I have no idea how that could influence the firmware to be honest but that is what I have in my memories. (Yes, I see the error in the logfile and in the DWC, not on the display only.)
Does that makes sene to you?
Cheers, Chriss
-
One more thing: I see the error already at boot time not only when when the macro gets called, if that helps.....
-
@Chriss If you are getting that error at boot time then something in your config.g file or the macros it calls is referencing the global. You seem to call two macros in your config.g and both of those calls are before you have created the globals are you sure that those macros (or any others they may call) do not try to reference the globals before you have created them?
From your config.g:
M98 P"/macros/print_scripts/speed_printing.g" ; Accelerations and speed M98 P"/macros/print_scripts/activate_z_probe.g" -
@gloomyandy Holy cow... you are right.... the /macros/print_scripts/activate_z_probe.g contains:
M558 P8 H{global.probe_settingsH} A{global.probe_settingsA} S0.003 F700:120 C"^121.io2.in" T8000 B0 R0
But this part of the config is older than the stone age, and the error popped up after a recent upgrade. I'm sure that I observed this messages after a print start too. So Davids fix did something too. I did not see the messages after I started the current print, my guess is that we had two problems here.
Long story short, I moved the variables to the start of the config,g. I will reboot the printer later today when the current print has completed and let you guys know.
Cheers, Chriss
-
@Chriss The code to report errors in the config.g file during RRF startup is a new feature in 3.5, so you would not have seen that message in early versions.
-
Got it... I'm not sure what the previous version of that printer was. I should have a logbook for that purpose.
Anyway, whatever David did suppressed the error message when the activate_z_probe.g gets triggered in the homing moves. My conclusion is that it was not only my stupidity with the order of the commands in the config.g
I guess that it is solved now.
Cheers, Chriss
P.s.: I just saw this:
M558 now supports two dive heights. When probing multiple times at the same point, the second and subsequent probes use the second dive height and it is calculated relative to the height at which the probe last triggered. The idea is to speed up probing if you make the second dive height smaller than the first.I think that I do not need my hack with the variables for H and A anymore for M588.
I should read the release nodes more carefully. 
