Messages

1771

General Mach Discussion / Re: Unit convertion issues and g-code questions

« on: September 01, 2009, 02:49:34 PM »

40100.250626566416040100250626566?

LOL

Hi Russ - How you doing? I was assuming room temperature  - also assuming Skippers 0.7980 was actually 0.8 (but then I think you know that  )

Best regards

Ian

1772

General Mach Discussion / Re: Unit convertion issues and g-code questions

« on: September 01, 2009, 12:54:37 PM »

Hi Skipper

40,000?

Cheers

Ian

1773

General Mach Discussion / Re: Step & Dir Pulse

« on: August 28, 2009, 07:23:42 AM »

Hi Hood - I was really more trying to make the point that Art states 1 to 2 meaning it can't be stated more accurately rather than why. but it doesn't really matter. The point really is that no-one prior to my post had mentioned that the values were ADDITIONS - I thought that was an important point to mention (edit back ).

Ian

1774

General Mach Discussion / Re: Step & Dir Pulse

« on: August 28, 2009, 07:02:58 AM »

Don't know if I can help with this but I'll try.

These input boxes aren't particularly well labelled or documented but they are covered albeit briefly in Art's video "Installation and Basic Configuration". In it he states that these values are ADDITIONS to Mach's standard step and direction PULSE WIDTHS.

He defines Mach's standard behaviour as being "approximately" 1 to 2 uSec for both. I assume (but may be wrong) that it's Mach's signal jitter that prevents him from being more accurate.

The Step pulse box:

Using a gecko 202 (other excellent drives are available) as an example, the manual says (for the step signal):

"The minimum logic “0” time is 0.5 uSec .... Microstepping occurs on the falling edge of the step input"

So the "approximate" 1 to 2 uSec that Mach delivers is MORE than adaquate, so with this particular drive there is zero point in extending it. You can of course extend it to anything you like - it will make no difference whatsoever except if you go reaaaaaaaaally long (and why would you?) and particularly at a high Kernel rate you will ultimately affect your potential max step rate!

There has been mention of the Max pulse width. The reason there is no MAXIMUM for pulse width is because the minimum is all that matters for correct switching of the electronics. i.e. with the example gecko drive the step signal falls and as long as it's kept low for the minimum 0.5 uSec the electronics will "do their thing".

Onto the The Dir "Pulse" box:

I quoted Art above as saying that this value (like the step pulse) is an ADDITION to the Dir PULSE WIDTH. This in my view can not be taken at face value and needs a bit more thought. The Dir signal (at least for the gecko and for every other drive I have ever seen and/or used) is treated more as a STATE than a PULSE. i.e the Dir signal does not LATCH the drive on a falling or rising edge, rather, it's STATE either high or low is "read" by the drive WHEN it receives a step pulse. The issue of course becomes particularly interesting when the Dir signal CHANGES and this along with Art's description are the clues to what I think this value ACTUALLY means. Here's another quote from the gecko 202 drive manual:

"Direction Setup: 1uS min (20uS min hold time after Step edge)"

Now of course this tells us that the minimum PULSE WIDTH of the dir signal is 20 uSec but I don't think this is what this box value refers to. I think it's the setup time of a CHANGING dir signal of at least 1 uSec BEFORE the falling edge of the next step signal. Therfore Mach's default of the "approximate 1 to 2 uSec" is again absolutely fine (for a gecko at least). The reason I think this is because Art states that this value should be changed if you have the problem of missing a step on a direction CHANGE (yes that old chestnut).

FWIW the direction hold time would only be of issue if your application wanted to change direction more than 50000 times a sec! Hmmmm - cutting microscopic saw teeth perhaps!

So as summary: Check your drive's tech spec and set accordingly by ADDING to the default 1 to 2 uSec if required, or if you prefer, leave both values at 0 unless you have problems.

Cheers

Ian

1775

General Mach Discussion / Re: Probe Wizard

« on: August 08, 2009, 12:39:33 PM »

Hi Keith - In your OP you mentioned you were getting G31 Z numbers like -6.**. I know this was to save you typing but just for fun here's the actual number I get: -6.2774385622042e+066. Which in inches (or mm for that matter) equates to about a gazillion miles - straight down :-) That's some probe depth and I don't blame you for being concerned, though of course even with this number if the probe trips it'll stop well before it bores its way through to China.

