First off let me apologize for being unclear with my thoughts and If 
my wording seemed overly strong.
 
>> IMHO -CSS should always wait
>> for an up to speed signal before STARTING feed otherwise the surface
>> feed might not be even close.
> 
> Are you talking about constant surface speed or feed per rev?

Talking about surface speed - now :) - as you pointed out Feed per rev
will be right no matter the speed of the spindle!
What I am saying is that while using CSS , before STARTING a feed line
 EMC should know that the spindle is up_to_speed . I suggest that a HAL 
bit pin (say spindle_up_to_speed) would suffice. Then an integrator could
 connect that pin to what ever logic he wants to confirm that the spindle is
 up_to_speed (and how close up_to_speed should be). It can be done in
other less direct ways but I think that such a fundamental behavior
should have a direct, clear pin for it.  

> When radius changes abruptly you have the same problem with speed.  I
> don't think you should stop feed in all these cases.  That could be a
> disaster with some materials or tooling.  It is often better to cut at
> a slightly wrong speed than to stop feed and rub the work with the
> tool.  It's a compromise either way.  EMC's current solution to that
> compromise is "let the user control it" (even if he just programs G4
> once in a while).

I agree about cutting at a slightly wrong speed. I am talking about a 
BIG lathe where it takes 3-4 seconds to come up (or worse down ) to 
speed but takes a second to rapid to the next feed position.
I'm also talking about only at the start of each feed line.
A small radius cut will not ask the spindle to change very fast.
A facing cut will ask a fairly slow change.
A feed at 4" od then rapid up to 10" diameter will ask for a huge fast
change, if the rapid speeds are fast.
It would be up to the integrator to decide that -50 rpm is ok but -200
is not and lets EMC know by toggling the described pin.
Again G4 is a crutch for something that should be handled by machine
logic not by a programmer.

>> The threading should only feed hold when it's not synced in my
>> opinion. Thats they way the Okuma was- If you hit feed hold (in the
>> middle of a pass) it would hold after the current thread pass was
>> finished.
> 
> EMC2 already does this.

perfect I didn't see this in the docs (I didn't look hard either)

> 
>> As for the spindle brake/reverse problem sort of the same thing- EMC
>> should not go from m3 to m4 (or vice versa with out stopping first and
>> it should know if it did stop.
> 
> I disagree.  Many spindle controls (all VFDs??) handle this perfectly
> fine.  My lathe is one.

That is really the point- for you all is good for the other guy he wants 
something different. When would you want to go from m4 to m3 
without stopping? Your VDF does it for you. Fast enough for EMC
or else you feed hold till it's done.

> 
> For machines with reversing contactor spindle control, you may want to
> stop before you reverse.  I agree with Stephen that you can handle
> this in HAL.  I have all sorts of machine-specific stuff in classic
> ladder on my lathe.  You cannot open the collet or change gears with
> the spindle running, etc etc.  I think it's an adequate way of
> handling these machine-specific peculiarities.

I guess I just disagree- I think the behavior is fundamental  and
common.
I also agree that it can be done in other ways. You can do it, I can do it
but can the ordinary ( just from MACH :) ) guy do it? It's a lot of work.
 
> 
>> What we need to do this safely is a feed hold that cannot be
>> by-passed . the current feed hold can be overridden.
> 
> This seems contrary to what you said two paragraphs up.  Can you
> clarify?

Yes If I am going to use feed override to do some of the things we talked 
about I need one that cannot be overridden. It will be up to me to not use it
when  say threading.
For instance for the spindle reverse I would monitor spindle fwd and rev
If they switch  I feedhold to do the brake and reverse.
If the programmer overrides feedhold with out thinking then I'm in trouble!
So either we have one that cannot be overridden by the user but does
 not feedhold for threading/tapping (works for me) or one that cannot be 
overridden at all and the integrator has to be careful (is there away for 
HAL to know when threading/tapping?.

> 
> Chris
> 
> P.S. Please wrap your text at 70 columns; it is very difficult to
> quote and reply to your messages with unwrapped paragraphs and have
> it remain coherent.

Sorry hope thats better is there away to make Hotmail do this automatically?


_________________________________________________________________


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to