I’ve been digging around in the codes that are output from HSMxpress and trying to figure out why Carbide Motion doesn’t like them, and specifically it seems to be grumpy about the lack of a J value when there’s an I value and vice-versa. I’m presuming that HSMxpress is dropping the associated value when it’s 0 and just not listing it, and Carbide Motion doesn’t like that implicit pass on the value, and really wants that value declared in there.
Would this be something I could fix with a Carbide Motion specific post in HSMxpress, or could this be resolved through the handling in Carbide Motion?
UPDATE: I’ve put a more comprehensive post together here about what I’m finding regarding the G-codes posted from MeshCAM vs. other packages such as HSMxpress, using the Mach3 and GRBL outputs for comparison purposes.
Carbide Motion doesn’t like it when arc motions (G2/G3) omit either the I or J value, which seems to happen when it’s either leaving the value the same as the preceding line, or it’s value is zero. I’m not sure which of those is the case, but obviously that could matter a great deal in actual behavior. In running the file through CutViewer, it doesn’t seem to care about these omitted arc details.
In fact, it would appear that MeshCAM doesn’t calculate or use any arc motions at all in it’s G-Code. This would explain the grumpiness in Carbide when dealing with G2/G3 motions, and why it complains about I/J values being missing. It also futher explains the G18/G19 errors as arc lead-ins are a no-no as well then. This effectively brings my work coming from HSMxpress to a halt, as I can’t figure out how to get it to convert all arc motions into linear ones.
Carbide Motion doesn’t like G28, even though GRBL will take it through the MDI just fine, and home happily. This however causes Carbide Motion to freak out because it’s not expecting limit switch contact, so the whole thing resets afterwards anyway.
Carbide Motion doesn’t handle tool offsets from other CAM packages, and doesn’t pass the tool definitions coming in with the files, such as G41/G42/G43/G44 Hx radius or offset declarations, to GRBL. I presume this can be in part explained through the format of tool declarations from Mach3 and Generic Grbl output, which doesn’t match the tool definitions from MeshCAM output.
Generic Grbl tool output from HSMxpress:
(T7 D=1.587 CR=0 - ZMIN=-6 - flat end mill)
Generic Mach3 tool output from HSMxpress:
(T7 D=0.0625 CR=0. - ZMIN=-0.2362 - FLAT END MILL) (I would note that this one was exported with G20/Inch settings, which would be OK for GRBL direct, but Carbide doesn’t handle entirely well on the tool change it seemed)
The format from MeshCAM:
(TOOL/MILL, 1.5885, 0,6.3500,0.0)
The Log ALWAYS reports distance units in MM instead of matching the G20/G21 setting, which is certainly helpful to know.
However, the “Cutter Position” as listed in the UI doesn’t match the log position, and I presumed it’s in a work-offset WCS by default. It’d be helpful for users to see both a “machine” position and a “work-offset” position at all times, or to be able to toggle the display between the two.
Also, setting a Work Coordinate Zero in the UI doesn’t seem to actually send messages to the GRBL controller, it only updates what’s going on in Carbide Motion. It doesn’t appear that anything gets set to the work coordinate systems in the GRBL controller for G54,G55,G56,G57, and then G58 and G59 have values listed, but trying to go to G58 zero positions leads to a limit-switch collision, and G59 leads to the tool change position, EXCEPT Z PLUNGES TO FULL DEPTH. This is dangerous as some post outputs might accidentally assign to WCS #6 (G59) and if Carbide uses it’s own mapping for that instead of a user’s set origin it’ll be exciting for everyone involved.
If one toggles to G20 and then tries to move/jog with the UI, and one hasn’t homed & done tool length checking yet, the machine can/will crash at end-of-travel as it tries to move to X-120 after homing, so that it can do a tool length probe (G38.2) but I’m glad that I figured that issue out on the move and not the probe. That would have been much worse.
Many CAM outputs include a G91 relative move to Z0 at the start, which Carbide doesn’t like. This should probably be ignored silently, or have an alternative z-axis home command issued instead.
G91.1 arc-movement definitions get silently ignored at file start, but Carbide Motion then halts and throws an error when it gets to G2/G3 arc moves where there isn’t an explicit feed rate listed for the operation. It seems that arc-travel is supported in GRBL, but not Carbide Motion (and not MeshCAM as I discovered earlier) so therefore Carbide doesn’t know how to properly pass the arc movement, since everything is done in G90 (absolute) offsets rather than relative offsets. Since the offset adjustments and tool length seem to be “on-the-fly” adjusted in Carbide, and not tool declaration settings in G-code, that’s problematic for code posted with tool offset declaration and usage (G41/G42, G43/G44 and G49) that Carbide doesn’t use, leading to surprises for users.
I think that’s it for my observations at the moment. Hopefully some of that feedback can filter into feature adjustments.
Right now, CM assumes I and J will be present on each G2/G3 line. I can change that.
MeshCAM will do it if you enable Arc Fitting but it really depends on your model or settings as to wether it’ll do anything.
We don’t set G28 from the factory so it’s at 0,0,0, which happens to be the contact point of the limit switches. I’ll add proper G28 support
An M6 automatically triggers a tool probe so G43 etc. is not relevant to CM and is ignored in V3
GRBL is always in metric and in absolute machine coordinates.
Offsets are handled in CM in V2. We had a big debate about showing machine coordinates and I lost, so they were removed. I’ll think of a way to put them back in a way that will not confuse noobs.
G54-59 are never sent to the machine. Right now, we only use 54 in CM . G58 and 59 in GRBL are used to keep calibration data for your machine.
If you change it to G20 in the MDI then bad things will happen. At various times, CM will rest GRBL back to a known state but it doesn’t assume that average people will type things into the MDI window.
What is the specific line/code that didn’t work?
If I remember correctly, G91.1 is the default mode of GRBL so I ignore that G91.1 since it wouldn’t have any effect.
To restate: don’t use the MDI unless we direct you to do something (or you know exactly what you’re doing). It bypasses all of the CM logic.
I’ll get G2/3 working as soon at the faulty Z offset in V2 is fixed.
Thanks for the follow-up on these Rob—and you’re quick!
Based on your feedback:
Yes please, if it can operate without whichever one goes missing sometimes, that would help tremendously, as I don’t know how to get arc-less output yet from HSMxpress.
I’ve tried a few different runs and examined a number of files produced, and none of them call G2/G3 so far… on trying again it would seem that when I checked arc-fitting and then made other changes it got un-checked somehow, so I just re-ran a tool-path generation with that being the only change made to the machining strategy, and it’s still not creating G2/G3 paths, only G0/G1 paths.
Excellent thanks!
It looks like HSMxpress Mach3 post puts G43 offsets after each tool-change, which therefore makes sense to ignore if the tool-length from the probing is going to apply instead of the tool length offset specified from the original posted file. Ultimately, if the software dealt with the tooling offset prior to Post, and then the offset differences are getting applied from the tool change on top of the changes already made in the CAM for the different lengths, it won’t fix the tool-path, only offset it further. Therefore the tool length/ZMIN or other CAM-originating tool-length data is important to counteract, right?
Good to know, just have to make sure there aren’t other G91 moves that come in the posts.
Well, maybe it can be another hidden hot-key to get to. Just being able to address the machine to a location via MDI and have it match the program position displayed would be sufficient really.
I know it’s asking a lot, but it comes to mind that you could have some kind of virtual representation of the machine as part of the GUI, which has the coordinate system super-imposed on it so people can stay oriented correctly since home is at the positive limits, and everything is negative from there…
This is probably great from a noob-proofing standpoint, but may make it more difficult to work with code from other CAM systems that are looking for a G54/G55/etc… to send to if you have multiple fixtures saved in the work area, unless Carbide handles this intelligently/auto-magically too. I’d like to mount a regular vise to the front-half of the work area and a small 4th axis indexer to the back, for example. Being able to teach it G54 for the vise near-corner and G55 for the top-center of the 4-axis stationary side of the clamp area would be handy and make setup for each piece more straight-forward, without having to re-teach it every time I want to go between the two. I realize that’s probably a “V4” functionality request
I figured as much—what I was testing was to see if the files I brought in from HSMxpress (which were exported as G20) were converting themselves to G21 or not through Carbide Motion, and if perhaps that was why it freaked out on the one tool change and tried to drive into the spoil-board. I didn’t come to conclusion yet where it was being odd, but moral of the story is to export G21, just in case.
The specific line is: “G91Z0” in some posts (GenericGrbl) and it doesn’t like G53, which I think has been mentioned elsewhere also.
Good to know this is the default, never mind then, I thought it was a problem, glad it’s not
Roger Wilco on care with the MDI, I’ve done a fair bit of CNC and I’m pretty quick with the draw on the E-stop.
Good news: The new V2 beta fixed the Z-offset issue.
Regarding the G2/3 codes, I tried to run a Mach3 style multi-tool output that I’d removed the G53 from, and it took all of the linear stuff in the first tool handily, and did the tool change correctly. Then when it got to the second tool, it started into the work just fine until it saw the first G2, and stopped there because it interpreted the lack of an F parameter as F=0, and just stopped in place, rather than keeping with the F value from the preceding G1… at least that’s my uneducated read on it…
The error Carbide shows is “GRBL Error: Invalid gcode ID:35” which it shows and then stops motion, but the spindle stays running and the project pauses.
HSMxpress and Mach3 apparently take the approach that “this is the variable until we say otherwise” when it comes to some of the variables, while from MeshCam it looks like on every switch from G0 to G1 it wants the feed-rate stated, and I see some places where it lists the feed rate before movements, like this:
Is that observation accurate, that it needs to declare F for each G1/G2/G3 block-start regardless?
I may be able to get the Post to put that in, but if Carbide is going to do more with G2/G3 in the future that should probably be part of the overall game-plan anyway, right?