As far as I can tell the reason this happens is that if you don't actually type anything into the wizard DROs and just accept the defaults then GetUserDRO returns these magical numbers!!! Just make sure you type a number - even if its the same as the default and hit return. Then the wizard will produce what you'd expect. I agree absolutely with Terry - Mach and the current VB offering don't play at all well together. BUT - once the wizard has produced your gcode - there's no further involvement btween Mach and the VB so if the gcode makes sense (allways check it) then Mach should do what it's told just fine - well as Terry says again - most of the time...

Ian

1776

General Mach Discussion / Re: edge finding/2.5D probing

« on: July 22, 2009, 04:45:36 AM »

An update. There are now new versions of probe25D.tap and M90000.m1s which appear at the moment to get over the problems that some users have experienced. Many thanks to Nelson who has steadfastly stuck with the testing. For those that already have the routines, just download probe.zip from the usual place, unpack and copy the above two files over your originals - no need to re-install the .dll. IMPORTANT: On Mach's main menu, select Config/General Config.. and TICK Ignore M calls while loading - before loading probe25D.tap. Otherwise it won't work. A re-read of the updated readme can't hurt.

Terry, just create a text file of your 2D points and throw it at the 3D routine. Format is X,Y,Z on each line e.g. 24.00000,11.00000,6.29200. Note: Z can be anything you like - it's ignored at the moment but must be there - if you get my drift.

Cheers

Ian

1777

General Mach Discussion / Re: edge finding/2.5D probing

« on: July 21, 2009, 12:50:50 PM »

Hi Terry - Thanks - yeah its been a while...

No its not a secret - the routine is freely available. Have you not tried it?

Cheers

Ian

1778

General Mach Discussion / Re: edge finding/2.5D probing

« on: July 13, 2009, 04:14:17 AM »

I've made a couple of changes which hopefully will get shot of a few issues that some folks have had and kindly told me about. I've tested against Mach V3.042.020 and it all works fine out of the box for me - hope it does the same for you. Grab the new Probe.zip and Readme.doc from http://www.razordance.co.uk/probe25D.htm. No need to do the install again, just copy M90000.m1s and probe25D.tap over your existing files. In brief the changes and things to note are:

1) Un-check Config/General Config/Ignore M calls while loading. Prevents the "cannot do G1 with zero feed rate on line #6" error.
2) Loop size in probe25D.tap reduced from 999 to 998. Stops the "too many nests" error.
3) M90000.m1s now tests for "isLoading" in sub G31Fix. Stops Mach attempting to generate a toolpath for ever and a day. Mach still attempts to generate the toolpath and actually finishes now after several minutes but just hit cancel - it makes no odds. There's no real toolpath to generate anyway in edge finding. Mach has no prior idea where its going.

Cheers

Ian

EDIT on 23rd July: This info has now been superceded. See later posts. Ian.

1779

General Mach Discussion / Re: edge finding/2.5D probing

« on: June 27, 2009, 05:25:10 AM »

Hi Marv

The routine works with whatever your default units are so just divide my defaults by 25.4 (or thereabouts - 25 would do) to get reasonable settings in inches. For example your startX would then be at 4 inches your startY would be 4 inches your safeZ roughly 1 inch etc. etc. (Oops - just noticed that I've labelled StartY as StartX - the perils of cut n paste - funny - none of the gazillion downloaders have pointed that out - tsk tsk  )

The pertinent bit in the readme is:

Your probe will lift to “Safe Z”, rapid to “StartX”, “StartY” and drop to “probe at Z”.
It will then travel Y+ve (North) at “Feedrate” towards your object to be probed. When it makes contact it will then traverse round initially moving X+ve (East). “2.5D Triplet File” will be populated with the contact points in X, Y and Z. (Obviously Z will be “Probe at Z”)

Hope this helps

Ian

1780

General Mach Discussion / Re: edge finding/2.5D probing

« on: May 15, 2009, 05:51:16 AM »

OK - just tried my system which I havn't used for quite a while and I'm getting the same problems. I'm not sure at this stage what's changed but I've made a couple of alterations to M90000.m1s (attached) and it kind of fixes things for the time being. I'll give it an in depth lookover as and when I can.

Now, when you load probe25d.tap for the first time it will (hopefully) not throw any of the errors above but will spend quite some time generating the path. This of course is redundant really because there is no pre-determined path. Does anyone know if it's possible to tell Mach not to generate a path on loading like you can tell it not to run macros?

Anyway - you can just hit cancel on the path generation progress bar dialog and all should be good to go when you actually run it.

Ian

P.S. Contrary to what I said above, because of whatever it is that has changed, for the time being, the macros are probably best left to run at startup, so don't tick "ignore M call while loading" in Mach's Config / General config.