Start_Print is set to parse the arguments
[gcode_macro START_PRINT]
gcode:
{% set BED_TEMP = params.BED|default(45)|float %}
{% set EXTRUDER_TEMP = params.EXTRUDER|default(200)|float %}
# Home the printer
G28
# Wait for bed to reach temperature
M190 S{BED_TEMP}
# Set and wait for nozzle to reach temperature
M109 S{EXTRUDER_TEMP}
BED_MESH_PROFILE LOAD="default"
# Use absolute coordinates
G90
# Reset the G-Code Z offset (adjust Z offset if needed)
#SET_GCODE_OFFSET Z=0.0
# Move the nozzle near the bed
G1 Z50 F9000
G1 Z5 F3000
G1 Z1 F300
Ok this was working then it stopped. I hadnt carried out any changes at all. I rebooted etc then it started working again…now its off again
If I hardwire a value eg M190 S45 I know its reading the start_print macro.
It sets correctly…when I start a print file that def has passed values it doesnt
Not sure what you are doing, but Orca is not adding unwanted commands.
Your entire klippy.log is just a collection of various errors and unfortunately it seems coming from a Sonic Pad, so it does not allow for any proper diagnosis but generally it seems to be fundamentally borked.
Yes atm its from Sonic Pad but it is for dev work until Im sure and then I have PI ready to go.
I realise orca isnt adding anything eg teh GCODE confirms that.
Its the passing of parameters that has issue unfortunately.
So are you saying the klippy.log should show verbose transactions normally and allow me to see debug info?
Your entire log is just a collection of various errors ranging from connection problems, over wrong macro definition to some weird SD errors.
All this combined with the completely crippled and unusable logs that the Sonic Pad is producing.
The most practical approach likely is to factory reset the Pad and start with a fresh config containing only the bare minimum and then start from there.
@Sineos Cheers yep will do that
I was just reading about klippy.log and seems its just transactional function rather than debug of code.
Its really just code…I had a reread of the command tempate etc which is more like modified python. I saw that there are function modifiers held the in the naming eg prefix with an underscore and you get an directive to hide macros from the system and instead of keeping case sensitivity, the have removed it…further varying the norm
Based on the fact I was using ‘x_’ as a prefix for transitional tokenisation…I changed the naming to plain english and I can confirm it is now all working.
So how you name in orca and the parsing into the ‘param’ object of the macro has some undocumented impact/features.
