ah yeah, I actually found that It does look promising. I’m trying to put it in the location of the other postprocessors on my system (/snap/freecad/16/opt/local/FreeCAD-0.18/Mod/Path/PathScripts/post/ in Ubuntu 20.04), but it’s giving me annoying stuff about copying it…
Okay, quick little update: you can apparently enter a custom postprocessor as a macro, and if it has the “XYZ_post.py” format, it just shows up in the postprocessor list for the job
So I did that and output the file with marlin. However, I’m still getting those errors… so now I think it might be about the feed rate thing you mentioned.
I haven’t ran the test crown, let me give that a try
Here’s the code I was running, after using the marlin_post.py postprocessor in FreeCAD: pocket_test_marlin.gcode (6.2 KB)
(I think it was failing at the same place as when using the GRBL PP, though.)
I think I have a hot lead maybe. It always moves the head (just has a pen attached right now) a few steps, but fails right after the last command in the console output I posted above. It appears to actually do everything I posted there, and shows it in the repetier-host tool path as well.
However, the next command (what I suspect is breaking it) is a G2 command (the first G2 command in the gcode I posted just now). I searched a bit and found this thread: Arcs on Marlin and Dual End Stops - #13 by jamiek
in which it appears a bug was discovered with the G2 code in Marlin! The guy did a PR, I’m not sure if it was accepted, and I’m not sure exactly which Marlin is on my board. But maybe that’s it, if my version is outdated? (it’s at least a year old, maybe more)
Anyway, I’ll try that tomorrow. I should reaaaally get to bed now
Those arc issues were related to slow movements, and they were sort of optimizing them. It shouldn’t just stop completely.
That version of software may be old or new. The bugfix is a moving target. Where did you get it? Ryan also marks his firmware with a number, like 425. 504, etc.
I’m honestly surprised arcs are more commonly a problem. The arc starts at the previous place, goes to the next XY, and has a center of IJ. That seems tricky to define on your own. I wonder if the Z is affecting it.
That bug is specifically when soft-stops are enabled (which is only true for dual-endstops unless you have manually enabled it) and when an arc move hits the edge of the workspace, it would go in a crazy direction instead of doing the ‘natural’ thing and remaining with in the workspace. The PR was accepted so it’s fixed in current versions. Your 302 build would have that bug but I don’t think that’s the reason for what you’re seeing.
Your “pocket test marlin” gcode looks okay to me, and ncviewer shows what looks like a reasonable job.
I guess I was just assuming because the date about the firmware in the console output said it was from 2018, and the post about the G2 was from 2019.
So…about the firmware. I was working on this with a few friends when we first built it, and it was one of them who installed the firmware. It was long enough ago that he definitely doesn’t remember where he got it Is there a way I can talk to the board to find the version?
or, could I just flash new firmware to make sure I’m using the right thing?
I’m honestly surprised arcs are more commonly a problem. The arc starts at the previous place, goes to the next XY, and has a center of IJ. That seems tricky to define on your own. I wonder if the Z is affecting it.
Hmm… I definitely don’t have endstops built in, and I don’t think I put them anywhere in my programs/code… Ahhhh what a mess.
Is there a simple solution here that only requires spending a bit of money?
Since it seems like even if I got this fixed, Marlin is its own hurdle, are there any simple/cheapish boards that would let me use the same motor drivers, but run GRBL instead?
We can probably walk you through flashing the board with newer software. It isn’t rocket surgery. If you want to go that route, post a pic of the board with your stuff connected so we can tell what you have and what features you have wired in.
If you do want to just buy your way out, the boards in the shop come preconfigured and flashed with recent versions of firmware.
Marlin supports a ton of boards (like 50) but it needs to be configured. We have a few common configurations covered (22 right now).
Grbl only officially supports the arduino uno with a grbl shield. There are lots of forks for other boards, but then you are dealing with non mainstream edits.
I know it’s complicated, but there is only so much we can do to make it easy. Ryan sells boards ready to go. We have some common configurations ready to flash. Board manufacturers are always going to try to get their board in your mind as one option.
oh sorry I don’t mean to be entitled or sound ungrateful! I’m incredibly impressed and thankful for the massive amount of work you guys have done for this project, it’s really amazing
I’m cool with flashing the board, I’ve flashed firmware a few times so I think I could figure it out from a guide if there is one.
I guess my main hesitation is that it seems like Marlin may be a bit of a constant stumbling block. I’m not criticizing Ryan’s choice to use it, I’ve read his reasons and they seem totally fair (and again, I don’t want to look a gift horse in the mouth ).
Basically, because FreeCAD and other CAM programs I might use don’t seem to output Marlin gcode, it seems like every time there’s a problem I’ll have to worry that it might be a Marlin vs “other” problem. I got that guy’s marlin_post.py script, which seems to run… but also output a G21 command that the console output said Marlin didn’t recognize… (is that because the Marlin units are always mm or something?)
But, if the simplest and smartest thing to do is just flash the board and use it, I wouldn’t mind. It seems like it’s at least worth a try, since it would be pretty easy and a potentially quick solution. Could you link me to a guide? thanks again!!
Share a pic of your board. I can point you to the firmware that is closest. There are instructions for arduino and platformio in the docs. Platformio is the future. Arduino is limping along with support.
I don’t mind using whatever, as long as it works on Ubuntu
(oh and I have five A4988 drivers on it. They were calibrated a while ago, I think. And I’m guessing that the fact that the manual control seems to work well should mean they’re decent enough?)
The A4988’s should be fine, but that’s another thing that needs to be configured properly in the firmware, and is not in the standard build (it’s set for DRV8825’s).
In the pic in that link, they only show 3 drivers slots with jumpers, but I’m using 5 (two X, two Y, one Z). Should I have all jumpers, under all five drivers?
Yes, all 5. And it’s because the A4988’s only support 16X microstepping, and the DRV8825’s support 32X microstepping. It’s one of the benefits of using them.
It does look promising. I’m trying to put it in the location of the other postprocessors on my system (
Is there a way I can talk to the board to find the version?
).