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.  

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