Messages

1931

General Mach Discussion / Re: Fun with Mach3 at the shop

« on: December 14, 2007, 05:37:19 AM »

broken link?

1932

General Mach Discussion / Re: gcode to mill half ball with cnc mill

« on: December 11, 2007, 11:53:04 AM »

nice one cameraman - good job - and thanks for the credit - much appreciated 

1933

General Mach Discussion / Re: Continuation after tool change

« on: December 10, 2007, 02:34:41 PM »

not sure if this is the place for this but... here goes nothing...

I've noticed it stated in a few other threads that Art is spending more of his time on the Yahoo group these days...
How can I put this delicately without causing offence or upset? which I sincerely don't want to do but if this is true... WHY? isn't this the Artsoft forum and isn't this thread a perfect example of where we could do with an answer or help from the top man?

1934

General Mach Discussion / Re: gcode to mill half ball with cnc mill

« on: December 10, 2007, 12:13:40 PM »

hint: #1003 holds the definition of the first circle (90 degrees / number of steps).

1935

General Mach Discussion / Re: gcode to mill half ball with cnc mill

« on: December 10, 2007, 11:51:21 AM »

erm - slight error. replace the line
 #1000=110 (total)
with
 #1000=[#1000 + #1001] (total)

I had it fixed radius but it needs the sum of the hemisphere and ballmill radius.

1936

General Mach Discussion / Re: gcode to mill half ball with cnc mill

« on: December 10, 2007, 10:45:44 AM »

Hi cameraman

try this - just replace the values of your choice up to "end of inputs" and rock n roll. Please note I knocked this up for you for fun - I haven't actually tested it on my mill so go carefully. Maybe I'll wrap it as a wizard if anyone wants it.

