alden

Here’s a link to an experimental hex file
https://www.dropbox.com/s/tvz765z7b58kbs6/tinyg_421.06_dev.hex

The default settings are mostly sparkcrafter settings, with the exception of the Z axis (motor 4) pitch which I set for my shapeoko.

It also has fixes for the repeated tn element in the {c:n} readout, and the double axis report, so [zzvm] should go back to [zvm]

It’s not been tested with tgfx, so I do not expect it will work with it (it might). Please realize that this is experimental and don’t beat me up too badly if it doesn’t work!

Thanks for your patience and perseverance. Yes, the issue is related to speed. We have been working on this issue for a few weeks and made substantial progress over the weekend. I am hoping that we found and fixed the root cause.

For now the revised code is in the dev branch as build 421.01. Once we validate that it works with tgfx we will push to edge. Hopefully that will be some time this week.

At that point we can see how this works across a number of setups.

Carl – to your observations

1. SR Skew. Yes. This is expected. What you should see, however, is the final status reports at a STOP should line up exactly as these report final conditions.

2. The “stuff” at the start is a collection of things. There are one or 2 header lines reporting the system revision. If a new settings file is present (after a load) it’s 2 lines, in most other cases it’s one. They you may see an initial status report with a bunch of values. Since it’s the first one every value is reported as the filtering starts once a value is reported.

3/4. That is expected, higher jerk ramps velocity more aggressively, resulting in overall faster job execution for runs 1 and 2

As for diagonal skew – we did a bunch of stuff over the weekend (and over the last few weeks) to chase down some inaccuracies we were seeing. In high probability these will take care of what you are seeing. Experimental code is out on the dev branch with these changes. We will be validating operation with tgfx this week and will push to edge as soon as we are comfortable with it.

You are welcome to grab the dev branch, of course, but if you use dev you are on your own, pretty much. You will need to clone the project, set up Atmel Studio 4 or 6, compile and test. Project setup should all be documented on the wiki. The changes in dev are too frequent to post hexes – and frankly, not all dev builds work or are even intended to work.

I will comment on your next post when I see it.

• This reply was modified 10 years, 7 months ago by alden.

I’m running $JA at 2,000,000 for Shapeoko, but it might be high. I’d try dropping back to 200,000 and see if you get different results.

We’ve been funding a number of cases lately where users are having problems that appear to be communications or firmware that turn out to be settings related. They just go away once the settings are dialed back. I wish there were a silver bullet for this, but I’m afraid there is not. And there are a lot of parameters. Here are some things we are trying.

– Some parameters push TinyG into operating limits that are on the edge of the processor to handle. For these we are attempting to chase down root causes and putting in “traps” to report if these conditions are hit. These will report out as exception reports (ERs). In some cases we can also optimize the code so it has a bit more headroom, but that never actually gets rid of the case, just moves it.

– We are contemplating more input validation for those cases that can be detected on the front end. For example, we really should have limits or warnings on extremely high jerk values. Axis feed rate limits (xFRs) should not be higher than velocity max for that axis. For example.

If you can think of other things we can do to help users and setup I’d be interested. We appreciate your hard work and contribution.

• This reply was modified 10 years, 7 months ago by alden.

Thanks. I’ll work with this info.

Update: I plan to push a build later today in a separate branch called Issue76. This build is derived from the current dev branch and has a number of small fixes have been incorporated since 412.01. The build number will be something upwards of 420.02. I will put the hex on the download page or perhaps make it available by a dropbox link. This will give us a good baseline to work from.

@sparkcrafter – Would you be so kind as to test your snippet with this new branch when it becomes available? My expectation is that the same behaviors you are seeing now will still exist.

@grim – This may or may not work with tgfx as it has not been integrated and tested. So no expectations on that front.

Thanks

@sparkcrafter – I would like to see if I can reproduce this. SOme questions.

– Were you using the settings you provided in JSON in the March 23, 3:00 AM post? If not, can you please post the settings you were using.

– Can I confirm that you are on 412.01?

There are adjustments that can be made in firmware to set the size of the planner buffer. See PLANNER_BUFFER_POOL_SIZE and PLANNER_BUFFER_HEADROOM in planner.h.

I will try to reproduce this some time today.

I ran the entire rabbit and the Z was off by 0.22 mm. You were seeing a sudden jump of 2.5mm?

I also think some of the 0.22 might have been due to the lousy way I connected the “DRO” to the machine (silver tape). I am going to try to fashion a better anchor and see if I can get that number down – or confirm that it’s a legitimate error. I was using the settings you provided from the earlier post, not the JSON settings. I may try them as well. More later.