Ok, that’s one step in eliminating a step.
This is what we’re not sure of. Somehow, what you did resulted in something that is different from what Jamie did.
We’re trying to help you. Honestly we are. Please try to help us. Wed aren’t trying to accuse you of doing things wrong, we’re trying to figure out where it goes wrong. When you toss ALL of the steps and ALL of the variables in, that makes it hard.
So small steps to get this done.
- Marlin Firmware doesn’t like the .nc file extension. This is usually the default for Estlcam (And what Estlcam will open again without saying unsupported file type) but it’s the exact same file as the .gcode file. If you rename the test crown file to “testcrown.nc” Estlcam will open it, but might not give you the results that you’re expecting.
- If someone else’s code (Probably also created in Estlcam) is working, then there’s something probably not right with your process. Therefore it becomes difficult to accept “I did everything correctly” – proof that you did it correctly is in a correct end result. I work in I.T. I hear “I did everything right, and it didn’t work” every day, but going through the steps with them, it either works, which means those weren’t the steps they went through, or else I can identify where it went wrong, and we can fix it. This is what we’re trying to do.
- Ryan has always been really good with dealing with issues where his product is at fault. I’ve seen him go above and beyond several times in replacing hardware, but it has to be appropriately diagnosed first.
If you get the tests crown working, we’ll be convinced that you’re transferring the file fine. I don’t think we need a video of that. You got Jamie’s .gcode file working, you say, which is all good. We’re repeating the process again is all. Work with us!
Here’s an idea… Put the gcode file up in a .zip so we can see what it does. It it works on someone else’s machine, then that speaks a lot more to a potential problem elsewhere.
Ok… Just watching the video…
That seems to be a lot of Z motion, that doesn’t look right for the amount of commanded motion, which I know is from +5mm to -1mm. It might be worthwhile adding G21 to the start of the file (Right after the G90 line would be perfect) It might not change anything, (It shouldn’t really) but it’s worth trying.
I will agree that the motion in your video is entirely wrong. This is before anything in the software is happening, so I’m entirely unsure how Jamie’s code could have been working correctly.
The motors sounded fine (What I could hear past the dogs) so it’s not likely to be a motor wiring issue, where we get skipping steps and chunky movement.
It could be timing issues getting the data from the SD card to the processor. The board being unprotected like that with cutting foam is a bit worrisome, but if commanded movement is OK from the LCD, the drivers and hardware are probably OK.
I’d ask you to try one thing: Try jogging the machine with the router running, particularly in Z. Zero the machine, and then go from 0 to 50mm, then back to 0 a few times and see if it does what you ask.