F3000
#1000=100 (hemisphere radius)
#1001=5 (ballmill radius)
#1002=20 (number of steps)
#1005=0 (centre X)
#1006=0 (centre Y)
#1007=150 (safe Z)
(end of inputs)
#1000=110 (total)
#1003=[90.0 / #1002]
#1004=[#1003]
G00 Z[#1007]
M98 P1 L[#1002]
M30
O1
#1008=[#1000 * sin[#1004]]
#1009=[#1008 / tan[#1004]]
g00 X[#1005 + #1008] Y#1006
G01 Z[#1009]
g02 I#1005 J#1006
#1004=[#1004+#1003]
M99

1937

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

« on: December 10, 2007, 04:31:21 AM »

First impressions:
- In entering my triplets into probe25d.csv I went around the probe object clockwise and picked off the triplets.
- In order to get the triplets for probe25d.csv I did G31 manually in the MDI window of mach3. I used the values in the X&Y in the DRO.

This is fine as we've agreed that the values don't have to be absolutely accurate in this particular case / use.
Ideally of course you'd get the x,y values from gcode params 2000 and 2001.

- I would feel more comfortable if the horizontal moves were G31 instead of G00 even though the moves are at SafeZ height.

I assume you mean in probe3D.tap? I agree - that would be better. I think the reason I didn't do this was because G31 causes enough trouble - especially when it doesn't actually get tripped.

- it seems that the triplets are modified by the stepover when the probe3d.tap file is made. In my case this threw me into conflict with my soft limits. Somehow a big stepover gave me softlimits warning, but small stepovers did not create a softlimit problem. I got around it.

Yes. Put simply - the way the probe3D.tap is generated is that a virtual (but normal zigzag rectangular) bed o nails probe is done over the X,Y extents of the boundary described by the triplets file probe25D.csv. Whenever the virtual probe is outside the boundary the X,Y values are ignored, whenever it is inside, they are added to the routine. Look at the star piccy again and you'll see that the probed points (circles) do not coincide with the triplet points (the arrows) in any way apart from the fact that the circles are inside the boundary described by the arrows.

- Although you made it clear, It has just hit me that your algorithm is pure bed-of-nails, while the mach3 pluggin is modified so that if there is no hit while going down, the probe will move hozontally at full depth, thereby eliminating extra Z moves. It is hard to compare the two as far as runtime goes, but now I question  which one is better suited to my needs.

Fair point - that I can't really help you with - your choice. I guess the plugin kind of works out the boundary on the fly, however there is the issue with the plugin of the pitch of the stepover being determined by the ratio of the X and Y.
Initially the whole idea behind my stuff was to provide only the 2.5D routine (which I believe is the only one of its kind at the moment). I added the 3D "bounded" routine because I thought it was a decent alternative to other methods and an improvement on most.

- Otherwise after 20 minutes I have not crunched my probe.

Good work Stirling, thanks

Excellent - long may it last.

BTW, this thing that you made that I'm using, does it have a name, have I missed something?

Hmmmm - yes, probably should have a name - Razordance probing utilities for Mach?

And finally... guitar? - probing body - neck hanging over the edge?

Finally - a quick edit to add that I recall why I changed the 3D routine to integer stepovers, (see post #59). Now I've changed it back to reals, you MAY get the problem where the vertical G31 doesn't stop when it trips but carries on down to the programed point - crunch. Note however that this is just as likely to happen in ANY probing routine under Mach as it appears its a fault with G31 itself.

1938

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

« on: December 09, 2007, 11:57:13 AM »

I don't think I made my question clear enough...
I'll manually enter triplets to create the 3D probe path because my object surpasses the table boundaries similar to your example.

So, The triplets that I manually enter into probe25d.csv ....are the triplets  the precise positions of the points on the objects ' boundary or the points posiition offset by the probe radius?

And once the above question is adressed....how accurate do  have to be. Can I guestimate the points or will there be that box-like hunting move if the triplets are not close enough to the actual point on the objects boundary . Does the tolerance in triplet position have to be within your 50%-70% backoff.

Sorry - I'm with you now . Entering the points by hand you'd (technically) enter the exact points on the boundary you want to create. However, it isn't actually that crucial in your case because all you're doing is creating a boundary for the 3D probing routine such that it won't waste time probing LOADS of unneccessary space. If you make the boundary a little larger than needs be it just means you'll probe a LITTLE unneccessary space. Probably better to give it a little leeway anyway - better you probe slightly more than you need than miss some of your model. I guess that answers the guesstimate bit - i.e. yes a guestimate is fine and you only need the minimum number of points to adequately "surround" your model.

The little box thing isn't an issue because that's in the 2.5D routine and you're not using that. The tolerance of the triplet doesn't have anything to do with the backoff and again you don't care cos the backoff is in the 2.5D routine.

Hope this helps - keep it coming - we will get your mystical object probed yet 

1939

General Mach Discussion / plasma torch control

« on: December 09, 2007, 08:02:57 AM »

Hi - Can someone give me a brief lesson in how this works/ties in with Mach please. Things like...

turning the torch on and off - presumably this is similar to spindle control?
how do you tap into the torch to "read" arc voltage for THC?
Can this be done with any torch or do only some have this "output"?
Presumably I need some (AD converter?) hardware between this and Mach?

TIA

1940

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

« on: December 09, 2007, 06:07:33 AM »

Bang head on keyboard... Thanks for spotting this and letting me know - It's now corrected - my apologies.
please download probe.zip again from http://www.razordance.co.uk/probe25D.htm

No need to go through the whole install again just unzip and copy the patch RazorProbeCtrl.exe over the original (in your case E:\programs\wherever...)

Thanks

Ian

PS - sorry - missed your two questions in your earlier post.

The triplet points, are they the exact object boundary or boundary offset by probe radius?

At the moment it seems the G31 command is in a bit of a state of flux in Mach. There are mentions here and there about whether Mach records on the approach or backoff and whether tooltip radius comp is implemented or not, but to be honest I'm not sure what the state of play is. That's why I've added in the touch point corrections tab. My way of calibration is to probe into an object at a known position, see what Mach says that position is and set the correction on the corrections tab.

A typical setup scenario would be to mill yourself a pocket (or island - doesn't matter) then probe it and apply corrections on the tab until the points file is correct. Your probe should now be calibrated for use with my software regardless of how G31 actually works.
 

how precise do the triplet point have to be(within backoff)?

Not sure I understand you here. Can you expand a little. But if it helps - don't confuse MY backoff with any G31 (internal) backoff. G31 (I think) backs off a small amount after a touch - this is when (I think) it records the point. Some seem to think this is some sort of advantage (as opposed to recording the point on approach). Personally I'm unconvinced it makes any difference at all - but I'm open to learn. My backoff is part of the perimeter walking logic and has to do with a compromise for handling the current "slope" of the perimeter being probed. somewhere around 50-70% should generally be good.