Uccnc not staying within acceleration parameters?

[rmtucker]

We did a lot more tests yesterday to find the problem. We are getting closer and closer, but give us some time to find it. I'll be back when I have any news, but I can't tell you when. It can be days or weeks: I can't prognose. If you have urgent job and you can switch back to do your job then do it.

Please don't think i am being pushy here.
I just think that the more users are informed/involved about this problem,the more they will be able to help and investigate these kind of problems and keep uccnc/cncdrive ahead of the rest of the competition.
Also i was wondering how you achieved the results in the status screen giving info like lost steps etc,or did you add it in some way?

[cncdrive]

Please try to lower the kernel frequency to 25kHz, because it seems to us now that the too high kernel frequency is causing the issue for you. Some stepper drives require longer dir signal time after the step edge and so the too high kernel frequency makes it impossible for them to work properly. So far what we see is that this is probably the issue for you. With your settings the 25kHz should work just fine.

[rmtucker]

Please try to lower the kernel frequency to 25kHz, because it seems to us now that the too high kernel frequency is causing the issue for you. Some stepper drives require longer dir signal time after the step edge and so the too high kernel frequency makes it impossible for them to work properly. So far what we see is that this is probably the issue for you. With your settings the 25kHz should work just fine.

Hi i am afraid i can not lower the kernel frequency as i require 40khz on 1 of the axis.
I did already try 50khz and it made no difference.
The only way i can lower the kernel freq to 25khz is to replace the gecko on that axis so i can reduce the microsteps from 10 to 5 and this would lower the 40khz requirement.
Or i can try halving the max velocity which will allow the lowering of the kernel freq just to test the theory if that helps.
Is this just a problem with the uc100 because according to dazoes tests yesterday the ethernet version did not display the problem?

[cncdrive]

All motion controllers handle the step/dir timing the same way, with 50% dir time.
Dezsoe test results are probably coincidence only. But they will make further measurements in a few days to see the issue exactly clear. (If there is any in the uccnc, probably not.)

[rmtucker]

Can i ask if a restart of the pc or uccnc is needed after a kernel frequency change is needed or does it come into effect as soon as i press apply and save?

[dezsoe]

Apply or save is enough. (Save applies first.)

[rmtucker]

After your suggestions about the kernel Frequency i did the following tests:-

1. Ran the large program in post #1 (Took around an hour).
Adjusted Z max vel to 1700mm so i could run at same speed as other tests.
Set to 100khz
Just the z axis drive powered.
All drives enabled in config.
Machine lost steps.

2.1. Ran the large program in post #1 (Took around an hour).
Z max vel to 1700mm.
Set to 25khz
Just the z axis drive powered.
All drives enabled in config.
Machine lost steps. (Not same amount as last Run).

3. Ran the large program in post #1 (Took around Half an hour because it is not accounting for x and Y moves).
So Z is making each move quicker.
Z max vel to 1700mm.
Set to 25khz
Just the z axis drive powered.
Only the Z axis Drive enabled in config.(Turned off x and y in config).
Machine did not lose steps.

The only difference is that it is sending pulses in Test 1 &2 and that the accel/decel profile will have changed to account for x and y moves.

[dezsoe]

You asked how did I check for lost steps. Here is a macro. It works only if you have home switches.

[cncdrive]

Just an idea: ISn't it possible that your step active edge is incorrect for your stepper drive connection?
I mean that your step active low is not set while your drive reads the step down going edge or your step active low is set and your drive reads the step up going edge?
If the step edge is set wrong then the direction signal can happen in the wrong timing, this usually results in a steps error mostly only a few steps per g-code program.

[rmtucker]

Hi
I have active low set on the z drive.(And the x and y for that matter)
Gecko manual states "Microstepping occurs on the falling edge of the pulse".
I have always had it set active low for 10years + using the parallel port and Mach3.
it was worth checking it just in case
But that would not explain no lost steps with x and y disabled in config?