You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(90) |
Jun
(272) |
Jul
(250) |
Aug
(93) |
Sep
(150) |
Oct
(112) |
Nov
(128) |
Dec
(205) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(179) |
Feb
(104) |
Mar
(94) |
Apr
(121) |
May
(141) |
Jun
(54) |
Jul
(75) |
Aug
(158) |
Sep
(127) |
Oct
(196) |
Nov
(227) |
Dec
(203) |
2005 |
Jan
(191) |
Feb
(165) |
Mar
(161) |
Apr
(120) |
May
(155) |
Jun
(38) |
Jul
(131) |
Aug
(165) |
Sep
(227) |
Oct
(227) |
Nov
(314) |
Dec
(113) |
2006 |
Jan
(323) |
Feb
(126) |
Mar
(276) |
Apr
(225) |
May
(217) |
Jun
(232) |
Jul
(299) |
Aug
(249) |
Sep
(129) |
Oct
(236) |
Nov
(243) |
Dec
(217) |
2007 |
Jan
(245) |
Feb
(326) |
Mar
(511) |
Apr
(258) |
May
(269) |
Jun
(286) |
Jul
(403) |
Aug
(605) |
Sep
(285) |
Oct
(643) |
Nov
(354) |
Dec
(393) |
2008 |
Jan
(454) |
Feb
(472) |
Mar
(482) |
Apr
(544) |
May
(636) |
Jun
(441) |
Jul
(400) |
Aug
(498) |
Sep
(487) |
Oct
(688) |
Nov
(904) |
Dec
(747) |
2009 |
Jan
(849) |
Feb
(373) |
Mar
(397) |
Apr
(774) |
May
(526) |
Jun
(713) |
Jul
(514) |
Aug
(261) |
Sep
(475) |
Oct
(666) |
Nov
(670) |
Dec
(495) |
2010 |
Jan
(478) |
Feb
(254) |
Mar
(857) |
Apr
(488) |
May
(633) |
Jun
(333) |
Jul
(434) |
Aug
(516) |
Sep
(839) |
Oct
(523) |
Nov
(551) |
Dec
(610) |
2011 |
Jan
(523) |
Feb
(625) |
Mar
(759) |
Apr
(555) |
May
(356) |
Jun
(410) |
Jul
(543) |
Aug
(522) |
Sep
(551) |
Oct
(722) |
Nov
(594) |
Dec
(604) |
2012 |
Jan
(1269) |
Feb
(1005) |
Mar
(842) |
Apr
(962) |
May
(1283) |
Jun
(770) |
Jul
(633) |
Aug
(895) |
Sep
(311) |
Oct
(510) |
Nov
(623) |
Dec
(573) |
2013 |
Jan
(359) |
Feb
(466) |
Mar
(512) |
Apr
(799) |
May
(711) |
Jun
(775) |
Jul
(593) |
Aug
(548) |
Sep
(555) |
Oct
(788) |
Nov
(757) |
Dec
(496) |
2014 |
Jan
(456) |
Feb
(647) |
Mar
(604) |
Apr
(522) |
May
(603) |
Jun
(490) |
Jul
(599) |
Aug
(343) |
Sep
(535) |
Oct
(705) |
Nov
(742) |
Dec
(518) |
2015 |
Jan
(335) |
Feb
(473) |
Mar
(589) |
Apr
(462) |
May
(641) |
Jun
(633) |
Jul
(468) |
Aug
(290) |
Sep
(639) |
Oct
(425) |
Nov
(510) |
Dec
(565) |
2016 |
Jan
(763) |
Feb
(548) |
Mar
(608) |
Apr
(602) |
May
(608) |
Jun
(268) |
Jul
(286) |
Aug
(416) |
Sep
(455) |
Oct
(736) |
Nov
(312) |
Dec
(382) |
2017 |
Jan
(297) |
Feb
(701) |
Mar
(600) |
Apr
(482) |
May
(481) |
Jun
(469) |
Jul
(397) |
Aug
(312) |
Sep
(123) |
Oct
(544) |
Nov
(319) |
Dec
(250) |
2018 |
Jan
(224) |
Feb
(152) |
Mar
(274) |
Apr
(308) |
May
(407) |
Jun
(128) |
Jul
(283) |
Aug
(350) |
Sep
(131) |
Oct
(246) |
Nov
(186) |
Dec
(240) |
2019 |
Jan
(259) |
Feb
(223) |
Mar
(597) |
Apr
(493) |
May
(202) |
Jun
(227) |
Jul
(232) |
Aug
(201) |
Sep
(221) |
Oct
(238) |
Nov
(167) |
Dec
(355) |
2020 |
Jan
(310) |
Feb
(474) |
Mar
(430) |
Apr
(427) |
May
(666) |
Jun
(660) |
Jul
(758) |
Aug
(416) |
Sep
(599) |
Oct
(305) |
Nov
(387) |
Dec
(498) |
2021 |
Jan
(453) |
Feb
(299) |
Mar
(451) |
Apr
(233) |
May
(129) |
Jun
(632) |
Jul
(513) |
Aug
(181) |
Sep
(199) |
Oct
(227) |
Nov
(192) |
Dec
(249) |
2022 |
Jan
(272) |
Feb
(295) |
Mar
(321) |
Apr
(249) |
May
(139) |
Jun
(122) |
Jul
(134) |
Aug
(70) |
Sep
(178) |
Oct
(182) |
Nov
(200) |
Dec
(88) |
2023 |
Jan
(172) |
Feb
(68) |
Mar
(84) |
Apr
(52) |
May
(53) |
Jun
(73) |
Jul
(120) |
Aug
(101) |
Sep
(101) |
Oct
(70) |
Nov
(74) |
Dec
(126) |
2024 |
Jan
(58) |
Feb
(50) |
Mar
(82) |
Apr
(154) |
May
(108) |
Jun
(25) |
Jul
(53) |
Aug
(71) |
Sep
(29) |
Oct
|
Nov
|
Dec
|
From: Alex J. <ale...@ro...> - 2008-12-15 20:01:17
|
Also look at halui for some positions exported. Regards, Alex ----- Original Message ----- From: "John Kasunich" <jmk...@fa...> To: "Enhanced Machine Controller (EMC)" <emc...@li...> Sent: Monday, December 15, 2008 9:43 PM Subject: Re: [Emc-users] Pyvcp position number > mci...@di... wrote: >> I would like to add a PYVCP that shows the actual X, Y, and Z position >> but larger than the Axis gui does standard. I have a working PYVCP panel >> but I am having trouble picking the correct hook into hal. I used Xpos, >> Ypos and Zpos and it responds to the movement of the axis but they do >> not match position. Does anyone know the actual variable that will give >> me exactly what is shown on the Axis gui for X, Y and Z position? >> > > The positions available in HAL are not going to be the one you want. > HAL is used mostly for low level stuff - motor control, etc. It doesn't > have access to things like g-code offsets, tool length offsets, and all > the other "interpreter-only" things that affect position. > > I believe there is a way to make the displays in Acis bigger, you might > want to check the wiki for that. > > Regards, > > John Kasunich > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, > Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Emc-users mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-users -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.18/1849 - Release Date: 15.12.2008 09:01 |
From: John K. <jmk...@fa...> - 2008-12-15 19:43:27
|
mci...@di... wrote: > I would like to add a PYVCP that shows the actual X, Y, and Z position > but larger than the Axis gui does standard. I have a working PYVCP panel > but I am having trouble picking the correct hook into hal. I used Xpos, > Ypos and Zpos and it responds to the movement of the axis but they do > not match position. Does anyone know the actual variable that will give > me exactly what is shown on the Axis gui for X, Y and Z position? > The positions available in HAL are not going to be the one you want. HAL is used mostly for low level stuff - motor control, etc. It doesn't have access to things like g-code offsets, tool length offsets, and all the other "interpreter-only" things that affect position. I believe there is a way to make the displays in Acis bigger, you might want to check the wiki for that. Regards, John Kasunich |
From: <mci...@di...> - 2008-12-15 19:38:31
|
I would like to add a PYVCP that shows the actual X, Y, and Z position but larger than the Axis gui does standard. I have a working PYVCP panel but I am having trouble picking the correct hook into hal. I used Xpos, Ypos and Zpos and it responds to the movement of the axis but they do not match position. Does anyone know the actual variable that will give me exactly what is shown on the Axis gui for X, Y and Z position? Thanks, Mike |
From: Stephen W. P. <sp...@so...> - 2008-12-15 19:16:05
|
Tom wrote: >Tom <kestreltom@...> writes: > > >>I will look at >>the outputs on the scope tomorrow. Also, I connected my cable shield to power >>ground in the computer ribbon cable, so that may be causing excessive noise >>feedback. >>You have to jumper the Mesa 7i33 for differential inputs, and I think it has >>noise filtering. >> >>Thanks, >>Tom >> >> >Well, I checked the differential encoder outputs on a scope on the machine while >running, and they are clean as a whistle all the way up to max motor rpm. I >re-routed the cable shield to chassis Gnd instead of power Gnd, and that helped >a little. > > OK, noise reduction is a good thing :) (Incidentally, I was asking about additional external filtering that might have reduced the bandwidth of the signal, not the filtering mode of the 7i33) >My pyVCP spindle speed bar display (the one that jumps around above 3000rpm) is >linked to "rev-scaled" which runs in a slow thread. I may need to adjust the >thread timing, and route the raw encoder counts through a lowpass filter. > > The newer Mesa drivers have an estimated velocity output, which should be pretty accurate. The scaling (*60) should be able to run in the servo thread just fine. I'm not sure when the velocity output was added, but I'm pretty sure it's in the hostmot2 drivers in EMC2 2.2.8. - Steve |
From: Tom <kes...@ya...> - 2008-12-15 19:08:19
|
Tom <kestreltom@...> writes: > I will look at > the outputs on the scope tomorrow. Also, I connected my cable shield to power > ground in the computer ribbon cable, so that may be causing excessive noise > feedback. > You have to jumper the Mesa 7i33 for differential inputs, and I think it has > noise filtering. > > Thanks, > Tom Well, I checked the differential encoder outputs on a scope on the machine while running, and they are clean as a whistle all the way up to max motor rpm. I re-routed the cable shield to chassis Gnd instead of power Gnd, and that helped a little. My pyVCP spindle speed bar display (the one that jumps around above 3000rpm) is linked to "rev-scaled" which runs in a slow thread. I may need to adjust the thread timing, and route the raw encoder counts through a lowpass filter. Tom |
From: Chris R. <ch...@ti...> - 2008-12-15 16:39:52
|
On Mon, Dec 15, 2008 at 09:34:53AM -0600, Len Shelton wrote: > Is there a code to just simply end a program? I have a scenario where I > don't want to reset my offsets (M2 or M30) and I don't have a cycle start > button (which makes sense with M60), but I want to jog the machine manually > between runs. Axis keeps warning me that my program doesn't have a percent > sign or end of program, so I thought maybe a percent sign would work, but it > does not. This warning is really annoying. You have to start AND end with the % as stated here: http://www.linuxcnc.org/docs/html/gcode_main.html#cha:Language-Overview |
From: Len S. <le...@pr...> - 2008-12-15 15:35:53
|
Is there a code to just simply end a program? I have a scenario where I don't want to reset my offsets (M2 or M30) and I don't have a cycle start button (which makes sense with M60), but I want to jog the machine manually between runs. Axis keeps warning me that my program doesn't have a percent sign or end of program, so I thought maybe a percent sign would work, but it does not. This warning is really annoying. >Len |
From: Tom <kes...@ya...> - 2008-12-15 05:53:00
|
Stephen Wille Padnos <spadnos@...> writes: > I think there's something off in your calculations :) > > 2000 counts/rev * 3000 revs/min = 6,000,000 counts/minute > Dividing by 60 gives 100,000 counts/second at 3000 RPM, at 6000 RPM it > would be 200 kHz. Stephen, I forgot to mention that I have a 1:1.5 step up pulley driving the spindle. Motor top speed is limited to 3,540 right now, so that is where I got my 120 KHz. > Are you sure the encoders are up to it? Do you have differential or > single ended encoders? Is there noise filtering on the encoder lines? The encoder is a older Northern Precision Labs differential model. The line drivers in the encoder are DS8830N(s) - I checked the driver's output full wave propagation delays which are approx 35 ns max, which should be good for 250KHz. I could not find a spec sheet on the encoder itself. It is likely that the encoder has a bandwidth limitation that is causing my problem. I will look at the outputs on the scope tomorrow. Also, I connected my cable shield to power ground in the computer ribbon cable, so that may be causing excessive noise feedback. You have to jumper the Mesa 7i33 for differential inputs, and I think it has noise filtering. Thanks, Tom |
From: Stephen W. P. <sp...@so...> - 2008-12-15 03:58:05
|
Tom wrote: >I am using the Mesa 5i20/7i33 system to retrofit my knee mill. I just finished >installing a 500 line (2000 ppr) encoder on the spindle, it is connected to the >Enc03 quadrature inputs on P2. >My timing settings in my ini file are: >BASE_PERIOD = 35000 > > Unless you're using "fast" I/O on the parallel port or similar, you probably don't need the BASE thread at all. >SERVO_PERIOD = 1000000 >TRAJ_PERIOD = 10000000 > > These are fine, though these days the TRAJ thread often gets run at the same rate as the servo thread (1ms). >My spindle is capable of turning at a max of about 6000 rpm. But above 3000 rpm, >my floating point value on the hal pin: "rev-scaled" starts to bounce all over >the place. At full spindle speed my encoder is turning at the rate of 120,000Hz >(pulses per second). > > I think there's something off in your calculations :) 2000 counts/rev * 3000 revs/min = 6,000,000 counts/minute Dividing by 60 gives 100,000 counts/second at 3000 RPM, at 6000 RPM it would be 200 kHz. Are you sure the encoders are up to it? Do you have differential or single ended encoders? Is there noise filtering on the encoder lines? >My question is: Is this too fast for my servo thread? If so, is it possible to >read every other pulse? > > No, this isn't too fast. The Mesa board can count at 1 MHz (x4 = 4 million counts/sec) in single ended mode, or ~10 MHz (40 M counts/sec) in differential mode. The manual does have a note: "The maximum input frequency may be lower with encoders that have high value (>1K Ohm) pullup resistors on open collector outputs." The counter in the Mesa card shouldn't overflow between reads (at a 1ms servo rate) until you get to 32 million counts/sec (or 8 billion if it's 24 bits, I don't remember which it is :) ) - Steve |
From: Tom <kes...@ya...> - 2008-12-15 03:41:41
|
I am using the Mesa 5i20/7i33 system to retrofit my knee mill. I just finished installing a 500 line (2000 ppr) encoder on the spindle, it is connected to the Enc03 quadrature inputs on P2. My timing settings in my ini file are: BASE_PERIOD = 35000 SERVO_PERIOD = 1000000 TRAJ_PERIOD = 10000000 My spindle is capable of turning at a max of about 6000 rpm. But above 3000 rpm, my floating point value on the hal pin: "rev-scaled" starts to bounce all over the place. At full spindle speed my encoder is turning at the rate of 120,000Hz (pulses per second). My question is: Is this too fast for my servo thread? If so, is it possible to read every other pulse? Thanks, Tom |
From: Stuart S. <st...@gm...> - 2008-12-15 02:17:23
|
Gentlemen, From the looks of some of the current kinematics files I will assume two things: 1: the 5 axis tool length compensation is handled outside the kinematics file. 2: the pivot length compensation is handled inside the kinematics file. Unless otherwise advised I will construct my kins with these assumptions. I am compensating for an out of parallel condition between the A and X axes and an out of parallel condition between the B and Y axes and a condition where the center line of the spindle does not project through the A axis and a condition where the center line of the spindle does not project through the B axis and I am adding orthogonal compensation. The algorithm I have now is an inverse kins. I am working on the forward kins. Future readability has been mentioned. The algorithm gets complicated. Would these be better handled as separate calculations? A few gentlemen have a good idea of my coding skill (or lack thereof). I used the term 'skill' with a grain of salt. Possibly a kind soul would lend a hand on the final version. :) thanks Stuart |
From: Leslie N. <les...@fa...> - 2008-12-15 00:00:44
|
I finally got some time to play around with this. Simply changing the read_x function to halve the X axis seems to work. I had a look through a Fanuc lathe manual and that appears to be exactly what they do. Axis already shows the X radius and diameter so it doesn't really need changing. DTG uses radius as well but as it is a blended value, it wouldn't really be sensible for it to work in diameter anyway. Currently I have hard-coded the read_x function to halve the X value which is of course not the correct way to go. The read_XX functions have access to the system parameters so it seems the sensible way to go would be to dedicate a parameter and maybe a G-code for diameter mode. Is there a list anywhere of the system parameters currently in use? Les |
From: Jon E. <el...@pi...> - 2008-12-14 20:26:23
|
BRIAN GLACKIN wrote: > Seb, > > THanks for the link. I checked the site and I cannot seem to access any of > the articles due to subscription requirements. Perhaps in the future I will > explore this avenue, bit for the time being, Christmas preparations preclude > spending on this. > it won't be real quick, but you could order that as a back issue. Jon |
From: Jon E. <el...@pi...> - 2008-12-14 20:22:19
|
Stephen Wille Padnos wrote: > > I was in the middle of writing a similar statement, with some general > instructions on writing a test program, when I decided to just write the > test program instead :) I found that the first version runs 1,000,000 > loops in about 0.5 seconds (on a 2.2 GHz Core 2 Duo), whereas the second > takes about 2 seconds. By making my own "sqr" function, that was cut > down to about 1.5 seconds (this surprised me because I would have > expected common subexpression elimination to work there, but I suppose > gcc can't know if any of the called math functions save some state and > may therefore return different values from call to call). > > Very interesting! Well, there are these outfits that sell super-optimizing compilers and claim their code runs significantly faster than GCC. My boss is still stuck in the Fortran world (gag, choke) and bought one, and he claims it can be twice as fast as g77 on heavy math stuff. The old DEC compilers on Vax and Alpha were REALLY good. Jon |
From: John K. <jmk...@fa...> - 2008-12-14 20:21:01
|
Given today's PCs, for all but the most hard-core numbercrunching, you are better off optimizing for readability. Don't do obviously bad things like computing the same value three times, but in general, if you are doing closed form math that doesn't involve loops or iteration, it will be very fast compared to most other stuff, like I/O. I bet your math runs in less time than it takes to send the voltage commands to the PPMC DACs. Regards, John Kasunich |
From: Jon E. <el...@pi...> - 2008-12-14 20:16:31
|
Stuart Stevenson wrote: > Gentlemen, > which style of computation would run faster in the kinematics file? > > this: > va1=atan(askew1) > > va2=atan(-bskew1) > <snip> > or this: > acomp=asin(((((sin(acmd))-(((cos(acmd))*(sin(-bcmd)))*$ > > (tan((atan(-bskew1))))))*(cos((atan(-bskew1)))))/$ > <snip> count up the number of sin, cos, etc. functions. If it is the same, then the time should be very close either way. If you just pulled all the equations apart to store every temp result in a variable, the compiler will end up generating the identical code. If you want, you could actually write a little program with a random number generator feeding your equations, and make it execute it in a loop 10,000 times. Run it with the Linux "time" command. Don't have the program write anything to the screen, but maybe store the values in an array so it doesn't get optimized away. Run both versions and compare. Jon |
From: Jeff E. <je...@un...> - 2008-12-14 18:40:58
|
I'm pleased to announce the next release of the emc 2.2 series, emc 2.2.8. This release contains a fix for a rare bug that caused incorrect movement for G2 and G3 arc moves, as well as a few other things. The new packages are now available for Ubuntu 8.04 "Hardy Heron" in the package repositories. If you have already installed an earlier 2.2.x version, this is available as an update in the Ubuntu update manager. If you are still using 2.1.7 but want to upgrade, instructions are here: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingTo2.2 For information on how to upgrade from 2.2.x to 2.2.8 without using the package manager, see http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?InstallingUpdates Ubuntu 6.06 "Dapper Drake" packages should follow shortly. CVS users can get this release by checking out the RELEASE_2_2_8 tag. Source tarballs are available from the package repository: http://linuxcnc.org/hardy/dists/hardy/emc2.2/source/emc2_2.2.8.tar.gz Many thanks to Chris Radek, who finally tracked down and fixed this arc bug. Thanks also to John Thornton who has been working steadily on improving the emc2 documentation. Changes in this release: * Documentation improvements * Fix rare incorrect movement for G2 and G3 arc moves * partial swedish translation now under correct 'sv' language. * hostmot2 improvements: encoder velocity and index mask. stepgen step types and bugfixes. better logging. improved device firmwares. Jeff |
From: Jack C. <ja...@co...> - 2008-12-14 18:33:16
|
You can grab a 'cheap' KVM from ebay, and a dumpster box to have a 'test system' on your desk. It may not be graceful, but if you can have the box in the workshop running, you can use VNC on your desktop inside to view what is going on there. I wouldn't really CUT anything with it that way, but for remote use, it works. Personally I like to have a hardwired link, but in my place currently I am using WIFI. For a box that you don't want to deal with wifi on but have an ethernet port, I suggest getting one or two 'wifi external game adapters'. I just purchased another (I have one belkin, one USRobotics, and a 'new to me' linksys' in my house/shop) - the linksys - from http://3btech.net/li80wigaadbr.html for $40 The KVM brand I like is a 4 port zonet ... right now they have one I really like http://3btech.net/fopomidekvmk.html for about $25 including cables. It has a place for a power supply, but it is not needed. I think it is refurbed too. For about $65 plus shipping if you already have wifi at home you would be in good shape. If no wifi currently you might want 2 of the game adapters. Still it probably isn't as cheap as running an ethernet cable. I hope some of this helps in getting your infrastructure going so you can have fun even if the shop is cold. BRIAN GLACKIN wrote: > Seb, > > THanks for the link. I checked the site and I cannot seem to access any of > the articles due to subscription requirements. Perhaps in the future I will > explore this avenue, bit for the time being, Christmas preparations preclude > spending on this. > > <snip> > Jeff, > > Thanks for the snippet of code. I will spend some time studying it and then > applying it to my cuts. It certainly appears to be what I am looking for. > > As for the other code in the example directory, I have not poked around in > there due to the temperature of my workspace. Seems I have a bit in common > with Gene in this respect. I do have several other dumpster boxes I am > looking for a monitor for so that I can have a simulator running in the > comfort of the house. Once I have that, I will certainly explore that more > fully. > Thanks for the replies > > Brian > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Emc-users mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-users > > |
From: Jeff E. <je...@un...> - 2008-12-14 18:29:35
|
You can also view that file, useful-subroutines.ngc, from the comfort of an internet-connected computer: http://cvs.linuxcnc.org/cvs/emc2/nc_files/useful-subroutines.ngc?rev=1.4;content-type=text%2Fplain Jeff |
From: John T. <je...@se...> - 2008-12-14 18:21:27
|
You might also look at the g code generators here http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_EMC_G-Code_Generators and take a look at http://www.linuxcnc.org/docview/html//gcode_main.html#sub:G92,-G92.1,-G92.2, http://www.linuxcnc.org/docview/html//gcode_main.html#cha:O-Codes John On 14 Dec 2008 at 11:58, BRIAN GLACKIN wrote: > Up until now, I have been using AC2GC for gcode generation. While > this is > ok, it gets tedious when I am generating multiples of a single part. > I have > reviewed the Gcode manual numerous times and cannot get my mind > wrapped > around the method for doing this. I reckon something along the line > of a > drilling cycle is in order with a coordinate system change. > > For simplicity, can someone show a looping routine to cut out a > square 1" X > 1" path (not worried about tooling offsets) then skip 1/2" on the Y > axis and > repeat. Once it reaches the end of the Y axis (24" in my case), I > want it > to index down the X axis and reverse on down the Y axis. I then > want to > repeat this full loop until I exhaust the X axis. > > I actually want to cut more than a simple square, but using it > should allow > me to understand the subroutine. > > Thanks. > > Brian > -------------------------------------------------------------------- > ---------- > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, > Nevada. > The future of the web can't happen without you. Join us at MIX09 to > help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visit > mix.com/ > _______________________________________________ > Emc-users mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-users > |
From: BRIAN G. <gla...@gm...> - 2008-12-14 17:58:21
|
Seb, THanks for the link. I checked the site and I cannot seem to access any of the articles due to subscription requirements. Perhaps in the future I will explore this avenue, bit for the time being, Christmas preparations preclude spending on this. <snip> Jeff, Thanks for the snippet of code. I will spend some time studying it and then applying it to my cuts. It certainly appears to be what I am looking for. As for the other code in the example directory, I have not poked around in there due to the temperature of my workspace. Seems I have a bit in common with Gene in this respect. I do have several other dumpster boxes I am looking for a monitor for so that I can have a simulator running in the comfort of the house. Once I have that, I will certainly explore that more fully. Thanks for the replies Brian |
From: Jeff E. <je...@un...> - 2008-12-14 17:45:14
|
Here's a program that does something like what you asked for. You might also be interested in the file 'interesting-subroutines.ngc', which should be installed in the examples directory. Jeff (- CUT HERE ----------------------------------------------------------) O100 sub (square [x0] [y0] [z0] [zr] [f1] [f2]) (cut a 1x1 square) (#1 = x0 = left hand corner of square) (#2 = y0 = lower corner of square) (#3 = z0 = depth of cut) (#4 = zr = retract after cut) (#5 = f1 = feed to cutting depth) (#6 = f2 = feed for square) (assumes already at safety height) G0 X#1 Y#2 G1 Z#3 F#5 G1 X[#1+1] F#6 G1 Y[#2+1] G1 X#1 G1 Y#2 G0 Z#4 O100 endsub O200 sub (l2r [x0] [y0] [dx] [count] [z0] [zr] [f1] [f2]) (#1 = x0 = least x coordinate) (#2 = y0 = common y coordinate for all squares) (#3 = dx = increment between x coordinates) (#4 = count = number of squares in row) (#5 = z0 = depth of cut) (#6 = zr = retract after cut) (#7 = f1 = feed to cutting depth) (#8 = f2 = feed for square) (cut squares from left to right at constant Y) (#9 = temporary for count of squares in row) #9=0 O210 while [#9 LT #4] O100 call [#1+#9*#3] [#2] [#5] [#6] [#7] [#8] #9=[#9+1] O210 endwhile O200 endsub O300 sub (r2l [x0] [y0] [dx] [count] [z0] [zr] [f1] [f2]) (parameters as for O200 sub) (cut squares from right to left at constant Y) #9=[#4-1] O310 while [#9 GE 0] O100 call [#1+#9*#3] [#2] [#5] [#6] [#7] [#8] #9=[#9-1] O310 endwhile O300 endsub O400 sub (squares [x0] [y0] [dx] [dy] [xcount] [ycount] [z0] [zr] [f1] [f2]) (#1 = x0 = least x coordinate) (#2 = y0 = least y coordinate) (#3 = dx = increment between x coordinates) (#4 = dy = increment between y coordinates) (#5 = xcount = number of squares in row) (#6 = ycount = number of rows) (#7 = z0 = depth of cut) (#8 = zr = retract after cut) (#9 = f1 = feed to cutting depth) (#10 = f2 = feed for square) (#11 = temporary for count of rows) #11=0 O410 while [#11 LE #6] O420 if [[#11 MOD 2] EQ 0] O200 call [#1] [#2+#11*#4] [#3] [#5] [#7] [#8] [#9] [#10] O420 else O300 call [#1] [#2+#11*#4] [#3] [#5] [#7] [#8] [#9] [#10] O420 endif #11=[#11+1] O410 endwhile O400 endsub G20 M3 S1000 O400 call [0] [0] [1.5] [1.5] [4] [5] [-1] [1] [12] [30] M2 (- CUT HERE ----------------------------------------------------------) |
From: Sebastian K. <se...@hi...> - 2008-12-14 17:26:54
|
BRIAN GLACKIN wrote: > For simplicity, can someone show a looping routine to cut out a square 1" X > 1" path (not worried about tooling offsets) then skip 1/2" on the Y axis and > repeat. Once it reaches the end of the Y axis (24" in my case), I want it > to index down the X axis and reverse on down the Y axis. I then want to > repeat this full loop until I exhaust the X axis. > > I actually want to cut more than a simple square, but using it should allow > me to understand the subroutine. There was a great series of articles in Digital Machinist <http://www.digitalmachinist.net/> recently called "Along the G-code Way", by Ed Nisley, that covered this exact topic from start to finish. The author even used EMC2 for all the examples, including screen shots from Axis :-) I dont know the exact issue numbers, but the search on the website above should find them for you. It's the best introductory tutorial I've seen on G-code programming. If there's a free online tutorial someplace i'd love to see it. -- Sebastian Kuzminsky One of my most productive days was throwing away 1000 lines of code. -- Ken Thompson |
From: BRIAN G. <gla...@gm...> - 2008-12-14 16:58:53
|
Up until now, I have been using AC2GC for gcode generation. While this is ok, it gets tedious when I am generating multiples of a single part. I have reviewed the Gcode manual numerous times and cannot get my mind wrapped around the method for doing this. I reckon something along the line of a drilling cycle is in order with a coordinate system change. For simplicity, can someone show a looping routine to cut out a square 1" X 1" path (not worried about tooling offsets) then skip 1/2" on the Y axis and repeat. Once it reaches the end of the Y axis (24" in my case), I want it to index down the X axis and reverse on down the Y axis. I then want to repeat this full loop until I exhaust the X axis. I actually want to cut more than a simple square, but using it should allow me to understand the subroutine. Thanks. Brian |
From: Stuart S. <st...@gm...> - 2008-12-14 15:53:58
|
Greg, I probably wouldn't yet take this work as the definitive kinematics. :) It is a work in progress and learning (OJT). having some fun now Stuart On Sun, Dec 14, 2008 at 8:38 AM, Greg Michalski <emc...@di...> wrote: > Stuart - Thank you for starting this thread and posting your kinematics > calculations. I hadn't delved into the kinematics aspect of EMC2, but > reading through your calculations the proverbial light-bulb went on and how > positioning is computed and achieved makes a lot more sense to me now. Once > again - something new is learned every day subscribing to this list - I'll > stow this for the unavoidable "I'll never use this stuff in life" argument > my daughter is starting to use in defense of her math grades (sure, she's > only in 8th grade and isn't exhibiting any interest in mechanical > engineering but I can make an analogy that works :). > > Thanks again. > > Greg > > -----Original Message----- > From: Stuart Stevenson [mailto:st...@gm...] > Sent: Sunday, December 14, 2008 12:14 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] equations in kinematics > > On Sat, Dec 13, 2008 at 11:05 PM, Stephen Wille Padnos > <sp...@so...> wrote: >> Chris Radek wrote: >> >>>On Sat, Dec 13, 2008 at 10:14:04PM -0600, Stuart Stevenson wrote: >>> >>> >>>>Gentlemen, >>>> which style of computation would run faster in the kinematics file? >>>> >>>> >>> >>>If they are equivalent (and I sure as heck didn't check that), >>> >> I didn't check for correctness either. I did notice one thing that >> seems like a bad choice, but it may be intentional: >> >> ... >> va2=atan(-bskew1) >> .... >> va8=va7*tan(va2) >> ... >> >> since tan(atan(x)) should equal x, it seems you should be able to just >> use "va8=-va7*bskew1". > > it was intentional only in that I have variables in my macro call that > I use two different numbers > if the magnitude of the variable is less than 1 I use it as a per inch error > if the magnitude is GE 1 I use it as an angle > this necessitates the extra step for testing > when I write it for the kinematics I will only use the per inch error > >> >>>it >>>will make little difference whether you split it up like #1 or have >>>huge statements like #2. The compiler will do approximately the same >>>work >>> >> I was in the middle of writing a similar statement, with some general >> instructions on writing a test program, when I decided to just write the >> test program instead :) I found that the first version runs 1,000,000 >> loops in about 0.5 seconds (on a 2.2 GHz Core 2 Duo), whereas the second >> takes about 2 seconds. By making my own "sqr" function, that was cut >> down to about 1.5 seconds (this surprised me because I would have >> expected common subexpression elimination to work there, but I suppose >> gcc can't know if any of the called math functions save some state and >> may therefore return different values from call to call). >> >>>. The only concern is which one you can understand better when >>>you (or some other unlucky person?) come back to it later. >>> >>> >> That is a big concern, and the code runs pretty fast anyway. Like I >> said, my 2.2GHz CPU can run the slower version 500,000 to 750,000 times >> a second, so even a 500 MHz CPU, that's not as well optimized for math, >> should be able to do it 100,000 times a second (or about 100 times as >> often as necessary) > > speed was my main concern > thanks > Stuart >> >> - Steve >> >> >> >> > ---------------------------------------------------------------------------- > -- >> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, > Nevada. >> The future of the web can't happen without you. Join us at MIX09 to help >> pave the way to the Next Web now. Learn more and register at >> > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ >> _______________________________________________ >> Emc-users mailing list >> Emc...@li... >> https://lists.sourceforge.net/lists/listinfo/emc-users >> >> > > ---------------------------------------------------------------------------- > -- > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Emc-users mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-users > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Emc-users mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-users > > |