Messages

1621

General Mach Discussion / Re: What Steps/ Units Settings for Z-axis (Quill) of CNC Retrofitted Radial Machine?

« on: May 22, 2010, 08:02:35 AM »

With One revolution (rough)  I am getting 120mm Rack movement it is almost 5inches.. and this is the reason I lost my Torque:(.. With 1200Oz-in Motor i am unable to drill a hole in Carbon steel.....

Well maybe.... but I wouldn't regard 1.6 inches per motor rev as out of order or anything like. That 1200 oz/in puppy should be unstoppable. I use 350oz/in steppers at about the same gearing as you and they'd push a bus 

Cheers

Ian

1622

VB and the development of wizards / Re: VB Dialogs and buttons

« on: May 22, 2010, 03:08:24 AM »

Hi donmair and welcome to the forum. What you want can be done. Take a look at page 25 of the cypress man. I've enclosed the example they refer to to help you figure it out.

Cheers

Ian

1623

General Mach Discussion / Re: What Steps/ Units Settings for Z-axis (Quill) of CNC Retrofitted Radial Machine?

« on: May 22, 2010, 02:32:26 AM »

Just to cover a couple of points FYI

to find the Pinion-Rack ratio or travel:
200 x 2 x 3 x Y= 12.344
Y=0.010286666666666666666666666666667  What does this means???

That is the pinion revs per mm. The inverse (97.213220998055735580038885294699) is mm per pinion rev - so your friend wasn't far out with his 4 inches.

...I somewhere studied the higher microstep means loosing accuracy...

Kind of but not quite. usteps though obviously finer resolution than full steps are not as accurate as full steps.Therefore they shouldn't be thpught of as making a system more accuarate. i.e. full steps may land within 5% of where they're meant to wheras usteps may land within 20% say, but this is non cumulative so it doesn't matter how many usteps you have it doesn't affect your step accuracy. For other reasons though there's no point in going above 10 usteps. Think of it as usteps give smoooooothness and gearing gives resolution, wheras alround quality gives accuracy.

Cheers

Ian

1624

General Mach Discussion / Re: What Steps/ Units Settings for Z-axis (Quill) of CNC Retrofitted Radial Machine?

« on: May 21, 2010, 09:05:35 AM »

We know that 1200 steps turns your pinion exactly once. So to get your 'Y' you could set your steps/per to 1200 initially and code g0 Z? where ? is some suitable integer and hence allways turns your stepper full turns. Obviously bigger ? gives you more accuracy in measurement. Measure travel and stir in a little maths to taste.

Ian

1625

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

« on: May 18, 2010, 03:22:40 AM »

Hi Denis - pleased you got something working but I admit I'm confused as to what's changed.

csv files in France (only in France???) are made with comma (x,000, y,0000, z,0000).

As far as I'm aware, csv files everywhere use commas - hence (C)omma (S)eparated (V)alues. Your csv file should just have numbers in there for X,Y and Z i.e. there shouldn't be any letters. e.g. each line should look like 1.2345, 2.3456, 3.4567

I have a question about the corrections tab : Is it only for the 3D routine, or for the 2.5 routine too, because it runs better with a big correction on the 2.5D routine. Are this corrections for the probe size? I mean, if I have a 0.1 inch ball on my probe, do I set 1.27 mm as corrections in all directions?

The idea was that you'd use these to compensate for innacuracies in your probe. To be honest I never had a good enough probe to test if these worked as intended. I allways left these as zero.

Cheers

Ian

1626

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

« on: May 17, 2010, 03:33:46 AM »

Hi Denis
Yes - the triplet file is complete rubbish and the gcode file has some very silly numbers in there. Add to that the strange error messages you're getting and it looks to me like the interface between the VB and the DLL is corrupt. What OS are you using?
Cheers
Ian

1627

General Mach Discussion / Re: input read frequency?

« on: May 14, 2010, 10:26:26 AM »

Thanks Hood - be interested in your findings.

Ian

1628

General Mach Discussion / Re: Sprial Cutting A Hole

« on: May 14, 2010, 10:10:36 AM »

This example will cut a hole centred at X5 Y5 from Z10 to Z0 over 3 passes. First two spiral down and the third gives a flat bottom. Change to suit.
g0 x10 y10 z10
g2 x10 y10 i5 j10 z5
g2 x10 y10 i5 j10 z0
g2 x10 y10 i5 j10 z0

(Distance and IJ mode are absolute)

Ian

1629

General Mach Discussion / Re: Pause for DRO Update

« on: May 14, 2010, 09:29:05 AM »

Kently - As Tweaki has said it's all down to the fact that Mach and macros execute in two distinct asynchronous threads. It's nothing to do with screen reading - nor is it a bug or poor design. Pausing should really be termed synching. IsMoving is synching, Sleep is pausing. Some argue it's good to put a sleep in the middle of an IsMoving loop, some that a sleep on it's own will do. I'd certainly disagree with the latter.

That said - I sometimes think synching is used unneccessarily - kind of - not sure if I need it so what the .... I'll put one in. I'm sure someone will correct me if I'm wrong but I think I'm right in saying there is no need nor point in synching before or after a read. There IS however very good reason for synching after a write. One caveat to this is if you do nothing in your later code that depends in any way on the written value, you needn't even synch after a write.

Ian

EDIT: There is some wisdom in delaying the synch after a write until immediately prior to a read (of the thing you wrote to). Then, the synch may return immediately, i.e. the time you would have waited has been occupied by the intervening code. This is not so much synching before a read but delaying for as long as possible a synch after a write.

1630

General Mach Discussion / Re: input read frequency?

« on: May 11, 2010, 02:59:51 PM »

You may well be right Hood. I guess the thing is that at first the view was that inputs were ALL polled at 10Hz. Then came the issue of the index input which we agreed must be much faster than 10Hz in order to work as it does. We then learned that it's fundamental to probing that it's input is read at kernel frequency. My contention is that IF THC was done at kernel frequency or at least a deal faster then it too would benefit greatly. I wonder why therefore, that the great and good chose to leave it slower. To be honest I'm not entirely sure this IS why THC is sluggish, which is where I was trying to go but somehow got distracted. I was just attempting to see if I could figure out why it's slow and if there was anything I could do to improve it's response.

Cheers

Ian