Re: [Emc-users] Stable plastic for a pallet. [Was: Workpiece is longer than the mill travel]
On Sunday, February 05, 2012 02:42:38 AM Erik Christiansen did opine: On 04.02.12 18:04, gene heskett wrote: What would you folks use when you need an insulated pallet? If nothing out of the junkbox will do, I'd fish out my old tin of automotive bog and make up a few suitably sized slabs. Admittedly, they'd have to be machined on the outside too, to make them look half respectable. If that isn't stable enough, then I'd fork out the $30 - $40 that a 3/8 or 1/2 sheet of acetal (Delrin equiv.) costs here: http://www.iplasticsupply.com/shopping-cart/acetal-delrin-celcon-sheet/ or anywhere else handy. With shipping too, it's worth being inventive, though. Here's hoping that the automotive filler will do. I've machined it after filling in a missing bit in an aluminium casting, and it cut fine. (I only had to mount a fuseholder there, so it was strong enough.) Erik I hadn't considered the bondo approach, mainly because I tried to fix a broken tower on an ignition coil with it something like 50 years ago, and it shorted out the coil. The fire could be seen jumping from the wire socket on the inside, about an eighth inch, then back to one of the low voltage terminals on the side next to the bondo. That was a 60 kilovolt rated, rather high priced 'hot rod' part at the time. I made a new pallet out of micarta last night, including a fits the T slot fin on the bottom to maintain x axis alignment if I dismount remount it, and it scans with a dial indicator on the mounted pcb with a variation approaching a full thou. My micrometers can measure that much just from thickness tolerance on the pcb, so I doubt if I'll get too much better unless I run down a more precisely made board than what the shack is peddling. I put a locator hole in the pallet, then thought I would re- enforce the hole with a short piece of brass tubing with a 1/16 bore from the hobby shop, something I could use my hole finder routine to locate its exact center, then run the machine to the corner of the board using the step jog function home the machine there. Or I could home it there and just plug in those small, known offsets with G92. That leaves one final problem. That of reliably finding the boards own reference hole once the board is turned over to do the bottom side. I've found the 1 oz copper is quite easily pushed out of the way, so the hole finder can't reliably find the sides of the hole, no probe contact. So tomorrow I will get one of those pcb pens from the shack and see if I can dummy up a thou or 2 of 'plated thru' down into the hole with it, which should make that contact area quite a bit more robust, even repairable if I wear it out by repeated probing. Progress at least, and I'm certainly learning a lot about my machine. For one, if I don't keep the z post swimming in vactra, it shudders as it moves in about 2 thou jerks, possibly telling me I have the gibs too tight, so that is something else I need to fine tune tomorrow, but from the looks of the doppler radar page, we may have, if there is any left when it gets here in an hour or so, some of Denvers snow to shovel first. It was moving pretty fast when I looked about an hour back. Thanks for the suggestions Erik, you never know when something said on 16th Avenue (Rosanne Cash) might be magic. ;-) 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 There cannot be a crisis next week. My schedule is already full. -- Henry Kissinger -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Control a hot wire foam cutter using LinuxCNC?
Hi Peter, I just figured out how to get it working again. The patch seems to be based on a snapshot of the master branch somewhere at the end of January. On my machine I can reproduce the (very nice) results with these commands: git checkout dcbaa105aaa5494ba5eea296ca66df893bd5c9b6 -b xyuv-sammel-28012012 git apply --verbose ../0010-foam-xyuv-Modification-2.6-pre.patch cd src ./autogen.sh ./configure --enable-simulator make -j 2 . ../scripts/rip-environment linuxcnc (then load the foam-xyuv.ngc) By the way, I'm also toying around with with model air planes. I have a small project at gitorious which can be used as CAM generator. https://www.gitorious.org/foambladesuite It can currently read a special kind of DXF files and export them to nc-code. LinuxCNC integration is still very beta, but we are going to improve soon. I'm going to do an extra announcement when I've tested it on a foam cutter... With best regards, Michael On Wed, 25 Jan 2012 18:32:50 +0100 Peter Georgi georg...@bluewin.ch wrote: Hi, Ben Jakson published the two links below. Since I have a four axis (XYUV) hot wire foam cutter I jumped into the tube at youtube. Mr. Sammel implemented exactly what I was looking for a while. I manly use the cutter for wing panels for model air planes. I downloaded the patch. But how to install it, that it runs inside Axis? Any hint or help are very welcom. Regards Peter -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] parsing the current language dialect, and describing as EBNF
sure, but either way you look at it: if there's a language change, there still
be a need for recognizing the old syntax, either for in-place compatibility or
external automatic conversion
-m
Am 04.02.2012 um 22:25 schrieb Kenneth Lerman:
The use of matching labels to resolve ambiguity was just a cheap trick
to lower the cost of implementation. There is no reason that we should
keep the labels on control structures. We should then follow the same
rules that C uses.
Ken
On 2/4/2012 10:25 AM, Michael Haberler wrote:
{this is a bit of language/compiler theory, but then the thread started
here; sorry;)}
One of ideas floating around was to to document the current language as an
EBNF, or an equivalent railroad diagram. An EBNF is a notation for a
context-free languages.
That will not work, because the current LinuxCNC RS274NGC dialect cannot be
described by a context-free grammar in the first place, and hence not as an
EBNF, if one tries to include the control structures as language elements.
This is different from the original language: the pre-oword syntax was
context-free, which is why there's a meaningful EBNF in the Tom Kramer
report, and working context-free parsers based on ANTLR and bison like here:
http://fennetic.net/irc/emc3/src/emc/interpreter/)
To see why the current language is context-sensitive, consider just one
example:
program start
o label1 do
...
o label2 while ..
...
o label3 endwhile
...
o label4 while ..
eof
You cannot determine by looking at a context-free grammar alone wether the
interpretation should be either:
1: (do ... while) (endwhile...while) or:
2: (do ... (while ... endwhile) ... while)
To resolve the ambiguity in scope, one needs to match the label *values*:
(label1 == label4) (label2 == label3) - interpretation 1 (in the
current language)
(label1 != label2) - an error at 'endwhile'
This also applies to if/then/elsif/else and repeat/endrepeat.
So the labels constitute the context. Technically, since the labels are
variable keywords, this means a language with a theoretically infinite
alphabet.
This has a couple of consequences:
- writing an EBNF is only possibly on a line-by-line basis, not including
the control structures . But then such an EBNF will not tell you wether a
given program is correct wrt current scoping rules, or not, and as such
fairly useless.
- it also means explains why my first attempt at a bison/flex parser *for
the current language* failed to properly recognize current control
structures because as it the stands the parser fails at the above
ambiguities. This also applies to other tools.
This does not mean these tools are unusable, it just means the scanner needs
to tie into the parser or scope stack. It does however mean an EBNF will not
fully encompass all aspects of the language. This might be useful already.
- Michael
ps: this is a clarification of what we have, not a critique - C, and C++
have similar issues and work just fine, too.
psps: so much for the comment 'G-code is extremely easy to parse.' ;)
--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Workpiece is longer than the mill travel
On 2/4/2012 4:29 PM, Kenneth Lerman wrote: I end up doing this all the time since my current small mill is limited to 16 X travel. However I define Y with respect to the upper jaw of the vise so all I have to do is slide the part in x to get the dowel pin aligned. I'll bet that Stuart does it all the time, too. His table is limited to 16 feet in X travel. :-) Ken Bigger machines just scale up the problems. ;-) Mark -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Control a hot wire foam cutter using LinuxCNC?
Hi Michael, Thank for the hints. I will soon try it out and report about the success. I'm using a program called ProfiliPro from Stafano Duranti (http://www.profili2.com/eng/), which produces quite accurate g-code and is easy to handle. Unfortunatly it's not free, but the 60€ are worth for it. Of course it would be fine if a similiar program under a GNU or what ever free licence would come out. If you are interested in the configuration files, please let me know. It would be a pleasure for me to give them to you. I would also help with testing the outcome of your g-code on my foam cutter. Regards Peter -Ursprüngliche Nachricht- Von: Michael Abel [mailto:c...@quasiinfinitesimal.org] Gesendet: Sonntag, 5. Februar 2012 11:17 An: emc-users@lists.sourceforge.net; Martin Krüger Betreff: Re: [Emc-users] Control a hot wire foam cutter using LinuxCNC? Hi Peter, I just figured out how to get it working again. The patch seems to be based on a snapshot of the master branch somewhere at the end of January. On my machine I can reproduce the (very nice) results with these commands: git checkout dcbaa105aaa5494ba5eea296ca66df893bd5c9b6 -b xyuv-sammel-28012012 git apply --verbose ../0010-foam-xyuv-Modification-2.6-pre.patch cd src ./autogen.sh ./configure --enable-simulator make -j 2 . ../scripts/rip-environment linuxcnc (then load the foam-xyuv.ngc) By the way, I'm also toying around with with model air planes. I have a small project at gitorious which can be used as CAM generator. https://www.gitorious.org/foambladesuite It can currently read a special kind of DXF files and export them to nc-code. LinuxCNC integration is still very beta, but we are going to improve soon. I'm going to do an extra announcement when I've tested it on a foam cutter... With best regards, Michael On Wed, 25 Jan 2012 18:32:50 +0100 Peter Georgi georg...@bluewin.ch wrote: Hi, Ben Jakson published the two links below. Since I have a four axis (XYUV) hot wire foam cutter I jumped into the tube at youtube. Mr. Sammel implemented exactly what I was looking for a while. I manly use the cutter for wing panels for model air planes. I downloaded the patch. But how to install it, that it runs inside Axis? Any hint or help are very welcom. Regards Peter -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Non-Contact limit switch issues.
I'm bringing up my mini-mill and have encountered a weird problem: I'm trying to use pins 10, 11 12 on the printer port as limit switch inputs for X, Y, Z axes, respectively, but the pins are acting like outputs. The limits switches are active high, with ether voltage dividers or diodes in line for level correction and short circuit protection. When I test the limit switches when not connected to the PC they work as expected. When connected to the PC a tripped a limit switch might cause the voltage to move by 0.5V or so, but the voltage is still held above the TTL high threshold. The X-axis limit switch system consists of two OPB972 optical sensors (TTL level output), which have totem-pole output. Both are diode-ORed together with a 20K pulldown. The Y-axis limit switch system consists of two Honeywell 103SR12A-2 Hall sensors, which have active source outputs (Open emitter, 12V supply, ~12 volt active output, floating otherwise). Both are wired together and put through a 5.1K/2.2K resistor divider. The Z-axis limit switch system consists of two Parker Proprietary Hall sensors (TTL level output), which appear to have totem-pole outputs. As a precaution, I've diode-ORed them together with a 20K pulldown. I’ve got the following motherboard: ECS TIGT-I2(V1.0) Intel Atom D410 @ 1.66GHz BGA559 Intel NM10 Mini ITX Motherboard/CPU Combo http://www.newegg.com/Product/Product.aspx?Item=N82E16813135269 I’m running EMC 2.4.6. Any ideas? Do I just need lower impedance pulldowns? N.C. -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] parsing the current language dialect, and describing as EBNF [Was: question on gcode parsing]
I must admit I've I've watched this thread unfold with a bit of apprehension. Certainly the current direction has evolved to the point where the result will likely not be usable for my purposes. I don't see a way of using a flex/bison-based parser from python apart from native bindings, so in terms of having a portable parser or lint-type tool this would not result in one AFAIK. The grammar might provide a good starting point for me, though. Secondly, although gcode is certainly not a great language, I'm not sure I fully understand the motivation behind yet another custom gcode syntax extension. I have always thought decoupling was a good basic idea, and IMO the practical interface between LinuxCNC is a gcode file. As long as this interface is stable, and ideally as concise and standard as possible, it allows myriad CAM tools to reliably generate input files. Keeping it dumb IMO has great benefits. It allows CNC educational programs and those who learned basic gcode a long while back to continue to be productive. For the relatively smaller edge case of those wanting to hand-code sophisticated machine control, gcode (even the LinuxCNC flavor) is already a terrible starting point. Wouldn't it make more sense to just develop something like a simple python API that corresponds to (results in) machine motion operations (it could ultimately generate gcode), and modify the LinuxCNC interface to interpret those files line-by-line (the code displayed and stepped through would be the e.g. python, not gcode). Then you would have as much looping, conditional, file inclusion, etc. as you could hope for. Language design is fun, and there certainly is a trend toward domain-specific languages, but we already have many good choices for scripting languages that could be employed to be much more capable than any sort of gcode extension could ever be. Of course, I typically use low-end CAM or write gcode generators, and I am a relative LinuxCNC newbie, so perhaps I am not understanding the use case for an incrementally better custom gcode vs. using a mature scripting language. My two cents, Scott On Sat, Feb 4, 2012 at 9:48 PM, Erik Christiansen dva...@internode.on.netwrote: On 04.02.12 16:25, Michael Haberler wrote: This is different from the original language: the pre-oword syntax was context-free, which is why there's a meaningful EBNF in the Tom Kramer report, and working context-free parsers based on ANTLR and bison like here: http://fennetic.net/irc/emc3/src/emc/interpreter/) It is worth noting here that the link points to another grammar which is empty of working gcodes. Look in: http://fennetic.net/irc/emc3/src/emc/interpreter/rs274ngc-flex-bison/parser.ypp Below the top-level block structure, we see grammar for only expressions and parameter settings. Like the empty grammar posted upthread, it is devoid of any grammar for gcodes. After checking both parser.ypp and the lexer (scanner.l) several times, I find that the letter 'G' is passed through, like a dose of epsom salts, without touching the sides. The so-called parser does not even know that a gcode exists. It looks like an Alphabet parser with some expressions. The empty grammars(*1) put up so far look disappointingly like that first 2% of a grammar that a uni student has to whack together in order to pass computer science 101. All the hard work remains to be done. I wonder if there is one out there with any gcodes in it? On 04.02.12 16:25, Kenneth Lerman wrote: The use of matching labels to resolve ambiguity was just a cheap trick to lower the cost of implementation. There is no reason that we should keep the labels on control structures. We should then follow the same rules that C uses. +1 Erik (*1) Empty of any handling of the input. There's not even a yyerror() function to generate syntax error messages. Since a yacc/bison parser calls that function on any syntax error, it's hard to see how these toys can be called a working grammar. -- The Roman Rule The one who says it cannot be done should never interrupt the one who is doing it. -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- 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
Re: [Emc-users] parsing the current language dialect, and describing as EBNF [Was: question on gcode parsing]
For the relatively smaller edge case of those wanting to hand-code sophisticated machine control, gcode (even the LinuxCNC flavor) For a lot of us hand coding is not an edge case, the available free open source cam tools simply do not cater for anything over 3 axis milling. which is just a subset of the users. The poor syntax of the current gcode held me back for a while. Wouldn't it make more sense to just develop something like a simple python API that corresponds to (results in) machine motion operations (it could ultimately generate gcode), and modify the LinuxCNC interface to interpret those files line-by-line (the code displayed and stepped through would be the e.g. python, not gcode). I see no need for anything pythonesk in machine control. This just adds an obscure level of abstraction from the real machine. I too wrote a gcode generator for some of my standard shapes but found it was more elegant to do it in gcode as I could use sensible(ish) variable names. why enter in a form, generate code, transfer, when it is a simple edit to a standard gcode file. Gcode needs bringing up to date we no longer need cater for paper tape. Dave Caroline -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Non-Contact limit switch issues.
On Sunday, February 05, 2012 01:28:12 PM N. Christopher Perry did opine: I'm bringing up my mini-mill and have encountered a weird problem: I'm trying to use pins 10, 11 12 on the printer port as limit switch inputs for X, Y, Z axes, respectively, but the pins are acting like outputs. The limits switches are active high, with ether voltage dividers or diodes in line for level correction and short circuit protection. When I test the limit switches when not connected to the PC they work as expected. When connected to the PC a tripped a limit switch might cause the voltage to move by 0.5V or so, but the voltage is still held above the TTL high threshold. The X-axis limit switch system consists of two OPB972 optical sensors (TTL level output), which have totem-pole output. Both are diode-ORed together with a 20K pulldown. The Y-axis limit switch system consists of two Honeywell 103SR12A-2 Hall sensors, which have active source outputs (Open emitter, 12V supply, ~12 volt active output, floating otherwise). Both are wired together and put through a 5.1K/2.2K resistor divider. The Z-axis limit switch system consists of two Parker Proprietary Hall sensors (TTL level output), which appear to have totem-pole outputs. As a precaution, I've diode-ORed them together with a 20K pulldown. I’ve got the following motherboard: ECS TIGT-I2(V1.0) Intel Atom D410 @ 1.66GHz BGA559 Intel NM10 Mini ITX Motherboard/CPU Combo http://www.newegg.com/Product/Product.aspx?Item=N82E16813135269 I’m running EMC 2.4.6. Any ideas? Do I just need lower impedance pulldowns? N.C. Generally, when an input meets std ttl specs, it will take quite a bit lower R's than 20k to pull a std ttl gates input to a logic zero state. I know little about the D510, I have a D525 myself, which is driving a cnc4pc C1G opto isolated interface board and working great. This board claims excellent speed, as in 10ns propagation delays thru the opto stuffs. That seems rather fast for opto's, and I haven't measured it although I have the scope to do it with. Each input is programmable such that its default input is either pulled to the 5 volt rail, or to ground. The pullup or pulldown it presents is in the range of 4.5K to 5.0k, so in that case a 20k pulldown is not likely to be noticed. This isn't germane, but if I were to use a pulldown, I would chose a resistor capable of pulling it down to not more than .15 volts in order to maintain some semblance of noise immunity. That, for the current sourced from a std ttl input, might not be too much over 150 ohms. It is the voltage that counts and even in a completely noise free environment, anything above .6 volts is going to be very erratic. I think most who set limit switches up, wire then as NC and in series. LinuxCNC then only cares that a limit has been exceeded and stops everything. A similar lashup can be used as a single wire home sensor, using only 2 port pins for both functions. Hitting the switch opens the circuit sending a logic one upstream in either event and the home position is set at the center of the tables travel, but can be arbitrary as long is the switches are not tripped again by the move to the home position specified in the .ini file. The limit switch is also capable of being used as a home switch, simplifying that to a one pin input solution. In short, there are quite a few ways of solving that problem, if indeed it is one. But for this, you need to determine the total R it takes to pull it down to at most +0.15 volts when activated. And any 12 volt circuitry needs to limit the logic one to not more than +4.3 volts as some ttl inputs will object to a full 5.0 volt pullup, and nearly all will fuss at 5.5 or more. -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users 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 McEwan's Rule of Relative Importance: When traveling with a herd of elephants, don't be the first to lie down and rest. -- 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
[Emc-users] AXIS default jog speed on A-axis
I am using AXIS 2.4.7 (caption says 2.4.6) At startup jog speed on axis A is 2094 deg/min and maximum is 21600. More suitable in my case would be default 100 max 2000 or so. How do I change the jog speed defaults? I have also tried to change axis 3 in the .ini to TYPE = LINEAR. This seems to have no effect. In my current case linear is more natural than angular, but it does not matter really. Just tried it to see if jog settings would change. // Lars -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Workpiece is longer than the mill travel
On Sat, Feb 4, 2012 at 11:39 AM, Martin Patton mart...@gmail.com wrote: This is probably an easy one but I'm stuck. How do I stop the program, reposition the workpiece and restart the program without losing the spacing? Thanks, Marty as stated, it's really easy because you just start a new program. One thing I've learned for repositioning is that if you get a couple of pins that are exactly the size of the t-slots, it makes repositioning a lot easier. You put the pins in the t-slots and locate the part off of those. It also makes putting the part back on for re-work a lot easier. This assumes your t-slots are reasonably straight. On a Bpt, they are straight enough for the kind of work I do that requires repositioning. If you really wanted to dial in the part better than that, it would make a great starting point. Eric -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] parsing the current language dialect, and describing as EBNF [Was: question on gcode parsing]
I see no need for anything pythonesk in machine control. This just adds an obscure level of abstraction from the real machine. I too wrote a gcode generator for some of my standard shapes but found it was more elegant to do it in gcode as I could use sensible(ish) variable names. why enter in a form, generate code, transfer, when it is a simple edit to a standard gcode file. Gcode needs bringing up to date we no longer need cater for paper tape. To me your first sentence does not seem congruent with your second. Surely a real scripting language would allow for much more elegance and expressiveness than a gcode language extension. One does not seem necessarily more obscure or abstract than the other to me. Although I must admit I would rather point someone at an existing scripting language tutorial for variables, looping and conditionals than try to explain the LinuxCNC gcode extensions for the same, even with sweeter syntactic sugar. In that sense, using an existing scripting language seems much less obscure. Also, I am not proposing an intermediate step such as filling out a form, generating gcode, etc. The scripting API would be directly interpreted by LinuxCNC, allowing the sort of edit-in-place you describe. Whether it generated gcode or made NML calls (or some other approach) would be an API implementation detail not visible to the person running the program. Hope that helps clarify, Scott -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Workpiece is longer than the mill travel
Another cheat is mount a rotary table off centre (even outside the normal xy envelope) and then you can make larger parts, ok the gcode is not so simple unless you are making a gear. Dave Caroline -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] AXIS default jog speed on A-axis
On Sunday, February 05, 2012 02:16:37 PM Lars Andersson did opine: I am using AXIS 2.4.7 (caption says 2.4.6) At startup jog speed on axis A is 2094 deg/min and maximum is 21600. More suitable in my case would be default 100 max 2000 or so. How do I change the jog speed defaults? I have also tried to change axis 3 in the .ini to TYPE = LINEAR. This seems to have no effect. In my current case linear is more natural than angular, but it does not matter really. Just tried it to see if jog settings would change. In your .ini file, this section [TRAJ] AXES = 4 COORDINATES = X Y Z A MAX_ANGULAR_VELOCITY = 30.00 - DEFAULT_ANGULAR_VELOCITY = 10.00 --- ANGULAR_UNITS = degree --- You can adjust the arrowed values. Mine is a stepper driven POS not very fast too much backlash. :( AIUI, the ABC axis's are assumed to be rotary for most purposes. They correspond to having a axis of rotation that is aligned with X for A, Y for B and Z for C. Eg when the table is flat on the mills table facing up, then it becomes axis C, standing on the end of the mills table facing the other end of the mills table which may have a tail stock mounted on the other end, it is axis A There are similar entries in the individual AXIS sections: [AXIS_3] TYPE = ANGULAR HOME = 0.0 MAX_VELOCITY = 30.0 MAX_ACCELERATION = 200.0 STEPGEN_MAXACCEL = 300.0 I see I don't have any headroom in MAX_VELOCITY, which could lead to joint following errors, so I should add 5 to the axis 3 entry. New computer, new profile, new driver packages not at all optimized yet. :) For C use, the [AXIS_3] and [AXIS_4] entries need to be there but empty, and the above becomes [AXIS_5] HTH. Cheers Lars, 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 belief, n: Something you do not believe. -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] AXIS default jog speed on A-axis
Thanks Gene, change in [TRAJ] was the cure. From your post: [AXIS_3] TYPE = ANGULAR HOME = 0.0 MAX_VELOCITY = 30.0 MAX_ACCELERATION = 200.0 STEPGEN_MAXACCEL = 300.0 Not immediately obvious, why is MAX_VELOCITY used here, not MAX_ANGULAR_VELOCITY ? It is similar in my .ini // Lars -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Non-Contact limit switch issues.
gene heskett wrote: This board claims excellent speed, as in 10ns propagation delays thru the opto stuffs. That seems rather fast for opto's, and I haven't measured it although I have the scope to do it with. I don't believe it! If they are really opto-isolators and not some other technology like magnetic, then anything less than 100 ns is almost impossible. I use some expensive optos with amplifiers in them, and they swallow pulses less than 250 ns wide. I don't particularly worry about the propagation delay, but the minimum pulse width is a concern. Jon -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] parsing the current language dialect, and describing as EBNF [Was: question on gcode parsing]
Am 05.02.2012 um 19:07 schrieb Scott Hasse:
I must admit I've I've watched this thread unfold with a bit
of apprehension. Certainly the current direction has evolved to the point
where the result will likely not be usable for my purposes. I don't see a
way of using a flex/bison-based parser from python apart from native
There is no decision on a language change, or any tools to use at it, at least
I dont see one. I dont even see a proposal.
Btw my post was about a property of the current language, not a tool. That
property poses certain restrictions wrt to the current language on the kind and
way any tool would be used. I've thought myself a bit of Antlr since, and so
far I believe these restrictions apply here as well. I would love to be proven
wrong on that.
bindings, so in terms of having a portable parser or lint-type tool this
would not result in one AFAIK. The grammar might provide a good starting
point for me, though.
Secondly, although gcode is certainly not a great language, I'm not sure I
fully understand the motivation behind yet another custom gcode syntax
extension. I have always thought decoupling was a good basic idea, and IMO
the practical interface between LinuxCNC is a gcode file. As long as this
interface is stable, and ideally as concise and standard as possible, it
allows myriad CAM tools to reliably generate input files. Keeping it dumb
IMO has great benefits. It allows CNC educational programs and those who
learned basic gcode a long while back to continue to be productive.
Whatever happens, I think that the basic concept of a G-code block must be
retained - there is too much knowledge and experience and code out there.
This is why a similar idea like the author package never caught on (see
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?PythonBindings). Note also the current
interpreter has a fairly complete set of Canon Python bindings at the G-code
remapping level, I'm not sure anybody except me used them so far - too low
level, just a building block.
The control structure work added by Ken is very useful. I've worked on flow
control, fixed several issues, and added a feature here and there. However,
there are limitations given the current design. For instance, your lint-type
tool will not be able to decide in the general case whether a given program
*flow* will run or error (just think of subroutine names derived from
parameters - whether that works depends on the parameter value).
Another issue is that the current language drives a machine nicely, but
severely lacks in introspective capabilities. Predefined named parameters
helped a bit, HAL pin access helps a bit, but overall it's not thrilling. I
think I fixed the some aspect of the extensibility deficit with the remapping
work which *embeds* Python, but that works 100% under the hood. Run-from-line
needs work. Conditional breakpoints and the ability to change values during a
breakpoint would be nice.
--
That said, I concur with you that cooking up yet another scripting language is
not necessarily a good idea. Inventing one is fun, but then there's building,
documenting, teaching and maintaining a language with yet another set of
control structures, execution model and syntax, plus the not-so-fun aspect of
backwards compatibility.
Fact is, this project has scarce manpower to work on that. I would thing this
community would be better off reusing other work to the maximum extent
possible, in particular in areas which are not terribly relevant to improve the
actual machine control part of the system, which is the core asset. It's
positively not 'scripting'. And the question remains whether the result will
be worth the effort compared to other alternatives. If the end result doesnt
look all that different from another scripting language, I dont see the
rationale for a build, or extend decision in the first place.
I think using Python would be a terrific and stable base for control structures
and execution model, and would bring the rest of the language for free,
including its documentation, tuorials for humans, an outsourced stream of fixes
and upgrades, IDE's, an active community, other data types, a better
Run-from-Line, conditional breakpoints, you name it. For instance, the recent
proposal to add a string datatype - well, thats in place, and in a better shape
than we ever could.
Again, G-code blocks must be there, there is no point in forcing everybody to
dissolve blocks into a series of function calls.
One option is to retain rs274ngc as a 'domain specific language' in Python.
As an example for what the end user impact would be:
0100 if [#4711 GT 23]
G1 x10 y20
0100 endif
would mutate into something like
if param[4711] 23:
g('G1 x10 y20...')
For linear code old style scripts, and MDI in GUI's, the g('') noise can be
made to disappear if so desired. Flow control would move exclusively to the
Python level. Parameter arithmethic
Re: [Emc-users] Non-Contact limit switch issues.
On Sun, 2012-02-05 at 12:41 -0500, N. Christopher Perry wrote: I'm bringing up my mini-mill and have encountered a weird problem: I'm trying to use pins 10, 11 12 on the printer port as limit switch inputs for X, Y, Z axes, respectively, but the pins are acting like outputs. The parallel port 10, 11 and 12 pins should always have high impedance, so your sensor circuit outputs should act the same way whether they are connected to these pins or not. If connecting the sensor output wire to the parallel port pin keeps the signal voltage from toggling, then there is something wrong with the parallel port. Many motherboard parallel ports are now running on 3 Volts, I would think the inputs should be 5 Volt tolerant, but they may be very easy to short out. I avoid using the motherboard parallel ports. Blowing out a $15 PCI card is much cheaper than replacing a motherboard, plus these usually run on 5 Volts. It should be easy to check these inputs with a wire and a 2.5k Ohm resistor. Connect the wire to an input pin, then touch the wire to the PC's ground or a +5 Volt source. You should be able to see the logic state change with HALmeter, HALscope or the watch feature in the HAL configuration window. The limits switches are active high, with ether voltage dividers or diodes in line for level correction and short circuit protection. When I test the limit switches when not connected to the PC they work as expected. When connected to the PC a tripped a limit switch might cause the voltage to move by 0.5V or so, but the voltage is still held above the TTL high threshold. The X-axis limit switch system consists of two OPB972 optical sensors (TTL level output), which have totem-pole output. Both are diode-ORed together with a 20K pulldown. I would avoid totem-pole outputs. The limit signal should be active low so that if the sensor, power supply or wire fails, the limit will trip. Open collector outputs make that easy. One just needs a pull up to the supply voltage to limit the collector current. A divider would work too, but I would rather have the full voltage drive an opto-isolator protecting the parallel port input. I avoid optical sensors unless they can be enclosed in a liquid proof container. The Y-axis limit switch system consists of two Honeywell 103SR12A-2 Hall sensors, which have active source outputs (Open emitter, 12V supply, ~12 volt active output, floating otherwise). Both are wired together and put through a 5.1K/2.2K resistor divider. The 103R's are a nice sensor, but they are expensive. I would go with the sink version of this sensor, but $.60 can get you a sensor that works very nearly as well in a hobby environment. The Z-axis limit switch system consists of two Parker Proprietary Hall sensors (TTL level output), which appear to have totem-pole outputs. As a precaution, I've diode-ORed them together with a 20K pulldown. Another thing, proper soft limits should be setup. With these setup, there is another layer of safety and they are more convenient because an axis will come to a controlled stop when it hits a soft limit. One can just jog away from the limit, whereas hitting a hard limit requires finding and selecting the limit override, then backing off. Wiring each limit for each joint to its own input is also more convenient than or'ing different limits together. PCI parallel ports are cheap and can provide plenty of extra I/O. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] AXIS default jog speed on A-axis
On Sunday, February 05, 2012 08:35:42 PM Lars Andersson did opine: Thanks Gene, change in [TRAJ] was the cure. From your post: [AXIS_3] TYPE = ANGULAR HOME = 0.0 MAX_VELOCITY = 30.0 MAX_ACCELERATION = 200.0 STEPGEN_MAXACCEL = 300.0 Not immediately obvious, why is MAX_VELOCITY used here, not MAX_ANGULAR_VELOCITY ? It is similar in my .ini // Lars Humm, by golly, I believe that is an excellent question, and one I do NOT know the answer to! Perhaps one of the other code masters here can illuminate that for both of us? Even a pointer to the correct docs would be great. Sorry, I was trying to 'pay my bills here'. And I do owe this list quite a bit for the help I have received. 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 On the other hand, life can be an endless parade of TRANSSEXUAL QUILTING BEES aboard a cruise ship to DISNEYWORLD if only we let it!! -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Non-Contact limit switch issues.
On Sunday, February 05, 2012 08:41:06 PM Jon Elson did opine: gene heskett wrote: This board claims excellent speed, as in 10ns propagation delays thru the opto stuffs. That seems rather fast for opto's, and I haven't measured it although I have the scope to do it with. I don't believe it! If they are really opto-isolators and not some other technology like magnetic, then anything less than 100 ns is almost impossible. I use some expensive optos with amplifiers in them, and they swallow pulses less than 250 ns wide. I don't particularly worry about the propagation delay, but the minimum pulse width is a concern. Jon Frankly, neither do I Jon, in fact when I read that, I immediately ordered up a whole trainload of skepticism. I didn't want to run out. In my present setup, I have the step pulse reset time at 4 u-secs, creeping down about .5 u-secs at a time when I think of it, which isn't often, till I see skip problems. I was cheerfully using about 1 microsecond with direct drive into a xylotex board. Stepconfig originally set it at 5 u-secs. All of those timing specs for the MM542 drivers seem to be a proprietary secret. They seem to be working well, but who knows when one of those specs has been pushed too far? Unless the machine does wild crazy things that are obvious. Then you'll finally know but likely not which one you violated unless keeping notes. 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 I believe a little incompatibility is the spice of life, particularly if he has income and she is pattable. -- Ogden Nash -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Workpiece is longer than the mill travel
Yes, like a jig for cutting a guitar fretboard for instance. Cut twelve frets, move the fretboard, cut six more. I think I just need to make a spacer. Thanks for the ideas. -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] parsing the current language dialect, and describing as EBNF
On 05.02.12 18:35, Dave Caroline wrote: For the relatively smaller edge case of those wanting to hand-code sophisticated machine control, gcode (even the LinuxCNC flavor) For a lot of us hand coding is not an edge case, the available free open source cam tools simply do not cater for anything over 3 axis milling. which is just a subset of the users. +1 The constructs of the LinuxCNC extended gcode language are fine for my purposes too. It's just that the current parser infrastructure does not meet the requirements expressed by a number of users: 1) Document the legal grammar. 2) Accept the current gcode extensions without useless obfuscating trash characters surrounding keywords and variable names. (They are only there because the current parser can't cope without. They are not there for user benefit.) 3) In Addition to accepting the _current_gcode_syntax_ (minus the unhelpful guff surrounding keywords and variable names), accept _also_ a more human readable form of the very same _current_gcode_syntax_. Several contributors have expressed interest in exploring this direction. My interpretation is that the other form of the LinuxCNC dialect should make clearer _what_ is programmed, rather than just recording raw machine code, which requires more mental translation effort, and can lead to wasted workpieces when under pressure, or on a hot Friday afternoon. Here, an example or two may be clearer than general arm waving. The HR (human readable) part of my growing dual grammar for an input filter for LinuxCNC currently accepts this input: » ; Setting of the coordinate system to one of the 9 workspaces uses ; a curious hotch-potch of numbers, masquerading as commands. ; Here instead, we state _what_ is happening. Workspace: 1 Workspace: 7 Workspace: 9 Workspace: 10 End « to generate: » G54 G59.1 G59.3 ; - Modal Error: Illegal Workspace M2 « Now the numbering is the same as for G10 L2, and we don't need to remember that G57 is married to G10 L2 P4. Because that part of the grammar and its handling were only written last night, the error handling does not yet display the offending source line. (Perhaps later today. The comments are handled too, but need not be repeated in this post.) Should we, though, be more verbose, using syntax like: » Select Workspace 2 ; Needs to be differentiated from G10 L2: Define Workspace 2 X3.2 Y6.4 « Now, for hand written gcode programs, does such explicitness improve clarity? (Here, I'll duck for cover, and count to fifty. :-) Incidentally is there any documentation for G10 L20 which more clearly explains what it does? Do the two wiki sections mean that L2 sets the nominated workspace origin to axes, expressed in the currently active coordinate system, while L20 sets the current position in the currently active coordinate system to be the position in the nominated workspace given by axes? The grammar also currently translates: Plane: XY to G17 etc. The poor syntax of the current gcode held me back for a while. It seems to be worth working on, then. Wouldn't it make more sense to just develop something like a simple python API that corresponds to (results in) machine motion operations (it could ultimately generate gcode), and modify the LinuxCNC interface to interpret those files line-by-line (the code displayed and stepped through would be the e.g. python, not gcode). I see no need for anything pythonesk in machine control. This just adds an obscure level of abstraction from the real machine. +377 I too wrote a gcode generator for some of my standard shapes but found it was more elegant to do it in gcode as I could use sensible(ish) variable names. why enter in a form, generate code, transfer, when it is a simple edit to a standard gcode file. Yes, my aim is to remain true¹ to the LinuxCNC dialect, just with optionally different pronunciation in one of the two grammars. e.g. End instead of M2, and End_Pallet instead of M30. Gcode needs bringing up to date we no longer need cater for paper tape. May I borrow that for my sig quotes? :-)) I have long felt that it was for paper tape and discrete valve controllers with 8 bytes of memory that those funny numbers were used instead of real commands which humans can read. Granted, if I had them ingrained in my brain, after decades of use, I would not change either. There is no reason to. An optional input filter only provides flexibility to anyone wanting more. The filter I'm playing with will offer decluttered old syntax, and a more human readable form. Should it be completed, its use is discretionary. Its formally documented grammars seem an appropriate foil to the python free-reign available at the other end of the LinuxCNC interpreter, also optional. Erik ¹ That doesn't mean including the useless clutter characters which
[Emc-users] Docs clarification needed.
Greetings Guys; 2 questions actually: 1. What is the schedule saying about the renaming of this list to linuxcnc-users@etc? 2. I apparently am having trouble understanding the G92 family docs, which state: G92 makes the current point have the coordinates you want (without motion), where the axis words contain the axis numbers you want. All axis words are optional, except that at least one must be used. If an axis word is not used for a given axis, the coordinate on that axis of the current point is not changed. When G92 is executed, the origins of all coordinate systems move. They move such that the value of the current controlled point, in the currently active coordinate system, becomes the specified value. All coordinate system’s origins are offset this same distance. For example, suppose the current point is at X=4 and there is currently no G92 offset active. Then G92 x7 is programmed. This moves all origins -3 in X, which causes the current point to become X=7. This -3 is saved in parameter 5211. Being in incremental distance mode has no effect on the action of G92. G92 offsets may be already be in effect when the G92 is called. If this is the case, the offset is replaced with a new offset that makes the current point become the specified value. It is an error if: all axis words are omitted. LinuxCNC stores the G92 offsets and reuses them on the next run of a program. To prevent this, one can program a G92.1 (to erase them), or program a G92.2 (to remove them - they are still stored). Ok Then: G92.1 - reset axis offsets to zero and set parameters 5211 - 5219 to zero. G92.2 - reset axis offsets to zero. G93.3 Restore Axis Offsets G93.3 - set the axis offset to the values saved in parameters 5211 to 5219 You can set axis offsets in one program and use the same offsets in another program. Program G92 in the first program. This will set parameters 5211 to 5219. Do not use G92.1 in the remainder of the first program. The parameter values will be saved when the first program exits and restored when the second one starts up. Use G92.3 near the beginning of the second program. That will restore the offsets saved in the first program. That seems to intimate that using a G92 axis number not only stores the desired position in the axis named, but also stores the rest of the axis positions in 5211-5219. What I am trying to do is add some position offsets on a per axis basis, but if a G92 actually updates all axis's to the current location except the one named in the G92 command, then the subsequent execution of a g92.1 it seems is restoring bogus numbers, as is evidenced when a new home operation is done, the z reading of 4.0681 doesn't revert to 0.. So, assuming the machine is sitting about .040 above my little brass tube I set in the pallet, nominally at X-0.3 Y+0.2, where I run holefinder.ngc in order to locate the precise location that brass contact within half a thou both ways. This routine uses G38.2 a total of five times, and sets #100 to the real X location, and #101 to the real Y location. I then use those #vars to move the machine to a position that is X-0.100, y0.000 from what should be the boards left front corner, and home x and y there. Then I raise it far enough to change out the drill chuck holding the conical tipped metal probe out for a collet and a 1/8 shank engraving bit, which raises the effective tool tip by about 4 since the collet is that much shorter than the drill chuck when its mounted,about 0.1 and run it down slowly with the down key until the bit contacts the pcb triggering the stop during a jog function. At that point, I home the Z. Its a bit abitrary as I do that same G38.2 once in the otedautoz call and use G92 Z to install a very small offset, a thou or less, in Z so I can fine tune the depth of the engraving done in the top.etch file. Now, in the remainder of the files, 4 more to complete the board, and at the present I am using the holefinder to locate a hole drilled in the board, which when the board is turned end for end, is used to install the offset value into the x so that the etch and bot.drill will result in the drill bit tips exactly meeting in the center of each hole. I know I will have to break this holefinder into 2 files since I don't want to muck with the Y location when running it the second time. Obviously I have to use G92 to install the Z offset that compensates for the drill length, that is unavoidable from my reading. I have no lengths in my tool table since I'm using a drill chuck, making those lengths arbitrary and requiring I G38.2 to find this out after every tool change. So what is the sequence of G9X's I must use in the remaining 5 files it takes to complete a board?, and which will not result in the machine moving its Z zero up in the air, both in axis
Re: [Emc-users] Non-Contact limit switch issues.
Thanks Kirk, I did as you suggested, and while I was at it I measured the series current when shorted and found that it was ~2mA. My pulldowns were in fact too high an impedance. I dropped them to ~300 ohms and everything is now working as expected. N.C. On Feb 05, 2012, at 05:56 PM, Kirk Wallace kwall...@wallacecompany.com wrote: On Sun, 2012-02-05 at 12:41 -0500, N. Christopher Perry wrote: I'm bringing up my mini-mill and have encountered a weird problem: I'm trying to use pins 10, 11 12 on the printer port as limit switch inputs for X, Y, Z axes, respectively, but the pins are acting like outputs. The parallel port 10, 11 and 12 pins should always have high impedance, so your sensor circuit outputs should act the same way whether they are connected to these pins or not. If connecting the sensor output wire to the parallel port pin keeps the signal voltage from toggling, then there is something wrong with the parallel port. Many motherboard parallel ports are now running on 3 Volts, I would think the inputs should be 5 Volt tolerant, but they may be very easy to short out. I avoid using the motherboard parallel ports. Blowing out a $15 PCI card is much cheaper than replacing a motherboard, plus these usually run on 5 Volts. It should be easy to check these inputs with a wire and a 2.5k Ohm resistor. Connect the wire to an input pin, then touch the wire to the PC's ground or a +5 Volt source. You should be able to see the logic state change with HALmeter, HALscope or the watch feature in the HAL configuration window. The limits switches are active high, with ether voltage dividers or diodes in line for level correction and short circuit protection. When I test the limit switches when not connected to the PC they work as expected. When connected to the PC a tripped a limit switch might cause the voltage to move by 0.5V or so, but the voltage is still held above the TTL high threshold. The X-axis limit switch system consists of two OPB972 optical sensors (TTL level output), which have totem-pole output. Both are diode-ORed together with a 20K pulldown. I would avoid totem-pole outputs. The limit signal should be active low so that if the sensor, power supply or wire fails, the limit will trip. Open collector outputs make that easy. One just needs a pull up to the supply voltage to limit the collector current. A divider would work too, but I would rather have the full voltage drive an opto-isolator protecting the parallel port input. I avoid optical sensors unless they can be enclosed in a liquid proof container. The Y-axis limit switch system consists of two Honeywell 103SR12A-2 Hall sensors, which have active source outputs (Open emitter, 12V supply, ~12 volt active output, floating otherwise). Both are wired together and put through a 5.1K/2.2K resistor divider. The 103R's are a nice sensor, but they are expensive. I would go with the sink version of this sensor, but $.60 can get you a sensor that works very nearly as well in a hobby environment. The Z-axis limit switch system consists of two Parker Proprietary Hall sensors (TTL level output), which appear to have totem-pole outputs. As a precaution, I've diode-ORed them together with a 20K pulldown. Another thing, proper soft limits should be setup. With these setup, there is another layer of safety and they are more convenient because an axis will come to a controlled stop when it hits a soft limit. One can just jog away from the limit, whereas hitting a hard limit requires finding and selecting the limit override, then backing off. Wiring each limit for each joint to its own input is also more convenient than or'ing different limits together. PCI parallel ports are cheap and can provide plenty of extra I/O. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- 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 Emc-users@lists.sourceforge.net
[Emc-users] rho-sigma machine?
List: Does anyone know of a Linuxcnc user that has implemented a working rho-sigma machine, eg. one linear axis and one rotary axis. The kins should not be difficult and it should prove to be quite stiff. Dave -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] rho-sigma machine?
On Sun, 5 Feb 2012 21:49:44 -0800 dave dengv...@charter.net wrote: List: Does anyone know of a Linuxcnc user that has implemented a working rho-sigma machine, eg. one linear axis and one rotary axis. The kins should not be difficult and it should prove to be quite stiff. Dave Yes, it is bad form to answer your own post but, I hope, not to correctly name the config ... rho-theta I think is the more normal version. Duh. ... and it is too late for more coffee. D -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] rho-sigma machine?
I was very seriously thinking about a machine like that, but with the rotary positioned at an angle. and an extra linear axis. We are waiting for the customer to make up his mind. All problems I saw was kinematics which as you said are not all that involved. And perhaps some python script to massage the output of the CAM package. Mainly since the feedrate depends very much on the cutter tip distance from the centerline of the rotary axis. In my case the cutter might even pass the centerline of the workpiece. But all that is only maths in the end. Have fun j. On Mon, Feb 6, 2012 at 7:49 AM, dave dengv...@charter.net wrote: List: Does anyone know of a Linuxcnc user that has implemented a working rho-sigma machine, eg. one linear axis and one rotary axis. The kins should not be difficult and it should prove to be quite stiff. Dave -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Different way to do offsets
Hi Guys; I think after a splitting headache from 3 hours of reading docs (too damned sweet too according to my sugar meter), I may have a better idea for the offsets. 1. Use tholefinder.ngc to locate home dead in the center of that brass tube which is nominally -0.2X and +0.1Y from the left front corner of the board. 2. Raise Z out of tubing but I think I did that in (t/b)holefinder.ngc. 3. By hand using LinuxCNC's fixed jog, move machine +0.1000x and -0.2000y, and HOME XY. This will establish a HOME that is -0.1X and 0.0Y from left front corner of board. The idea of the X offset there was to better center the circuit on the board. 4. Run Z up and swap drill chuck and probe for engraving bit. 5. Run to 0.2x 0.1 y, and run slowly down till the bit stops with error message as it touches the board. Probe hooked up of course. HOME Z. 6. Use G10 L2 P2 X0.2000 Y0.1000 Z0.000 to establish that G55 is the machines operating position image to be used for all XY ops till top of board is done, etch, text drill. Z will get diddled extensively particularly as the last *.top.drill file runs. 7. Quick dirty explanation, for the top of the boards, in tedautoz.ngc use G10 L2 P2 Xoffset Yoffset Zoffset and force use of G55. (This is why there is a tedautoz, a bedautoz, tholefinder and bholefinder since t* stuff will use G55, and b* stuff will use G56) 8. For the bottoms of the board, again Set G54 to do the probing and use the known G54 locations to probe for Z offset. We know for this board the X offset for the bottom etch drill will be a hole drilled all the way through by top.drill at about X=2.195 Y=0.1, so drive it to about there, more or less centered in the reference hole, and run bholefinder.ngc, AFTER painting the hole with a half drop of deicer repair fluid and letting it cure properly. 9. Then remount the board and run bholefinder which will set the figure in #100 to the offset + 0.1 needed of offset the original -0.1 I used to move the top board pattern so it was better centered. 10. When bholefinder is done it will leave the correct x and y offsets in memory in #100 #101. They will be shown with (debug, X=#100 Y=#101) everytime it runs. If my pallet is any good this time the Y(#101) values should be within a thou and ignorable. 11. These offsets are then incorporated by bedautoz.ngc to set G10 L2 P3 Xoffset Yoffset as it will also switch to G54 to probe the Z depth, then set that in the above G10 L2 P3 Xvar Yvar Zvar, and set the final co-ord model to G56 so the bottom etching and drilling will run in that mapping. This is almost making sense to me, but I ran out of coffee 3 hours ago, so what do you fellows think? A lot of this hasn't been written in yet, but will be by the time it warms up enough to hit the shop tomorrow. 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 There can be no daily democracy without daily citizenship. -- Ralph Nader -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Non-Contact limit switch issues.
On Mon, 2012-02-06 at 05:08 +, N. Christopher Perry wrote: Thanks Kirk, I did as you suggested, and while I was at it I measured the series current when shorted and found that it was ~2mA. My pulldowns were in fact too high an impedance. I dropped them to ~300 ohms and everything is now working as expected. N.C. I'm glad you got it sorted out, but I think it was Gene that caught the resistor value being too high. I'll put a gold star by his name, and requisition another beer or two for a toast. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
