I just want to say thank you to Doug for posting this info, even though it’s early. I’ve ordered my M5Dial but it won’t arrive for a bit.
I totally get the concern that it’s alpha/beta state and that requests at this point will only distract and potentially impact scope.
I do think it’s interesting to hang out and skulk in the dev discord.
Thanks again Doug.
I definitely don’t intend to discourage anyone or cause them to be afraid to try it. Just want to make sure expectations are reasonable for anyone that does.
I don’t think there’s a big risk. They are working on it and see no reason why it won’t be a success. It will just require a bit of patience.
I upgraded the FluidNC firmware to 3.7.12 using terminal, and doing erase first, and then re-uploading my config.yaml file afterward, and almost everything I mentioned before, was fixed. Regarding these things that I mentioned previously:
Homing - “works but the little radio buttons don’t light up when end stop switches are pressed.” - FIXED - the little green radio buttons now light up.
Jogging - “I applied bug fix code, yet I’m still getting the backwards stutter when doing continuous jogging with the dial.” - FIXED - ‘mostly’ - I seem to be getting no stutter like before, except once or twice I got a stutter when barely nudging the dial, and I think it was a hardware sensitivity issue in the dial (like I was “between notches” or something).
Jogging - “works but the DRO of the location does not update on the touch screen.” - FIXED - The DRO values update beautifully.
This last issue (below) is the only one I am still seeing.
Jogging - “is not supposed to allow going too far, such as past a detected end stop, yet this happens.” I still can get it to go past an endstop. I asked this of Bart via the Discord server:
Is this feature of not going past a stop, supposed to work with both dial nudges and button press nudges? I think I was using button movements when it happened.
I thought you had to enable soft stops to prevent the machine from going past a stop. Use of G92 makes the machine forget where thr stops are, so it no longer has any way of knowing where it is relative to minimum or maximum travel.
Use of workspace coordinate systems G54 etc allows you to set a bed size and enable soft stops, which will prevent travel outside of the machine limits. – At least, that is what I have set up in RepRap Firmware, and have planned for FluidNC when I get my new laser working. I want to get the A40640 running on FluidNC. I just have to build the kinematics.
OK, so I located two different kinds of settings options in config.yaml — “soft_limits” and “hard_limits” — and they were all set to “false.” Are these the right thing? I’m editing them to “true” — will try and report back.
BEFORE:
soft_limits: false
AFTER:
soft_limits: true
BEFORE:
hard_limits: false
AFTER:
hard_limits: true
Those were the right settings! I just now tried both hard limits (end stop, if I understand correctly) and soft limits (the far side of the table based on the table size values I entered into the config.yaml file, if I understand correctly), and both work GREAT. I cannot force the machine to move out of bounds once it’s homed, either accidentally or even intentionally!
Screen shots from after editing in config.yaml to set soft and hard limits — and I had already set my CNC table’s size. That’s very important for the soft limit stops to work right.
If you use soft limits (the table size you set in the yaml) if you use G92 and move negative you will get issues. You now have to be very careful with your CAM. Most cam sets your material corner as zero and works in the negative space on both axes for cutting things out.
As Dan pointed out if you are going to use soft limits you should start using workspaces G54+ instead of G92.
Hard limits says there are switches wherever previously defined, you can leave this it prevents you from driving through your end stops. (I have them off as occasionally I use that extra 3-4mm after a trigger)
Thanks for the explanations!!! I will study the gcode numbers you gave and try to gain understanding!!!
I confess I don’t know what G92 is, and I had no plans to use it. I’m reading the description, but it’s somewhat cryptic and I don’t fully comprehend it. Does the fact that I’ve enabled soft limits mean I’ve somehow invoked G92?
I’m reading here: Supported Gcodes | Wiki.js
Quote:
G92 Coordinate System Offset
G92 axesG92 makes the current point have the desired location specified. It creates an addtional offset from the current G54-G59 to achieve this. The value of the offset can be read with the
$#command. The offset is volitile and will be lost at reboot.This should only be used by advanced users. Many newbies use it as a simple way to set a work 0. The desired affect is lost if system restarts, you change to a different G54-G59 system or the current G54-G59 offset is changed. Most people should use G10. Most gcode senders will use G10.
Most people who properly use G92 are also using G10, so if you are using G92 without G10, you are probably a newbie.
Dan, are you saying that by switching on soft limits I’m invoking G92 somehow? I’m not aware of invoking G92 and have no plans to. I’m confused because I want to use soft limits, and have no plans to use G92, yet mulitple people are warning me against using G92, and it “feels” like I’m being warned against using soft limits?
It is common for people to use G92 at the start of their GCode to set whatever the current position of the tool is to (0,0)
For instance, this is the starting GCode from the docs Ryan has for EstlCAM:
G21
G90
G94
G92 X0 Y0
M0 (MSG Attach probe)
G38.2 Z-80 F200 P0.5 (probe down set thickness )
G1 Z10 F900
M0 (MSG Remove probe)
M62 P1 (If used start spindle pin27 )
(Was going to continue, but I see Ryan is coming to explain it better )
You probably use it every job you run. I have it included as the default starting gcode.
I highly suggest you do not alter my yaml and just do not drive your machine out of bounds. How often do you really move your machine to its limits?
OK. Here is my ESTLcam start code:
;Project
;Created by Estlcam version build
;Machining time about hoursG90
;M03 S // Spindle Stop
OK, thanks. It turns out I do not use G92 in my start code, and I’m currently thinking I never have.
This is part of the reason I do not think pendants are that useful. If you commonly need to move your machine far, use workspaces. If you use workspaces and pendant is not all that useful. It saves a couple seconds.
This is useful as a interface for Fluid and we can turn off all web stuff, but now that it is available, is the M5 knob the best interface? We will see. An oled and a couple buttons is far cheaper and might be easier to code.
I am on the fence about this since it is so early in the lifecycle.
I totally follow you on this.
Then you will not need a pendant. That means all of your code starts from home and you will not drive your gantry anywhere.
I think it would be much better to use the work they did for the dial and develop a little replacement TFT display that does the same thing. Could be really nice on a 5-7" screen and much less limiting than the tiny dial
I occasionally drive my gantry around for various reasons, like to get it out of the way of the drill I’m using, or vacuum I’m using, etc, and I routinely will move the gantry to a desired starting point for a job, and historically, I would then press to zero my X and Y to that location. A pendant is not needed, but could be used, is my thinking, and if the pendant gains ability to do search of gcode files on SD card and start jobs, then the device could be used to home, position, zero, start jobs, etc. I realize another devices besides a pendant could be used, and other screens besides the dial could be used.
Somehow this is not what I do, and yet I also do not have G92 in my start code. I usually use either a gcode snippet (or macro) to drive to a set point away from home, and set XY to zero at that location, before starting my jobs.
