Messages

661

General Mach Discussion / Re: subroutines

« on: October 16, 2010, 05:28:26 PM »

You want to use a variable to set the Z height, and update it after each pass:

...
N10 #100 = -0.01 (set initial Z depth)
N20 N30 M98 P600 L3
...

O600
G1 Z#100 Fx.xx (Plunge to depth)
(do your cutting here)
G0 Z1.00 (return to safe Z height)
#100 = #100 - 0.100 (set depth for next pass)
M99

Regards,
Ray L.

662

General Mach Discussion / Re: call macro from another macro

« on: September 28, 2010, 09:54:58 AM »

You can call one macro from another, but there are a number of pitfalls.  In particular, you cannot assume the first macro will resume execution when the second one completes - it won't.  The second macro is spawned in a new thread, so the two end up running asynchronously, and concurrently.  This can be circumvented by use of a semaphore that causes the first macro to wait:

M1000.m1s:

SetVar(1000, 0)  ' Clear sempahore
... Do something here
Semaphore = GetVar(1000)   ' Set semaphore
Semaphore = Semaphore + 1
SetVar (1000, Semaphore)
Code "M1001"   ' Call M1001 macro
Semaphore = GetVar(1000)   ' Wait for M1001 macro to complete
While Semaphore > 0
    Semaphore = GetVar(1000)
Wend
... Do something here

M1001.m1s:

... Do something here
Semaphore = GetVar(1000)   ' Reset semaphore
Semaphore = Semaphore - 1
SetVar (1000, Semaphore)
Return

Using this technique, you can nest macros safely to pretty much any depth.

Regards,
Ray L.

663

General Mach Discussion / Re: feed hold button

« on: September 25, 2010, 11:55:10 AM »

You can set up Stop to move to a safe Z height when pressed but not FeedHold as far as I know. You could however make a Brain that would raise the Z when it sees the FeedHold LED (OEM 805), maybe that would suit what you want?
Hood

But, then how would you un-do that so you could properly resume the cut??

Regards,
Ray L.

664

General Mach Discussion / Re: Newbie question- using PM-DC motor as servo

« on: September 21, 2010, 11:40:15 PM »

Thanks Ray,
       I was hoping it could be done. I am still a bit concerned about the voltage limits of the gecko units though. They have a max voltage of 80, and these motors I have are 90 which isn't a great amount but if a treadmill motor were employed for spindle drive it would be 130. Does a person just have to sacrifice rpm at the top, or could the output of the geckodrive be fed to the voltage following inputs of a secondary motor drive like the KB units. I wonder how the Geckodrive is actually controlling motor speed and acceleration. If it is varying voltage then the voltage folower inputs of the kbsi 240d isolater could track that and send an appropriate signal for any motor controller to follow. If it is pulse width modulation that is taking place it might be a little trickier. Of course in any case a person would have to work out a method of reversing the motor since that part of the loop would be lost in translation between the gecko and the signal isolator. How much loss of efficiency would a person see using the gecko at its upper limit and just losing that top end voltage I wonder?
     Regards, Les

Geckos are designed with a hefty safety margin (like 30%), so you can operate them up to their spec limits with no real worries.  The cheap treadmill motors are typically very high RPM (like 6000), which you won't be able to use. So, operating them, at reduced voltage will not really hurt you at all.  Geckos are current-limiting PWM drives, and they do a very good job of protecting themselves, unless pretty severely abused.  Heating of the motors is really not a concern, unless you operate them under heavy load for a long time.  Reduced voltage has no real bearing on motor temperature.  Even under heavy machining use, you will rarely be operating the motor anywhere near it's peak rating more than very briefly.

Regards,
Ray L.

665

General Mach Discussion / Re: Newbie question- using PM-DC motor as servo

« on: September 20, 2010, 10:36:14 PM »

Yes, you can do that, but you need a DC servo controller, like a Gecko G320/340 to operate it.  There are folks on here who are running their mills using the ubiquitous DC treadmill motors as servos, by simply adding a digital quadrature encoder, and running it with a Gecko.  It may not be quite as good as a real servo motor, but is plenty good enough for hobby use.

Regards,
Ray L.

666

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: September 13, 2010, 10:46:18 PM »

That's very odd....  Perhaps yet another bug.

On the plus side, I did hear from Brian today, and sounds like v4 is coming along, and may finally be out soon-ish.

Regards,
Ray L.

667

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: September 13, 2010, 12:45:58 AM »

