Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: dmoore on May 10, 2020, 07:12:02 PM
-
I am attempting to switch 4 CNC router tables from Mach3 over to Mach4 but one area I'm stuck on is the "Time in Seconds" period of an axis in which the velocity is applied.
Here in Mach3 you can see the period of time is 1 second (which works perfectly fine).
Here in Mach4 you can see the period of time is 4 seconds (which coasts too long after jogging).
How do I adjust the "Time in Seconds" period from 4 seconds to 1 second?
Thanks in advance!
-
Hi,
that is not a setting per se. The Mach4 motor tuning graph shows a velocity/time graph of the motor as it accelerates at max accel to max
velocity and then decelerates at max accel. The time scale is a convenient means for you to establish the time spent at each phase.
Try for instance to drastically increase the acceleration and see what happens to the time scale. Try also much higher and lower max velocities and
see how the time scale varies.
Craig
-
Thanks for the reply. While I don't know what the exact numbers for "drastically" are, I tried a number of combinations shown below and never could get a number (time frame) less than 4.0 seconds. Can you possibly provide any specific numbers to get it closer to 1 second?
-
Additional examples:
-
Hi,
I have experimented with changing the speeds and it seems that the display is restricted to 4sec.
Remember that that is just a visual representation of the time/velocity diagram, not necessarily a practical movement.
My new build mill for instance travels 350mm (the X axis travel) in 1.6 seconds including both acceleration and deceleration
phases, thus my machine will NEVER perform a G0 move of 4 seconds duration, and if it attempts to it will crash BIGTIME.
Craig
-
I have experimented with changing the speeds and it seems that the display is restricted to 4sec.
Thanks for your help! So would you call this a "bug" since it doesn't actually represent the actual value even though the underlying value is actually changing?
Is anyone else able to get their motor velocity chart to show correctly as it shows correctly in mach 3?
-
I've put in a ticket with support and we'll see if we can determine if this is something I am doing or it is actually a "bug".
-
Hi,
So would you call this a "bug" since it doesn't actually represent the actual value even though the underlying value is actually changing?
No, I don't consider it a bug at all. Its a graphic representation of a speed vs time diagram, no more, no less.
As I said my servo will cause my axis to accelerate up to max speed (15m/min) in 90 ms at which time it will be travelling at 250 mm/s. Clearly
it will have to decelerate and stop in short order so as not to overrun an axis of 350mm. The speed vs time graph does not include any limitation
due to finite axis length, nor is it required IMO.
Craig
-
The speed vs time graph does not include any limitation due to finite axis length, nor is it required IMO.
If the graph only provides an "overview" of the rise and fall of velocity, why wouldn't they just have removed the time reference?
-
dmoore,
I really hate to say this but give it a break.
You can clearly see in the graphs the time it takes to accelerate, followed by a max feed followed by a decelerate.
The times are all there.
Who cares if the overall time is 1 sec or 5 sec?
Sorry to be a jerk on this.
Bill
-
I really hate to say this but give it a break.
You can clearly see in the graphs the time it takes to accelerate, followed by a max feed followed by a decelerate.
The times are all there.
Who cares if the overall time is 1 sec or 5 sec?
I care. I never got the the point of tuning since I assumed the times were clearly wrong (that the ramp up and down would happen over a 4 second period). It might be debatable if it is a "bug" but don't put information in place if it is known to be wrong.
There are two types of companies - those that beg their customers to tell them what is wrong or how to improve their products and then they take those suggestions to heart and then there are companies that think every time a customer "complains" they should dismiss the feedback because only they know best.
I run a company in which we actively reach out to customers, asking for feedback and complaints - even our CS person sends an email after every order asking if there were any problems to be 100% sure there isn't a problem we could solve. Thank God our competitors don't do that. Maybe we shouldn't decide for Newfangled which company they want to be.
-
It is not wrong.
The time shown to accelerate and decelerate is right there.
The time at constant speed is irrelevant.
-
It is not wrong.
The time shown to accelerate and decelerate is right there.
The time at constant speed is irrelevant.
You took the words right out of my mouth, Bill.
The slew speed time is irrelevant and simply meant just to give a visual representation of the trajectory. I think the time IS expanded if the acceleration and deceleration portions of the trajectory exceed the default time of the graph.
The time it takes for the acceleration and deceleration is the only thing that will ever change on that graph, time wise. The max velocity will determine the height range of the graph. But otherwise, the <slew time> = <default graph time> - <acceleration time> + <deceleration time>.
What should we do? Have a constant slew time? 1 second? 2 seconds? And always shrink or expand the total graph time to the the sum of <acceleration time> + <deceleration time> + <slew time constant>?
I think it is just semantics as to what portion of the graph is constant. And I'll be the first to admit it doesn't work like Mach 3. But I always say Mach 4 is not Mach 3. It is Mach 4. :)
But anyway, we have a time portion on the graph simply because it is part of the little graph widget that we used. And you can see your accel and decel times, as they are relevant.
Steve