Machsupport Forum
Mach Discussion => Mach Screens => CVI MachStdMill (MSM) => Topic started by: thosj on September 15, 2010, 04:35:30 PM
-
Not sure if this is an MSM issue, SS issue, both combined, or what.
Today I tried to drill a bunch of holes with G73. The hole was only a couple pecks, 3 maybe. It seemed to do one peck, not to the correct depth, retract up too far, peck again to HIGHER than the first one, retract HIGHER yet. When it was done, Z said +.100, the R plane, but it was 3/4" above the part. Each hole got worse, Z saying .100, and it was higher each hole!! WCO G54 Z was still what it was, TLO for T6 was still what it was, but the tool was NOT where it should have been. Only way out was re reference Z even though WCO Z did NOT change before or after referencing!! Set G73 Pull Back .1 and .05, same result although the numbers may have been different WRT depth and retract.
Tried G83, same result.
Drilled the holes with G81 just fine, no peck.
Haven't tried 1024 screen or PP instead of SS. Not sure what to try or what's going on.
Here is a sample of my G-code:
O1
G90 G80 G40 G17
T6 M6
(TOOL 6)
(17/64 DRILL)
(OPERATION 2)
G0 G90 G54 X-8.625 Y-0.375 M3 S1400
G43 Z1. H6
G0 Z0.1
G73 G98 X-8.625 Y-0.375 Z-0.4798 Q0.2 R0.1 F8.0
Y-3.8125
X-5.1875
......
......
This has worked with 1024 screens for years, so it isn't the code.
Tom
-
Switched to PP, problem went away! G73 peck drill holes all afternoon.
So........yet another SS issue, with MSM apparently. I never had this issue running SS on 1024 in the past. I almost always peck drill holes.
Sigh.......after the probing thing, now this, I'm beginning to wonder why I keep trying to use the SS. As of this minute, I'm done. I'll stay on PP until the next urge hits me, like when Dave/Brian ask if I'll test the LATEST FIX!!
If I have to give up one thing, SS or MSM, SS is outta here!! My setup runs just ducky on pp at 60K, so ramming my head into a wall is just entertainment.
BTW, I have entire directories setup, so rename, shut everything off, swap cables SS/PP, and I'm able to go either way!!! SS is mounted inside computer case with 26 pin to DB25 backplane cables. Minor hassle at update time, have to do it twice with the renaming and such, but not a large problem.
Tom
-
Tom,
Screen sets of any flavor have no way to impact the actions that a g-code causes (as far as I know).
(A minor exception is a few specific M codes that mach exposes (M6Start, M6End) for customization. )
So, I was suspecting this is a function of the mach revision - but.... as I was writing this I got your 2nd post...
Weird! I would never have expected that. I was pretty sure the canned cycle actions are decomposed into axis movements by the time mach sends the movements to the SS. (I.e. SS didn't know know what a G73 is).
My "module isolation approach" would have been to see if the test code runs correctly on the lock down rev (3.42.40), using 1024 for both lock down and development test - that eliminates MSM as a variable.
I will say that I will be real surprised if it's an MSM side effect as screen sets don't even know about canned cycles - it's not part of their concept of the universe.
Care to try the same mach rev (3.43.22 I assume) with 1024 on PP and SS?
Dave
-
Care to try the same mach rev (3.43.22 I assume) with 1024 on PP and SS?
I'd have to refigure out how to get to 1024. I'd probably have to start from Mach3Mill and redo my entire setup unless you have a good shortcut!!! Remember, during the probing thing, I started completely OVER, then even rebuilt my box with a PMDX-125 and stuff. 1024, bah!!
I'm certainly not blaming MSM, so you're saying it must be in 3.43.022 and not in lockdown, or any rev. prior to dev. versions?
Tom
-
I don't really know what it actually is - I'm just doing semi-educated guessing at this point.
My guess would be a combo of 3.43.22 and SS - but I'm at a loss to see how a G73 canned cycle is different between PP and SS - I would have thought mach did all the canned cycle processing and just passed Z motions to the lower layer (PP or SS).
I think this is one for the Mach Wizard man in the corner behind the curtain. ;)
Brian likes small concise test cases - can you post a small gcode file that runs on PP and not SS?
Dave
-
This is going to be a tough sell, Dave, but here goes.
I spent half the afternoon creating profiles for MSM/PP, MSM/SS, 1024/PP, and 1024/SS, all on Mach3 v3.43.22. Both 1024 profiles created from scratch from Mach3Mill and all settings entered from scratch. I have Mach3 directories for both SS profiles and PP profiles so there's no cross pollution, SS plugin isn't even IN the PP profile directories.
All the profiles work with G73, exact same gcode in all instances, EXCEPT MSM/SS. MSM/PP works fine, and both 1024 profiles work fine. To convince myself, I ran the test in both 1024 profiles then restarted everything and ran the MSM/SS profile and the problem was the same as I had earlier.
I have no clue what this is, I hope you do!! I don't know if there could be something in my MSM/PP profile setup that's causing this somehow. I can't imagine what it would be except perhaps G73 pullback, but this happens with G83 also, a full retract peck cycle, so the pullback wouldn't come into play here. I DID try .050 and .1 G73 pullback with no change in behavior. It seems that on the second peck it doesn't feed at all, but stays put then retracts the retract amount from there, higher, then does it again. It's hard to tell, because when it's done and it's supposed to be an Z.1, it's some odd amount around 5/8" above the part. Each consecutive hole it gets worse, stopping higher off the part but with Z DRO reading .1.
I know this sounds insane, but I just burned myself out testing and this is what I see!!
Tom
-
Will just try to help some...... FWIW......
I don't remember a problem using G73 / G83 with version 3.042.032 and if i recall that was with both SS & PP and 1024 ( mill only ).
So the time frame was about a year ago when i was trying peck drilling.
I haven't used the SS since then and only use PP now.
Now about that time, a few folks had drilling problems and Melee posted some peck drilling cycles that i did test on both the lathe and the mill
using the 1024 screen sets and the above version 3.042.032 & also .033. They worked very well / no problem on the lathe and mill.
So, don't know if this time frame and version is a help, but will say that the combination does work for me.
I would think there are enough users out there, that have done peck drilling, thus they can relate a problem to any version of Mach and use of PP /SS.
RICH
-
The catch here is if one wants to use MSM, one needs the dev version of Mach3, so that leaves out the .032 and .033 and .040 lockdowns.
And I have peck drilling working fine on MSM/Mach3 v3.043.022/PP, so it isn't like it's a peck drilling thing for me as I've been peck drilling all along.
I think the next thing I'll try is cloning my working 1024/SS profile that seems to work and making a new MSM profile and see if somehow the profile/XML is hosed. Don't know what else to try until Dave chimes in with a tip or 2!!
-
Tom,
The catch here is if one wants to use MSM, one needs the dev version of Mach3, so that leaves out the .032 and .033 and .040 lockdowns.
This is correct - the reason that MSM won't run on the lock down version as that it requires mach APIs that don't exist in the lock down rev.
Don't know what else to try until Dave chimes in with a tip or 2!!
Oh my, while I'm flattered, I fear the expectation may be more than I can meet in this case. :-X
Here are some (maybe) relevant thoughts I've had:
There are three ways I can think of to get G-code into mach for execution.
1) load a file into mach.
MSM does this the same way all other screen sets do - call the mach interface to load a gcode file. A screen set has no knowledge of what's in a gcode file etc. User pushes button, mach interface called, mach returns, screen set's part is then all done.
2) MDI control
mach provides 1 MDI control - all screen sets use the same control. Again the screen set is not involved in the contents of the data entered via the MDI control.
3) Script Code statements. This is not applicable for the situation at hand.
Once ode is loaded, when the user starts the code, the screen set job is the same simple sequence of
a) button pushed, b) mach "run code" interface is called.
Again the screen set has no knowledge of a canned cycle - an conversion of a canned cycle is handled by mach and motion is passed to the motion device (at least that's my understanding).
So I'm at a loss for "tips" as to why you could see this with a MSM/SS combination.
Some other musings on my part:
1) Screens sets and plugins don't use any common interfaces that could conflict (MSM does not use a plugin to run). It was designed that way to avoid potential multiple plugin interface issues.
2) The PP driver does not interface to the rest of mach via a plugin interface - it is a more "intertwined" part of mach.
I suppose the combination you are seeing could be peck drilling via a plugin motion control device - but that still does not quite fit all of what you have described.
I can only do rudimentary SS testing as I don't have a SS connected to actually drive iron (just a bench test set up for the SS).
Right now, I think this remains an unsolved mystery until more clues are found by someone.
And (uh, no offense meant; really!) before going hunting, it would be nice if more than one person could confirm the problematic combination. Just to many unknown variables yet to make a plan of attack.
I will shoot Greg an email to ask him to read the thread in case he has any ideas.
Dave
-
It sure sounds like a syncing problem to me. The SS tells Mach it is still and what the current position is. Mach calculates the next move, but it must be using the wrong positions. I am going to ask Brian to help figure this out because I haven't changed anything in that area of the code. I suspect it is a timing issue.
I'll let you know what I find out.
Greg
-
I never considered this, but I'm currently on the v16bd plugin Greg posted somewhere in a noise discussion. I could go back to v15ogx2 and see if that makes a difference. Won't be this morning, but later today.
The catch is why only with MSM? I'm still suspecting a corrupted XML. No idea how an XML could get corrupted like that, only affecting peck drilling, but stranger things have probably happened! I will create a new profile later today and see if that fixes the issue.
-
HI DAVE,
Just been trying g73/g83 in msm but no joy, changed to standard screen set and all ok.
using latest versions of both msm and mach,
no smooth stepper.
rgds Mick.
-
Hmm...well now, Mick.
Can you perhaps elaborate on "no joy"? What exactly are YOU seeing with regard to G73/G83, something similar to what I was seeing or something else?
And no SS in your equation.
Hmm....indeed.
I'm at my part time University job this morning so not in my shop, but will be looking forward to any development here!
-
thomsj,
yesterday i spent about 3hrs creating a gcode program which was running perfectly last night,
this morning loaded the same program and got an unrecoverable error,tried many times to load,
the only way it would load was after i deleted the g83 at the begining of the line.
Then i started to mess with changing to g73 at one stage the A AXIS started to move although
there arn't any a axis moves anyywhere in the code,afer that i gave up and came indoors to try
this laptop,in msm with g83 x0 y0 z-25 r5 dro's zero'd out i get y movement ! then z goes to -25
and retracts to safe z, the peck distance is ignored.
Load machmill and the line runs as it should.
mick.
-
Mick,
Can you post a bit of your gcode with the G83/G73, just for a look-see? Your issue is WAY different from mine for sure.
Tom
-
Mick,
Uh, You know I didn't really want to know this right? :( (....just kidding)
Re the A axis movement:
What page were you viewing when you saw the Z axis movement?
Was this while running the 10x7 resolution and on the run-path page?
If so, there is a bug on that page where the A axis DRO is actually showing the Z axis values.
I have that fixed but it has not gotten out in a release yet.
OTOH, if you saw this on a different page, it is probably something different.
Dave
thomsj,
yesterday i spent about 3hrs creating a gcode program which was running perfectly last night,
this morning loaded the same program and got an unrecoverable error,tried many times to load,
the only way it would load was after i deleted the g83 at the begining of the line.
Then i started to mess with changing to g73 at one stage the A AXIS started to move although
there arn't any a axis moves anyywhere in the code,afer that i gave up and came indoors to try
this laptop,in msm with g83 x0 y0 z-25 r5 dro's zero'd out i get y movement ! then z goes to -25
and retracts to safe z, the peck distance is ignored.
Load machmill and the line runs as it should.
mick.
-
Dave,
The movement was on the run screen not the path screen, the dro's were not just updated,there was
real movement of the axis.
10*7 screen
mick.
-
OK, it's not the DRO bug then -
From the unsolved mystery list:
A couple of times over the last year I've had an issue with cross coupled axis movements like you describe. This has been with both 3.42.40 lock down and the later 3.43.x series. I've never been able to pin down a way to reproduce it at will, and I've never been able to show it to Brian. When it happened, the XML I thought had the problem would not cause the problem on a different PC.
In the course of trying to find the bug, I did learn that building a new mach XML from scratch has always made it go away (at least for me)- but I have no idea why.
FYI - I've sent a beta 11 off to get posted. The only change it has is the fix for the A axis DRO on the run-path page.
Dave
-
thoj,
-
Dave,
just load g83 code i was running about an hour ago on this computer and now niether msm or macmill
will accept it ,they both crash.
mick. ;D
-
ArtCode 3336 saying that the MPG code is crapping out.. To test please do not run in MPG mode
Thanks
Brian
-
Back to the original issue!
Dave, as you suspected, you and MSM are off the hook ;) Today I tediously created all new profiles for MSM and 1024 cloned from Mach3Mill and entered all my info (I am getting good at this!). My problem with G73/G83 is present on MSM and 1024. Once in a while a hole will peck drill OK, but 98% of the time it does NOT.
Here's what I observe. Drilling starts, moves to X/Y, comes to Z.1, starts the first peck, stops feeding at some seemingly random spot but the DRO says it's still moving, retracts when DRO says it's at the right spot, retracts seemingly the right amount, .1 in my case, starts next peck, same thing, DRO says it't moving when it's not, it may move some again seemingly random amount before stopping with DRO still going. It seems to start feeding, stops while Mach thinks it is still moving, leading to Z being OFF location now. I tried drilling holes .5 deep, .2 pecks, then .1 pecks. It's worse with .1 pecks as it almost never feeds. By the end of 3 holes the Z is off by about an inch and a half!! Thankfully PLUS!!
I switched to PP, pecking works just as smoothly and consistantly as possible, over and over, all aftrernoon, MSM or 1024.
So, it seems to be an SS/Mach3 issue, again. I did try both SS plugins, 16bd and 15ogx2, no difference. If anyone thinks it might be something with my setup, please advise, but seeing as it works on PP and NOT on SS, I'm thinking my setup/mechanical stuff is OK, and it HAS been OK for a year or so.
I'm not sure if I should take this somewhere else or let it simmer here as long as Brian AND Greg have made appearances. I'll leave that up to them and you, Dave.
Tom
-
Tom,
Was the latest round of testing you did all with mach 3.43.22?
(I think so, but I want to confirm)
Dave
-
Tom,
I summarized what your text said into this table - did I get it correct?
---------------- MSM ----------------- ---------------- 1024 -----------------
mach ver SS 15ogx2 SS 16bd PP SS 15ogx2 SS 16bd PP
dev rev 3.43.22 bad bad Good bad bad Good
lock down 3.42.40 n/a n/a n/a not tested not tested not tested
If this table is accurate, it seems to indicate a Mach/SS issue. (whew! :D )
We don't know if it is an issue with the lock down or only the dev rev.
I'd guess dev rev - as if peck drilling didn't work on SS with lock down, I'd think that would have surfaced before this.
Given that the issue happens with mach/1024/ss, earler dev revs can be tested (using 1024).
If you have the time (you're already done lots to isolate this down - thanks for that BTW), could you try it with 3.43.6/1024/SS 150ogx (as that was the first public dev rev with all the new APIs etc)?
In any case, since it feels like a sync issue between mach and the SS, I think it's going to be up to Brian & Greg to peer under the hoods to see what they can find.
Dave
-
Yes, all my testing was with Mach3 v3.043.022.
Your chart is correct.
I'll have to see if I'm up to testing with the first dev rev!! When I get thru 4 hours of this I'm convinced I'm done screwing around but then I sleep on it and my mind is reeling and I go back down there and do it all again!! Good thing I don't have to make money with Mach3 and my milling machine!!
I suppose to test 3.043.006 I'd have to rename the Mach3 directory and install 006 from scratch. I could copy a profile in and that wouldn't be too bad. Hmmm....might not take much to try that!!!
I could also look thru my saved Mach3 directories from the past and see if I have one with 040 lockdown setup for my new PMDX hardware, but I don't think so. But one more run thru a complete new profile wouldn't be that big a deal either seeing as I am so damn good at it now! I almost have my Ports & Pins setup memorized and I do have my motor tuning settings memorized. I can set Config/General Config pretty much without looking, too!
At any cost, I think you're right assuming it's a dev rev thing as I drilled with G73/G83 all along with lockdown versions and 1024 screens for 18 months without any issues. I am NOT sure I've drilled any since rev devs and MSM unless I did it while on PP and never saw it with SS. I've done so much profile switching and PP/SS switching since this all began I can't remember it all! Then to add to the confusion I went from CNC4PC C23 BOB to PMDX and went from Gecko G320 to G320X during this time. If I ain't careful I'll approach 'expert' status one of these days.
Tom
-
he he,
I think you have discovered Brian's secret - I'm convinced there's something that goes into the software that hooks one into "I'm sure I can lick this, if I just try this one more thing....". ;D
Dave
-
Brian,
there are no MPG'S enabled, i don't have an MPG.
Mick.
-
Where can it get the SS v16bd plugin? I seem to have missed that.
Cheers
Calum
-
Where can it get the SS v16bd plugin? I seem to have missed that.
I don't remember but it was in a forum thread about the SS and noise, perhaps on the Mach3 Yahoo group or Geckodrive group? Greg posted it there but I've never seen it anywhere else, like on the Warp9 website. Not sure if it fixes anything as I took the advice in that same thread and mounted my SS inside my computer case at the same time.
I don't know if it's proper forum ettiquitte to post it here as it's not "official", or I would.
If you want to email me at thosj1 at gmail dot com, I'd email it to you.
Went hunting, found it here: http://groups.yahoo.com/group/mach1mach2cnc/message/121135
-
Brian,
there are no MPG'S enabled, i don't have an MPG.
Mick.
I don't know what MPG Mode is either, but perhaps if we told Mick how to check if he is IN MPG Mode. I seem to remember about a "mode" where you could step thru the program with the MPG, but I've never done it or even looked into it. Maybe Mick somehow got into "MPG Mode".
-
Seems odd that you can see the DRO change but the axis is not moving.. The Positions on the screen are from the index registers in the SS. The index registers are set by the pulses that go OUT of the SS. So this tells us that the Pulses "should" have been sent from the SS to the axis drive. is there a chance that you drive faulted due to over acceleration and that we have an accel problem rather then a Drilling problem? I would lower your Z axis acceleration by 50% and see if you still have the problem.
Thanks
Brian
-
Seems odd that you can see the DRO change but the axis is not moving.. The Positions on the screen are from the index registers in the SS. The index registers are set by the pulses that go OUT of the SS. So this tells us that the Pulses "should" have been sent from the SS to the axis drive. is there a chance that you drive faulted due to over acceleration and that we have an accel problem rather then a Drilling problem? I would lower your Z axis acceleration by 50% and see if you still have the problem.
Thanks
Brian
I'll certainly try that, and I can look at the G320 led and see if it faults during this peck cycle.
But how would one explain it working on PP and not SS? Do they handle the acceleration differently somehow? Motor tuning is identical between my profiles, PP and SS. I don't get a drive fault any other time moving the Z, but pecking is definately a test!!
-
Well... I don't know at this time but with the data that I am getting it looks like the direction we need to be looking.. Welcome to my world :) It will all get sorted out as time goes on.. but you have it so you can make the problem happen and that is a big part in fixing the problem!
-
Well, I lowered my acceleration by 50% and the problem went away!! As always, Brian, you KNEW!! I guess I should have been watching the Gecko fault LED, but I NEVER THOUGHT of acceleration.
Thanks for that.
Now, how DOES one determine acceleration? I've been running with my accels at 7 for a long time. Suddenly it goes berserk! I set it to 3 for Z and the peck drilling works great. I don't actually notice much difference. Is there a procedure for determining optimum acceleration values? I have Keling servo motors on all three axes, KL34-180-90s, the big bruisers, a 72 volt PS, Gecko 320X/320 drives. CUI AMT-102 encoders at 400 line count. X and Y 24000 Steps per, Z 19200 Steps per. X/Y 100 IPM, could go to 150, Z 40 IPM, could go 50, Z is counterweighted knee on BP clone. Is determining accel a trial and error thing and I just happened to stumble on the break point, or is there a "scientific method"?
Tom
-
There is a "scientific method" since there are programs that do all the calcs based on the physicals of the machine. Or you can do the calcs manualy as an engineering exercise. But calculations are only as good as the assumptions used and info in the calcs, and finaly the understanding of what the calc
is telling you.
So practicaly speaking, trial and error ( which dosn't take long to do anyway ) is a perfectly fine way to do it.
What I have done is after the steps per unit are correct, i then find the max velocity i can get and reduce it to allow for cutting etc, then with that velocity setting i do the same for acceleration. This way there is headroom in both the velocity and accel settings for the work to be done.
Then some machining tests are done for the worst case of material etc to affirm there should not be a problem for the work that i normaly do.
Which lately seems like not a heck of a lot! :D
RICH
-
Dave,
my problem with g83 is solved, i'm useing two programs allmost identical appart from z depths, but one of them
was missing the Q word , if a prog with the Qword in, it will load ok ,without it won't. the mpg error code will show.
if however the Qword is edited from loaded prog, it will be loaded after editing,but shut msm down, then try to reload
the mpg error code causes a crash .
this is repeatable every time on my machine,the attachment is the prog that is to blame for my drink problem . ;D
Mick.
-
Mick,
Thanks for letting me know you found the problem.
That wraps up both of the G73/G83 related problems as solved. :)
I'll forward the info about editing the Q word to Brian. My guess is that he'll add it to the V4 list as he's trying to concentrate on that over V3.
Dave
-
Mick,
Thanks for letting me know you found the problem.
That wraps up both of the G73/G83 related problems as solved (at least from an MSM viewpoint). :)
I'll forward the info about editing the Q word to Brian. My guess is that he'll add it to the V4 list as he's trying to concentrate on that over V3.
Dave