September 2, 2019 at 5:46 pm #111784
So I’ve run into my first issue with my MPCNC (dual end stops, Rambo, Marlin, all stock from V1).
I’ve run the crown test, with a pen and a bit – no issues. I did a full 3D carving (~8hrs milling, attached) with no issues either… until I went to cut the frame. Specifically, on the corners of the frame the steppers went crazy, trying to pull the bit in opposite directions – or at least that’s what it looked like because both X and Y axis were off after the bit passed the corner. Luckily the arc was small and I was able to shut it off quickly. As such, I ended up cutting the frame out separately, as seen in the photo attached.
I inspected gcodes I had successfully run, including the Test Crown 12mm/s and the 3D carving base file and both only had G0 and G1 movements, i.e., all linear and no arcs. However, the frame file had G2 movements at the corners (e.g., G2 X187.065 Y-2.455 Z-1.500 I-1.585 J0.000 K0.000 F480.000).
The issue seems to be with the G2 command. I can only assume and speculate this may be related to how Marlin translates the G2 movement to the steppers that leads them to behave erratically.
Has anyone else experienced this or can anyone confirm successful G2 command on a dual end stop MPCNC?
- This topic was modified 2 weeks, 6 days ago by Victor D..
Attachments:September 2, 2019 at 6:13 pm #111787
What software/post processor were you using? and can you post the full gcode?September 2, 2019 at 7:29 pm #111792September 2, 2019 at 9:07 pm #111799
By the way, the gcode was generated on Ubuntu. Notepad (Windows) does not open it right, but the MPCNC sees it with no issues as evidenced by the carving.September 3, 2019 at 5:18 am #111834
Sorry, I don’t have an answer for you, but now I have a question. I thought the Rambo boards used GRBL, but your post indicates you use Marlin. Furthermore, you used a GRBL post processor to generate the gcode. That leads me to the perplexing conclusion that you are running GRBL code on a Marlin board. Is that correct?September 3, 2019 at 5:50 am #111840
The Rambo board from V1 comes with Marlin. I was debating switching to GRBL but decided against it (for now) because all the previous tests I ran worked fine and I like having the display + SD card.
Others can explain better, but short answer is, Yes. As I understand, Marlin and GRBL gcodes are practically the same, with differences on plane (e.g., xy, xz, yz) selection/definition.September 3, 2019 at 8:17 am #111850
I am pretty sure I messed up the junction deviation setting in the newest Marlin. Try doubling that number and re-flashing. If that works I will update the firmware.September 3, 2019 at 8:23 am #111853
I am pretty sure I messed up the junction deviation setting in the newest Marlin. Try doubling that number and re-flashing. If that works I will update the firmware.
Just to confirm, do you mean in Configuration.h, change from 0.005 to 0.01?
// Use Junction Deviation instead of traditional Jerk Limiting
#define JUNCTION_DEVIATION_MM 0.005 // (mm) Distance from real junction edge
#endifSeptember 3, 2019 at 8:25 am #111855September 3, 2019 at 8:32 am #111856
Won’t be until later today but I will report back once I have a chance.September 3, 2019 at 3:23 pm #111916
Alright, updated the junction deviation to 0.01 to no avail other than it seemed to make the turn quicker – may just have been my impression.
However, I did make a cut with it to demonstrate the issue. As shown on the attached photos, the corners are far from correct and on the bottom left corner, the axis actually distorted the perpendicularity of the cut.
I understand that avoiding G2/G3 is an option but not really a solution… I’m open to any suggestions that could help with this!
Attachments:September 3, 2019 at 6:48 pm #111934
For another point of reference, I opened the gcode in bCNC and an online gcode viewer, both show the same path correctly.
Attachments:September 3, 2019 at 9:39 pm #111945
I can’t explain the dual steppers going opposite each other, but I have seen reports of strange behavior when the soft limits are triggered with G2/G3, and it looks to me very similar to your strange cuts. See here: https://www.v1engineering.com/forum/topic/strange-movement/
Linear movements are clipped to prevent going non-negative, and I think arcs are supposed to be clipped but the implementation is incorrect, causing bizarre movement. I notice in your gcode file you have negative coordinates.
Negative coordinates are fine if you jog the machine to the workpiece and do G92 X0 Y0. The machine will know that it can go negative relative to the G92 work offset without hitting the soft limits, so it is fine. But if you attempt negative movements in absolute space it will not move as programmed. This can happen even if the machine can physically move negative, e.g. if you power cycle the machine while it is at the workpiece, it won’t know that it’s not at the edge of the workspace and it will still clip.
Maybe, and this is speculation, the incorrect implementation of soft limits for G2/G3 also has a bug causing the two motors to move separately.
If you think this is plausible, a simple test is to place the workpiece at a healthy offset and jog to the workpiece and do G92 X0 Y0.September 4, 2019 at 2:46 am #111956
Ok, so I went digging in the code and found what I think is a bug regarding G2/G3 and soft limits. I’ve submitted a patch. Here is the pull request: https://github.com/MarlinFirmware/Marlin/pull/15156
Here is a video showing the problem. (Assuming this is the same problem you’re facing but not sure.)
Even with the bugfix, hitting the soft limits is still bad. Your cuts will deviate from what the CAM is trying to do. But with the bugfix, at least your tool won’t suddenly lurch into negative coordinates.September 4, 2019 at 4:55 am #111967
I just did a quick test and this seems to have solved it!
I homed the machine, jogged (not moved by disabling the stepper motors) the bit to within the work piece, reset coordinates using the custom commands menu on the LCD, and started the gcode.
The solution makes sense to my original workflow because the frame component was an afterthought (thus the negative components). Therefore, I turned off the machine once the engraving was done, and turned back on at the workpiece zero and simply started the frame code.
My subsequent test, I did not bother to home because… well, it was a test and I didn’t know better.
As for the motors moving in opposite directions, that may have just been my impression because of the slanted cut, and me trying to figure out possible issues. It did not happen again.
September 4, 2019 at 9:55 am #111996
- This reply was modified 2 weeks, 5 days ago by Victor D..
Dang you are my hero. Solved a problem and squashed a bug!
1 user thanked author for this post.September 5, 2019 at 8:20 am #112148
Thanks for the marlin edit last night! Awesome, I really think collectively MPCNC users have made a pretty solid impact on Marlin firmware. I am sure they can get tired of all of use trying to bend 3D printing firmware to fit our needs but they really seem to be more perceptive and open now. Thanks again for being in the Crew.September 5, 2019 at 8:48 am #112152
I am doing the initial tests on the firmware update. We are something like 800-900 commits behind. I will flash and run all my printers this morning and hopefully tonight test some CNC’s. I tweaked the junction deviation and arc length, I think that was the only issue. If you can think of anything else let me know.
Sorry I know it isn’t the right thread but it kinda fits.September 5, 2019 at 2:42 pm #112195
The joystick code still hasn’t been accepted into mainline Marlin. I’m not sure why. It is finished as far as I’m concerned. I’ll give it a nudge and see if they will accept it into the main branch.September 5, 2019 at 2:59 pm #112201
Yeah I am not sure how the things get noticed, but I have seen extremely tiny changes not get pulled for a very long time.September 6, 2019 at 10:22 pm #112347
Just an update, and to call this solved.
Prepared the attached using Blender and FreeCad (GRBL post-processor and lots of G2/G3 commands) and ran with the proper workflow (i.e., home then jog to position) and it worked like a charm!
On a separate note, I have to say that I’m very happy with Marlin on the CNC – having the LCD and SD is a major plus for me!
Thanks again Jamie and Ryan for helping resolve this.
- This reply was modified 2 weeks, 2 days ago by Victor D..
Attachments:September 6, 2019 at 10:25 pm #112350
Yeah I am not sure how the things get noticed, but I have seen extremely tiny changes not get pulled for a very long time.
Does the firmware here on the V1 Eng. site have all the updates to date or do you typically wait for the commits to be applied before you upload here?September 7, 2019 at 4:53 pm #112457
Kind of a tricky question. The official release is still Marlin 1.9, we have been on 2.0 for a long time. I try to update periodically but it moves fast. As for features I do not like to add them to the firmware unless they are in Marlin or we need them specifically (dual pin swaps, laser delay).
You must be logged in to reply to this topic.