Hello Guest it is December 11, 2019, 09:37:52 AM

Author Topic: Spindle at Speed  (Read 1809 times)

0 Members and 1 Guest are viewing this topic.

Offline smurph

*
  • *
  •  1,155 1,155
  • "That there... that's an RV."
    • View Profile
Re: Spindle at Speed
« Reply #10 on: May 09, 2018, 02:30:12 AM »
I have just tested the at speed and at zero signals and they works perfectly.  

There are multiple spindles waits.

1. Time based (setup in the spindle range tab)
2. RPM feedback based (spindle stabilization)
3. Signal based.

Pick one method.  Not 2 or 3, but 1.  :)  

The stock (and default) default method is time based.  It does not require anything but setting up the ramp times in the spindle tab.  It does not require a m3.mcs script in the profile.  99% of the hobby users use this.

The signal based waiting also does NOT require a custom m3.mcs script.  If you have a m3 script, it will override the default behavior of the Core and you will have to duplicate the default behavior.  

For the signal based method.

1. Map and ENABLE the at speed signal.  You have to map it to an I/O object.  In this case, a coil from a modbus device.  Enabling the signal mapping is important as it will NOT work if it is not enabled.  That is how Mach know to look at the signal.  Otherwise, it will use the time based wait.  And if you have no times defined, the spindle will start instantly.  
2. DO not check the spindle stabilization check box in the spindle settings.  That is RPM feedback based.  And because the VFD will hopefully tell us it is stabilized with the signal.

So I downloaded a nice little modbus simulator and configured it along with the modbus plugin configuration.  I then mapped that modbus input to the spindle at speed input signal and enabled the signal.  I can now control my spindle at speed signal at will with it and thus, my spindle start wait.  http://www.plcsimulator.org/downloads

If you are having problems with the spindle immediately starting, I suspect that the signal is not enabled.  Again, it has to be enabled and mapped.  Once it is enabled and mapped, issuing a M3 should block until it times out.  (approx 10 seconds).  Or your m3 script is not doing the right thing.  If you need a custom m3 script, have a look at the scripting manual.  It has spartan example of one.  It ALMOST duplicates the stock M3 behavior with the exception that it does NOT wait.  Use mcSpindleSetDirectionWait() to enable waiting on the spindle.  

Another thing you may need is the spindlespeed.mcs script.  This is run every time a S word is issued.  It is a handy way of setting a speed for a modbus controlled VFD.  

There is a plethora of documentation in the Doc folder in the Mach installation directory.  Scripting Manual, Mach4CoreAPI.chm, Operators Manual, G code manual, etc...  They may not cover everything, but I feel like they are pretty decent.  Try reading Fanuc manuals!  The problem is, as with most anything like this, the only way to REALLY understand the system is to read every one of the manuals, cover to cover, and then read them all again.  Sometimes several times!  :)  

And the manuals keep getting bigger.  I just updated the G code manual with a whole lot of things for the newest development builds.  3784 is on the FTP site if any are interested.  

Steve
Re: Spindle at Speed
« Reply #11 on: May 09, 2018, 03:30:54 AM »
Hi Steve,
your post is most informative.

I a while back was trying o help a bloke who wanted the Gcode file to pause until an AT_SPEED output on his VFD came good.
I used the mc.SignalWait() API. I had some bother with it until I discovered that the range of input signals for which it works is limited
from 0-63, ergo ISIG_SPINDLE_AT_SPEED being outside that range didn't work. I commented at the time that had even the shortest of
comments about the restriction in the API.chm document would have been most handy.

Once we had that matter in hand coding the rest was pretty straight forward.

Is there any formal process where users might post a specific addition or correction to the current documentation? There has been two posts in recent
months where this particular problem has cropped up for users. I was able to assist in both cases but it would have been easier still if the document had
a single line addition.

Craig
My wife left with my best friend...
     and I miss him!
Re: Spindle at Speed
« Reply #12 on: May 09, 2018, 11:19:33 AM »
Hi

thanks Steve

this was the trick:

Quote
The signal based waiting also does NOT require a custom m3.mcs script.  If you have a m3 script, it will override the default behavior of the Core and you will have to duplicate the default behavior. 

I did not delete the m3.mcs, I just commented out all lines.


Helmut

 
Re: Spindle at Speed
« Reply #13 on: May 09, 2018, 11:43:57 AM »
Thanks Steve. Your  posts are always most welcome and never fail to shine an unseen light.

A possible issue with the  mcSpindleSetDirectionWait() call is that it gives no indication that it has timed out , so after 10 seconds or so the machine just continues on. Fine if that is what you want, but maybe you'd rather it stopped so you could resolve the cause. The default timeout may behave in the same way - I haven't tested it so I don't know.

Allan
Re: Spindle at Speed
« Reply #14 on: May 09, 2018, 01:56:12 PM »
Hi Allen,
no there was a test for 'timed out'. The rc was MERROR_INVALID_ARG.

Craig
My wife left with my best friend...
     and I miss him!
Re: Spindle at Speed
« Reply #15 on: May 09, 2018, 01:58:12 PM »
Hi Allen,
and  the API was mc.SignaWait()

Craig
My wife left with my best friend...
     and I miss him!
Re: Spindle at Speed
« Reply #16 on: May 09, 2018, 02:05:22 PM »
Hi Craig

Just wondered where you got that info. It doesn't make much sense to me, as a bad argument is quite distinct from a timeout. When I tested the timeout condition returned error 0 (no error).

Allan
Re: Spindle at Speed
« Reply #17 on: May 09, 2018, 02:12:58 PM »
Hi Craig

We may be at cross purposes. I was referring to the call mcSpindleSetDirectionWait() mentioned by Steve above.  SignaWait() gives the error MERROR_TIMED_OUT as you might logically expect.

Allan
Re: Spindle at Speed
« Reply #18 on: May 09, 2018, 02:45:29 PM »
Hi,
the API which is subject to the signal range restriction is mc.SignalWait(). If the input signal is not  in the range ISIG_INPUT1 to ISIG_INPUT64 then you will get MERROR_INVALID_ARG.

Steve introduced mc.SpindleSetDirectionWait(), but that introduction to the conversation is recent.

Craig
My wife left with my best friend...
     and I miss him!
Re: Spindle at Speed
« Reply #19 on: May 09, 2018, 04:27:39 PM »
Hi Craig

My comments applied only to Steve's suggestions. These do not have the 0-63 limit. Sorry if I muddled things.

Personally, I continue to use mcSignalWait() due to its more complete error handling.

Allan