Re: Analog Spindle

[Dave Engvall <dengvall-at-charter.net>]

Hi J, D, R:

Clearly Ray's searching capabilities exceed mine...that is good because it
demonstrates there is some code to start from.
My simple brain envisions another axis defined as S that has PID control and
expects to use the dac channel one past the defined axes. E.g if one defines
X, Y and Z in the normal manner then going X Y Z S would get spindle
control. The scale would be number of counts from the encoder for one
rev...and some sort of timing would be involved as feedback to the PID to
determine speed and deviation from the target speed rather than position as
in the other axes.

Thanks Ray for searching.

Dave 


On 9/4/02 6:02 AM, "Ray Henry" <rehenry-at-up.net> wrote:

> 
> 
> Hi Dave, Kurtis, Jon
> 
> I did a search of the emc/src and directories below it and found more
> than 50 files that contain the word spindle.  I'm clueless when it comes
> to reading C and C++ but it would appear that the spindle speed notion
> travels quite a ways through the code.  For example in
> bridgeporttaskintf.cc about line 1934
> 
> "int emcSpindleOn(double speed)
> {
>   EMC_SPINDLE_ON spindleOnMsg;
> 
>   spindleOnMsg.speed = speed;
>   sendCommand(&spindleOnMsg);
>   return 0;
> }"
> 
> There is an interesting comment in emccanon.cc
> 
> "1-Apr-1998  FMP added spindleOn flag for resending CW, CCW if speed
> change"
> 
> And in emcio.hh about line 51 we see the comment
> 
> "    Spindle commands are given as on (with a signed speed) or off; they
>     are converted to brake-on,off, spindle forward,reverse for the lower
>     level spindle controller."
> 
> In emcops.cc about line 184 speed is also present in status messages.
> 
> "EMC_SPINDLE_STAT::EMC_SPINDLE_STAT() :
>   EMC_SPINDLE_STAT_MSG(EMC_SPINDLE_STAT_TYPE, sizeof(EMC_SPINDLE_STAT))
> {
>   speed = 0.0;
>   direction = 0;
>   brake = 1;
>   increasing = 0;
>   enabled = 0;
> }"
> 
> It is also clear from bridgeportspin.cc that someone had planned for
> spindle feedback because about line 214
> 
> "  // sync status vars with sensors
>   spindleStatus.speed = 0.0;    // no speed sensor"
> 
> So some planning for it is in there.  Kurtis and Jon have the right
> thoughts that any real CNC spindle needs to be handled by a real servo
> interface with encoder counters like the Pico, STG, Vigilant, Studio
> Ferraris or other similar boards.
> 
> I was not able to find any kind of comparator between spindle speed as
> commanded and actual speed from a speed sensor.  Nor was I able to find
> any position comparison.  But I need to restate my innocence of these
> languages.
> 
> Just a thought here, emccfg.h,  inispin.cc, and  inispin.hh all look at
> the [EMCIO] section of the ini file to setup spindle stuff.  This is okay
> for the parport forward, reverse, increase, decrease, brake on kinds of
> things but for servoed spindles, I'd think that we would want to use a
> section more like an axis definition with gain, max speed, and D/A
> control.    
> 
> Ray
> 
> BTW -- inispin.cc would be a good place to start streamlining the code if
> Microsoft CE is no longer supported.
> 
> 
> On Tuesday 03 September 2002 11:02 pm, you wrote:
>> Sorry to be the cynic but:
>> So where is the code...I only find basically a stub in
>> cannon_stand-alone.cc But nothing really implemented. I hope it is
>> there someplace.
>> 
>> Dave
>> 
>> On 9/3/02 7:26 PM, "Jon Elson" <elson-at-pico-systems.com> wrote:
>>> Kurtis Martineau wrote:
>>>> Dave, and anyone interested in the emc interpeter,
>>>> 
>>>> Please take a look a the following manual:
>>>> 
>>>> http://www.isd.cme.nist.gov/personnel/kramer/publications.html#RS274
>>>> NGC3
>>>> 
>>>> Unless I am mistaken, it would appear that the emc interpeter is
>>>> more complete than we using it.
>>>> The S**** command for speed is ready to be used (I think) - just how
>>>> can I direct it?
>>> 
>>> Yes, absolutely, the interpreter handles the S word, and sends an NML
>>> message through to some level inside EMC.  And, some code has been
>>> written to pass that along  to the STG-I card.  I don't know if it
>>> works now.  I suspect it DID
>>> 
>>> work at some time.  I will take a look at it in the BDI version I am
>>> working with
>>> right now, and see if I can get it to work with my new parallel port
>>> hardware.
> <s>
> 
> 
>