Wow that is a mess... the first thing I noticed is your wrapping your code with % AND using a program end M2. You only use one or the other. M2 resets a bunch of things (see the manual) and %% does not.
I commented out the G38 and corresponding G10 lines and the back plot as viewed from Z is perfectly over the preview. The reason your back plot is shifted in the X and Y directions is on line 128 and 131 you set a G10 L2 which shifts the G54 coordinate system over. I think your having way too much fun writing G code! My normal way to run G code is to touch off and set the X and Z offsets so that X0 is the left side of the material, Y0 is the back side of the material and Z0 is the top of the material. This way I just have to create G code that assumes that X0 is the left side and Y0 is the back side and Z0 is the top side. As I said the other day when you have a probe move LinuxCNC can't know where the probe is going to touch off so it can't put the preview in the correct spot unless you probe first and set the coordinate system then open and run your program. Try splitting out the two functions and lose the %%. JT On 10/11/2015 9:43 AM, Gene Heskett wrote: > On Sunday 11 October 2015 07:06:44 John Thornton wrote: > >> Gene, >> >> Can you attach the G code that you ran? >> >> JT >> > Attached John. It is a mess, a mass of control switches because its > intended to do all 4 side parts, and all 4 base parts, just by setting > control vars at the top of the file. If #<_upper> is a 1.0, it carves a > 1x12. If #<_side> is a 1.0, it does the long front and back side ends > of the chest. If its a 0.0, the carved pattern is mirrored for the ends > of the end boards. If 'upper' is 0.0 it carves the ends of the much > narrower base boards, following the state of 'side' rules by mirroring > the cuts so they all fit together as in the picture. > > And much of that mess is because there is a not quite duplicate path if > #<_roundover> is set. The boards if carved without the roundover, need > a huge amount of sanding to roundover the edges of the fingers so that > when the fingers are meshed, they will sit clear to the bottom of the > corresponding pocket, not being held out 1/8" by the square edges the > 1/4" mill leaves. > > That roundover isn't near fully functional yet. But not having a > backplot that means much, will make it 10x more difficult for me to > single step thru it and determine where I need to adjust a "fudge" > factor. > > Because this uses G38.2's to reset a co-ordinate maps 0,0,0 points, to > run it on a sim session, I cobbled up a timer set for 3 seconds to > simulate those G38.2 contact events in the sim setup, and the offset > results shown are identical to what I see on the real machine. > > The sim is running V2.7 and the real machines are running the latest > 2.8.0pre. Again, same results. > > On my machine, the M7-8-9 controls have been re-dedicated, with the mist > checkbox controlling a motor & gearbox from a junked out paper shredder > to swing the gauging bar on the rear of the jig into position to serve > as a fence to locate the end of the board when clamping up the next > board, it also carries a 3 sided brass dohicky which is the 3 contact > points the G38.2's search for. Its a 1.5"x .5" mahogany bar about a > foot long, mounted to the rear edge of the jig, swinging on a section of > piano hinge that has an o-ring hooked up to pull the end play out of the > hinge, and the output gear of this motor is connected to the bar with > about 8" of junky plastic hose which can bend and absorb motor > overtravel. A homemade cam on the reduction gear triggers a couple > microswitches with diodes across them so that all I have to do is the > usual DPDT relay reverseing on the armature polarity. So it runs not > quite 180 degrees from switch to switch when I toggle the "mist" button' > > The same general idea but using a charge pump, starts and stops a vacuum > cleaner whose nozzle is right behind the cutting tool in an attempt to > contain the huge pile of wood swarf. Thats what the M7-M8-M9's in the > code do. Unfortunately, by the time I got a big enough path thru the > vacuum plumbing yesterday so it would pass & not get clogged up when it > picks up the little blocks of wood released by the final cut, I was up > to 1.25" plastic pipe and a rubber radiator hose to allow the mills Z > motion, and a measly 6.5 amp vacuum needs about 2 or 3 x the amount of > air flow than what it can deliver if its to really keep the area clean. > > Too big a nozzle equals slower air flow. A work in progress so to speak. > My 1.5 hp dust collector with a 4" intake I use on the planer has the > air flow, but not the vacuum to move the air thru as much plumbing as is > involved with a centrifugal debris separator I made (and it works pretty > good) out a pile of pvc pipe, 1.5" drain pipe and a 4" drain for the > spin section. BTDT. I'll have to see if I can find a bigger vac that > isn't also too big to fit the space. What the bucket max has going for > it is its price, $22 USD at Lowes, its a small vac motor and a short > hose, mounted to a 5 gallon bucket lid, you supply the bucket. > > I'll shut up now, but I expect it will generate more questions. > > Thanks for offering to look at it, John. This thing can be a real time > sink. But until I fall over, thats what I have. ;-) > >> On 10/11/2015 3:51 AM, Gene Heskett wrote: >>> Greetings all; >>> >>> I had asked for an explanation of why the run trace, and the initial >>> trace, do not align in the backplot, and it was suggested that I was >>> using something in the G90 to G92 in my code. So It removed any of >>> that from my code, with no effect detectable in removing them. >>> >>> The first thing my code does is take the machine back to its G53 >>> home position, and when that is reached, the g10 command to zero the >>> global co-ordinates to that position, this to keep my g55 mods from >>> accumulating run to run. >>> >>> So enclosed is a screen snapshot taken from the simulator, backplot >>> in overhead view mode, trimmed down to just the backplot window. It >>> exactly matches what I see on the real machines monitor so its at >>> least consistent. According to the MDI window, there is a G91.1 in >>> effect, but it is not in my code. And its not present in any file >>> in the sim-axis directory. So I assume its an internal default. >>> >>> Note from the snapshot that the offset in the Y direction is >>> nominally 2x that shown in the x direction. The white line segments >>> can be clicked on if one is patient enough with his clicking, so >>> that the line of code in the code window is highlighted. If one >>> could call it high lighted, the colors chosen renders it very close >>> to invisible. Extremely low contrast result. This needs to be >>> fixed, but I've no clue how. >>> >>> None of the traced, red lines are clickable. >>> >>> The default co-ordinate map used for reference is G54, the actual >>> movements are, with the exception of the G38.2 stuff to find and >>> calibrate it to the contacts on the jig, done in the G55 co-ordinate >>> map. Are/can these offsets be responsible for the apparent >>> miss-match? >>> >>> Thanks all. >>> >>> Cheers, Gene Heskett >>> >>> >>> -------------------------------------------------------------------- >>> ---------- >>> >>> >>> _______________________________________________ >>> Emc-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/emc-users >> ---------------------------------------------------------------------- >> -------- _______________________________________________ >> Emc-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-users > > Cheers, Gene Heskett > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
