Forum Replies Created
-
AuthorPosts
-
aldenMember
Chris – I have been testing the arc changes on a Shapeoko and on a Probotix and am getting correct arc movement and no clunks. Can you try on your machine? What kind of machine are you running and can you post your settings? This will help work though exactly what you are seeing and help to develop a better strategy for short, isolated lines.
aldenMemberI am looking at the feedrate issue. This needs to be addressed before the clunking in any event.
There was a rather glaring error in the feed-rate calculation that overlooked arcs. Here is a hex that corrects that. I’m positing it now so you can give it a try. I will be testing this over the weekend before pushing to edge if it’s OK.
https://www.dropbox.com/s/23f54xjgnj0i0ku/tinyg_435.07_dev.hex
- This reply was modified 10 years, 4 months ago by alden. Reason: More info available
aldenMemberThanks for the detailed analysis. THis is a case that should probably be handled as an exception. If a G0 movement is too short to plan at the max velocity, reduce the velocity so it is moved. I will take a look at this over the weekend. Thanks for the diagnosis and the reporting.
aldenMemberI still have some work to do on the changelog. It’s not as automated as I’d like and with as many commits as we do I have to go back through the commit messages and filter out those that are not important to end users.
This release (intended for master once it has some more field exposure) advanced the firmware version to 0.97, and most of the changes in config are documented on this page of the wiki:
https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97Most of the internal changes are summarized as:
– Improvements to absolute and long-term accuracy; we can now run long, multi-hour jobs with +/- 1 step accuracy, which in a typical machine translates to about 10 microns.
– New strategies in place for handling Gcode moves that are too short to draw.
– Fixed a number of bugs related to inches mode and other display problems.
For the rest I need to comb the commit messages.
aldenMemberPsyko – I’d recommend updating to the new edge branch. We have been working on a number of issues that may be related to this one. Go to the github.io download page http://synthetos.github.io/ and look for edge build 435.06 (or later)
aldenMemberThanks for the info. I know there is work to do on the new power management. It’s on the list to work on.
The PL parameter is in place for the v9 work we are doing (ARM based) where the power level is set by the MCU via a PWM channel, as opposed to being set by the potentiometers. On the v8 it’s present, but has no effect.
aldenMemberThanks to you for helping me isolate it. Nice work. Once I do some more testing on my own I’ll push this to edge and re-link the download page to it.
aldenMemberJohn, If you can, please try running the job with build 429.04. This is quite preliminary – just something that I knocked out this morning. I have not had a chance to test this thoroughly, so if there are issues just abandon it and let me know what you find.
Here’s a link to the hex.
https://www.dropbox.com/s/8gu1b45mjf076jh/tinyg_429.04_edge.hex- This reply was modified 10 years, 5 months ago by alden.
aldenMemberJohn, I’ve been doing some testing. Have you been able to reproduce the issue starting later than line 3200? Anything that skips the some or all of the X axis back-and-forth facing operation would make the tests go faster. If this is not possible it also tells me something. Thanks.
aldenMemberI created a numbered version. Can tell me roughly where you see the plunge?
https://www.dropbox.com/s/815g3cu96bi5qw3/Roughingtinygmm.NUMBERED.txt
…and sorry if you have already said this, but what are you using to send the file, and what communications settings are you using – flow control, etc.
Also, how big is your work area? Mine hits the edge. I have an old Shapeoko.
Thanks — Alden
- This reply was modified 10 years, 5 months ago by alden.
aldenMemberLet me run this with coolterm to make sure it’s not on the board itself. An axis losing it’s mind points to a communications error, but I’d like to rule out everything else. Can you air-cut this with coolterm? Use Con/Xoff for flow control.
aldenMemberI have promoted dev to edge and posted the hex for build 429.01 on the synthetos.github.io download page. Please see if this is what you need.
aldenMemberI’ll get this posted to edge over the weekend. I’m traveling this week following up from Makerfaire.
In the mean time you can pull that release from dev and build it if that helps.
aldenMemberThe G0 maximum rate is set by the velocity max. So for Z it’s $zvm=xxxx.
If the machine is going too fast it may also be your motor parameters and other settings. Are you sure the motors steps, travel per revolution and other settings are correct?
Does the machine also move too fast on G1 moves?
There’s some useful information in the wiki: https://github.com/synthetos/TinyG/wiki/TinyG-Tuning
aldenMemberFlux – I had a chance to run your files. You found a nice “perfect storm” test for the short-line issues we’ve been working on. I’m sure it’s not much consolation, but thanks for that! I’m getting much much better results with changes that we made in dev. Please check the email with which you registered for this forum for a note I sent you about connecting up directly, or try me at the synthetos gmail address. I’d like to try a few experiments if you have time.
-
AuthorPosts