If you’re referring to the “linux native” target then I tried it and although it compiles I didn’t have too much success with it. I wrote a small python script that does some pty magic and allows me to connect pronsole to it instead of driving it directly from stdin but this is all I got.
2 Likes
Please poke holes, I am completely baffled now. Not argumentative at all.
Certainly. I keep thinking about that. But something is not right. I will try it again.On mine, the smaller arcs on the letter all have severe ripples after them, which could just be correct, and the accel needs to set it lower, but the larger arcs (should have less slowing and be exiting faster) do not (to me they seem correct). You can actually hear my machine come out of the small corners. At 40mm/s things are more obvious it sorta snaps out. Heck maybe it is junction deviation messing up, but the letters are pretty much a 1mm 180 degree turn, that should slow more than the large logo arcs.
Maybe I can get a video today, but I have a new set of parts on it…I could try to get other vids as well. When you break it, set it poorly, you can see the issue clearly. Like I said, with super low accels, or large minimum arc segments you can see the same thing happen in different ways…I feel like a crazy person. I need to get video.
Just worried about a constant load, which seem s dumb because the large arcs are fine the small ones would never have enough load to work about.
What about a test file that has small zig zags for several seconds, straight lines. And some more likes that are small arcs, and some long arcs, all the same length. You should see the zig zags take longer, because of the acceleration params, and the other two take about the same time (assuming the speed wasn’t too high).
1 Like
Okay, adding a few more test segments would be cool.
Taking a small step back this test should be at accelerations that work at every reasonable speed, right?
So I should be testing at a “worst” case scenario, I think. Since my build is basically the recommended build size and specs I will test at 50mm/s travel and cutting. At 12V our drivers should not break down significantly until above that 60ish if what I learned from Ed is right.
So If I like it at 50…8-10 should be awesome.
Just making some notes. I will pack some boxes and then get back to testing…
I’ve updated my test pattern generator to create zigzag patterns at different speed and acceleration, so I can estimate the good range for my machine. I was also going to add the ability to put arcs at all the corners but I ran out of time. I’ve got activities this weekend and I tried to squeeze it in but I could only get some of it done. I’ll be on the forum but I wont be able to do any real work this weekend.
1 Like
I’m still chugging away, but you guys were right. The firmware as I have it does seem pretty good.
Maybe there was some eeprom issue yesterday. Something still still seems fishy so I am testing extremes just in case before I put this to bed.
Okay I think I am done obsessing. I came up with something.
Jamie your code gave me an idea, and showed me we could change the factor while it was running.
I ran another butt load of tests today and found out I could not have my cake and eat it too. I could make it run how I wanted or I could have nice small arcs not both. Your code works but still forces a choice.
I stared at that dam G2-G3 page, looked up all the code I did not know and thought might cause the issue and then it hit me. I found a solution that does what I want/expect!!!
Segment length scaled by the radius! (with a min and max)
I hacked up your code and tried it and it is heavenly to my eyes! The logo and small letters move how I keep trying to explain.
So think about this. We have people milling PCB’s and people cutting full sheets of plywood. a .1mm segment length kills the buffer and is certainly not needed on a subtle 8’ curve. So we have a minimum by default in marlin our min is 0.06mm, and a max is the point where we start to be able to see the segment (1-1.5mm). Radius is already solved in Marlin even!
segment length = radius * our factor.
NOLESS(segment length, mm_segement)
NOMORE(segment length, our max)
Is there a more elegant way to do that, I was trying to make it match the G2-G3 page. NOMORE, NOLESS is new to me I would have done it another way but…
So in trying that “our factor” can easily be mm-segment. Set it to something really low, like 0.15, just use it as minimum. Max could easily be a hard number like 1 so you would only need to turn on or off scale by size.
Using those numbers you do not start scaling until a 2mm circle, and do not hit max until 12mm and at a 1mm segment I see no slowdowns and also do not see segments.
If you see any issues let me know. I ran a few test files and they were nice. I didn’t have a max and you could start to see segments on the squished square.
If I understand correctly, specifying a segment length proportional to radius by some factor should be equivalent to specifying that the arc is a section of a polygon with a fixed number of sides, i.e. the angle from one segment to the next is fixed. I think this is equivalent to the MIN_ARC_SEGMENTS option, except that instead of MIN_ARC_SEGMENTS kicking in occasionally just for small-radius arcs you are wanting it to be in effect the majority of the time.
It appears that this can be implemented using MIN_ARC_SEGMENTS = 2 pi / “our factor” and MM_PER_ARC_SEGMENT = “our max”, except it wouldn’t limit the minimum segment length for very small radii. Adding a minimum limit (besides minimum steps) should be able to achieve the same outcome.
I hope I am not taking a step backwards – I know you tried a hundred combinations of values already but maybe your new way of thinking about it produces new values and is key to understanding why it works?
I have been digging in this all morning. I have not tried your version from the previous reply yet. I got stuck on…
I think #define MIN_ARC_SEGMENTS is broken now. edit nope same as before (don’t think this works right).
I see some of my issues are from the file, some arc are broken into a few pieces with flats between them, that describes a few of the hitches but not the accel jumps in them.
I think so, I just don’t think min arc segments works or the equation to do it is over whelming it. It has, angular_travel, in the equation, so is that forcing it to do the trig equation above it for each arc, or each segment? You are right the way I did it basically does the same thing except it does not choke when it runs.
Uploading the video now.
I understand that code is probably not correct but it functions enough to get the motion I feel should be happening.
It is subtle but if you watch the triangle logo back to back, and each test section back to back it is pretty clear to me. If it isn’t super clear I can try to edit together the test back to back.
1 Like
Fix is in,
So now I will try to make a crude branch you all can have a look at and see if there is a way to make my change less crude, if you see the differences and feel they are right?
I would love for someone to try this out. Rambo, Series, V417, https://github.com/Allted/Marlin/tree/V1CNC_Rambo
BASE, https://github.com/Allted/Marlin/tree/ArcSegment_Radius_Scaling
Reminds my of old Z80 days. As there was nothing available, we programmed the firmware of our first X-Y-table ourselves in TurboPascal and kept it in EPROMs, using the CP/M I/O routines to get the thing moving. Even the step controllers ran in an interrupt routine, based on Mr. Bresenhams algorithm. In those days, if your need for precision and resolution in sine calculations were not that extreme, a look-up-table was helpful. Some sine algorithms are slow, some a bit less. Just my two Pfennig from the past (that was about 1982 or so).
1 Like
Jeff, the way from 0,0 to 100,100 is about 141, or am I in the wrong movie? So, at 100 units/s travel speed, it would be 1.41 seconds to go from here to there, or?
isn’t 141 about 140?
Yep. What is F then? The distance to go? Sorry for my ignorance.
F is feedrate, in mm/min
Sorry, it was too long ago I wrote some detailed gcode, should have associated that. Got some fresh practice with the new machine and LinuxCNC these days.