What happens when you just home, then run you G1 X10 F2000 command?
Same thing, but if I do G1 X10 F2000 again it acts normal. if I then jog and repeat the G1, it moved left. I also tried homing and then G90 and then G1 X10 F2000 and it still moved 50+.
Have you tried this on your system?
Sounds like you might have found a fluidnc bug. I will give it a try later.
The two ways I am sure people use this does not include mixed modes.
1- Home, use the buttons to drive to a location.
2- home, enter gcode to drive to a fixture. (or use workspaces).
Both of those should work fine.
I will look at moving with buttons and then using gcode.
Does it still happen is you use G0 (travel move might be a rapids issue), G1 is a working move?
I am asking specific questions because if you or I submit this to FluidNC these are the questions they will ask. We will need to show a repeatable error.
I have not tried it, but my guess is it set some other origin and it is moving based on that. My start gcode has G92 X0, Y0, so maybe I need enter this after homing before entering a gcode command. I will give it a try when I have a chance. I have not tried G0 either.
On a related note, maybe the G92 command needs to be in the after homing macro?
This is from the FluidNC wiki macros section. I am not sure what is under the hood in the homing routine or jogging that may or may not set the origin.
Config Items
- startup_line0: & startup_line1: These are legacy features from Grbl, which called them $N0 and $N1. These run when the firmware enters idle for the first time.
- macro0 through macro3 This is the text of the macro that will run when the associated control switch is activated. These switches must not be in the active state at startup. You need to deactivate the switch before you clear the alarm.
- after_homing (as of v3.7.6) This macro runs after homing is complete, i.e. after every axis that has homing enabled has been homed.
- after_reset (as of v3.7.6) This macro runs after the system has been reset, either from an initial power on/startup, or after a CTRL-X realtime reset, but only if the system is in Idle state immediately after the reset.
- after_unlock (as of v3.7.6) This macro runs after a $X unlock command.
Config Example
macros:
startup_line0:
startup_line1:
macro0: G90&G53G0Z-1&G0X0Y0
macro1: $SD/Run=drill.nc
macro2:
macro3:
after_homing: g0 x1 y1
after_reset: g20
after_unlock: g91
Give it a try.
How often are you worried about doing this? I understand you found something odd but I think the way you are getting there is kind of equally odd.
If you need to move to a specific point, directly after homing does the manual Gcode not work?
PS, there is a new firmware version, might want to try that to see if maybe it was a bug that is already fixed.
I fat-finger the jog controls quite often. In this case I was checking the square because I am about to redo my spoilboard and it was a lot of jog button presses, so I thought entering the gcode command would be easier. With my new spoilboard, I will have a few spots to install a fence and would like to enter the command to go to that location. This does not really seem like an odd use: Home, enter a G0 or G1 move and then start my job (which sets the origin and then probes Z). Alternatively, maybe I can put it in a macro.
You can zoom in. Even on my phone that makes them huge. If you go about squaring by typing in each coordinate it should work right, seems like just the mixed commands that are making things odd.
Since it is a repeated test making a small handcoded gcode is an even better way. I do it each time.
Square check.gcode (481 Bytes)
This is where you would use workspaces, or program the coordinates into your starting gcode., you will not move to them with buttons and gcode commands mixed.
Like I said, I get it, seems like it might be a bug. I just am not sure you will run into this in daily use. I am not capable of fixing it, but if we are going to submit a bug report to FluidNC it takes a bit of work to lay out exactly what happens.
Does it still happen?
So I just tried my machine, with 3.7.8 still.
If I home I can move with the buttons and use manual gcode just fine. Gcode is 90 mode, buttons are g91. Everything works as expected. Buttons move that direction by that much. Manual Gcodes go to whatever coordinates you plug in (form the home point).
If I do not home first movements are randoms as you pointed out.
Am I still missing something?
Looks like I am getting a different result than you are. Did you use G0 or G1? I have not tried G0 yet.
So when you home first, use the buttons to move X100. Then type in G1 X10 F2000. What happens.
Mine moves back to X10.
Maybe reflash your board. It is very easy and only takes a minute. Instructions on the jackpot page.
I think I figured this out. From the FluidNC wiki:
$GCode/Modes or $G
- Shows the state of all of the modal gcodes.
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
If I look at my console, I have this:
If I look at my coordinates, I have this:
So, it is using G54 work coordinates that are set to -141.5, -110. A G91 jog moves 100 as expected. A G1 X10 command moves to 151.5.
I don’t understand work coordinates very well. Where is the G54 command coming from? How do I get the system to use the machine coordinates on startup?
What happens when you home first. GRBL is built on homing first, is is actually not made to move at all until it is homed, I disabled that step. I might need to enable it.
If you reflash using the erase option and reload it should function correctly just like mine does. I think somehow you changed a setting and saved it. If you read a bit more in that wiki it tells you how to change and save that but really a wipe and rest is just as fast.
So what about moving x or y negative, is that disabled as well? If I want to move zero to -10 after I zeroed it, I had to reboot. But i was getting frustrated the other night with my speeds and feeds and just shut down. I was trying to move x and y to basically -10 and it would only move to the homed 0. nothing past it.
Nope, don’t think so. I am sure I have cut negative X and Y when I set my CAM to zero at teh corner and when it cuts out it goes negative on both.
What does Zeroed mean, G92? If you home you can not move to -10 because it will hit the end stops. If you G92 more than 10 mm away it should be fine.
1 Like
All of my tests were homed first.
Okay, I highly recommend doing the firmware and configs again using the erase feature. Something had to have been changed.
I showed you my exact steps above, every board should function identically. If yours does not then it should be reset.
I am still using 3.7.8 with the latest configs.
1 Like