No, the problem is a "blended" move, when you're moving in two axes, then bring in a third, the acceleration of that third axis is not handled correctly, so the axis acceleration limit is not respected.  IIRC, it only occurs when the third axis is started up *during* a circular move in one or both of the other axes.  If they're all straight-line moves, it works correctly.  It always happened to me when doing a rapid into a 3-axis helical move.  The instant the third axis (Z) started up, the third axis servo would fault, as it was being asked to accelerate at some horrendous rate.   It has nothing to do with the precision of the math.  The algorithim being used simply does not handle that case correctly, and it expects the third axis to essentially accelerate instantly to what rate is required.

Regards,
Ray L.

668

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: September 13, 2010, 12:12:13 AM »

Brian started working on a fix for this when I first found the problem, about a year ago, IIRC.  But, after a few days, he got off on something else.  AFAIK, he's never come back to it.  And I know it was NOT a simple thing to fix either.  Last I heard from him - probably close to six months now - he was spending all his time trying to get v4 done.  I haven't heard anything about his progress on that for a long time either.

Meanwhile, the only solution for this problem is exact stop mode - not a very nice way to work.  Or, avoid starting a third axis while two others are already moving.

Regards,
Ray L.

669

General Mach Discussion / Re: Smoothstepper and probing, home and THC

« on: September 05, 2010, 02:20:21 PM »

All making sense and understood but get a grip with the old quoting mechanism Ray - I've just about done my already poor eyesight right in 

I'll go away and have a bit more thinks but at the moment I'm thinking so why no THC - it (now)sounds to me relatively trivial - THC to SS: "UP", SS to Z: "pulse", and then the occasional SS to Mach: Update the Z dro/pos to: "3.142".
Job done and we all go down the pub.

Cheers

Ian

Ian,

I suspect there's no reason the SS *can't* do THC, it simply doesn't (yet), same as with backlash comp.  The hardware is entirely capable, but the firmware and plug-in code has yet to be writtento support it.  SS development largely stopped about a year ago, as Greg has had other, higher-priority, more profitable work to get done (a higher-end motion controller aimed at commercial and industrial machines).  The sadfact is, the hobby CNC market is quite small, and tough to make money in.  So, for now, the SS is very good at some things, not so good at others.  For those that don't need backlash comp, THC, and the few other features it doesn't yet support, it's a great product.  It dramatically improved the performance of my mill, so it serves a very useful purpose for me.  But, it's not yet the "Swiss Army Knife" of motion controllers.  That may, or may not, change in the future.

Regards,
Ray L.

670

General Mach Discussion / Re: Smoothstepper and probing, home and THC

« on: September 05, 2010, 10:37:03 AM »

Gentlemen - I think we're getting closer - but as always - the devil is in the detail. Can I push a little deeper.

When probing, the Mach3 parallel port driver issues a step pulse, then immediately checks the PROBE input to see if it's gone active.  If so, then it knows the probe is complete.

Well not quite complete - we're not done yet. What then "goes on" between the PP and "Mach3"? i.e. the probe trips. Then...? (see the next bit for what I'm getting at)

With the SS, Mach3 tells the SS to probe.  The SS issues the step pulses, and tests the PROBE input.  When the PROBE input goes active, the SS stops stepping

Well not quite - it DECELERATES to a stop. How does it (the SS) know how to do a deceleration curve?

and sends the position back to Mach3.

Ah - one of my earlier questions - How?

Cheers - and let's keep it cool guys - I'm grateful for ALL your input.

Ian

The SS *knows* what the accleration and velocity settings are for all axes.  So, when it needs to do an acceleration, or deceleration, it knows how to do it.  Mach3, through the SS plug-in, does not tell the SS "issue a step pulse on this axis", it tells it "move this axis to this position", and the SS hardware handles all the details of the move.  And the step pulses, including accleration and deceleration ramps, are generated entirely by hardware.  The firmware on the SS simply programs the hardware so it knows what to do.  Once motion starts, the hardware is doing everything autonamously.

Communications between Mach3 and the SS is by messages, not parallel port pin signals.  Each message consists of a sequence of bytes, some short, some long, using a protocol defined specifically for SS.  Those messages tell the SS to do things like "jog this axis at this speed", "move this axis to this position", "set this output to this state", "read this input", "home this axis", etc.  Of course, the actual communications is far more complex than that, but that is the general idea.  Messages are flowing pretty much continuously, with the PC telling the SS what to do, and the SS returning status to Mach3, so it knows what it needs to know about what is going on.  But, with the SS, the PC is doing FAR less work than it does using the PP, because all the "heavy lifting" is done by the SS itself.  The PC is left to run the UI, and do the trajectory planning, but no longer needs to concern itself with the details of the trajectory execution.

Regards,
Ray L.