Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: stirling on October 01, 2007, 06:49:54 AM
-
Hi - As I understand it there are no macros/wizards/plugins currently available in Mach for this - i.e. you're on your own with G31. Is this correct?
-
THat is correct at this time. SOme of us have written simple macros to do simple Probing. The real problem is that Mach cannot correct itself for probe tip radius compensation or probe touch/trip movement error before it recorded the data so it makes it impossible to know what the true touch position is.
Art has his thinking cap on concerning the G31 so hopefully we will have a solution soon. I keep poking at him from time to time about it (;-)
Once that part is fully functional it should be fairly simple to create a plugin to do CMM type 2.5d probing with Mach recording the session as you go......
Might want to help remind him from time to time.
(;-) TP
-
Thanks TP
SOme of us have written simple macros to do simple Probing.
Could you point me at a couple of examples please?
The real problem is that Mach cannot correct itself for probe tip radius compensation or probe touch/trip movement error before it recorded the data so it makes it impossible to know what the true touch position is.
Could you expand on this a little please?
Are these shortfalls restricted only to 2.5D probing? if so, why do they not affect 3D probing in the same way?
Might want to help remind him from time to time.
Hmmmmm - I may be on his back pretty soon about CV - don't want to be too heavy on the man ;D
Ian
-
Hi IAN, THe 3d approach to probing currently used is known as the bed of nails approach. It is basically probed with just the z axis going up and down and the positions are moved by the xy axis. The height of z when it trips is recorded along with the xy position. The height of the z is really only relative to the reference height of the part. In the trip point file the only thing relative is the relation of the lowest and highest points as a reference so the true position of z is not needed and the position of xy is relative only to the grid you probed on. You will end up with 1000s of points that have to be converted to a skin, later to be carved out by MACH
In CMM type probing you are actually probing in the x,y and z planes and the radius of the probe tip AND any movement error associated with the length of the probe arm AND the direction of axis TRAVEL HAVE to be corrected to give you the exact touch point center line. THat way you have an exactly replication of the coordinate values needed to recreate the surfaces probed. You will only need the coordinates neccassary to recreate the surface. For a straight surface you will only need a start point end point and a base height and top height point to draw the surface. For curves you will need to collect curve data in order to recreate it..
Please don't be TOO hard on them about the cv. It can be a beast to impliment across the extremely broad range of equipment types it is being used on.
It would be a piece of cake if it was only used on one exact type of machine. Then it could be fine tuned to the conditions relatively easy. I find most problems are machine/operator generated. Too small of drives for machine, and too fast of settings for conditions, or getting heavy on the FRO (;-)
Hope that helps (;-) TP
-
Hi TP - thanks for your reply
the radius of the probe tip AND any movement error associated with the length of the probe arm AND the direction of axis TRAVEL HAVE to be corrected to give you the exact touch point center line
Understood - but isn't this a problem that can be solved by either post-processing of, or on-the-fly-processing of the data? What I'm getting at is that there seems to be the idea that currently 2.5D probing can NOT be achieved in Mach. Is it not simply the case that no-one has yet written a plugin/wizard whatever to do it?
i.e. I'm thinking of writing one - I have all the algorithms worked out and tested but if there's something that Mach can't do (that I don't know about) then I'll shelve it for the time being.
-
Hi Stirling, YES A plugin CAN be constucted as it is. But it will be a beast to impliment. Yes you can do the coordinate value corrections on the fly after collection/posting. BUT there is a lot a variables involved to do it as a whole. If we wait until ART gets the G31 worked out for CMM type collection it will be a breeze as Mach will do the hard part for us. I think he has a plan worked out but just needs a liitle time to refine it.
I do this all the time with a collection of probing macros and even using the MPG and a special MACH page with AXIS directional DROs and trip indicator LEDS but do the actutal corrections by hand as well as the recording of the points. Pencil, paper and calculator method(;-) WHile wating on ART to get enough request to make it worth his time and effort. It is really hard to justify the time and effort for just a few users. WHEN the masses figure out how USEFULL it really is THEN the light will come on.(;-)
Some things to think about
Tip radius correction
probe arm movement error and ratio corrections
4 axis movement correlation +/- directions of each to know in which direction the compensation applies.
THe current G31 movement will NOT allow you to jog off the trip point you must make a gcode move off the trip THEN you can resume a jog mode. I believe G31 is a JOG mode in itself.
A logical ordering of points collection
(;-) TP
-
My thinking is that Art & co. probably have enough on their plate at the moment so I think I'll go ahead and have a go. First I'll make a probe and try Art's wizard.
-
OK so I now have myself a working probe. However I've hit the first snag and am wondering if anyone can help me through it.
It seems that there is no way of telling with G31 whether the probe actually gets tripped or not.
i.e. at the end of G31 it stores X,Y and Z in machine params 2000, 2001 and 2002 whatever happens.
For example: if I start at X0 and have an obstacle at X100 and program G31 X120 then I get (correctly) 100 in parameter 2000.
However if I program G31 X80 I get 80 in parameter 2000 whereas I would have expected some sort of error indication.
Anyone know how to tell if the probe is actually tripped?
-
Sure can, look on the diagnostics page there is a LED that indicates when the probe trips. You need to include this check to see if the probe trips(ledon) before you hit the axis probing limit. It would tell you 1. the probe did not trip or 2. the trip point was beyond the axis probing limits. Therefore you need to repeat that move to try and verify a nontrip due to a probe error.
(;-) TP
-
Hmmmmm. I tried that but there's a problem. If I drive into an obstacle with a jog, or a G01 or a G00 then the LED changes state. BUT if I drive into an obstacle with a G31 it doesn't, even though the trip has been actioned by Mach.
I even tried reading the parallel port with a GetPortByte and that doesn't work either with a G31 but does with a jog, G01 or G00.
I'm beginning to think that there are more issues with G31 than you/me/we thought - I'm even thinking of writing my own simulation of a G31 with a G01 and testing the LED as you've suggested.
Any thoughts?
-
HUM I just checked and on my machine if I run the G31 and trip the probe the Digatize LED lights up on the trip.????
It will light up on any trip of the probe does not matter what process you are running, or just sitting there and you trip it with your finger.
Be VERY carefull if you run the probe in any function other than the G31. Crunched probes get expensive(;-)
Like I said before the G31 in the bed of nails approach is a piece of cake. Using it it a CMM type probing is very difficult with the current G31 cycle and NO tip compensation.
Alot of times I just drive it around with the hand pendant and have a huge led setup on the CMM probing page. I just drive it until I get a trip on the LED and back off the trip. I then apply the comp by hand/calculator and record the position on a piece of paper. I then use macros to do other functions such as center of circle with diam. Center of two points x,y z and a axis. COR rotation of the vise or COR of part by two hole method, etc.
NOT always classy looking but functional.
If the G31 had tip COMP it would be easy to construct a plugin to probe the majority of 2 d objects with a little hand intervention from time to time.
(;-) TP
-
I've taken a bit more of a look at the digitize LED lighting/not lighting. It seems that sometimes it does and sometimes it doesn't. If you have a moment, try this code in the VB Script window. I'd be grateful for your findings on your system.
code "G21"
code "G31 Y100"
While IsMoving()
Wend
MsgBox GetOEMLed(825)
arrange for the probe to be tripped by some obstacle (i.e. not your finger) at somewhere around Y50 mm. Try it with different feedrates. On my system at feeds around 1000mm/min the LED always lights fine but when you get down to lower feeds around 100mm/min, although the probe trips - i.e. it stops! - the LED doesn't light.
-
If there is extra movement in the probe mechanism you can get that. When moving slowly you can actually bump the trip switch but when it stops it losses contact and the led goes out. When moving faster there is always a touch of overun that will keep the switch in contact.
It would be nice if the G31 cycle would be movement to trip switch then back off switch untill it untrips THEN record position.
(;-) TP
-
If there is extra movement in the probe mechanism you can get that. When moving slowly you can actually bump the trip switch but when it stops it losses contact and the led goes out. When moving faster there is always a touch of overun that will keep the switch in contact.
yes - I've done a bit more experimenting and I agree. It seems to be all about tweaking the motor tuning to make sure you get a good trip! - reduce accel and up feedrate etc.
It would be nice if the G31 cycle would be movement to trip switch then back off switch untill it untrips THEN record position.
Indeed it would, but I think I've found a way to get round it.
-
Actually we need to build better probes that are more dependable(;-)
If we build the mechanical side to be as dependable and acurate as we want the software side to be we will have it whipped(;-)
(;-) TP
-
Agreed.
Bit of an update on progress. My cheap (well actually it cost me zippo ;D) and cheerful probe is at least allowing me to experiment with the software side of things. So far I have a working wizard that's producing some reasonable toolpaths. At the moment the main issue is the probe ocasionally "sticking" when I retract from a touch - but hey, I'm learning lots so I'll stick with it for a while longer...
-
OK Stirling, Art has fixed up the G31 code so it writes the tip COMPed position to the points file. SO now we have a true touch position available for use. (;-) TP
-
Hi TP - Nice one - thanks Art.
Which version/revision do I download to get it please?
Update on my progress then. I have a 2.5D edge finding/profiling wizard that works fine apart from an issue with what I can best describe as suspected communication sync problems between the Mach thread and the VB thread which occasionally trips it up. I've discussed this with Art and he thought this was probably down to the G31 command as well. Maybe his G31 fix will have resolved that also - I'll need to test it out. (see thread http://www.machsupport.com/forum/index.php/topic,4456.0.html)
The other problem I'm having at the moment is with my setup. I seem to maybe have a dodgy sig/gnd which I'm trying to resolve over on the zone (see http://www.cnczone.com/forums/showthread.php?p=356082#post356082).
Hopefully in a few days, time allowing I'll have an up and running routine for beta testing if anyone's interested in giving it a whirl.
-
Stirling the same thing may be causing the problem in both instances(;-) A very POOR contact at the switch. If the switch has a high resistance at the contacts you can get phantom signals from it as it attemts to make contact. Normally a small capacitor across the two leads will help it clear the contact and make connection. That is the problem with running with a 5volt source there is little energy available to help maintain contact. As a test try raising the debounce setting in config. it may give the switch enough time to settle before mach deals with it.
THe probe tip COMP is in V2.56 BUT there is a small glitch it is corrected in version 2.57 so wait for the .57 version to be posted
When you get ready to test your plugin let me know I always like to see other peoples work. I usally get to learn something from the example(;-) TP
-
Stirling the same thing may be causing the problem in both instances(;-) A very POOR contact at the switch. If the switch has a high resistance at the contacts you can get phantom signals from it as it attemts to make contact. Normally a small capacitor across the two leads will help it clear the contact and make connection. That is the problem with running with a 5volt source there is little energy available to help maintain contact. As a test try raising the debounce setting in config. it may give the switch enough time to settle before mach deals with it.
Yes - I thought of this, so I actually took the probe right out of the equation and just shorted the input pin to ground with a jumper - same problems still happened. Tried messing with debounce and no change.
I've got a thread running on the zone http://www.cnczone.com/forums/showthread.php?p=356625 where we're looking at the possibilities of an unstable (floating) earth. It almost seems like earth is managing to occasionally come up to logic 1.
THe probe tip COMP is in V2.56 BUT there is a small glitch it is corrected in version 2.57 so wait for the .57 version to be posted
I still haven't quite understood how to know when a new release/version/bug fix is in the offing - maybe you could let me know - thanks.
When you get ready to test your plugin let me know I always like to see other peoples work. I usally get to learn something from the example(;-) TP
When I'm happy it isn't likely to trash your probe ;D
-
If you are shorting the pin to return/grnd at the port itself not the cable, then you may have a LPT card or MB problem. The port does not depend on an earth grng to function it has its own return path for all the active pins. If you did the test at the end of the cable then you may have a bad cable.
The only other thing I can think of is if you grounded all your components in a series ground instead of a star ground then you may see recirculated currents. Still it should not effect a good lpt port when checked at the port.
Just some thoughts, (;-) TP
-
Hi tp - problem sorted - see http://www.cnczone.com/forums/showpost.php?p=356556&postcount=8 onwards.
Now the only remaining problem I have is the possible bug with G31 so as soon as .57 is posted I'll give it a whirl.
Thanks TP - really appreciate your help and interest.
-
Stirling has the problem reoccurred since you corrected the problem with the signal??? We have run the G31 code for hours without error before. ???? (;-) TP
-
Hi TP - yes it has.
I have a little routine to check the consistancy of my probe. It goes something like this:
G91
while I have nothing better to do
G31 X10
while ismoving()
wend
store touch point
G01 X-5
while ismoving()
wend
wend
There's an object at about X5 so it just merrily bounces back and forth recording the touch point each time. Most of the time it's fine BUT - once in a blue moon it fails to execute the G01 and therefore doesn't back off. Actually - the first blue moon is round about 10 to 20 iterations in.
Ian
-
Ian, out of curiousity try using a G1 instead of the G01. I have seen sometimes that when running VB inside of mach it tends to get ahead of itself and forgets things.
(;-) TP
-
Tp - tried your suggestion. Just the same. Not sure where to go from here - think I'm stumped... but...
I have seen sometimes that when running VB inside of mach it tends to get ahead of itself and forgets things.
could you expand a little - this may be a clue.
-
In some VB programs (powerfeed for example) If you enter in more than 3 commanded moves at a time it seems that VB starts to overwrite the buffered code that is waiting to be used. If it overwrites far enough then it will seems to skip over sections of forgotten code and then only runs the most current code in the buffer.
BUT in your example it still points to a switch problem in the probe. I would program a single loop of VB code. I would then manually test the code one loop at a time to see if the problem still occured.
If it did then I would program a single loop of code in GCODE and repeat it to see if it failed.
If it failed in VB but not gcode then it could be a VB problem.
If it failed in both VB and Gcode then you have a switch problem.
Have you tried placing a small capacitor across the probe leads to help the switch make/break the connection. A lot of times with low voltage switching it is needed to keep the contacts working correctly.
Just some thoughts, (;-) TP
-
BUT in your example it still points to a switch problem in the probe.
Sorry TP but I don't understand your conclusion - A G1 command neither knows nor cares about the existance of a probe - or shouldn't do anyway.
Also now that I've littered my code with debugging traps and printouts I'm getting indications of all sorts of wierdness. Seems to me there are serious sync problems between the mach and vb threads and possibly even some corruption of the vb workspace by mach. Art has indicated he's aware of timing issues in the interaction between mach's implementation of G31 and vb. I'm beginning to think this is only the half of it. ::)
Seems to me that the reason the bed o' nails approach is possibly more successful is more to do with the fact that g-code is static i.e. pre-created and is then run in Mach as per normal. With 2.5D probing the g-code has to be dynamic, i.e. created on the fly as it works round the profile. Clearly in this case the interaction between Mach and VB is more critical. Certainly more critical than Mach/vb seems to be capable of at the moment. Shame. :(
Whether V2.57 will solve the issue I don't know - any update yet?
-
The point was that given a long list of commands stored in VB it overuns the buffer and appears to rewrite the buffer thus lossing some commands. Or so it seems.
So far the only time I have seen the g31 hang was if it did not trip or reset properly.
Just a thought, (;-) TP
-
OK - a bit of an update. After having found a way to kludge round the problems with G31/VB I now have a working 2.5D probing routine. My homemade probe's a bit crappy :'( so the resolution is no way as fine as I would like, but anyway - some progress! 8)
Haven't got into posting on youtube yet so in the meantime here's a couple of vids on my site of it probing (a french curve) and then running the auto-generated toolpath.
http://www.razordance.co.uk/probe25D.htm
-
Stirling that is a great routine we are doing some arrays for probing. We are over in the topic G31 probing arrays stop by and have some fun.
Mike could use your routine to probe the guitar(;-)
Is the routine available to test yet???
(;-)TP
-
Oh Stirling.............. ;D ;D ;D ;D ;D ;D You have made my day.
Terry thanks for the heads up. This is exactly what I need.
Now do you guys think we can bribe Art and Brian into adding this to the 3d plugin to set a boundry for 3d probing. This would cut so much excess time for me due the odd shapes I have to probe. Hey I'm not above begging either! ;D
Mike
ps Stirling I haven't read the whole thread.....so how do I get this goodie?
-
MIKE this one or the array type can do what you need to set the boundary for the 3d plugin. You will not need fine resolution as you are just doing a boundary survey to set up the 3d routine. All they need is the point file to calculate the boundary. They could easily set the XYZ boundary to probe.(;-)
Problem is that ART and company are so swamped that it will be HARD to get anyone interested in MORE work(;-(
THe only hope we have is that when ART is really retired HE will want to do some of that fancy sawdust slinging and will need a good probing routine to make life easier. Drop him an email and invite him to drop by our topics and have some fun.
Hopefully someone will come along that can do the programming of the plugin or A wizard for that matter, for what you need.
Stirling please keep us up to date on where you are at. LOOKS GOOD DUDE.
(;-) TP
-
Stirling what you find on the G31 stopping work around?? I think I know what is causing it. It is a combo of switch jitter and it confuses Mach sometimes.
(tp)
-
Hi Guys. Thanks for the positive comments. I just need to do a little more testing and tidy things up a bit and then I'll post it for you and anyone else that wants to test it out.
TP - The workaround was to find a way of taking the G31 "code" command/statement out of the VB search routine. In it's current implementation when G31 fails to touch something several times, it corrupts the VB stack.
Cheers
Ian
-
Stirling I have also found that MACH will choke on the math inside of a Gcode program using gcode variables if you use cos,sin to calculate the next positional move of a g31 position. It will throw an error and stop, but a cycle start push will get it running again.
(;-) TP
-
Terry is this where you have to wait for the color of the cycle start button to change before pushing it?
Mike
-
MIke I have it worked out now. It was a time constrant problem with Mach running out of time to process each leg of the array on the fly. I fixed the problem. I will update the files tonight.
-
Hello stirling,
Any updates?
Mike
-
Hi Mike
Sorry - been off the case for a while - too much to do too little time :'(. Hopefully I'll have something usable to post in a couple of days.
Cheers
Ian
-
Hi Stirling,
I actually do know how you feel. I had taken off testing Terry's array probing to carve some foam and knew I was going to have a break for a day and was hoping to get the guitar digitized. Today's the break day! ;D Now as a gentle hint, what you showed in the video will work just fine for me as long as it does work.....hint....hint!
Mike
-
Hi Mike - sorry for the delay in replying.
I havn't wanted to post the routines until they were tidyer and easier to use because I've fallen foul of releasing software too early before - it just leads to grief and a lot of running round in circles - mainly for me ;D
Anyway I now have a bundle that you're welcome to try. I don't want to post it publicly yet until they've been "beta"'d by at least one person - and you seem to have volunteered yourself :D. Drop me a PM with how I can get them to you (a 1.5 Meg zip) and we'll take it from there.
Cheers
Ian
-
Pm sent, email included, guinea pig waiting! ;D
-
IAN, if you need another tester let me know. I would be happy to help out and take it around the block a time or two. (;-) TP
-
Hi TP, No problem - as I said to Mike, drop me a PM with how I can get them to you (a 1.5 Meg zip) and we'll take it from there.
BTW Mike I took the .zip extension off and mail hasn't bounced it this time so hopefully you have it by now.
Cheers
Ian
-
Ok you guys should both have a copy by now - let me know how you get on.
cheers
Ian
-
Hi Ian,
I just got back from the shop from loading the program on the shop pc. I followed your readme.txt so now do I just run the gcode?
Mike
ps I had to come home for a while....frustration with not having the correct tool to try to do a simple job and my cnc machine is not equiped with a good holding system, i.e. vise! >:(
-
(;-) THat is what you get for being just a SAWDUSTand pink foam slinger(;-) TP
-
I feel the salt in the wound! Man you are cold! I'm redrawing them right now to get some new dimensions so I can do it on the table saw! How embarrassing ;D
Terry have you tried the new routine of stirling's? Do you run the gcode like with your array to get it to start?
Mike
-
Mikey just picking on YA. (;-) The wife is after me to get HER a sawdust slinger up and running. SO I guess I will SOON havta join the ranks and become a sawdust slinger myself.
I will havta rely on you for some help then. I dont do 3d as a habit. I hope you are well versed on software to do the points cloud convertion thingy(;-)
SHE also said that ART had best get on the ball with his Laser scanner as SHE was NOT going to wait all day for some points to process. Talk about a TASK MASTER (;-)
(;-) TP
-
Woah.....you need to signe her up on the forums and let her coax Art and Brian! ;D ;D ;D
hey anything I can do to help. I use Rhino for my point clouds, but I'm not much of a modeler!
Mike
-
Hi Mike - this could get frustrating what with the time difference...
You could just run the g-code but it'd be better to run the app from your start menu first. By default all the settings are in mm so you might get a few surprises - like a feedrate of 3000 for instance. :o So....
Run the app, set up your choice of params, run probe25D.tap. The probe will move to startX,startY at a height of safeZ then drop to probe@Z and then travel Y+ve till it hits your edge, it'll then wander round the edge putting points in your triple file. Note that you need to move/delete/rename the triple file each run because it's appended to - not re-written. BTW double-clicking on a file text box will bring up the open/save dialogs. Must write some destructions for it all ;D
Also - could you send Terry a copy of the zip - I'm having trouble getting it through...
-
TP - Re: your g4p0 trick - is that for use in VB as in after a "code G31..." or in a .tap or both? I tried it in a .tap and no difference.
G1 Z10
G1 X10 Y10
G31 Z0
G4 P0
Still crashed down to zero even though the object probed was at Z5 - strangely it records the point correctly - just doesn't ****ing stop! and crunch AGAIN!
So can you actually run a bed o nails routine and have it work ok? - I've never got one to work properly yet!... whether I use Art's wizard or Art and Brian's plugin. every time - crunch - I've tried versions of Mach from 1.84 to 2.6. - all the same.
-
Hi stirling,
No problem sending the file to TP. I will do that in a few minutes. Ok I know I'm going to look stupid, but I have before and will again! ;D How do I run the app from the start menu? How do I load it in Mach or rather call it so that it appears?
Mike
-
Hi Mike - yeah sorry didn't explain things too well. I'm assuming you've:
1) renamed the file I sent as probe.zip
2) unzipped it
3) run setup.exe
4) copied the gcode file and the macro as instructed
now please have a look at the attached (word) doc.
-
Ahhhhh........I had not installed the exe file correctly. It will be a little while before I can get to the shop to test, but I will run a test sometime today and get back with you. Thanks for your help, and I will get this to Terry. He will be able to wring it out better and quicker than I! ;D
Mike
-
Ian now try adding in a delay G4 P1. First set your config page for G4 to be MSec not secs. I had to adjust what it took in delay time for it to work correctly. Processor depend I believe.
It is used in both G31 and CODE"g31" I have seen where MACH will skip over code intructions IF it gets tied up to the point that the instruction overran the available cycle time and MACH was forced to continue. AND when it did, it was an instruction or two down the road and would miss some things.
In you case and mine , Mach was so busy trying to get the trip point data and record it to the file that it missed the STOP and retract instruction occasionaly . CRASH goes the tip.
SOme say that could not happen but in my case the G4 P1 solved the problem(;-) I have since probed thousands of cycles without mishap.
Just a thought, WHat processor and speed is YOUR computer??
(;-) TP
-
Terry, just tried it with a few delays and thus far no luck - I'll try some more experimenting tomorrow. BUT - how's this for wierd?
I just noticed that it fails to work in a pattern. I went back to Art's wizard and set it to probe 100mm in the X and 50mm in the Y with a stepover of 5mm. It turns out that whenever X is 0 or 5 or between 95 and 175 it works fine, any other value of X i.e. between 10-90 and 180-200 and it doesn't. i.e. it fails in "stripes" in the Y direction. Regular as clockwork ???
Tomorrow I'm going to probe my whole table and I'm betting it spells something out - like playing a sabbath album backwards ;D
-
IAN it probably spells out GOTCHA(;-) That is weird. BUT I did notice it failed in a pattern, it would cycle for number of cycles and error, cycle for about the same number of cycles and error so a skip pattern could occurr.
(;-) TP
-
couple of updates: Couldn't seem to get anywhere Terry with the delays. But I've found another way of getting round the problem. If I make sure that probing is started on integer X and Y and stepover is integer then it seems quite happy. Of course this is only really practical if you're in mm. If I make the machine coords the same as work offsets then it's even more likely to succeed - ??? ??? ???.
Did a probe of a good chunk of my table with Art's wizard and sure enough same old same old - failed in stripes in both X and Y - looks a bit like tartan!!!! That's how I came to figure out the integer bit - set everything to integer boundaries with no work offsets and it works every time!!!!
I've also added a bounded 3D probe vid to the web page for your entertainment ;D http://www.razordance.co.uk/probe25D.htm
How's the software going? - got it probing yet?
Ian
-
Wow.....stirling,
This is what I've been waiting for, and the neat thing is, I think Terry is nearly there as well using a completely different method. Do you have any idea how many hours this will save me when I digitize a rifle stock that is 34 inches long, with all the different contours looking at the side profile???? Do you? Thank you so much for your work on this.
Sorry I haven't been able to test the last two day. Yesterday was a US holiday and today my daughters needed me to baby sit! What a dad!
Mike
-
Sterling,
I have been lurking on this thread, very interesting.
I have just finished up my new probe and wanted to give it a good work out, but the existing stuff in mach seems pretty limited.
Can I try your probing routine?
Thanks Arnie
-
Hi Arnie - Happy to have you onboard.
The utility is now available to download at
http://www.razordance.co.uk/downloads/probe.zip
and instalation and operating instructions to download are at
http://www.razordance.co.uk/downloads/readme.doc (a word document)
If you don't have MS Word then a copy of the readme is online at
http://www.razordance.co.uk/probereadme.htm
Cheers ;D
Ian
-
Ian just a note about Open Office which is an open source project. I used it to open your doc just fine. Have you added all the goodies that go with the software where it probes the inside of the profile?
That video was so cool. I had to take a break from my testing to get some actual work done but I hope to take at least one day next week to test everything. I will let you know how it goes.
Mike
-
Ian just a note about Open Office which is an open source project. I used it to open your doc just fine. Have you added all the goodies that go with the software where it probes the inside of the profile?
Hi Mike - yes it's all there in the download - it'll do all you see on the vids.
That video was so cool. I had to take a break from my testing to get some actual work done but I hope to take at least one day next week to test everything. I will let you know how it goes.
Great - any help needed just let me know.
Cheers
Ian
-
I certainly looks good
I wish I could use it.
I get Error on linne 65 <G31FIX> when I try to run the probe25.tap
Same thing when I try to regen to toolpath.
I tried clearing the workoffsets and even had G4P1000
So it won't even run
Is this something the Mach3 Gurus are lookinng at?
-
Hi looker1
I'm assuming you've installed everything as per the readme and noted the bit about this error in the hints n tips bit at the end of the readme. If you aknowlege the error and just carry on as directed in the readme, does it still not work then? Regarding the regen of the toolpath, this is not really neccessary or particularly meaningful as there isn't really a toolpath to regenerate. The toolpath is calculated on the fly as probe25D.tap is running.
In short just acknowlege (or ignore) the error and run probe25D.tap anyway. Also I'm assuming you've run the probe utilities application on your start menu first to set up the parameters of your choice for probe25D.tap?
Incidentally please be aware that this is not an Artsoft application - the only "guru" involved is me ;D
Get back to me and we'll get it going step by step if you need me - but like I say - please read the whole readme first if you haven't already.
Cheers
Ian (Stirling)
-
Hi looker1
I'm assuming you've installed everything as per the readme and noted the bit about this error in the hints n tips bit at the end of the readme. If you aknowlege the error and just carry on as directed in the readme, does it still not work then? Regarding the regen of the toolpath, this is not really neccessary or particularly meaningful as there isn't really a toolpath to regenerate. The toolpath is calculated on the fly as probe25D.tap is running.
In short just acknowlege (or ignore) the error and run probe25D.tap anyway. Also I'm assuming you've run the probe utilities application on your start menu first to set up the parameters of your choice for probe25D.tap?
Incidentally please be aware that this is not an Artsoft application - the only "guru" involved is me ;D
Get back to me and we'll get it going step by step if you need me - but like I say - please read the whole readme first if you haven't already.
Cheers
Ian (Stirling)
Ian, you are still a guru regardless! ;D
Mike
-
Cheers Mike ;D - how's things going with you? - done any probing yet?
Hey Terry - how about you?
-
Hi Ian,
No not yet. I had a good size job I was cutting Sat using mdf and I don't know if it was the dust or just my router motor being old but I blew the router motor up. I have it off the machine now ready to take it to the shop to get a bearing taken out and am hoping it is just bearings.
Have you ever met Mr. Murphy personally? >:( I know him all too well.
Speaking of Terry, I haven't seen him here, Yahoo or the Zone in several days. I hope everything is ok with him.
Mike
-
Hi looker1
I'm assuming you've installed everything as per the readme and noted the bit about this error in the hints n tips bit at the end of the readme. If you aknowlege the error and just carry on as directed in the readme, does it still not work then? Regarding the regen of the toolpath, this is not really neccessary or particularly meaningful as there isn't really a toolpath to regenerate. The toolpath is calculated on the fly as probe25D.tap is running.
In short just acknowlege (or ignore) the error and run probe25D.tap anyway. Also I'm assuming you've run the probe utilities application on your start menu first to set up the parameters of your choice for probe25D.tap?
Incidentally please be aware that this is not an Artsoft application - the only "guru" involved is me ;D
Get back to me and we'll get it going step by step if you need me - but like I say - please read the whole readme first if you haven't already.
Cheers
Ian (Stirling)
I have followed the first half of the paragraph the starts " Errors: I haven't added as..." The "too many nests" error doesn't occur.
I configure probe25d.tap in the utility.
I'm working in E:\mach3\gcode, so have M90000.m1s in the right place, ditto for probe25d.tap.
when I start to probe, the probe moves the start position, them moves in a small, erronious, square pattern for about 8 moves, then I get the error "error on line 65" in the file m5.m1s
-
OK - you're nearly there. The little square dance is what it does when it loses the edge. (In the future this will/may form the basis of a "re-find lost edge" routine). Ignore the G31Fix error - I have no idea why M5 should raise this as an error - but it doesn't matter.
It loses the edge more often than not (but not exclusively) because "backoff" is set too high. If you have it set at the default (75%) then try dropping it to 50%. Also obviously I don't know what you have set stepover to be, but until you get it all working I'd recommend setting stepover to no less than approx 1/4inch (6mm) - the smaller the stepover - the more sensitive all the settings become - around 5 to 6mm is a good place to start untill you get the hang.
-
Does anyone know if working off of the ( E ) drive will still affect certain things in/related to Mach?
Brett
-
OK - you're nearly there. The little square dance is what it does when it loses the edge. (In the future this will/may form the basis of a "re-find lost edge" routine). Ignore the G31Fix error - I have no idea why M5 should raise this as an error - but it doesn't matter.
It loses the edge more often than not (but not exclusively) because "backoff" is set too high. If you have it set at the default (75%) then try dropping it to 50%. Also obviously I don't know what you have set stepover to be, but until you get it all working I'd recommend setting stepover to no less than approx 1/4inch (6mm) - the smaller the stepover - the more sensitive all the settings become - around 5 to 6mm is a good place to start untill you get the hang.
I'll reduce the backoff and increase the stepover, I'll give it a try when the current run is completed.
-
I successfully use mach3 off the E drive. It seems seems that Stirlings routine can be made to work off the E also, just follow his instructiuons.
-
By the by, stirling, can the object being probed be bigger than the X&Y travel of my machine?
-
By the by, stirling, can the object being probed be bigger than the X&Y travel of my machine?
Not sure I'm with you there looker1, can you expand a little?
-
Not sure I'm with you there looker1, can you expand a little?
Lets say for example my X&Y travel is 2" x 2"
Now lets say my wierdly shaped object has a footprint of 6" x 6".
I manage to shoehorn it on my table, with parts overhanging the edge of the table. BUT with some empty space within the 2" x 2" work area.
Can your routine deal with not being able to go completely around the probed item?
If so how would you characterize the efficiency compared to a standard bed-of-nails run?
-
That, as they say, is a very good question. I'm intrigued as to what you have in mind. Maybe you have a feature for the ? ? ? tab.
The answers: Currently my 2.5D probing routine will not cope with not being able to go all around the object. Why? because it wasn't designed to do that and it will hit limits, soft hard or physical.
Re: the efficiency of my 3D routine: The less rectangular the object, the more efficient it is over a "standard" bed o nails routine. I'm thinking there's probably a nice mathematical equation for calculating the actual efficiency and it might be based on something like this: Calculate the area of the rectangular bounding box of the object. Calculate the actual area of the object. Divide the former by the latter giving a measure of efficiency. Obviously the more real estate that is NOT probed by mine but that IS probed by the standard, then the more efficient mine is.
Hope this helps.
Ian
-
That, as they say, is a very good question. I'm intrigued as to what you have in mind. Maybe you have a feature for the ? ? ? tab.
The answers: Currently my 2.5D probing routine will not cope with not being able to go all around the object. Why? because it wasn't designed to do that and it will hit limits, soft hard or physical.
Re: the efficiency of my 3D routine: The less rectangular the object, the more efficient it is over a "standard" bed o nails routine. I'm thinking there's probably a nice mathematical equation for calculating the actual efficiency and it might be based on something like this: Calculate the area of the rectangular bounding box of the object. Calculate the actual area of the object. Divide the former by the latter giving a measure of efficiency. Obviously the more real estate that is NOT probed by mine but that IS probed by the standard, then the more efficient mine is.
Hope this helps.
Ian
Well then I think that I won't be able to use your routine for the monent because my object is larger than my table.
I'll keep an eye on it though for smaller projects I may have.
-
All may not be lost yet. From what I can tell your interest is in the 3D probing rather than 2.5D and you'd just (ideally) use the 2.5D to produce the boundary for the 3D probing routine - is that correct?
If so, then you don't HAVE to use the 2.5D routine to create the boundary. You can create that by any number of means, even by hand and feed it into the 3D routine. Check out the attached image and you'll see what I mean. This shows a table with the object (the rough star shape) to be (3D) probed overlapping the table. The small circles show the points (at some arbitrary stepover) that need to be probed and of course the small crosses represent wasted probing in standard routines. The arrows show the points that you could enter into the triplet file by hand, in this case 17 of them. Depending on your amount of "waste" space and the complexity of your object you may find it worthwhile to try this approach. Remember your boundary profile doesn't have to be hugely accurate to cut down dramatically on the waste probing. This example has a saving of nearly 40% over standard routines (crosses / (crosses + circles) * 100)
-
All may not be lost yet. From what I can tell your interest is in the 3D probing rather than 2.5D and you'd just (ideally) use the 2.5D to produce the boundary for the 3D probing routine - is that correct?
If so, then you don't HAVE to use the 2.5D routine to create the boundary. You can create that by any number of means, even by hand and feed it into the 3D routine. Check out the attached image and you'll see what I mean. This shows a table with the object (the rough star shape) to be (3D) probed overlapping the table. The small circles show the points (at some arbitrary stepover) that need to be probed and of course the small crosses represent wasted probing in standard routines. The arrows show the points that you could enter into the triplet file by hand, in this case 17 of them. Depending on your amount of "waste" space and the complexity of your object you may find it worthwhile to try this approach. Remember your boundary profile doesn't have to be hugely accurate to cut down dramatically on the waste probing. This example has a saving of nearly 40% over standard routines (crosses / (crosses + circles) * 100)
This is what I meant, thanks.
I'll look into in depth over the weekend, thanks
Two questions in the mean time:
The triplet points, are they the exact object boundary or boundary offset by probe radius?
how precise do the triplet point have to be(within backoff)?
as for efficiency there is another point. Compared to the 3D pluggin: the pluggin reduces the stepover of one direction in relation to the ratio of the size of the individual values for X and Y probing area. So the time increases in proporion to the ratio of the probing area.
-
If so, then you don't HAVE to use the 2.5D routine to create the boundary. You can create that by any number of means, even by hand and feed it into the 3D routine.
...minor glitch, the X&Y values in probe3d.tap have been all rounded to integer vaues. This makes me conflict with softlimits.
I have tried saving probe25d.csv as *.rtf and *.txt but still no good.
Any advice?
-
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.
-
Bang head on keyboard... Thanks
The triplet points, are they the exact object boundary or boundary offset by probe radius?
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)
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.
-
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 ;D
-
Hope this helps - keep it coming - we will get your mystical object probed yet ;D
Cheers, ....off to probe.
BTW, this thing that you made that I'm using, does it have a name, have I missed something?
-
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.
- I would feel more comfortable if the horizontal moves were G31 instead of G00 even though the moves are at SafeZ height.
- 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.
- 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.
- Otherwise after 20 minutes I have not crunched my probe.
Good work Stirling, thanks
-
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.
-
How about:
RazorProbe
ProbeDance
Stirling Probe
-
........or dancing Stirling! ;D
Ian I am off on a 30 hr round trip drive to deliver some parts I machined and am taking next week off to get some personal stuff done. I will do my best to probe the guitar next week and send you a screen shot!
From the looks of the # of posts, I have some catching up to do!
Mike
-
happy new year to all.
Mike (and anyone else that's giving my probing routines a go) - how's it going - I'm intrigued - so far there's been around 200 downloads but not a whisper of any results. It'd be good to hear some feedback - good preferably but failing that - anything...
Cheers
Ian
-
Ian as for me, I still haven't been able to test due to other "things" getting in the way. Mostly work, but I gotta do that! ;D I hope to get to it soon. In fact I have to get to it soon as the guitar customer wants to get started as soon as I can get ready.
Mike
-
I tried your routines and they actually work. I had to do a little tweaking to get them to work without mach throwing up a few errors but after a little fiddling they actually did work.
A few suggestions I would make would be to have an option to offset the border by a selectable margin. This would enable the probe to get points at the zero plane. Or the border file could be combined with the point cloud to get those points. Also I think a good addition could be making the point cloud a g-code toolpath that Mach could follow to replicate the object just scanned.
Just remember these are opinions from an armchair CNC guy that just started probing this week! I just might not know what I'm talking about! :D
-Corwin
-
I tried your routines and they actually work. I had to do a little tweaking to get them to work without mach throwing up a few errors but after a little fiddling they actually did work.
LOL - pleased to hear it Corwin - that was the idea :D
A few suggestions I would make would be to have an option to offset the border by a selectable margin. This would enable the probe to get points at the zero plane. Or the border file could be combined with the point cloud to get those points.
Good point - I toyed around for quite a while with that thought but in the end I decided it actually didn't gain anything (I think anyway): For the points file to be of any use at all, you have to have CAD/CAM software that will load it as a point cloud and then be able to produce a 3D model from that cloud and ultimately create a toolpath from that 3D model. If you have the software to do that then telling it that the model's boundary is at the zero plane is trivial (usually a function of the "drape" option or whatever. These zero values are therefore redundant in the original points file.
Also I think a good addition could be making the point cloud a g-code toolpath that Mach could follow to replicate the object just scanned.
Absolutely right - but this is not trivial. If it could do this then the software would be moving well into the realms of CAM which it was never intended to be. I suppose it would be fairly trivial to create the gcode for a "bed o nails" type machining option but I don't think that would really be very satisfactory.
Just remember these are opinions from an armchair CNC guy that just started probing this week! I just might not know what I'm talking about! :D
-Corwin
Hey Corin - I really appreciate your comments - around 300 downloads and you're the first one to comment in a donkey's age. ;D
-
Hi,
I need to know how you obtain that surface in Rhino from points? I try point cloud but I failed. So,...
TIA
Gabi
-
Hi gabi
It depends on whether you have Rhino3 or 4. If you have R4 I'm told this http://en.wiki.mcneel.com/default.aspx/McNeel/PointsetReconstruction.html works pretty well though because I only have R3 I can't use this or comment on it.
The way I did it in R3 (bound to be other ways too) is to use the drape command. Unfortunately you can't drape points. So the way I chose to do it was to convert the points into small planes - which you CAN drape.
So, using the replace command in any decent text editor convert each point into a plane i.e. 26.00000,11.00000,0.12800 becomes _plane 26.00000,11.00000,0.12800 2 2 i.e. all your points become 2x2 planes, then just run the file as a command script in Rhino with "tools/commands/read from file" and it will create a "plane cloud". Then you just drape it. Voila.
A tip is to put _SetRedrawOff at the beginning of the command file and then _SetRedrawOn at the end - otherwise you'll need to go for a long walk whilst it's doing its thang. Hope this helps.
Cheers
Ian
-
Hi Ian,
Many thanks.
Regards
Gabi
-
Hi Stirling( Ian), Been away from probing for a short while. How is your probing solution coming along?? Sounds very interesting. I will try to make time to test it this week. My probing arrays have worked out fairly well they are simple but effective. Might need you to help me clean them up a bit code wise, I am a terrible programmer(;-).
Can it do an inside profile as well? It would make an excellant program to scan the combustion chamber of a race engine head(;-) or the port areas.
Can it do layering down into a void like a combustion chamber layering the shape as it goes down. Then when it reaches the bottom in could convert to a 3d probe of the floor???
Just to let you know there is a probe tip compensation in MACH now. It will add the tip comp to the output VAR and send it to the save file.
You can turn it off by setting the tipcomp to zero.
Just a thought, (;-) TP
-
Hi Terry - welcome back :)
I released the routines in the hope that they would be useful and that as feedback came in I'd tweak and improve them if the demand was sufficient. Unfortunately apart from one or two I can't say there's been much feedback at all though there has been around 400 downloads so far. So maybe they're doing exactly what people want or maybe they're not - I don't know.
Yes, they can do inside profiles as well as outside. As far as layering - good idea - yes they can do that as well, though at the moment you'd have to do a separate pass for each z level or layer. That would be a relatively easy addition to make - i.e. to set number of passes and stepdown per pass.
When you get to test them let me know how you get on - I may resurrect the project - as ever, depends on time and interest really.
Cheers
Ian
-
IAN that is always how projects work. You put it out there and it may seems like decades before anyone responds, but at some point they figure out just how usefull your routine is and you will get flooded with responces.
Keep up the good work. By the way have you ever programed any hot swap tool changer routines in mach?
(;-) TP
-
Cheers Terry
Can't say I've done anything with toolchangers at all.
Ian
-
I've been looking at your Probing Utility and using it with the SmoothStepper. It appears to work very very well. Thank you for your efforts with this.
Just wanted to say thanks, and if I don't manage to crunch my probe first, I'll post some results. :-) I am using the TP-100.
Once you get the hang of it, this method of probing "within the lines" makes much more sense than the traditional square probing. I've been desperately seeking a faster method of probing and this may just do the trick.
You are correct how important the Accel settings are, they cannot be underestimated (in the context of Decel anyway).
Would you consider posting it on www.cnc4free.org? I have no affiliation with the site, but it may get more "air time" there.... just a thought.
Rich.
-
Hi,
I was wondering if someone could help.
I've installed the software but when I run the Gcode to do the edge finding I get the error:
cannot do G1 with zero feed rate on line #6
Does anyone know what I am doing wrong?
TIA
-
I'm also stuck. I re-read every post in this thread, and gone over the readme several times.
When I load the probe25D.tap, I immediately get an error "Lost the edge. Carefully jog nearer the edge and press Cycle Start". The odd thing is that I have not pressed Cycle Start yet. Mach is in the middle of doing path generation and I have not actually run the script yet. I cancel the path generation, but still cannot run the script. It displays the same "Lost edge" dialog every time.
I've tried playing with the values, but different values seem to have no effect. I can see in the macro source code that this error happens when the G31fix routine returns a status of 2, but I don't know the internals of that routine, or why it's returning the error.
Thanks,
Steve
-
pilotjunky - thanks for the feedback - hope you get some good results. I'll take a look at cnc4free. Thanks.
markhammill - Have you successfully installed and run Start Menu / All Programs / Probe Utilities/ ProbeCtrl which apart from other things provides init values for probe25D.tap. The reason for your error is that there appears from what you say to be no values in the Mach vars - you can check this out via the Mach menu Operator / Gcode var monitor.
stevespo - Looks to me like the macros are being run at startup - and they shouldn't be. As you know - when you load a gcode file into Mach, it is processed to calculate the path. Often however it's desirable to NOT have Mach run macros during this phase. A way to achieve this is to set the checkbox in Config / general config / ignore M calls while loading. Another way is to build into the macro the test "isLoading". I've chosen to use the latter with the intention of making things easier for the user which certainly used to work fine. I'm wondering if something's changed in Mach and "isLoading" is maybe not working - but that's just a guess at the moment. Try setting the "ignore M calls" checkbox to see if that helps.
-
HIYA Stirling, YEP There seems to be some strange things with probing in the later versions of MACH (;-(
Just a thought (;-) TP
-
Thanks for the pointer! I will give that a try as soon as I finish today's jobs. I'm running Mach v3.042.020 - which was downloaded/installed just a few weeks ago, so it should be the latest and greatest.
Steve
-
Well, not running the macros got me a little farther. When the .tap program loaded, I got an error:
Cannot do G1 with zero level feedrate
I thought that was strange, so I edited the .tap and inserted F#1001 after the G01 instructions. When I hit cycle start, the probe dropped down to Z=0, rather than .025" - so I realized it wasn't picking up the values from the config program.
I re-ran the config program, checked the registry (all values correct) and hit cycle start again. Sure enough, the probe moved down to Z=0 and then I got the "Cannot do g1" error once more.
So, unless I have something misconfigured, there is definitely a problem with the newer version of Mach and the probing macros/routines.
Thanks very much,
Steve
-
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.
-
Ian, I'll give the new macro a try over the weekend. Thanks for the help.
Steve
-
Stirling,
I've managed to load the probing utilities, but Im stuck with not being able to configure for inches. I don't know what values the various configuration tabs are looking for. I'm running a Bridgeport Series I CNC, that has an effective cutting area of 15" Y, 18" X and about 5" Z. The controls are Gecko 203's through a Bob Campbell breakout board. Can you, or another user, give me direction to configure the software. My probe from Arnie Minear, will be here in a few days.
Thanks,
Marv Frankel
Los Angeles
-
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 ;D)
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
-
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.
-
HIYA IAN, Glad to hear from you(;-). Question for you I am trying to wrap my head around figuring a way to create a 3d probe grid from a 2d points shape file(points file).
I see you have done this. Is it a secret process or something that can be shared.
I work with probing cylinder head ports and this may be handy to do the port FLOOR at the same time I do the port. Also would be handy to do the combustion chamber. Probing thin air gets old after a while and waste a lot of time.
Thanks (;-) TP
-
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
-
Oh yea I tried it(;-) What I need to do is be able to take MY points file and use YOUR software to create the 3d probe grid.
I work with probing cylinder ports on engines. I can generate the perimeter shape up and down the port wall just fine buit I needed a way to convert the 2d shapefile into a 3d grid type routine for doing the FLOOR of the port. Down inside of the port(think of it as a cylinder with variable shaped walls that may be 3-4"tall) there is NO extra room so it is imperitive that I keep the probe INSIDE of the shape of the cylinder.
Clear as mud ? (;-) TP
-
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
-
Stirling,
I'm finally getting to try out the probe I got from Arnie, but I need help. I'm somewhat "CNC challenged", and can't complete the probing routine configuration. Is there somewhere I can find instructions, tab by tab, to complete the configuration?
Marv Frankel
Los Angeles
-
Marv
Have you downloaded the latest version and the readme? http://www.razordance.co.uk/probe25D.htm (http://www.razordance.co.uk/probe25D.htm)
If you can tell me your specific problem i.e. how far have you got. I'll try to help.
Cheers
Ian
-
Hi Ian
Want to you inform that I have published on Youtube a video with the use of your program.
At the end of the second part I have inserted the link to your site.
These is the link to Youtube:
1 of 2) http://www.youtube.com/watch?v=n3QanVLmQRw
2 of 2) http://www.youtube.com/watch?v=JMNzBlZg6o8
Videoes have the explanations in Italian but this there is no problem about seen that the images speak by it self.
Thank you very much for your beautiful software.
Andrea
-
Hi Andrea
Great videos. Glad you like the software and it's doing what you want. Thanks for letting me know.
Cheers
Ian
-
Copied from VB and the development of Wizards as it's probably better if we keep it here.
HIYA Stirling, question ,there is a fellow doing probing of an engine intake ports. Can your crawler routine probe the inside of a 3d object such as a port?
HIYA Stirling, question ,there is a fellow doing probing of an engine intake ports. Can your crawler routine probe the inside of a 3d object such as a port?
Hi - It's basically a bed o' nails with the added benefit of only probing inside a prescribed boundary. As you know a standard or dumb bed o nails only probes inside a defined rectangle which can mean it spends an inordinate amount of time probing useless space. All I can sugest is your fellow gives it a whirl. Don't know if you've seen it but there's an Italian company in this thread www.machsupport.com/forum/index.php/topic,4352.msg97649.html#msg97649 (http://www.machsupport.com/forum/index.php/topic,4352.msg97649.html#msg97649) that has a couple of nice vids on their site and youtube of the routines in action.
Let me know how you get on.
Cheers
Ian
HUM there is really nothing to probe in the Z axis just a big hole. The area to probe would be in the X/Y directions and step down in z as it goes deeper into the port.
Your crawler routine works great but I don't think it will work in this application unless it could be modified to crawl the perimeter from the inside out then step down.
(;-) There IS a market for a PORT probing routine to do this IF you are interested.
I have seen your routine do the combustion chambers of the head, that IS a perimeter and bed of nails type of probing solution
Thansk
Thanks for the suggestion - sounds good and I WILL do it soon as I get some time. But you could kludge it at the moment by just resetting the Z level on the perimeter routine and re-probing each level. Because the triplet file is appended to, you'd get what you want in the end. Not ideal I accept but...
Cheers
Ian
-
That would take a while(;-) as each step is .010" and the port is from 2-3" deep.
-
can you do me a rough sketch of the cross section of a port? Also do you use a probe tip that's in some way different to a "conventional" tip? At the moment I don't undertand why coming at the port sideways as it were will give different results from coming at it vertically. A touch is a touch regardless of what direction the probe was travelling previously. I'm sure you're right but I'm just trying to get my head round the problem.
-
Picture a piece of 2" pipe 3" long standing straight up sitting on the table.
We start from the top of the pipe and probe to find the center of the pipe then move to the center and probe down .010" then move over to probe the wall of the pipe all the way around. then move down .010" and do it again. Keep going down until you get to the bottom OR a stop point.
There is NOTHING for the probe to touch going straight down(vertical) UNTIL you get to the bottom and touch the table(;-)
We then take the points and take them into a 3D cam to create a 3d shape file that can be cut.
Hope that helps
-
Here is a diagram of the port
-
OK - got it - the crux is that you have overhang or undercut - whichever, which is why I asked if you used a probe with a "special" tip - i.e. one that can *reach* into the undercut without the shaft fouling. I understand your analogy with the pipe but clearly if the sides were *truely* vertical then there'd be no need to probe in multiple Z levels - they'd all be the same ;)
As I've said I will sort this asap but meanwhile I'll take a look at the routines and see if there's a quick kludge for you as I'm a bit strapped for time at the mo.
Cheers
Ian
-
The Pipe was just an example that I could decribe(;-)
The port is probed with a .375" ball on the end of a long probe shaft or sometimes a flat disk on the long shaft. The tip used depends on the port itself. You have to use a tip smaller than the smallest radius. Using a 4th axis machine sometimes you may have to index the port several times to get all the port scanned.
THERE is no hurry take your time.
In reality the top end of the port is probed based in the centerline and then the head is indexed over to the other end and it is probed on the centerline as well. Then in the drawing the ends are aligned with the centerline. then the shape is converted to a cut file.
The head to be cut is then put into the fixture and indexed into position to cut.
-
Hello,
I tried your Program on my router, but I can't get it to work:
When I run my created probe25d.tap file, I have an Y move until my probe touch, an X move, and always a mistake msgbox :"type mismatch"
The history file in Mach3 say: Error in line 44 :internal error <G31Fix>.
I can't find what I am doing wrong.
Have anyone an Idea?
Thanks
Denis
-
Hi Denis
When you say...
When I run my created probe25d.tap file
I'm a tad confused. You don't create probe25D.tap. It's already created for you as part of the package and should NOT be changed. Before we go any further can you just confirm you're running the unchanged file please.
Cheers
Ian
-
Hi Ian,
Thanks for the fast reply.
That's right, the file I run is the file I copy from your website to my folder (c:Mach3\Gcodes\). I didn't create a new one, or change anything in it.
I just thought that something was changing in this file when I click on "configure 2.5D probing routine".
Another thing : Do I need a soft for the csv file (Excel?)
Cheers,
Denis
-
I just thought that something was changing in this file when I click on "configure 2.5D probing routine".
No the file never changes. The configuration part just puts values in the registry which are picked up by G31Init in the macro which places those values in the gcode vars for probe25D.tap to pick up.
Another thing : Do I need a soft for the csv file (Excel?)
Not really, the .csv is used by the other functions in the software e.g. the 3D probing routine or the routine that creates the gcode to reproduce the perimeter you probed. That said you can look at it and make whatever other use of it you want. It's just a text file. The reason it probably has an Excel icon is that by default if you have excel it "grabs" the association.
Back to your OP...
I have an Y move until my probe touch, an X move, and always a mistake msgbox :"type mismatch"
The history file in Mach3 say: Error in line 44 :internal error <G31Fix>.
This has me stumped at the moment - I've never seen this error before nor has anyone else ever reported it.
All I can suggest at the moment is to increase your debounce, as the usual cause of strange errors is "indistinct" touches. Also until you get it behaving you could try a larger stepover. i.e. work on the basis of trying to get good solid switching of your probe at first.
Cheers
Ian
-
Hi Ian,
I tried yesterday with a large stepover (10mm) and 50% backoff. I had 3 moves, and after a msgbox "lose the edge".After jogging near the edge, i have a "type mismatch" error.
Until yet, I try only to make a test with a small rectangular piece (40mm x50mm)."Start X" is 0, and "Start Y" is 10, so I can hit the piece at the first Y move (after Probe initialisation).
I run with smoothstepper, so I tried to increase the time for the probe input, to be sure to have a solid signal, but nothing change. I have no problems with Mach when I type a G31 routine.
As you can see, my english is a little bit poor, what do you mean about "debounce"?
Cheers,
Denis
-
Hi Denis - I can see no reason for a "type mismatch" error at the moment and have never had it reported before. I'm going to have to do some close checking of the code and get back to you asap (bit busy at the moment though so it may be a while).
If you have a parallel port could you try it without the smoothstepper and see what happens?
Debounce is set top right of the config page in mach and has some effect on countering "dirty" switching - try increasing it and see what happens.
Cheers
Ian
-
Hi Ian,
After working on my machine, and retune the parameters, I finally had a triplet file. I think it cames from the "dirty probe signal". Smoothstepper don't like noise, and I haven't try with a parralel port.
But now, I can't have a 3D probing routine, I have an error message : "invalid call or argument".
I tried to have a 2.5 Gcode file, it made me one but it's strange. I've attached both of them ( I renamed the ;csv in .txt). I tried to change the "," between the X,Y and Z coordinates bi a";" but it had no effect.
Cheers
Denis
-
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
-
Hi Ian,
csv files in France (only in France???) are made with comma (x,000, y,0000, z,0000). I changed them to x.000; y.000; z.0000 and I had a triplet file that works .I can now generate a 3D probing file that works in Mach3.
i will make a complete test now, and let you know how it works.
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?
I'm using a french windows XP SP2.
Thanks for your help,
Cheers,
Denis
-
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
-
Hello,
after watching the vidios on youtube i installed the probing routine but can't get it to work
the problem seems to be, the variables are not loaded into the gcode, can you please tell
me what i've done wrong.
many thanks, mick.
-
the problem seems to be, the variables are not loaded into the gcode
Hi mick - Let's check that out first.
I'm assuming you've run start/all programs/probe utilities/probectrl.
put Mach into single block mode and run the first line of probe25D.tap. Using the gcode var monitor in Mach, check the value of var 1001. Is it the feedrate you set in probectrl?
Cheers
Ian
-
Ian
no the value in var 1001 is always 1 no matter what is set, the following are the var's with
any value other than zero.
#1001=1
#1007=10
#1013=10
#1014=1
thanks mick
-
mick - do a search in the registry for PR25D and let me know what you find
Ian
-
Ian,
is this what you mean.
-
not quite - hit f3 and you should get something like the attached under VB and VBA Program Settings (just down a bit on your left pane).
-
Ian,
try this one.
thanks for your time.
-
looks fine mick. So we know the config routine is posting the values to the registry ok but it looks like the probing routine is not pulling them out again.
Have you copied m90000.m1s to the correct folder?
Look bottom right of the main Mach screen and note the profile your using. Now check m90000.m1s is in folder C:\Mach3\macros\"your profile name" (assuming you installed mach in c:\mach3 that is).
Ian
-
yes Ian , m90000.m1s is in c:\mach3\macros\machmill
by the way should i be able to see the values set , in the gcode, because when i single step through the code
when i get to f#1001 the feed rate is loaded.but not visable in #1001=.
mick.
-
yes Ian , m90000.m1s is in c:\mach3\macros\machmill
Just double check that. By default your profile would be mach3mill - not - machmill. You may have changed it of course which is fine.
by the way should i be able to see the values set , in the gcode
No - not in the actual gcode - i.e. you'll not see F#1001 changed to F3000 or whatever. - you have to use the var monitor if you want to check the gcode vars are what they should be.
because when i single step through the code
when i get to f#1001 the feed rate is loaded.but not visable in #1001=.
Then it sounds like it IS loading the gcode vars - sorry you've lost me now - you originally said
the problem seems to be, the variables are not loaded into the gcode
-
Ian ,
yes sorry it is the default mach3mill.
this is what i'm doing,
run probectrl enter values, press config probeing routiine, comes back you can now load gcode.
load probe25.tap
single step to #1001=1, enter 1001 in var moniter and update, value returned 1
step to #1002=0 enter 1002 in var moniter and update, value returned 0
and so on to #1014=1 ,when i reach f#1001 the feed is entered into mach.
thanks mick.
-
single step to #1001=1, enter 1001 in var moniter and update, value returned 1
step to #1002=0 enter 1002 in var moniter and update, value returned 0
Sorry mick - still confused - there isn't any line that says #1001=1 or #1002=2 etc.
the line F#1001 will set your feedrate to whatever you set it in the config app, which you said above, it does i.e. when i get to f#1001 the feed rate is loaded.
..and the line: G00 Z#1002 will move your Z axis to whatever you set safe Z to in the config app. etc. etc.
-
Ian ,
thanks for helping. this is what i see at the start of the gcode.
-
LOL - my apologies mick - You're quite rightly using the latest version and I'm not! OK - so when it's done the line - M90000 P1 it SHOULD have set all the gcode vars to what you specified in the config app. So, what's their values at that point?
Sorry again for the confusion - my memory's worse than I thought!
Ian
-
Ian,
iv'e found the problem. all my fault, the actual profile on the desktop running the mill was mach3
as soon as that was changed to mach3mill ,all is ok.
The laptop i'm on line with also has the correct profile, but is not connected to anything.
anyhow many thanks your guidence, and if can get results anything like the vidios,thanks for a super program.
regards mick.
-
Hi - mick - glad you've got it sorted. It's a shame that Mach doesn't throw an error message when it can't find a macro - that would have cleared this up straight away.
Cheers
Ian
-
Ciao Sono nuovo qui scusate ma il mio Inglese è cattivo userò Google per la traduzione
Ho realizzato la sonda http://www.cncitalia.net/forum/viewtopic.php?f=25&t=19934
in Forum Italiano.
Ho download questo http://www.razordance.co.uk/probe25D.htm
Io ho un problema la conversione da File triplet25D.csv a file gcode25D.tap crea un errore di Punto e virgola in decimali Italiano .. Volevo chiedere se esite una "probing Routine" che funziona per windows versione Italiano... Grazie
Hello I am new here sorry but my English is bad I will use Google Translation
I made the probe http://www.cncitalia.net/forum/viewtopic.php?f=25&t=19934
Forum in Italian.
I download this http://www.razordance.co.uk/probe25D.htm
I have a problem converting from file to file triplet25D.csv gcode25D.tap creates an error in decimal point and comma in Italian .. I wonder if exists a "probing routine" that works for windows version Italian ... Thanks
-
file.csv and file.tap error in Italian
-
Hi grisuzone - welcome to the forum
Hai provato a usare le opzioni di italiano regionale. Pannello di controllo / Opzioni internazionali e della lingua.
In alternativa, è possibile contattare Andrea al http://www.robotfactory.it Ha le routine di lavoro bene.
Have you tried using the Italian regional options. Control panel / Regional and language options.
Alternatively, you could contact Andrea at http://www.robotfactory.it (http://www.robotfactory.it) He has the routines working just fine.
Cheers
Ian
-
Hello and thanks for your kind answer I try to contact Andrea and then I make you to know if I have resolved my problem hello good day
-
This is just to let users of my probing routines know that I've just uploaded a small fix. The edge following routine now does up to 10,000 iterations rather than the previous limit of 998. For those that are interested in the workings, Mach has a limit of around 998 iterations in a gcode subroutine loop. All I've done is add a nested loop with each of the two loops iterating 100 times - hence the 10,000.
Cheers
Ian
-
Any new stuff going on with edge probing?
-
Any new stuff going on with edge probing?
If you are a probe user, you may be interested in the abilities built into the MachStdMill software:
http://www.calypsoventures.com/machstdmill/videos.html
Dave
-
I looked at that, thank you.
I downloaded Stirling's program, but i can't get it working. Probe comes down, moves forward to contact, retracts, moves forward to contact and then stops. I have adjusted speeds and acceleration up and down. I'm not sure what to try next. I think I'm almost there. Help.
EDIT: By Stirling. As I explained in our PM correspondence it clearly states in your controller manual that Ajax handles G31/probing differently from the standard Mach3 way and that's why my routines don't work FOR YOU. It's unlikely that ANY Mach probing routines will work with the Ajax controller UNLESS they're specifically written for it.
Ian
-
I downloaded Stirling's program, but i can't get it working. Probe comes down, moves forward to contact, retracts, moves forward to contact and then stops. I have adjusted speeds and acceleration up and down. I'm not sure what to try next. I think I'm almost there. Help.
-
I have been using the polar array probing program. It runs fine.
-
Marv
Have you downloaded the latest version and the readme? http://www.razordance.co.uk/probe25D.htm (http://www.razordance.co.uk/probe25D.htm)
If you can tell me your specific problem i.e. how far have you got. I'll try to help.
Cheers
Ian
Stirling, where can I get a copy of your probing routine? I'm doing some edge probing experimentation and your Mach probing routine will give me a good starting point. I understand I will be totally responsible for any issues I may have using it.
Thanks. Jeff
-
Stirling Mentioned a while back that he had ideas for a much better 3d process. Hopefully he will bring out the new DELUXE model soon.
(;-) TP
-
Hi Jeff - I've sent you a PM.
Hi Terry - I'm currently working on the DELUXE model which will have some NICE new features - preview coming soon! (I'm also the most part through coding a brand new all singing all dancing screen editor).
Cheers
Ian
-
Ian,
I'm very impressed how good your probing routines work in Mach3. Can't wait for your Deluxe version to come out. Thanks again.
Dave,
I really like your MachStdMill Professional Edition with the probing operations also. Still running the Trial License, but will register it soon.
Jeff
https://www.youtube.com/watch?v=9skopcbhurU
-
Jeff - thanks for the comments and the video - glad it does what you want.
Cheers
Ian
-
Hi there
I have been trying to find where to download this probing software without having any luck could you tell me if it is still available to download anywhere? Please
Many thanks
Alan
-
Hi Jeff - I've sent you a PM.
Hi Terry - I'm currently working on the DELUXE model which will have some NICE new features - preview coming soon! (I'm also the most part through coding a brand new all singing all dancing screen editor).
Cheers
Ian
Any progress on this Stirling?
-
Any progress on this Stirling?
Hopefully soon. I have to get a new batch of THCs out asap as my priority but then I can get back to the probing and the screen editor.
Cheers
Ian
-
Hello i recently install the probe and when i start the code i have a internal error in line 44 g31fix anybody have an idea
tanks you
Serge
-
This software has been withdrawn and is no longer supported.
However this error probably means it's failing to store parameters in the registry, probably the user you installed under doesn't have the required access rights.
-
tanks for you fast reply ,i am only user on this pc and i am admin and it seems that this is what happens to you, it is something to do in order to remedy this problem
tanks
Serge
-
Just because you are logged in as ADMIN does not mean it recognises that IF you open a program. At least not in Vista. I am also single user as admin BUT I have to open MACH# as ADMIN for it to run correctly.
Just a thought, (;-) TP
-
tanks, there is only an account on this pc and it's admin on win xp
Serge
-
Hi Ian,
Is there any way to get a copy of the probe routine? I understand it has issues and am willing to take my chances.
Cheers
Chris
-
Would love to find out how things are going on this. Could really use it for a couple of projects.