Since I don’t use a limit switch on my Z (not sure in the homing input counts since I use a probe block) but when I set my Z limit_neg_pin to NO_PIN and change allow_single_access to false (as mentioned in the wiki) I get either and error 8 or error 9 when trying to move the Z. Error 8 if I try to set my Z0 from it’s current point, too.
I’m obviously missing something. Does anyone have a direction to point me in?
Is this for an MPCNC? The standard config sets the homing cycle to 0 for the Z axis which means $H won’t affect the Z axis.
Please share your config.yaml file.
Yes, for the MPCNC. The only change I’ve made to the Z motor cylce is to set a NO_PIN for limit_neg_pin and allow_single_axis to false. I then moved the Z neg pin for use as a macro pin.
Blockquote
z:
steps_per_mm: 200.000000
max_rate_mm_per_min: 1200.000000
acceleration_mm_per_sec2: 80.000000
max_travel_mm: 300.000000
soft_limits: false
homing:
cycle: 0
allow_single_axis: false
positive_direction: true
mpos_mm: 200.000000
feed_mm_per_min: 300.000000
seek_mm_per_min: 800.000000
settle_ms: 500
seek_scaler: 1.100000
feed_scaler: 1.100000
Blockquote
motor0:
limit_neg_pin: NO_PIN
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 4.000000
tmc_2209:
addr: 2
cs_pin: NO_PIN
uart_num: 1
step_pin: I2SO.10
direction_pin: I2SO.9
disable_pin: I2SO.8
r_sense_ohms: 0.110000
run_amps: 0.680000
hold_amps: 0.500000
microsteps: 8
toff_disable: 0
toff_stealthchop: 5
use_enable: false
run_mode: StealthChop
homing_mode: StealthChop
stallguard: 0
stallguard_debug: false
toff_coolstep: 3
macro1_pin: gpio.32
Error 8 is homing fail on the pull off and error 9 is homing fail on the approach.
Can you clarify what exactly you are doing? So, you turn the machine on, and attempt to jog Z without doing anything else? When setting Z0 you’re executing G92 Z0? Something doesn’t add up here.
I would also want to see your $SS output to see if there’s an error in the config file. How did you update the config file?
I had to copy the new file over. I edited using VS Code.
I am using the tablet controls in the web interface to try to move the axis.
Yea, I’ll need to see the $SS output. What you changed shouldn’t affect anything unless you are homing.
I’d also like to see the entire config.yaml file. You can attach it as a zip file.
There is defenitely something wrong with the config.yaml. It’s starting in an alarm state (error 8 is trying to send a command when the system is not in an IDLE state.) My previous config.yaml doesn’t do that (I tested). Zip has the old config, new config, an $SS output as well as the output when I try to clear the alarm.
fluidnc.zip (2.6 KB)
The only other thing I can think is that it’s having an issue with the size of my macro1 and macro2. Comparing the old and new only the PINS and macros are different.
Well this is the only thing that stood out in the $SS output.
[MSG:INFO: FluidNC v3.7.8]
FluidNC has changed a lot since then.
In general, that startup error is the root. I’d bet that macro pin definition is the issue. It can’t be triggered on startup. Might need to add a :high or :low to it.
Macro3_pin has been set that way and I don’t get any errors. The only other thing I can think of is that macro3 is on an expansion board while the other two are on the main board.
Set macro1_pin back to NO_PIN and see if you still get errors. If you do, I think you’ll have to set it to gpio.32:high or gpio.32:low. I get confused on which needs to be what when. gpio.32 is with the set of inputs used for inputs on the Jackpot and I think they have 10k resistors which may cause them to behave differently than the ones on the expansion board.
Your config is also different than the current one for the MPCNC. That’s a pretty old version of FluidNC you have so that’s adding to my confusion.
I decided to flash to 3.9.7. I’ll play with the config again and see what happens.
Having spent a little bit with 3.9.7, yeah, the config.yaml is different. Im going to try my changes in the new yaml to see what happens.