I purchased one of these boards from the V1 store and have the components installed and moving in the right right directions (optical end stops not installed yet) . It came with FluidNC installed so I downloaded the .yaml file to try to make sense of the settings. I found a post with settings that appeared to be from the same or similar board:
Comparing the settings from both files, I see the following differences:
So the / separates the actual config from a comment (typically the previous or default value.) Ignore what comes after it.
The pulse_us is microseconds to have a pin high for. Looks like it was set to be a bit longer.
Soft limits are to set the machine so that it must know where it js, and cannot try to go out of its defined boundary. Most V1 machines have this turned off, as it mostly gets in the way with typical work flow.
Cycle defines when an axis homes. For the ZenXY, the Y axis must home first, or the X end stop cannot trigger.
The limit pins must be told that they trigger on logic high for the optical end stops. Default behaviour is to trigger on logic low.
See above
Not for the ZenXY, but it doesnt hurt anything.
Ditto. Coolant or air assist pins exist, but nothing will be connected to them.
No. You are changing the “running config” in memory when you change it in the UI.
In order to write it back to the file, you need to issue the command $CD=config.yaml in the terminal. If you are using Ryan’s config with his macros, this is what his “SAVE” macro does for you
I was having trouble making what I wanted to show appear correctly in the preview. No matter what I did, I couldn’t get it to look like a table. The “/” on each of these just separates the the 2 different settings noted on the files (Preloaded file / Forum file).
Couple more questions:
What is mpos:?
What is pulloff_mm: and is this a new setting that the forum file would not have had? The WebUI has a setting of 1.000 and preloaded file has .500 . Why would they be different?
Should the cycle setting be the same for both axis? The files have different settings but they are the same for both axis.
During a homing cycle, the axis will move until the switch is triggered, then back off the switch. This controls how far (in millimeters) is needed to back off. Different switches may have different distances to be deactivated. A full mm is probably a pretty safe default, the preloaded file may be better tuned for the actual switch being used.
My yaml below - think it required a couple of tweaks to home. I think my hardware is vanilla and I have the same electronics, ordered about 2 months ago.
HTH
Details: This is the distance to pull off a touched switch with this motor. This value should be greater than the amount you can travel after the switch is activated. This makes sure you can always clear the switch during homing.
Does this affect the1st, 2nd or both pulloffs during the homing cycle?