Strange issues after 3 month downtime (Video)

Mostly Printed CNC - MPCNC Troubleshooting
#1

I haven’t used my MPCNC in about three months. Today I tried to fire it up to cut a simple radius onto the end of a board. I’m using Fusion 360 with the MPCNC Mill Laser post processor. (Rambo board) I saw the thread that some changes in the free version of Fusion have led to Z issues and low feed speeds, but when I try to run a simple program that is supposed to cut a radius, I get all sorts of strange lead in moves that are not in my program before export.

If I change up the programming just slightly in fusion I get other crazy results like it will feed over to halfway into the radius and start from there, but then completely ignore the curve and make straight lines, or even once acting like i had programmed an adaptive clearing operation rather than a contour. Totally wacky output vs what I had in Fusion.

Do you think this is due to the update, or seems like something else? As far as I can see, I should only be having Z and feed issues from the Fusion update right?

#2

This doesn’t sound like the Fusion 360 issue, but you can eliminate it completely by sending the following g-code to your machine:

M203 Z8   ; Limit feedrate to 8mm/s (480mm/min)
M500      ; Save the changes to EEPROM

This is a persistent change, so you only need to send it once.

Next, just to be sure, paste your g-code into a g-code simulator to make sure the g-code is okay. I’ve used this one a few times to track down problems, but only because it was the first Google hit.

If neither of these two changes solves your problem, providing a video link showing the behavior might allow someone here to identify the problem. The only thing I’ve even remotely experience that is similar to what you describe is when I once homed the machine, release the steppers, and then attempted to cut. It would not cut anything with a negative value in the g-code.

#3

Thanks for the reply Robert. I’ve sent the suggested codes to the machine and the issue remains. As suggested I’ve made a video of it in action. As you can see, the simulated code looks good, but the toolpath ends up having all sorts of strange lead in moves when run.

Also of note, I know if got my origin on the top right causing the machine to have to move negative, but I dont think that’s the problem since I tried moving it to the bottom left and still had the issue.

Thanks for any ideas.
Ben

#4

A puzzler. I’m wondering if there is a communication problem between the computer and control board…bad connection, noise on the line, etc. If you have a display on your control board, run your g-code from an SD card. Swap your USB cable for a new one and make sure it is not next to other potentially noisy wires.

#5

Ill check out the board and connections. That does seem like the next step. Although I’m not sure why the same crazy lead in moves would be added each time if it was noise. What ever changes I make, the same exact path errors happen each time I run the code.

Thanks for your time man.

#6

3 questions:

  1. Could it be related to arc changes in Marlin? (Not using Marlin myself so can’t be sure)
  2. Could it be “ramping down” to start the cut? I’d think that would show up in the path displays, but again, since I’m not using Marlin in this context I don’t know.
  3. Do you have another way to send gcode to the lowrider? That would let you isolate whether it is in the code or something Repetier is inserting as it sends the code. Are there any macros or scripts stored in the Repetier settings windows?
#7

This occurred to me too when I suggested it. My only thought was that the arc might be a single g-code command, but the lead-in might be many commands that have a higher likelihood of being corrupted. It is a long shot.

Tom suggested it might be the arc command in Marlin. Since you’ve not change the firmware, this is doubtful, but you could eliminate it by turning off arc generation so the g-code is all line segments.

If you want to attach your g-code file, I’d be glad to run it on my Primo as another data point.

#8

Posting the gcode might help. Maybe there is something funny in there. It looks like it is in control the whole time. Which is why I am suspecting something funky in the gcode.

Are you using the guffy post processor?

#9

Yup. Guffy post processor. Here’s a link to the code.

#10

So I ran your g-code file on my MPCNC. It ran exactly as simulated in the g-code simulator…no extra loops or movements. I noticed, at least in the example video, the problems occurred at places in the g-code file where G2 commands are executed. As mentioned before, you might do a test run with arc commands turned off. In the guffy post processer there is a “Job: Use Arcs” that can be turned off. If turning arcs off solves the problem, I suggest upgrading to the lastest firmware. If for some reason you are already running the latest firmware, I’d back up one version. Some changes were made between the two versions that impacts arcs.

FYI: while there is no problem with a dropbox link, the forum does support directly attaching g-code and a few other file types. In addition it supports .zip files, so any file can be attached if it is inside a .zip.

#11

Hi Robert,

Thanks for checking out the code on your machine. So I’ve made another video in which you can see the following points:

  1. I actually had not been running the Guffy post. It was an older MPCNC_Mill_Laser one.

  2. I updated to Guffy post and even though I had “manual spindle” on, I found I needed to go into the code and comment out the M0 line to get it to run.

  3. I get wildly different behavior on the same path when I move the origin to the top right or bottom left of the cut. Also turning on or off Arcs changes behavior.

  4. It wasn’t in the video, but I seem to be able to run other cuts ok. I did try making a completely new file for this cut and the results were the same errors.

  5. I’m trying to update to latest Marlin firmware. I’m unsure which version to use, although I think it’s just “Rambo Dual” which I just found on a different page than the one I was looking at before, which seemed to have two different dual endstop rambo versions. Anyway, I am unable to load the firmware and get the error seen in the video. I suspect this may be because I’m using the old version of the Arduino software?

So thanks for looking at all this. The video ended up being 5 minutes long… Sorry… thanks again man.

#12

“manual spindle” on

Manual spindle on is what generates the M0. It is pausing so that you can manually turn on the router.

Firmware is released here. Assuming you are running dual end stops (each stepper gets is own driver), then V1CNC_Rambo_Dual-2.0.7.2-src.zip is the version you need. The “LR” dual version is for the LowRider and is not the version you want. The Arduino error you are getting is a know issue with older versions of V1 firmware. Jeffeb3 has fixed the problem on the versions at the release point I pointed you to. In addition, because of this issue, it is suggested to migrate to Microsoft Code and Platform.IO for compiling the firmware. More information here.

The arcs off vs. the arcs on behavior is really strange. I suggest you update the firmware next. You can either confirm or eliminate it as the source of the problem. The fact that the problems survived when you went to a new post processor eliminated a lot of the possible sources of the issue.

1 Like
#13

What a valuable post. Thanks so much man. Getting me all caught up on everything I missed out on by not pouring over the forums lately. Ill make the changes suggested here and let you know how it goes. Thanks again!

#14

It worked!!! I updated to the latest firmware via Visual Studio and all the crazy lead in lead out moves have vanished. So good to see a good toolpath. Thanks so much Robert. I owe you a beer for sure. This has inspired me to get the rest of my machine into shape. Thanks again man.

PS: Is there any settings I need to modify for my specific MPCNC build in this version of Marlin? I poked around a little but didn’t see settings for bed size like in the old version.

#15

I’m glad it is working for you. This was a strange problem. As for bed size, you need to change these two values in configuration.h (not configuration_adv.h):

// The size of the print bed
#define X_BED_SIZE 300
#define Y_BED_SIZE 300

Note that this is only thing I had to modify in my version of Marlin. If you don’t, then your router needs to be within 300mm of the origin for homing to work, but there is no other impact unless you want to enable soft stops for some reason…