Forum Replies Created
-
AuthorPosts
-
March 3, 2021 at 4:46 pm in reply to: Occasional unrealistically high velocities causing position errors. #11954
JTW
MemberUPDATE: After some on/off debugging of this problem over the past couple of months I believe I have determined the cause, albeit not an elegant resolution.
The problem (position error due to high velocity) occurs when a COLLINEAR series of G1, G0, and G1 moves occur. In my case, the tinyG was executing a G1 at a 45 deg angle (i.e. both X and Y axes engaged) over a move of about 10mm which is long enough to reach full velocity, followed by a short, 1mm, G0 move at the same angle (i.e. collinear), followed by another G1 move similar to the first again at the same angle (i.e. collinear).
The result of that sequence is that the first G1 move executes properly, but then the tinyG ramps up to G0 speed, blows thru that end point and finishes at the end of the next G1 move (but does so in such a way that G1 move is a “spin-out” – that is, a position error).
Has anyone seen this before? Is this a known bug? Does it have anything to do with setting jerk settings (jm/jd/ja)?
Cheers!
JohnDecember 30, 2020 at 1:28 pm in reply to: Occasional unrealistically high velocities causing position errors. #11931MemberThe more we can eliminate, the closer I am to an answer!
Yes, the G1 speed does see frequent changes in the sense that it may get a feedrate request of 3000 for a string of maybe 200 commands, then shift to feedrate requests of 6500 interleaved with G0 commands (at 7500 mm/min) for a few hundred commands. (Imagine drawing the perimeter of a complex polygon at a slow speed in a continuous sequence, then shifting over to orthagonal fill lines at high speed that draws a single pass with a G1 then make a tiny G0 step before drawing the next pass as one moves across the interior of the polygon.)
And that answers your next question. Yes, there are many, many, G1-G0-G1-G0 sequences. In fact, this is where the error has always occurred!
If this means anything more to you please let me know. Otherwise, thank you for your thoughts and I will shift over to the link you provided and start a thread there.
Cheers!
JohnDecember 30, 2020 at 11:12 am in reply to: Occasional unrealistically high velocities causing position errors. #11929MemberThanks very much for your input!
I did give the other thread a read, and altho interesting I don’t think its the same thing for two simple reasons: (1) all moves generated by my code are either G0 or G1 … my code is not sophisticated enough yet to use arcs, and (2) I am already working in millimeters.
Wondering out loud, could the resulting high velocity value tinyG reports back be cause or effect? What seems to be happening for reasons that I do not understand is that the planner is not generating an “S-curve” for this one move and instead hitting it with a step acceleration (jerk) that spins it out. As a result the velocity reported back is near the maximum allowed.
Would it help for me to create a drop box repository outlining the specifics? (tinyG setup commands, gcode stream, return stream)
Cheers!
JohnMemberThanks all for the prompt responses!
<<The power for drivers and power from USB to the main chip are seperate – Without any external power applied, can you talk to it using something like the Arduino IDE com monitor?>>
I have tried powering down the tinyG while a plink connection is active. As soon as the blue pwr LED goes out on the tinyG, the RPi posts a “Bad file descriptor” msg implying that their connection is dependent upon tinyG being powered.
<<Pressing reset while connected to a Comms app, what happens?>>
Nothing. It is as if the reset button is inoperable. Blue LED does not even flicker. RPi/plink stay happy although when you look at the device log you can see it disconnected and reconnected.
<<Have you tried reloading firmware?>>
No. I was hoping to avoid this as it also appears that the bootloader no longer works. From what I understand, the spindle light should blink upon power up indicating it is in bootloader mode on contemporary v8 boards (which this is), but this does not happen in my case. I only get the blue pwr light, nothing else.
So unless you see something different, I think it is becoming apparent that the firmware (including bootloader) somehow got wiped from the ATMega chip. I do not have any specific equipment/software for burning firmware to the ATMega chip from scratch… but also have nothing to lose at this point. I will go read up on if this is possible from an RPi, which will likely involve soldering in a header for Rx/Tx and setting up old school serial from my RPi as Zootalaws suggested. I was just hoping for a silver bullet to avoid all this…
Thanks again for all your input!
-
AuthorPosts
