Since I feel feed override should not affect rapid moves,
I looked into what it would take to change this.
Looks like one line added to tc.c would do it:
I used this for a test:
in tcGetPosReal()
snip
} else if (tc->motion_type == TC_LINEAR) {
--> if (tc->canon_motion_type == 1) {tc->feed_override = 1.0;}
if (tc->coords.line.xyz.tmag > 0.) {
snip
Now I know that is a hack (eg hard coded canon type: RAPID_TRAVERSE as 1)
but the point is this seems easy to fix.
I tried this briefly and feed override has no effect on rapids but max override
does. Feed override does still adjust feed moves.
I didn't try it with any other moves then G1 and G0 at this time.
How do people feel about this change in behaviour?
My opinion:
Feed override is for feed (hence the name) so should not affect rapids.
When running a program I should be able to adjust the feed rate for
conditions without the rapids slowing down. I think most (all?) industrial
machines work this way.
I also think we should have rapid override rather then use max velocity
as max velocity affects feed moves, though I am not nearly as excited
about that compared to the feed override behaviour.
Thanks
Chris M
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
