Moving from SB to Mach software is it really that easy or good

[Gerald_D]

Over the last couple of months we have used Mach3 (http://www.mechmate.com/Forum/messages/28/581.html) software for the MechMate, our second CNC router. Our original ShopBot is still going along on the DOS version of the software.

Although we still have some things to resolve with the Mach software, we have no doubt that it is the better solution for us. The original ShopBot will also be converted to Mach as soon as I've built a decent control box for it.

The major factors that swung us to Mach are:
1. The metric version is solid. (SB's metric Windows versions didn't work for us and that kept us at DOS)
2. Setting ramp speeds is a once-off, straight forward process.
3. No blown drivers, no mystery z-dives. Okay, these are not essentially software issues, but the SB software tied us to a hardware that might be causing the problem between them. With Mach, we had a choice of hardware - it fits in with the big-boy industry standards, (and you get to start feeling like a CNC-pro http://www.mechmate.com/Forum/clipart/happy.gif)

Anyway, this is not a thread to knock SB, who were great for getting us started in this CNC world, but it is time to move along. My intention with this thread is to find those SB'ers who are using Mach, maybe a little scared to come out of the closet and admit it http://www.mechmate.com/Forum/clipart/happy.gif, and develop our Mach experiences together.

[Gary Beckwith]

Gerald, although I operate under imperial measurement I agree with your short assessment that the Mach software was the next step up in the CNC world for us as well.
As you said this is not to knock SB for I can honestly state we would not be where we are today in the CNC industry if it was not for SB.

For me the Mach software has so much more to offer, I gained stability that I never could get under the Windows version of SB, so I too had to operate under the DOS version which ran very well and remained stable, but the dos programs are pretty much redundant and I doubt if there will be any upgrade with them.

Switching to Mach and the change to g-code was very easy, it took about an hour of playing to get aqainted and we were off and running. Some of the features that I like are:

1. The ability to change the layout of screens including adding DRO funcion buttons and programing them.

2. Real time display of the g-code and toolpath running concurent with the toolhead.

3. Being able to move all 3 axis with the arrow keys at the same time either at a feed rate (move speed) or a rapid jog.

4. Ability to run multiple 0,0 locations on the table (over 250 if needed) as well as the table reference home point.

I'm only a novice with the Mach software but look forward to hands-on learning experience as Art Fenerty(Artsoft- Mach) & Brian Barker (Newfangled Solutions)will be attending & doing a vendor presentation at our Oct 6th & 7th camp

[Gerald_D]

We are having some issues that we we havn't been able to get to work satisfactorily. Maybe it is a setting up issue on our side, but we are starting to think that Mach3 hasn't been fully developed/de-bugged for the metric router users. (We will give the older Mach2 a trial as well).

1. The major issue is the "Feedhold" function:
- The router can move a further 4" (100mm) after pressing the Feedhold button. The SB stops almost instantly. The Mach guys will tell you that they have to "clear memory buffers", but that is their problem, not ours - we want the machine to stop when we say stop. We could learn to live with this issue, if it was not for the next issue ....

- After pressing a Feedhold, the system often refuses to "Resume". The Mach guys again have excuses for this, but that is also their problem, not ours. We want to be able to "Stop/Start" cuts/feeds like we can do with SB. (Note that I am not talking of E-Stops here - an E-stop in Mach3 forces a crash stop that is not recoverable).

2. The second big issue is that Mach does not mathematically join two line segments smoothly together. See these discussions on the Mach forum:
http://groups.yahoo.com/group/mach1mach2cnc/message/57925
http://groups.yahoo.com/group/mach1mach2cnc/message/57933
http://groups.yahoo.com/group/mach1mach2cnc/message/57957
Snag with this issue is that the machine tends to gallop along a supposed smooth path when someone (maybe a client) has drawn that path composed of tiny segments. The "galloping" (subtble, audible speed changes) can set up resonances in the gantries and cars and stops one from using higher speeds with some files. We can draw efficient files, but we don't enjoy cleaning client's files that have exploded splines. Again, the SB was better.

These two issues may be bugs in Mach3 that were not in Mach2. But, I cannot join the chorus of Mach praises until they are resolved.

[Patrick Toomey]

Gerald, is this a problem only with metric setups or is it universal? This would be a show-stopper for me as I pause and resume quite a bit on some of my projects.

[Gerald_D]

I don't know if it is universal, or metric related - it just seems to be something that either people don't want to talk about, or something peculiar in our situation.

Here is my attempt to resolve it at the Mach forum:
http://groups.yahoo.com/group/mach1mach2cnc/message/57631

[Sheldon Dingwall]

Damn, I use a lot of splines.

I've noticed with Rhino/Vector/SB Curves that originated with splines often have jerky movement due to tiny jog moves between curves. I've gotten into the habit of doing a search and replace for J3 moves after posting the tool path.

Is this similar in Mach or is it something completely different?

[Gerald_D]

Sheldon, this is something different...

An example in SB code:
M2,0,0
M2,1,1
M2,2,2
will give two line segments running up at 45 degrees from the 0,0 to the 2,2 point. Running it under SB, we can't hear when the cutter finishes the first segment and then starts the second. Doing this with Mach3 (and the appropriate G-codes), there could be quite a noticeable change in sound as the segments join.

(Sheldon, you should be able to cure that with Vector if you do an "Optimise/Trim/extend" cleanup first)

[Sheldon Dingwall]

Hi Gerald,

Thanks for the example. Is this not a problem in imperial too or just metric?

Also, in my version of Vector (9) there is no Optimize function. There is Change>Trim+extend>chain, but that doesn't have any effect.

[Scott Worden]

Sheldon,

Try setting "Closed Chain" mode before "Trim + Extend" If the segments are on differents planes, they won't trim either.

Could you send me one of those files (dxf before doing anything with it in Vector).

Gerald,

With movements like what you explained there (segments), what happens with v-carving files where there are many short segments (M3's)? Do they flow smoothly or is there hesitation. Although these segments would be much smaller than your in example.

[Gary Beckwith]

Gerald, hitting the freehold button will stop after emptying the buffer as you said, it will also do the same by hitting the space bar, I have never seen a 4" overrun. Now if you want to dead stop like hitting the space bar in SB then you click the stop button (alt S) or the esc key, to restart press the cycle start button and it will continue from where you stopped. My external e-stop button which when pressed will stop my machine, if I reset the e-switch and press the cycle start button it will continue from the stopped position.
If your system is not working in this way I would suspect you have something incorrectly setup and would double check before continued use.

The second point you mentioned re: line segments I have never seen happen and I cut both 2d and 3d files all day long but then again I am not running in metric either. Most of our drawings are produced in cadd with the explode all continious lines on and never have a problem with splines. Would you send me a file that you experience this happening, not only would I like to see if I get the same results running in metric but as Art will be here for the Camp then we can get it direct from the horse's mouth so to speak & see if it's a bug or not.
Incidentally which version of Mach are you runing, is it the lock dowm version or beta?

For those that have never looked at Mach the following link has some excellent video's, I would recommend viewing the one titled "Screens - An Overview" this may clear up any misunderstandings of screen controls.
http://www.machsupport.com/videos.htm

[Gerald_D]

Scott, V-carving under Mach appears to be very similar to SB - it sounds and looks the same. This "galloping" issue does not happen all the time, just with chopped segments of a certain length and frequency that we havn't been able to fully define yet. Bottom line is that Mach says it is to be expected and that it is normal, while we didn't see it in SB, nor in the other big CNC routers working around here.

Gary, a dead stop by hitting Esc is not recoverable - steps are lost/gained when doing this type of crash stop.

On both these issues, Art has stated that this is how Mach is supposed to work, and I have sort of given up on hoping for something better. However, I do accept that our setup may be slightly unusual, and I do appreciate the offers to check some sample files to look at the segmenting. But, the feedhold is becoming the dealbreaker for us.

[Mike John]

Gerald
Just to clarify for those of us who always need the 'Dummy's Guide".
If we are only cutting our own 'home produced' files, we can avoid the 'galloping' problem.
I'm not sure I fully understand the buffer clearing problem. Does this mean that, after hitting stop the computer spends time clearing the buffer then stops?
This doesnt seem a huge problem if its very small providing you can restart from the same spot, but this also seems a problem.

.........Mike (confused again!)

[Gerald_D]

We have more or less decided that we can live with the gallops because it is caused by customer files. We have to turn down the speed when it happens and the customers accept (so far) that a job becomes longer and costs more.

To quote Art Fenerty of Mach: "When you feedhold, the buffer needs to empty before it can ramp down. This is why the 100mm move. Feedhold is not an instant thing, it cant be in a buffered controller." and "IF the interpreter finished a program (and it can be up to 50 lines ahead) then a feedhold may not be able to be restarted. Depends on a lot of factors, and what the Gcode is like at the end of program." A little greek to me as well, but it is clear that this is the way Mach works and that I will be obliged to accept it - or find an alternative to Mach.

[Gary Beckwith]

Gerald, I have not had any of the problems you are experiencing, the freehold button I have no problem with as I expect the ramp down stop.

Mike,
You have the option of clicking the freehold button to stop which will empty the buffer & stop or having a dead cold stop by pressing the red stop button under the freehold button or you could use the Esc key. I continue from these stops all the time with no problems. You can check for lost steps by running the "Verify" button on the MDI screen (screen 2)Make sure you understand what this does before pressing.

I would like to see a file that gives gallops? This is one thing I have never had, yet I run some of the worst files from customers especially the small fast sign shops, some of their dxf files are just terrible and I have never seen this.

The offer stands since Art will be here at my shop, this would be the perfect time to find out if its software related or not.

[Mike John]

Gary, if it empties the buffer (presumably its looking ahead to the next few commands), how does it get back to where yo want to statrt cutting again?
If it had just one command in the buffer to move the X axis 1 metre(39 inches), would it carry out this command before stopping?
I am confused about what is happening.

..........Mike

[Gerald_D]

Gary, I accept and understand that Mach is working for you, but right now it isn't working for us. When I have cleared my backlog after the holiday, I'll make some videos to illustrate the issues.

The stopping distance we are seeing is very much longer than the decel ramp - I see a very much shorter decel ramp when using the cursor control and would be ecstatic if the feedhold could be as fast as that.

[Gary Beckwith]

Mike it doesn't have to go back to find where it left of. When you press the freehold button and watch the g-code display you will see it run a few more lines until the buffer is empty then stops. It remains at the next line of code and is ready to go as soon as you press the start cycle button. It's just like a pause and enter too continue in your file.

Good question about the one line of code, haven't had that scenario but as soon as the file thats cutting now is finished I will try it and get back to you.

[Patrick Toomey]

I'm wondering about Mike's question as well, if it executes the last few lines of code in the buffer that could be huge, what if the last few lines are moving 8ft down the table and then cutting a 3ft diameter circle. That would be a hell of a stop time and all sorts of disasters could occur during that. If this is the case, and there's no other way to stop except a non-restartable e-stop, Mach will never work for me. I'm assuming I must be missing something here.

[Gerald_D]

a. If a moving mass has to be stopped, it needs to decelerate over a distance.

b. If that distance is longer than the distance allowed by one line of code, then it has to run into the next line, and the next, if the lines of code represent distances which are less than the controlled stopping distance.

That is the only reason I will accept for the machine having to stop over a couple of lines of code. "Clearing memory buffers" is something that can be done after the machine has stopped. If they have to be cleared before the machine will stop then that is a shortcoming in the software, IMHO.

[Mike John]

Sorry to appear stupid, but I still dont understand.
Does clearing the buffer mean executing the code in the buffer?

..........Mike

[Gerald_D]

I think that is how some people understand it. But I don't think it is worth pursuing the exact meaning because that is the programmer's territory. When I have set a decel ramp value on the machine, and I tell it to stop, it must stop at the set del rate. If you tell me that my car will only stop when the gas tank is empty, I am going to get another car - I won't argue tank sizes and fuel rates with you! http://www.mechmate.com/Forum/clipart/happy.gif

[Gary Beckwith]

Ok Mike I just ran a file with one line of code g1x80
Approx 30" down the table I clicked the freehold button and it ramped down to stop with about 1/2" of travel. Clicking the recyle go button it continued to the 80" distance.

I may be wrong but if the code in the buffer is not carried out then you would lose steps on start up. I don't know how much is buffered at a time or if this is even the correct terminology either way it works for me, this has been the most stable and best software that I've tried todate.

[Patrick Toomey]

That makes more sense as the other alternative of executing the whole command would have been insane. After doing some digging and more research I think I may have a potential explanation. I don't think they're executing more G Code commands to flush the buffers, I think they're flushing the lower level steps that have already been created and are in the process of being sent to the drives. This would explain Gary's results. It does not however explain Gerald's results of a 4" stop. There must something else going on here, perhaps a buffer size setting, a different controller, a bug in the metric version? Anything else would be wild speculation on my part but I thought I would throw this much out to see if it helps.

[Gerald_D]

Art has just let me know via e-mail that he has found a bug and we will check some files to see if the bug applies in our case.

Mike, g1 x80 means go to x value 80 at move speed.

[Gerald_D]

Before Art's last mail he sent the following (which may shed some light for those that want know these things):

"When feedholding, it isnt only the decel distance that is in effect. All the mach versions buffer up movement as a series of pulses. When you hit feedhold, the buffer must empty because the ramp down is at the end of the buffered pulses. Slower feedrates take longer to stop then faster ones for that reason.

Now the Run command should be able to restart it though, BUT, if the file is near its end, it may sense the feedhold only after it thinks the file is ended. Im pretty sure I stopped that behavious in the latest development version though. Ill run some tests here to see if the feedhold will refuse to restart."

an hour later he said that he did find something funny and has asked me to check some settings back at the shop.

[Gerald_D]

Extracts from the history:

4 July:

Our first report: Used Feedhold about ten times - from remote OEM trigger as well as Space bar. On two occasions the feedhold worked correctly, but then refused to accept a Ctrl-R or remote button "Resume" - we first needed to do a Alt-S Stop and then a re-start. One of those faulty
feedholds was prompted by the space bar, the other from a remote button. Using R1.84.001.

Mach response: Was it near the end of a program? IF the interpreter finished a program (and it can be up to 50 lines ahead) then a feedhold may not be able to be restarted.
Depends on a lot of factors, and what the Gcode is like at the end of program.
Other than that I cant think of anythign that woudl cause that kind of symptom..


11 July:

Example 1 (below) was sent with the note: "The attached file was run six times today. There were 4 or 5 feedholds during each run of the file. For the first 5 runs, the Resumes worked 100%. For the last run of the file, 3 of the feedholds stopped everything dead - the only way to restart was to re-load the file. None of the problematic feedholds were less than 100 steps from the end - the nearest to end was 165 steps."

Mach response: I dont see anythign that shoudl cause that type of loss. I suspect its a question of it the feehold is done in a line, or just happens to happen at the end of a line. Technically, thereis a huge difference between the two possibel stops. Since its unlikely to stop exactly as a line temrinates, it may explain why it occurs. G41 program in particualr may have this happen. Ill schedule a recheck of that code to tighten up that possibel scenario..

In the meantime, try to take note if it happens when a line is doen or if it seem never to happen if a line is stopped mid-line.. It may help me track it down..

Our response: When I was testing the software (reverse run) I managed to get the feed hold stuck during a line cut. After the first pause I could resume straight away as per normal. But if I pause 20mm later during the same line it gets stuck. My guys weren't stopping and starting like this. They would only pause the machine ever so often to shift a clamp.

22 Aug:

Our reminder: We have given up on using "Feedhold" for our CNC router because:
- it takes a long unpredictable distance of cut before it stops (not too serious)
- the crunch issue: a "resume" does not reliably get the machine moving again.

There has been some correspondence on this before (below), and you might find some ShopBotters in Kansas asking about it.

Have you maybe found any bugs on this in the last month?

Mach response: The distance, (which should be equal always to the deceleration distance) I cant do much about, its a technical function of the driver. But I cant find any reason why it wont restart. Is this after moveing away from the feedhold position? Is this from the screen control or only from an external button that it wont continue?

Our response: If the feedhold stopped the system within the deceleration distance, this is perfectly understandable, and totally acceptable, of course. I can judge the deceleration distance from the response to the cursor keys - the feedhold stopping distance is way longer than that (at least 10 times more). I might be able to video it for you if you want.

When we say that the restart often does not work, we mean this even if the restart is the very next function after the feedhold, and with both functions executed from the keyboard. ie. an Alt-R immediately after a Space Bar hangs up the file. Mostly, the only way to get it going again is to re-load the file. As my son says, it happens within a long straight line.

The PC is dedicated to the router, runs under win 2000.

Should I be trying a another PC and Mach2 perhaps?

Mach response: I have found an error in there on feedhold. Im unsure when it crept in, I dont typically use hold. Im tracking it down and will let you know what I find..

An hour later: I found one trouble, I had screwmapping enabled, and it seems to be a bit buggy in the current versions, once turned off though, Im able to feedhold and start again over 100 times with the roadrunner file. I need you to check first that the Screwmaping is off, and then to try it in simulatio with roadrunner, if it runs there, then I need the file that seems to do it to you, all mine seem to feedhold correctly and restart as long as screwmapping is disabled..

The above is the crux of the issue, it is not the full extent of the correspondence.

Today I mailed off the following: Here are a collection of problem files. Our screwmapping appears to be off (maybe verify that with the .xml attached? - I can't see a clear on/off "switch" for screwmapping, other than the default graph being a straight zero line?). I can't get roadrunner to hang up, but it isn't metric. (A gripe with shopbot is that the metric version is a poor cousin of the inch version - maybe something happens when the metric router users have coordinates in the thousands?)

(files in old Forum here (http://www.mechmate.com/Forum/show.cgi?tpc=28&post=748#POST748))

[Gerald_D]

And more today:

Im curious, all your programs are using G41, but I dont see a tool call being used. Are you actually using G41 fucntionallity or is your CAM putting out the G41 even thoguh it isnt used?

We havn't given a moment's thought to the codes used by the CAM program ("Vector" with emc post-processor - CAD is AutoCad). We do all the tool compensations/offsets in AutoCad before using Vector as almost a blackbox dxf to g-code converter.

This could be something to look into........

G41 programs automatically create a limitation in the feedhold code. This is for many technical; reasons in the program, since you already deal with the issue in the cam, removing the G41 lines form the program woudl turn on normal Feedhold capability. Im thinkning this may be the root cause of the problem. Try a couple files with the G41's stripped out, I think youll find, that liek the roadrunner file, you wont be able to easily fool it..

Have looked at some of our other programs and most don't have G41's in them. Let's hope this was the cause of our problems..... (http://www.imsrv.com/cgi-bin/discus/show.cgi?tpc=12&post=1003949#POST1003949)

There are still two other Mach issues that I want to improve, but I plan to make videos of them before I pursue them further:
-1 Slow stop of machine after a feedhold (mine takes about 4" at times while the Ascension guys report 1/2")
-2 "Galloping" when a longish arc or straight line is perfectly chopped into shorter segments.

[Gerald_D]

A note received from Art today:

A lot of work was recently done to the feedhold, reverse and such due to a few shopbotters seeing some issues. The feedhold behaviour is very strong now in 2.0. Version 2.0 is about to lockdown sometime in the next couple weeks, so at that point, I'll advise an upgrade, it should take care of pretty much all your issues, alot of the new runs tests were done on Shopbots to stabalise because I've noticed they seem a bit more tempermental in operation, not the fault of the bot of course, just the mixture of accel and velocity I think. At any rate, there are a lot, and I do mean a lot, of changes specifically designed for shopbots in the latest versions, and the capability of even loading and running Shopbot code will soon be out.

I'm rather glad that other folk also started to see these problems and that solutions are now being sought.

[Mike Richards]

Art seems to be the kind of guy that can't sleep when there's something wrong with his software. I wish all software suppliers had that kind of insomnia. I particually liked the part where he said that it would have "the capability of even loading and running Shopbot code". That will be the final obstacle that I need to cross before making major modifications in my Alpha.

[Robert Cheal]

Does the Mach 3 software require a 3D radius to be splined or is that just a Shopbot thing?

I've had that qustion lingering in my mind for a while.

Thanks to anyone who could clarify that for me.

Robert

[Scott Worden]

Good question Robert. I will often use a splined Z arc for entries into the material. I just created one in Vector and simulated it in Mach3 and the 3D arc file gave this warning "K word given for arc in xy plane on line #2". The spline arc file ran fine. It looks as if if doesn't, but maybe someone more experience in Mach/G-Code can shed further light.

(files in original Forum here (http://www.mechmate.com/Forum/show.cgi?tpc=28&post=872#POST872))

[Gerald_D]

Robert & Scott, the word "spline" in your posts confuses me. If you are asking if Mach3 can do straightforward helical motion, then the answer is "yes".

Don't use it myself, but often see the other guys discuss it. (Used for milling threads)

[Robert Cheal]

Gerald,
My question is based on doing the following.

If I set up a lathe on my PRT and use a side mounted router then I would just cut the curves on the X and Y plane. If I cut with the standard router mounted in the Z axis then I would cut along the Z and Y plane. As the ShopBot software can't recognize the radius in the Z plane I would have to use Vector to break the curved lines into straight segments. I was wondering if that was also true of the Mach 3?

I am not sure if I understand enough about radius tool paths in 3D.

Thanks,
Robert

[Scott Worden]

Gerald, maybe it should be called an arc that has been interpolated in Vector (Change/Break/Interpolate) into segments. On the flip side, you can then take the result of that or any chain of segments and do a Arc/Spline to smooth it out by fitting arcs and splines (straight segments).

Isn't the helical motion for cutting threads or spiral down pocketing a "canned" cycle much like ShopBots CC or CP with spiral and bottom pass?

Here's another example more like what Robert explained above. One is in the XZ plane and one in the XY plane. The XZ one gives the error and the XY obviously runs normally. I don't fully understand why the K word gives an error in the XY plane when K is for Z axis offset for arcs.

Just for fun, what if you swapped the Y and Z cables, feeding Y moves to the Z and the Z for the Y. Hmmm...It's to late to wrap my mind around that tonight. http://www.mechmate.com/Forum/clipart/crazy.gif

Files in original Forum here (http://www.mechmate.com/Forum/show.cgi?tpc=28&post=876#POST876)

[Gerald_D]

I think you gents are using the word "spline" for a polyline of straight line segments - I think a spline is a more complex thing.

When Vector's postprocessor gives you a lot of straight bits, it does not mean that this is what Mach3 wants. Mach3 uses the standard G2 code for circular or helical interpolation. Vector doesn't seem to recognise this?

An example of a flat circle in the X,Y plane:
G1 X0.0 Y1.0 Z0.0 F20.0 --go to X1.0, Y0.0 at a feed rate of 20 inches/minute
G2 X1.0 Y0.0 R1.0 --go in an arc from X0.0, Y1.0 to X1.0 Y0.0, with a radius of R=1.0

If you want a helical plunge of 1" then:
G1 X0.0 Y1.0 Z0.0 F20.0
G2 X1.0 Y0.0 Z-1.0 R1.0

The G2 command also works in the other planes, and it can work with R (radius) as above, or with I,J,K coordinates.

With a Google on G2 Helical, found this page (http://www.nfrpartners.com/nfrg2g3.htm) that explains G2/G3 quite well. The helical bit is actually a minor, logical feature - see "3D Circular Interpolation" right near the end of the page. Makes one wonder why SB doesn't do it.

[Robert Cheal]

Thanks Gerald,
I need to spend some time reading up on G2 code. My questions stem around plans to build another machine leave me wondering about which software is best suited for the future. I presently go from Acad to Vector 9 (I have held off on upgrading Vector)and then ShopBot. I am more of an end user desigher and builder, lacking when it comes to grasping the best software solutions and all the programming details.

Thanks, Robert

[Gerald_D]

Robert, we also go from AutoCad to Vector 9 and then to machine code (either ShopBot or G-Code). It doesn't bother us that Vector chops a curve into little straights because the file size is not an issue, and because we can specify the tolerance with which Vector does the chopping.

I think the time is fast approaching for AutoCad to give code directly - quite a few people are working on it. That's why we aren't investing more time into Vector.

[ralph hampton]

Hi folks,
In order to help me think around this mach - sb issue, could one of you g code folk tell me if it is possible to use programming statements, if, or loups with interface, in a gcode file, in order to make it interactive?
I have several files of this sort, for morticing, tennoning and dovetailing, that I can just fill in the numbers and press go.

r/.

[Gerald_D]

Some M-codes are standardised (eg. M3 always seems to be "start spindle clockwise") and cannot be user-defined. See more in this doc (http://www.linuxcnc.org/handbook/gcode/g-code.html#anchor259776). The Mach3 guys seem to use M600's for their subroutines.

[Mike Richards]

Ralph,
Another option would be to use the programming language of your choice to do the actual computations and then have that language generate G-code. That's the way that I wrote the doors program for the Shopbot. I started by entering all dimensions into a spreadsheet and then using 'C' to read the spreadsheet. The 'C' program computed the tool path using the data from the spreadsheet and then wrote shopbot code to SBP files. By doing that, I was only limited by 'C' and not by the commands available in Shopbot's language.

[ralph hampton]

Gerald,
Unfortunately I don't know (aka have avoided like the plaque) VB. Is it the same as VBA? I'm a bit old to learn new languages (I'm struggling with Italian at present, having put Chinese on indefinite pause), unless they are seriously simple scripting like shopbot. I'll look into it, but I guess that whatever language you use, it must interact with windows.
Mike,
Trouble is, what I like to do is stand at the console next to my benchtop and put in the numbers as I go - sometimes 2 sets in succession for the same setup. Partfiles I build on a separate computer in my teeny office. I have a second horizontal motor on my Z for tennoning, horizontal pocketing etc, and I only use this with such interactives. To build partfiles for such a setup would be beyond most simple software and my teeny brain.

R.

[Gerald_D]

Ralph, I'm out of my depth here! Looked at the Mach discussion forum a bit more and it would appear that VBA is also being used? Wonder if the actually language really matters - maybe Italian will do? http://www.mechmate.com/Forum/clipart/happy.gif

[ralph hampton]

Thanks.
I only said VBA because it is included with wordperfect (my wp). Ill have a look.

ciao

(:

[Mike Richards]

Ralph,
Using Google's "define: vba" feature, I found this:

VBA is "An abbreviation for Visual Basic for Applications, the official name of which is "Visual Basic, Applications Edition." VBA is Microsoft's common application programming (macro) language for Access, Excel, Project, and the Visual Basic programming environment."

Somewhere, way in the past, I looked at it for a few weeks when I was looking at various methods to connect to and extract data from databases.

[Gerald_D]

Here is something that Art posted on his forum today:

"Shopbot camp was very interesting and has led to a few ideas and a few code
correction plans.....Seeing the shobot in operation gave me a few hints about a few things that need to be done.."

[Robert Standard]

I was at the Kansas Camp and met Art. I would like to add "hold on to your hat" we have not seen anything yet. Mach3 Rocks! This group is motivated and full of ideas. I think Art spends over 12 hours a day working on his program. It is only going to get better for everyone.