@Debreuil Oops…@kalel76 it’s hard to tell from your previous post which gcode file worked and which didn’t.
The parts of gcode you have highlighted as different exist in all the files I see. As @Julien stated, the F250 should work for all subsequent G1 motion commands. When the F250 is on a line with a G1 motion command, it will apply to that line and all subsequent G1 motion commands. I don’t know why CC outputs both ways.
If Motion is doing something weird, it’d be nice to have two files, one that worked and one that didn’t.
6 Likes
@Julien,
The short video clip was the “test too patha again again.nc” file.
I’m going to try a few things from a different pc now.
1 Like
I downloaded Carbide Create and Carbide Motion to my laptop. I created and tried new gcode and my old gcode. This was the result each time:
I then connected the Nomad back to my original PC and received more of this:
I have run many of the exact or very similar jobs over the last month with no issues. No changes have been made to my workflow or setups, nor software or hardware. Everything has remained the same since I first set everything up. It just stopped working properly out of nowhere.
I had a suspicion, but I wanted to test, so I just did.
I’m pretty sure this is a bug in Carbide Motion. I’m not sure why, but Motion seems to “preprocess” the commands sent to the controller. In doing this, there is an issue when the F-word (not often I get to type that) is on its own line.
Example (the two snippets below should function the same)
G1 Z5 F10
Y20 F250
AND
G1 Z5 F10
F250
Y20
Grbl will interpret those the same, as it should. When using Carbide Motion, the first snippet will work as expected with a Feedrate of 10 for the Z move and a feedrate of 250 for the Y move. The problem is that Motion ignores the F250 in the second snippet. That would result in a Feedrate of 10 for the Z and a feedrate of 10 for the Y.
I’ll attach my test files below. Run at your own risk as they are hand coded and I knew where I was starting and what I was expecting.
@kalel76 Can you try another sender?
I wonder if this is new output from CC or if it just goes mostly overlooked because most people don’t use plungerates of 6mm/min.
CM_F_test1.nc (234 Bytes)
CM_F_test2.nc (229 Bytes)
test_1 is the one that will not work correctly in Motion. I commented the gcode (quickly, it’s late), but both files will basically rapid move to Y10Z20, lift the Z really slow (10/mm/min), then move to Y0 at what’s supposed to be 250mm/min. test_1 will make the Y move at 10mm/min.
I tested with a couple other senders, and just sending the commands through PuTTY…all worked as expected except for Motion.
I think Create should be consistent in its output and this should definitely be addressed in Motion.
(Anyone feel like confirming my results?)
9 Likes
@neilferreri,
Thanks for your research on this. I thought that I was on to something when I saw the F-word (haha) being placed on its own line, and noting that was the type of gcode that was failing, but I couldn’t describe it as eloquently as you did. Thank you for that. I’ll do some further testing tomorrow with the files you attached. Thanks again!
3 Likes
Unfortunately, the only current option is to use another sender or generate the gcode in a different CAM program, like Fusion 360.
This was unusual because your code SHOULD work. Like I said, I wonder if others have the same problem (likely) and just don’t notice it because they’re not running feedrates that low.
2 Likes
Interesting. And now that I think of it when I tested the Lines.nc included in the first post, I defaulted to using CNCjs, which explains why I did not see the problem.
@neilferreri I’ll test your files and confirm the CM bug later today (unless someone else beats me to it, that would be appreciated)
3 Likes
Which post-processor are you using?
2 Likes
I have had the same issue. I reported it the other day and submitted some files for examination. I was told the g-code should work just fine. I wonder if I still need to send them a video of the issue.
Edit: and FYI, it was occurring on both a pocketing and advanced vcarve tool path. Had a feeling it was a CM snafu as I could run the same exact file and get “slow” spots in completely different areas from the last time I ran it. My file was a mix of lone F’ers and some attached to the end of a x/y line and it seemed to “hiccup” at random on the lone F lines.
4 Likes
It should. Although it’s weird that Create would output feedrate changes in different ways, the resulting gcode should work, and does… Just not with Motion.
2 Likes
In your opinion, which sender would be the easiest to set up to match my current workflow with the bitzero, setter, and runner accessories?
2 Likes
Thanks everyone for your work on this. I feel much better now. I thought I was going crazy. I won’t be able to mess with it until tonight or maybe even tomorrow but I’m glad it’s not just me! Hoping for a fix so I can keep my same workflow for now. Fusion is still a little complex for me at the moment.
@Microwave_Monkey, nice avatar.
2 Likes
I’ll test tonight but I think until this is fixed, a possible workaround could be to edit the file to merge those lonely F250.0 lines back into other lines. It would be tedious at best to do it manually, but I think it could boil down to to doing a “search and replace” of “F250.0\n” by “F250.0”. We’ll see.
2 Likes
A text editor which supports regular expressions would make short work of this — hoping to look into this presently.
3 Likes
Ok, so I just tested on my machine
@neilferreri: using your test files I confirm the CM bug (test1 is OK when run with CNCjs, and fails with CM)
@kalel76: using the original “Lines.nc” you posted, I replicated the bug when using CM, and then I applied the workaround described below and it worked fine after that.
First I tried the “let’s merge the F250.0 on the next line” and it does not work (the search & replace must break something else, I did not bother investigating)
BUT, if one does a “search and replace”, replacing every occurrence of “F250.0” by “F250.0G1”, then the file works fine with CM (the idea is that the added G1 is harmless, since this is the modal state the machine was in anyway, and if it needs to change there will already be specific g-code lines. This must make the CM parsing do things slightly differently, and not ignore the F command then).
The original Lines.nc modified this way works fine=> that’s the workaround for now.
I’ll report the bug and hopefully we can get this fixed in the next CM version (maybe if @robgrz is around he can comment on the likely cause for this behavior)
5 Likes
The easiest, to maintain your current workflow, would be to just use the Find & Replace solution that @Julien described.
If you’re looking to try something new, CNCjs will work with your setup.
3 Likes
@Microwave_Monkey, @neilferreri,
I haven’t had time to test but I will be using the Find and Replace solution. I had to do that same thing with another issue with Carbide Motion a few weeks ago and it worked fine. Just a little extra step. Hopefully it gets resolved soon. Thanks again everyone for looking into this!
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.