In my .ini, I have all of the acceleration parameters set to the same value, but these limits seem to be selectively violated by the trajectory planner. Using the bbxy.ngc file that ships with BDI, I plot the commanded X-axis velocity as the program finishes its initial X-axis move and turns 90 degrees to start the circle. At this corner the X-axis overshoot is first reversed by accelerating at about *twice* my set limits. Then, it decelerates at the set limit to stop on the commanded position. Does anyone know under what conditions the trajectory planner will violate the accel limits in the .ini file, and by exactly how much? If you could point me to the place in the code where this decision is made, that would be helpful. Thanks, Matt
On Saturday 18 February 2006 15:12, [email protected] wrote:
In my .ini, I have all of the acceleration parameters set to the same value, but these limits seem to be selectively violated by the trajectory planner.
Using the bbxy.ngc file that ships with BDI, I plot the commanded X-axis velocity as the program finishes its initial X-axis move and turns 90 degrees to start the circle.
At this corner the X-axis overshoot is first reversed by accelerating at about *twice* my set limits. Then, it decelerates at the set limit to stop on the commanded position.
Does anyone know under what conditions the trajectory planner will violate the accel limits in the .ini file, and by exactly how much? If you could point me to the place in the code where this decision is made, that would be helpful.
I don't know if this is a 'datapoint' or not, but I looked at that with the halscope in emc2 testing, then looked at the code. The code overshoots the starting positions starting radius of the circle by 1.5 units, I assume as a chip clearing move possibly. Looking at its traces with emc2 testing code, neither the initial move nor the reverseing at that point seemed to violate the maxvels set, the angle of the approach to the endpoint, there was a small radius in the trace as it turned around, then rose at exactly the mirror angle to the real starting point before the y motion was started. I Plotted following errors too, for those I had to raise the gain into the microvolt range to see it at all. So the code as it existed in testing 3 or 4 days ago seems to be nearly correct for this condition in that it was doing exactly what bbxy.ngc told it to do. This 'TESTING' code I'm running ATM has little or no blending enabled at this time I've been told. I do know that for a straight line but segmented move, I can hear the individual segments in the motor noises, almost as if its stopping between segments. Blending would smooth that out a bit. YMMV of course, I'm using steppers here, so I believe stepper_mod is the driver in use. One thing thats not too clear to me is how I should translate the halscopes traces into something that would correspond to motion in seconds type of data. The seconds is easy enough, but how does the displayed voltage trace translate in motion at the cutter?
Thanks,
Matt
Thanks, Gene -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Hi Matt On Saturday 18 February 2006 20:12, [email protected] wrote:
Does anyone know under what conditions the trajectory planner will violate the accel limits in the .ini file, and by exactly how much? If you could point me to the place in the code where this decision is made, that would be helpful.
If you want to update the emc-modules package, I think you'll find this little gremlin has been put to rest. The routine causing the violations of limits is tpRunCycle() when an if test kicks in for blending. It ended up passing an incorrect value back to tcRunCycle.. Regards, Paul. -- From the Klingon book of C: Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.
On Saturday 18 February 2006 18:07, Paul wrote:
Hi Matt
On Saturday 18 February 2006 20:12, [email protected] wrote:
Does anyone know under what conditions the trajectory planner will violate the accel limits in the .ini file, and by exactly how much? If you could point me to the place in the code where this decision is made, that would be helpful.
If you want to update the emc-modules package, I think you'll find this little gremlin has been put to rest. The routine causing the violations of limits is tpRunCycle() when an if test kicks in for blending. It ended up passing an incorrect value back to tcRunCycle..
Has that made it to emc2 HEAD yet Paul?
Regards, Paul.
-- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Sunday 19 February 2006 05:40, Paul wrote:
Hi Gene
On Sunday 19 February 2006 05:24, Gene Heskett wrote:
Has that made it to emc2 HEAD yet Paul?
Short answer. No.
Humm, SWAG on when?
Regards, Paul.
-- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
participants (3)
-
Gene Heskett -
mt0000@sympatico.ca -
Paul