alden

Flux – Are you getting good results from 412.11, just not master and earlier edge builds? It seems that the gcode7 test still fails.

Are there any other problems in 412.11 that you are aware of?

(The last few weeks have made it impossible to spend enough time on this but I’ve finally got some time to pay more attention on a regular basis).

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

No problem with the questions. There are a few things that need to be satisfied for an external driver to work

– Voltage. The external driver must accept 3v pulse signals or you will need a level shifter of some sort. I like the 74HC125 or 74HC126 (OnSemi is a good manufacturer). Power the chip with 5v and a 3.3v logic input will output 5v.

– Pulse timing. The external drive must be satisfied with step pulse widths down to about 2 microseconds. Use the edge branch (412.01 or higher) if you need these widths. THe code in the current master branch (380.xx) outputs pulses about 1 microsecond width. We added some pulse stretching later which is currently not in the master branch.

– Enable. THe enable signal from the TinyG is active low.

The step pin should also outputting 3.0v to 3.4v. 29mv is very low. What axis are you trying and does the low voltage occur on all axes?

Changes from the dev branch are introduced gradually from 412.03 to 412.10. These may help but the main items affecting positioning are still to come. I’d be interested in your results from 412.10 if you are so inclined, but I would also not be surprised if the results are the same.

Are you running build 421.06? Since 421.06 I have found what I believe is the root cause of the problem. I want to run some more tests on the current build then push a commit sometime Saturday.

In build 421.06 plan_line.c lines 229 and 230 need to be reversed. There is a condition caused by a series of very short and/or high-speed Gcode blocks that leads to a buffer starvation, causing the position to be mis-recorded.

Can you please confirm the build you are on?

Thanks

I ran the test on a probotix v90. This is what I got:
https://farm4.staticflickr.com/3710/13611819744_5f2de23222_o.jpg

Kind of hard to tell, but it looks like there is some variation on lines, but they are very close. My pen mount on this is pretty bad (ad-hoc), so it might be due to that. I ran this with the dev build.

Curious what happens with your shapeoko build.

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

The junction acceleration of 2000000 is the correct way to enter it – as to whether 2000000 is a good value for your setup – you have to test.

The only number that is taken with a million multiplier are the jerks, as these numbers are well over a million. The rule for jerk values is that any number less than 1m is multiplied by 1m internally, and any number over 1m is not. This allows old configs that had all the zeros to continue to work.

I hope that answers your question.

I was not able to test on a screw machine last night. Hopefully tonight.

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

I’m running this tonight. I’m wondering if some of the mis-alignment might be backlash in the belt mechanism, so I want to see if this behaves on a screw machine. I’ll run this on a Probotix V90 that I use for test.

As for the reset, it’s control x (ctrl+x) – no shift. Sorry if my post was misleading,

Here’s an experimental hex file with the changes. You will need to update settings for your system
https://www.dropbox.com/s/tvz765z7b58kbs6/tinyg_421.06_dev.hex