G10 command in RRF 3.50-rc1
-
I noticed in the changelog for 3.50-rc1 that there a some changes for the G10 command but did not see (?) mentionings about mandatory number format adaptions for parameter values...
In rel 3.4.6 I did a "G10 P0 X0 Y0 Z0" for tool 0 axes offsets as well as a subsequent "G10 P0 R0 S0" for tool 0 heater temps. This was working for me.
When running my config.g in rel 3.50-rc1 I stepped into the situation that the config was prematurely stopped without any messages with these commands (took me some longer debugging to isolate this).
When I change the first G10 to "G10 P0 X0.0 Y0.0 Z0.0" config works OK and executes the command.
Changing the 2nd command to "G10 P0 R0.0 S0.0" seems to not to help, but I continue to investigate...
I am wondering how macro execution just terminates without any messages ...Are there plans to split up this command into separate variants as its current use may create confusion?
-
@hlwerschner A few questions to help work out what is happening...
Is this standalone or SBC? How are you determining that the config.g file has been terminated early? Does the same thing happen if you run the file using M98 p"config.g". If you have a minimum config.g file that demonstrates the problem then please post it.
-
@gloomyandy Hi, I can answer part:
1/ it is MB6HC with Raspi 3B which previously (before switching to 3.50-rc1) did run fine with 3.4.6 even for 9hrs prints.
2/ I did insert echo statements between every few lines and at some point there was no output in the log. Then I did add a global var at the begin of config.g likeglobal var test = 0 ... some lines set global.test = global.test + 1 ... some more lines set global.test = global.test + 2 ... and so one , having some bits set in global.test while propagating through the config.g ... at the end of config.g I would add echo "config . final state : " ^ global.test
I also created a small macro to be called independently from config.g to show global.test (bitwise).
With these helpers I was quite sure to identify that config.g stopped execution at some point midwise.
3/ yes, reproducible behaviour. I currently have the effect that in the middle of config.g I have a sequence; ----------------- actually from line 151ff ----------------------------- if global.verboseExecution echo "config : further config settings in sub-macros ..." ; Axis Limits echo "config : call sub-macro configAxesRange.g ..." M98 P"0:/sys/configAxesRange.g" ; set M561 & M564 S1 H1 at the end echo "config : macro configAxesRange.g executed, result = " ^ global.configAxesRange set var.configCompleteSubmacros = global.configAxesRange ; Endstops M98 P"0:/sys/configEndstops.g" echo "config : macro configEndstops.g executed, result = " ^ global.configEndstops set var.configCompleteSubmacros = global.configEndstops ........
and the cosole output is
14.10.2023, 12:45:17 M98 P"0:/sys/config.g" 14.10.2023, 12:45:17 config : macro configAxesRange.g executed, result = true 14.10.2023, 12:45:17 configAxesRange : Therefore the real nozzle is somewhere at Z = -4.0 ... -5.0. 14.10.2023, 12:45:17 configAxesRange : NOTE that Z axis MAX is set to 345 to prevent early nozzle crashes. 14.10.2023, 12:45:17 configAxesRange : all axes min & max positions are initialized 14.10.2023, 12:45:17 configAxesRange : Z axis : 0 : 345 14.10.2023, 12:45:17 configAxesRange : Y axis : -22 : 312 14.10.2023, 12:45:17 configAxesRange : X axis : -19 : 325 14.10.2023, 12:45:16 configAxesRange : init running ... 14.10.2023, 12:45:16 config : call sub-macro configAxesRange.g ... 14.10.2023, 12:45:16 config : further config settings in sub-macros ...
where this console output is to be read reverse (i.e. last msg on top).
The last msg is "14.10.2023, 12:45:17 M98 P"0:/sys/config.g" but the expected output from the command "echo "config : call sub-macro configEndstops.g ..." and anything following is missing. Obviously config.g was stopped after that last visible echo and the next (almost immediately following echo) somewhere. I did comment out the assignement statement between these two echo statements, but no change.
Btw: I checked with Ultraedit the config.g (and all sub macros directly used) for proper indentation for If#s etc (I always use blanks instead of tabs) and no garbage after code lines which might confuse a code-interpreter. All files are NICE looking.
4/ Stripping down config.g to achieve something small might be difficult. First I will try again by replacing the macro call by directly inserting the complete macro code into config.g which will make it quite large! I hope that this does not create new problems
-
@hlwerschner Can you post the configEndstops.g file. Also I don't see any "echo "config : call sub-macro configEndstops.g""in the file you have posted.
-
@gloomyandy I am quite sure that it is not in that macro.
I commented out the macro calls in config.g and inserted their respective content instead (without the final M99 ;-)).
The config.g now stops somewhere in the configAxesRange coding in the area :if !exists(global.ZaxisState) global ZaxisState = "unknown" ; may be "Homed" when Z axes endstops nicely triggered ; or "HomedZero" when G30 for Z = 0 in the center was done ; or "Levelled" when bed.g (for command G32) executed OK ; or "MeshGrid" when G29 has been done for the complete grid ; or "unknown" again after resetting/failure happens if global.axesZnumber == 1 if move.axes[2].homed && move.axes[3].homed set global.ZaxisState = "Homed" else if move.axes[2].homed set global.ZaxisState = "Homed" echo "configAxesRange : set up axes, phase 3" if !exists(global.XaxisMin) global XaxisMin = -19.0 else set global.XaxisMin = -19.0 echo "configAxesRange : set X axis range: " ^ global.XaxisMin
and the last log output is "configAxesRange : set up axes, phase 3" !
I use these if ... else sequence everywhere when I need global vars and it NEVER failed.My only suspicion currently is that there is a limit of global variables reached while running the config.g (plus every such variable pending since M999/reboot which was somewhere created).
I have to study how to get some system info about used/avail memory (perhaps).
If this is the case for rel 3.50, its a roadblocker for me.
-
@hlwerschner I'd try running the same macro in standalone mode (you will need to insert an sd card with a sys directory on it into the board) and see what happens with that. Other than that post your full (combined) config.g file so @dc42 and or @chrishamm can try running it.