On Saturday, February 04, 2012 01:56:47 PM Fox Mulder did opine: > Am 04.02.2012 18:22, schrieb gene heskett: > > On Saturday, February 04, 2012 12:04:30 PM Fox Mulder did opine: > >> Am 04.02.2012 13:02, schrieb gene heskett: > >>> On Saturday, February 04, 2012 06:46:40 AM Fox Mulder did opine: > >>>> Am 04.02.2012 08:25, schrieb gene heskett: > >>>>> I have moved these labels one at a time to other layers so I can > >>>>> try 5 layers per run of pbc-gcode, but I'm having zero luck > >>>>> finding the magic tname label that works. > >>>>> > >>>>> So, what layer in eagle do I move these text labels to so they > >>>>> come out in the $basename.top.txt.ngc file? > >>>>> > >>>>> And is there something else I need to do, the pcb-gcode previewer > >>>>> shows total blanks where they should be at all times. > >>>> > >>>> To show the text in the top ngc file you have to put it into the > >>>> top layer. This way it will get milled in the same step as the top > >>>> traces and will be shown in the preview window of pcb-gcode. The > >>>> TNAME layer is only for reference and will never be in the > >>>> generated gcode. > >>> > >>> But then it carves it as an outline, and pcb-gcode alludes to just > >>> carving the centerlines of the character somehow. It is quite > >>> readable on the first pass but later passes as the isolation is > >>> increased do a massive job of making the characters illegible. > >>> pcb-gcode does generate the files but they show as blank in the > >>> preview viewer, and contain no code that touches the board for > >>> either .top or .bot. files. The font is set to vector. > >>> > >>> I there something I can set in the eagle 'info' screen for these > >>> characters that will tell pcb-gcode that this is text, treat it > >>> accordingly? > >> > >> Ah ok now i know what you wanted. For that you have to put the text > >> into the milling layer (46). If the text is normal it will be on the > >> top side and when mirrored it appears on the bottom side. In > >> pcb-gcode you have to activate "generate text" in the "generation > >> options" tab. Than after generation you will see a preview of the > >> text and the output for the text is in a file called > >> $basename.top.text.ngc and > >> $basename.bot.text.ngc. > >> > >> I tried it myself and it works as expected for engraving result. :) > >> > >> I doesn't like the way that pcb-gcode normally will mill away all > >> copper which is not used. Therefore i put a polygon over the whole > >> board with a gap of ~0,2mm between all traces. Than pcb-gcode will > >> only mill away these small 0.2mm width lines around the traces which > >> is much faster and preserves your precious router bit. :) > > > > Which is what it is doing now, so I wonder if we have the same version > > of pcb-gcode. My version only mills away to the maximum isolation > > setting & anything outside of that is left. However, by golly that > > worked, and even has the right polarity, showing the white characters > > on a black background. On this point I am a happy camper again, thank > > you very much Rainer. > > Hmm ok, maybe i forgot that pcb-gcode already does it this way. :) > I've started using the technique with polygons for GND layer over the > whole board since many years back from the etching time where it saved > time and acid. > > To be honest i never really used pcb-gcode for milling a board because i > never found perfect settings. And my hobby mill doesn't have such a > constant z-depth that the layouts would be good enough over a longer > track. Maybe with help of the automatic depth-probing which was > discussed lately i can start experimenting again. :) > I am working on that part and will publish when it works. ATM it isn't, I presume because my use of G92 Z#100, followed by a canceling G92.1, is mucking with LinuxCNC in two forms.
But what follows is my view of something I would consider a show stopping bug in the development (master-rt) versions of LinuxCNC, so I will relate the details as I see them here: First clue: I use a position.txt file which I am beginning to regret, most notable is that when LinuxCNC has been homed at the workpiece surface, and a G92 Z0.0007 has been executed, the axis backplot, while showing the new Z height is now 0.0007 from the board shows the tool as being about 2" up in the air. Second clue: After several tool changes that use the G92.1 to clear the old offsets, (axis shows the restored numbers but I don't recall if it also corrects the tool position image this morning) and another G92 Z0.0007 that compensates for the drill bit length and chucking variations as found by a G38.2 probe, LinuxCNC runs out of room to move to the tool changing position, which, because the drill chuck is about 5" longer than the engraving bit, is at Z=6.00 absolute, or should be. According to what I'm reading here, a G92.1 should absolutely restore that, and does according to the numbers in the axis display, but something, internal I guessing, is not being properly restored, so the offsets seem to keep accumulating till it cannot go past its idea of the Z limits. The Z limits are set at +- 9.9"! and the next step is to raise the up limit to several feet & just let it bang against the nut carrier hitting the screws holding the motor plate on top of the housing. That noise (thhat motor is on a belt drive and the step slip thump is quite obvious) will inform me that the reference zero has been lost and that I need to re-home that axis. I actually have about 14" of total motion available. Now, while those limits _should_ be absolute and I have no issue with that, I have not found a way to restore or maintain that as a fixed value. Hence the thought of doing away with the position.txt file since the error once generated, seems likely to be subject being propagated over a restart by it, rendering that method of doing a reset to defaults null and void. Re- homing the machine is of no help, LinuxCNC's idea of the limits is being diddled somehow and it doesn't show in the machine status for troubleshooting in a form I recognize. :( So those are my 2 clues there there is a problem and I am a bit surprised that other users of G38.2 and the G92 family have not also been bitten. Perhaps 2.4.7 doesn't suffer from this? It would be quite jolly good if there was a list of all the #5000 and up variables and their read/write status listed in a table in the users manual, but if listed, its just as bit & pieces, maybe 10 at a time scattered through 250 pages and not indexed at all. Is it listed in the latest developer manual? I hesitate to print that one as it is expected to be more volatile than the user manual. And no clue if that rebuild is done a nightly or not. I need to take the lappy out and set it up for reading the current versions right off the site. At least I could sit down and rest my failing back. > Ciao, > Rainer Thanks for reading this far, Rainer. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> Twenty Percent of Zero is Better than Nothing. -- Walt Kelly ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
