What would I need to change to use this on my MPCNC?
To use this type of gcode or use Z leveling gcode? It requires FluidNC 3.8.2.
I don’t think Z leveling applies to the MPCNC? Isn’t that just manually done by trying to make the legs all the same length? I imagine you could probe in each corner and the center to see which way it’s tilted. Once you know that you could adjust the corners. There wouldn’t be a pulloff value you could modify to fix it though like with the Lowrider.
3 Likes
I just tried it on my Beta RC2 LR4 and it works amazing! That is so much easier and faster than doing it the manual way!!!
3 Likes
Ok, that makes more sense to me now. You’re right, there isn’t a pulloff for Z on the MPCNC.
1 Like
@jeyeager First off thank you for sharing this gcode, it really is neat and you were right to be excited about it!
One thing you might think about changing… Add in a M0 to remove probe BEFORE it makes the jog to X Max. My probe wire is a little long and it almost got hung up in the core before I could grab it lol.
2 Likes
Oh does this mean I can set motor current in gcode?
I’d like to use low current when idle, and higher current for running, but I don’t trust the TMC2209 idle current because it is per-axis and a pure X move might not hold Y.
If I can set run current to let’s say 0.8 A and idle current to 0.4 A when not running, and then boost idle current to 0.8 A when running a job, that would be nice.
Then when job finishes I can set idle current back to 0.4 A.
4 Likes
Yes, I think it does, if we can figure out the right syntax for it.
This is a really powerful capability.
Think about how RepRap firmware dosn’t even need a config file, you can just feed it a gcode file that sets all the settings.
2 Likes
Good idea. Updated above.
1 Like
Awesome! Thank you!
Another question that just popped in my head… How does it know which side is wired as Z0 vs Z1??
I found this out part by accident and partially from what I learned developing extensions. It appears that you should be able to edit any setting in the config.yaml file this way.
I previously knew that I could set config.yaml properties via the terminal (or via the extension API) by passing commands in this format:
$/axes/z/motor0/pulloff_mm=2.000
$/axes/z/motor1/pulloff_mm=4.598
When I tried to use the $ format for setting the value from a variable, it didn’t work. So, I tried the #<> format which did.
The syntax is easy enough, for every level in the config.yaml, just put a / in between. So, for the z motor 0 that I’m modifying, it’s in the config.yaml as:
axes:
...
z:
motor0:
pulloff_mm: 4.0000
...
This is also what shows on the Settings → FluidNC Features → Config section.
@jamiek Since you just want to set it to hardcoded values, you can use the $ format instead of the #<> format.
2 Likes
I assumed that Z0 is on the left and Z1 is on the right. I’m not quite sure what it would mean to swap them nor did it cross my mind that was even a possibility.
One of my favourite features of RRF. You can also completely reconfigure the machine on the fly. I also like its use of variables and looping structures. For example, my bed levelling macro for the MP3DP starts with a test if X, Y or Z are not homed, then home them, so that it won’t do it if it doesn’t need to, then it uses a loop structure to probe for the motor heights 3 times, and finally set Z=0 by probing at the bed center.
I had some fun with the LR3 beta reconfiguring it so that each Y and Z motor were their own axis, and moving them independently.
So long as the firmware makes the same assumptions. I ended up with Y0 and Z1 left, and Y1 and Z0 right on my LR3 because it made sense with how I square the machine. (Could have done it differently, but it works now. I probably should have just changed the gcode but I remember that being a 2:00 AM session where I swapped the Z axis.)
1 Like
I think it depends on which side of the machine you have your control board. But honestly it can be either side just as @SupraGuy guy.
If I am standing at the front of the machine looking at the router. Z1 is to the left and Z0 is on the right. So mine would be backwards from yours.
So is it possible to have a variable that you set for if Z0 is at X Min or X Max?? Or is it better to just alter wiring a touch and move to make Z0 Left and Z1 Right?
And I guess that now proves that I didn’t go back and double check that it made the right adjustments 
1 Like
I’m trying to make sure I understand what this means. Am I correct in that the only difference between your setup and mine other than the stepper cables being swapped is that the Z endstop cables are swapped as well? So, as long as they are paired up, it doesn’t really matter.
Assuming my understanding is correct, I could support this with an extra variable.
As for left or right for Z0/Z1.
RRF has a leveling feature built into G30 (probe) that can adjust independent Z motors. To do that, it needs to know the location of the Z motors relative to the bed. The levelling feature for Marlin, the motor’s approximate locations must be as the firmware expects, but the exact offsets aren’t needed.
So in RRF, the motors just need to be defined. In Marlin, they must be 0 left, 1 right if you want to use the bed level feature. I don’t know for FluidNC, if it has the feature or if it cares which is which.
For sure though, the end stops must be matched to the motors, but for them to function, it does not matter which is 0 and which is 1, and it does not even matter if Y0/Z0 are the same side, so long as the stops agree with the motor.
1 Like
Correct. As long as the correct endstop is connected with the correct stepper it makes no difference to the machine which is which, at least until you try to do something like you have here
I believe your understanding is correct
1 Like
I think there is a FluidNC bug. I noticed after doing this a couple of times, it was taking awhile to connect after restart. On occasion, I even saw low memory warnings.
Looking at my updated config.yaml, I saw that this was added:
web_commands:
wifi:
ota:
mdns:
wifi:
telnet_server:
notifications:
web_commands:
wifi:
ota:
mdns:
wifi:
telnet_server:
notifications:
Which corresponds to these results from $SS:
[MSG:INFO: WiFi on]
[MSG:INFO: Start mDNS with hostname:http://fluidnc.local/]
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]
[MSG:INFO: WiFi Disconnected]
[MSG:INFO: Connecting to STA SSID:YEAGER]
[MSG:INFO: Connecting.]
[MSG:INFO: Connecting..]
[MSG:INFO: Connected - IP is 192.168.0.240]
[MSG:INFO: WiFi on]
[MSG:INFO: Start mDNS with hostname:http://fluidnc.local/]
[MSG:INFO: WiFi Disconnected]
[MSG:INFO: WiFi Disconnected]
[MSG:INFO: Connecting to STA SSID:YEAGER]
[MSG:INFO: Connected - IP is 192.168.0.240]
[MSG:INFO: WiFi on]
[MSG:INFO: Telnet started on port 23]
[MSG:INFO: Connecting to STA SSID:YEAGER]
[MSG:INFO: Connected - IP is 192.168.0.240]
[MSG:INFO: WiFi on]
[MSG:INFO: Start mDNS with hostname:http://fluidnc.local/]
[MSG:INFO: Connecting to STA SSID:YEAGER]
[MSG:INFO: Connected - IP is 192.168.0.240]
[MSG:INFO: WiFi on]
[MSG:INFO: Telnet started on port 23]
I’ll have to investigate further. If I remove those extra items, it’s good again.
1 Like
Might want to report that on Github and see what they say about it.
Yea, I want to figure out the scope of it first. Is it unique to doing this from gcode? Does it happen if I update the values from the WebUI? What are the simplest steps I can come up with to reproduce it?
1 Like
I posted on the FluidNC Discord about this. We’ll see where it goes. It has nothing to do with the fancy gcode. You can reproduce the problem quite simply:
- Run $CD=config.yaml. Those extra lines are added to the config.yaml file.
- Restart the board.
- Run $CD=config.yaml again. Those extra lines are duplicated in the config.yaml file.