MechMate CNC Router Forum

Go Back   MechMate CNC Router Forum > Archives
Register Options Profile Last 1 | 3 | 7 Days Search Today's Posts Mark Forums Read

Closed Thread
 
Thread Tools
  #1  
Old Thu 27 July 2006, 01:48
Gerald_D
Just call me:
 
Moving from SB to Mach software is it really that easy or good

Over the last couple of months we have used Mach3 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 )

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 , and develop our Mach experiences together.
  #2  
Old Thu 27 July 2006, 17:34
Gary Beckwith
Just call me:
 
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
  #3  
Old Mon 21 August 2006, 00:29
Gerald_D
Just call me:
 
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/mach1m.../message/57925
http://groups.yahoo.com/group/mach1m.../message/57933
http://groups.yahoo.com/group/mach1m.../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.
  #4  
Old Mon 21 August 2006, 07:23
Patrick Toomey
Just call me:
 
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.
  #5  
Old Mon 21 August 2006, 08:01
Gerald_D
Just call me:
 
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/mach1m.../message/57631
  #6  
Old Mon 21 August 2006, 08:31
Sheldon Dingwall
Just call me:
 
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?
  #7  
Old Mon 21 August 2006, 09:44
Gerald_D
Just call me:
 
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)
  #8  
Old Mon 21 August 2006, 15:30
Sheldon Dingwall
Just call me:
 
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.
  #9  
Old Mon 21 August 2006, 16:04
Scott Worden
Just call me:
 
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.
  #10  
Old Mon 21 August 2006, 20:35
Gary Beckwith
Just call me:
 
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
  #11  
Old Mon 21 August 2006, 23:00
Gerald_D
Just call me:
 
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.
  #12  
Old Mon 21 August 2006, 23:08
Mike John
Just call me:
 
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!)
  #13  
Old Mon 21 August 2006, 23:38
Gerald_D
Just call me:
 
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.
  #14  
Old Tue 22 August 2006, 06:41
Gary Beckwith
Just call me:
 
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.
  #15  
Old Tue 22 August 2006, 07:31
Mike John
Just call me:
 
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
  #16  
Old Tue 22 August 2006, 07:48
Gerald_D
Just call me:
 
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.
  #17  
Old Tue 22 August 2006, 08:27
Gary Beckwith
Just call me:
 
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.
  #18  
Old Tue 22 August 2006, 08:50
Patrick Toomey
Just call me:
 
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.
  #19  
Old Tue 22 August 2006, 09:21
Gerald_D
Just call me:
 
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.
  #20  
Old Tue 22 August 2006, 09:34
Mike John
Just call me:
 
Sorry to appear stupid, but I still dont understand.
Does clearing the buffer mean executing the code in the buffer?

..........Mike
  #21  
Old Tue 22 August 2006, 10:06
Gerald_D
Just call me:
 
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!
  #22  
Old Tue 22 August 2006, 10:33
Gary Beckwith
Just call me:
 
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.
  #23  
Old Tue 22 August 2006, 13:03
Patrick Toomey
Just call me:
 
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.
  #24  
Old Tue 22 August 2006, 13:08
Gerald_D
Just call me:
 
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.
  #25  
Old Tue 22 August 2006, 13:42
Gerald_D
Just call me:
 
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.
  #26  
Old Fri 25 August 2006, 04:51
Gerald_D
Just call me:
 
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)
  #27  
Old Fri 25 August 2006, 09:15
Gerald_D
Just call me:
 
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.....

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.
  #28  
Old Thu 28 September 2006, 11:59
Gerald_D
Just call me:
 
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.
  #29  
Old Thu 28 September 2006, 14:26
Mike Richards
Just call me:
 
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.
  #30  
Old Fri 29 September 2006, 11:28
Robert Cheal
Just call me:
 
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
Closed Thread

Register Options Profile Last 1 | 3 | 7 Days Search Today's Posts Mark Forums Read

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 06:32.


Powered by vBulletin® Version 3.8.3
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.