tune stepper function

Right because 90*4000 = 360000 = 1000 steps/degree
It also means 1 RPS = 60 RPM = 360K PPS!

It also means 1 RPS = 60 RPM = 360K PPS!

LOL - neither the driver nor the motor supports that speed.

According to tune-dialog and halshow output - motor and driver are limited to 10000°/min or 2500 turns/min or 167kHz. That matches the specs of optocopler used at driver, which has an min duration of high pulse of 2u and min duration of low pulse of 3u.

I played a bit with different accelerations, but could not notice any differences of acceleration values beyond 1000mm/s² - what "obscured behaviour" could limit accelerations?
Below 1000mm/s² I hear a difference and see the difference in scope too.
But beyond 1000mm/s² I could not detect any differences.

halshow shows the right values, so I guess, they will be transmitted. But I'm quite sure, that they won't be used.

Any idea, how to get rid of "real" accelerations without high end measuring equipment?

Is this on the rotary axis? If so that would be 1000 degrees/s^2

At a maximum velocity of about 30 RPM (180 degrees per second),
this would only be about 200 ms from stop to full speed, possibly
running into the torque limitations of the motor/drive

Nothing in the stepgen hardware limits acceleration though
you need to set both the driver acceleration limits and
LinuxCNCs limits so they do not bound the setting.

That is, there is nothing preventing the step rate going from
0 Hz to 200KHz instantly

PCW wrote: Is this on the rotary axis? If so that would be 1000 degrees/s^2

Yes, I use the rotary axis, as it has the same stepper resolution, than my linear axis, but I don't risk to run into crash on the rotary axis.
.

... possibly running into the torque limitations of the motor/drive

Well, I don't hit any driver limits, as the driver would than go into error state ...
But ...
... may be, that the driver reduces acceleration to some value, that don't hurt the motor.
.

this would only be about 200 ms from stop to full speed

As you mention the time ...
You're right - my tests were ridiculous. I was hunting for milliseconds, that don't have any relevance - pretty dumb

I was triggered by some shiny guys, that stated, that lower acceleration would lead to higher topspeed. So I was testing where I could find a difference ...

My problem was - I was looking at the travel distance of the ramps only - and the difference between 1000 and 5000mm/s² was about 12mm - which seemed big to me.
Now I calculated the difference in time, which is about 0.1 seconds - not worth to continue testing.

Thanks for putting me right.

I think part of your problem may have been using halshow to monitor pins and its not a real time application. Therefore its not possible to monitor the signal like you were trying to do. You need to use halscope.

When I've reviewed velocity and acceleration, I've always plotted motion.current-vel and calculated the time it takes to get to the commanded velocity. I think when I did this last it appeared that for MDI and jog commands the acceleration used was 50% of the ini file max limit which was used from Gcode. I suspect becasue these moves were managed by the simple trajectory planner. I wonder if the same applies to pncconf?

Here is an example which clearly shows the trapezoidal acceleration profile. Note current-vel is in units/sec, not units per minute so the velocity here was 10,240 m/min from memory.

Hi Rod,

I was triggered by m5 (its german). But I guess, the picture at 17:10 is clear anyway.
It says - the faster you want your max-vel, the lower must be acceleration (as the stepper runs into error / looses steps).

So I wanted to know more about the physical limitations of my stepper/driver set. But my tests showed, that relevant physics starts way beyond the max speed of a stepper motor.
Stepper driver uses TLP185 which has 2us min time for stepper high level and 3us min time for stepper low level - which leads to about 175kHz, or in my case speed of 10500 mm/min.

If I use symmetric step signal with 2,5u stepper driver runs into error beyond 10500 mm/min and says "step signal was too fast".
When I use asynchronous step signal with 2u high and 3u low, than the driver runs into error beyond 10500 mm/min, but this time driver says it lost steps.

So 10500mm/min is my max. velocity ...
Now I wanted to know, whether things change with different accelerations.
Short answer: it does not.
No matter, whether I use 50mm/s², 500mm/s² or 5000mm/s² - max velocity does not change.
I tried to lower resolution / microsteps to see, whether I could break the limit, but it does not make any difference. Lower resolution fails beyond 10500mm/min too.

So I see no reason, why I should use different resolution.
My parameters fit perfectly.

Some of my friends say, that it is impossible. My motors can't reach that speed.
So I created 2 small videos, which show the motor in action.

My setup is a rotary axis and the stepper-tuning page from pncconf:


Part of the message is hidden for the guests. Please log in or register to see it.

Calculation says, that ramp of 1000mm/s² to 10500mm/s leads to about 15mm.
My rotary axis has same stepper parameters, than my linear axis, so 15mm is equal to 15° - so I tested 40° to see, whether topspeed hits the border (which is the case).

To see, whether the motor/driver set can hold that speed for longer distance, I tested 180° to both sides, which leads to 360° - which runs fine too.


Part of the message is hidden for the guests. Please log in or register to see it.

Calculations says, that 10500mm/s equals to 175kHz or 2625rpm - which my friends take for impossible, as the motor is rated for 1200rpm only