#linuxcnc | Logs for 2012-12-10

Back[00:02:02]-!- logger[mah] has quit [Remote host closed the connection][00:02:08]-!- logger[mah] [logger[mah]!~loggermah@ns1.mah.priv.at] has joined #linuxcnc[00:04:36]<Aero-Tec> that was just the main part
[00:04:59]<Aero-Tec> it works fine
[00:05:17]<Aero-Tec> would like it to be one long smooth run and not stop
[00:05:30]-!- BHSPiMonkey has quit [Ping timeout: 264 seconds][00:06:26]-!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc[00:07:30]-!- BHSPiMonkey [BHSPiMonkey!~BHSPitMon@68-185-203-185.dhcp.dntn.tx.charter.com] has joined #linuxcnc[00:07:41]-!- cmorley2 [cmorley2!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc[00:08:00]-!- cmorley1 has quit [Ping timeout: 252 seconds][00:11:00]-!- cmorley has quit [Ping timeout: 264 seconds][00:13:12]<Aero-Tec> found camera
[00:14:34]<JT-Shop> can you pastebin the G code?
[00:15:09]<toastyde1th> if your program is stopping after every line, there is an exact stop mode that might need to be disabled
[00:15:52]<JT-Shop> 3 done 3 to go http://imagebin.org/238708[00:15:57]<Aero-Tec>http://pastebin.com/nZVDbQ8a[00:16:36]<toastyde1th> also the machine has to know it has a contouring b axis for it to allow g1 moves
[00:16:55]<toastyde1th> (to jt-shop)
[00:17:04]<Aero-Tec> that is the new G93 version
[00:17:38]<JT-Shop> contouring axis?
[00:17:42]<Aero-Tec> can convert it back to old version if needed
[00:18:08]<Aero-Tec> they move at the same time
[00:18:13]<toastyde1th> JT-Shop, i'm not sure how emc handles it, but machines can have two types of rotary axes
[00:18:14]<Aero-Tec> B and X
[00:18:47]<toastyde1th> indexing, where the table cannot actually cut during a move, so the machine locks all other axes down and disallows g1 or any other type of cutting move while the axis is unlocked
[00:19:01]<toastyde1th> and contouring, where the axis is like any other lineaer axis and can handle cutting forces
[00:19:03]<JT-Shop> ah let me look that up
[00:19:12]<toastyde1th> *linear
[00:19:41]<Aero-Tec> it just stops for a split second between moves
[00:19:43]<toastyde1th> i'm also 95% sure that EMC implements an exact stop mode, which is something Aero-Tec should look for
[00:19:55]<toastyde1th> because it's bad to have on unless you need it
[00:20:10]<JT-Shop> ah the sim had it configured as a locking rotary
[00:21:17]<Aero-Tec> G64, is that not suppose to disable exact stop?
[00:21:25]<JT-Shop> no error now but nothing moves
[00:21:36]<toastyde1th> i don't know what emc does with g64, because i am used to Fanuc, not emc
[00:21:55]<JT-Shop>http://linuxcnc.org/docs/devel/html/gcode/overview.html#sec:Modal-Groups[00:23:07]<toastyde1th> emc handles exact stop very differently from fanuc, so i can't help other than to say it sounds like an exact stop problem
[00:23:47]<Nick001-Shop> JT-Shop> put the net slide info in and it came up with zero timeout with wait type !=immediate return error - Put a Q timeout and it continued to load. Only now it operates to the timer weather pin 10 is high or low - what did I miss?
[00:27:05]<JT-Shop> does motion.digital-in-00 toggle in a watch window when you toggle the switch?
[00:27:28]<JT-Shop> Aero-Tec: it runs smooth in the sim with constant velocity
[00:28:37]<Nick001-Shop> ill set the q for 30 sec so the switch will hit and go true and see what happens brb
[00:31:16]<JT-Shop> ok
[00:32:17]<Aero-Tec> that was the new code
[00:32:29]<Aero-Tec> I have not tryed it yet
[00:32:40]<Aero-Tec> but it should run smooth
[00:32:51]<Nick001-Shop> the switch goes true but the motion.digtal stays false
[00:35:52]-!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]][00:37:04]-!- rob_h has quit [Ping timeout: 265 seconds][00:39:44]-!- hashfail [hashfail!~hashfail@64-121-232-59.c3-0.eas-ubr3.atw-eas.pa.cable.rcn.com] has joined #linuxcnc[00:40:33]hashfail is now known as gimps[00:40:48]<Aero-Tec>http://imagebin.org/238710[00:40:57]<Aero-Tec> very bad pix of setup
[00:41:02]<Aero-Tec> needed more light
[00:41:12]<jdh> really very very bad
[00:42:02]<JT-Shop> really bad
[00:42:24]<Aero-Tec> I can add some light and try again
[00:43:38]<JT-Shop> Nick001: what is the hal line you used to connect the parallel port to the dio pin?
[00:44:38]<JT-Shop> This is what I use on my plasma M66 P0 L1 Q2 (Wait 2 seconds for Arc OK from Torch)
[00:45:01]<JT-Shop> as I understand it should be L3
[00:46:44]-!- jpk has quit [Ping timeout: 265 seconds][00:47:29]<JT-Shop>http://www.youtube.com/watch?v=uonWwpgor7U[00:51:45]-!- Keknom has quit [Quit: Leaving.][00:54:09]<Nick001-Shop> found the prob - forgot a dash in the net slide line and now motion digital is switching
[00:55:10]<JT-Shop> cool
[00:57:12]-!- asdfasd has quit [Ping timeout: 255 seconds][00:58:14]<Nick001-Shop> be back in 30 min and tell you what happened - boss called and dinner is ready -)
[00:58:31]<JT-Shop> I'm waiting for the same call
[00:58:44]-!- Nick001-Shop has quit [Remote host closed the connection][00:58:45]<tjb1> JT-Shop: dinner is ready.
[01:00:19]<JT-Shop> what did you cook for me honey?
[01:00:28]<JT-Shop> did you see my new slats?
[01:01:39]<tjb1> hot dogs
[01:01:40]<tjb1> and no
[01:02:28]<JT-Shop> Nathens?
[01:02:29]<JT-Shop> 3 done 3 to go http://imagebin.org/238708[01:02:35]<Aero-Tec>http://imagebin.org/238715[01:02:52]<JT-Shop> looks like a pile of springs
[01:02:57]<Aero-Tec>http://imagebin.org/238714[01:03:22]<Aero-Tec>http://imagebin.org/238713[01:03:31]<JT-Shop> crappy photo but I get he idea now
[01:03:38]<Aero-Tec> almost 300 of them
[01:03:40]<tjb1> Why dont the arc?
[01:03:42]<tjb1> they
[01:03:51]<JT-Shop> ?
[01:04:00]<Aero-Tec> arc?
[01:04:00]<tjb1> Should arc your slats
[01:04:11]<JT-Shop> they do form an arc
[01:04:22]<tjb1> Thats a tiny arc :P
[01:04:29]<Aero-Tec> crappy camera
[01:04:31]<JT-Shop> no it is a huge arc
[01:04:34]-!- gimps has quit [Ping timeout: 240 seconds][01:04:52]<tjb1> You knew what I meant...
[01:04:57]<JT-Shop> yes
[01:05:30]<JT-Shop> it's 1" in 60"
[01:05:42]<tjb1> Since mesa is still in the 90s, I cant order until tomorrow
[01:05:51]<Tom_itx> JT-Shop, what's your latest conversion you were working on?
[01:05:53]<Tom_itx> your lathe?
[01:05:57]<JT-Shop> the last ones are straight and still good after 4 years of use
[01:06:31]<JT-Shop> Tom_itx: fixing my plasma table and making lift and spins
[01:06:56]<tjb1> JT-Shop: I took about 2.5lbs off my Z
[01:06:58]<Tom_itx> hmm i thought you were rewiring something recently
[01:07:09]<JT-Shop> tjb1: did that help?
[01:07:35]<tjb1> A bit, also added a bunch of litium grease
[01:07:38]<JT-Shop> hmmm I don't think so, last conversion was the BP from Anilam to LinuxCNC
[01:07:52]<Tom_itx> ahh
[01:08:03]<Tom_itx> get it all workin?
[01:08:10]<Tom_itx> you were having noise problems or something
[01:08:17]<JT-Shop> it's cutting the slots for the plasma table slat supports now
[01:08:41]<JT-Shop> yep, still do from time to time but not enough to raise the hair on my neck
[01:08:45]<tjb1> What is a realistic acceleration number?
[01:09:06]<Tom_itx> probably depends on your setup
[01:09:17]<tjb1> Well I am pretty sure 30 isnt real
[01:09:28]<tjb1> Is acceleration like in machine units squared
[01:09:33]<tjb1> *Isn't...
[01:10:24]<JT-Shop> tjb1: I find that 10-20 times the max velocity is about right
[01:10:26]<icee> tjb1: what's your peak speed?
[01:10:54]<tjb1> JT-Shop: So if you have 7 for velocity you set your accel at 70+?
[01:11:03]<JT-Shop> yea
[01:11:03]<icee> it all depends on the machine
[01:11:21]<icee> for some, accelerating from max vel one way to the opposite in 1/10th of a second is not sane
[01:11:35]<JT-Shop> dinner bell
[01:12:31]<icee> especially with gantries and stuff, you need to think in terms of torques and power required and leadscrew loading
[01:12:37]<JT-Shop> tjb1: all the machines in my shop fall in that range, of course that may not work for machines that would not fit in my shop
[01:13:09]<tjb1> I set my max on x and y to 400 now
[01:13:17]<tjb1> Still doesnt stop on limits
[01:13:49]<JT-Shop> plasma x and y
[01:13:50]<JT-Shop> MAX_VELOCITY = 7
[01:13:51]<JT-Shop> MAX_ACCELERATION = 125
[01:13:51]<JT-Shop> STEPGEN_MAX_VEL = 8.4
[01:13:51]<JT-Shop> STEPGEN_MAX_ACC = 150
[01:14:00]<JT-Shop> dinner bell for real
[01:14:12]<Tom_itx> heh
[01:15:09]-!- ybon has quit [Quit: WeeChat 0.3.8][01:16:56]-!- Valen [Valen!~Valen@c122-108-45-139.blktn6.nsw.optusnet.com.au] has joined #linuxcnc[01:19:34]-!- Keknom [Keknom!~monkeky@c-76-125-214-194.hsd1.pa.comcast.net] has joined #linuxcnc[02:12:50]-!- Iron [Iron!~adminuser@190.142.186.4] has joined #linuxcnc[02:13:16]<Iron> Saludos
[02:13:23]<Iron> alguien que hable español
[02:13:26]<Iron> ?
[02:14:41]<Tom_itx> no
[02:19:16]<Iron> How can I make linuxcnc not print me upside down images that I want graphic with cnc machine
[02:26:11]-!- andypugh has quit [Quit: andypugh][02:43:08]-!- hashfail [hashfail!~hashfail@64-121-232-59.c3-0.eas-ubr3.atw-eas.pa.cable.rcn.com] has joined #linuxcnc[02:50:45]<Aero-Tec> looks like the new code is doing the exact same thing
[02:51:16]<Aero-Tec> JT-Shop: are you still around?
[02:54:02]<Tom_itx> i doubt it
[02:55:01]<Aero-Tec> any EMC gurus?
[03:05:16]-!- micges has quit [Quit: Leaving][03:06:32]-!- luvroot [luvroot!~luv@183.129.220.243] has joined #linuxcnc[03:19:32]-!- Iron has quit [Quit: Ex-Chat][03:33:31]<skunkworks> Aero-Tec: what is the issue?
[03:34:05]<Aero-Tec> still doing the stopping on move end
[03:35:12]<Aero-Tec> does G64 stop that
[03:35:59]<Aero-Tec> G93 did not stop it
[03:38:09]<Aero-Tec>http://pastebin.com/AJrFHxfG[03:38:13]<Aero-Tec> the code
[03:38:48]-!- luvroot [luvroot!~luv@183.129.220.243] has parted #linuxcnc[03:39:18]<Aero-Tec> trying to get it to make spring in one continuous move
[03:40:34]<Aero-Tec>http://pastebin.com/nZVDbQ8a[03:40:45]<Aero-Tec> a G93 version of the code
[03:42:15]<Aero-Tec> skunkworks: you still there?
[03:43:44]<Aero-Tec> G64 is go as fast as possible in one continuous move
[03:43:59]<Aero-Tec> or am I wrong
[03:48:27]<Valen> sure its the mill?
[03:48:50]<Valen> bah sure its EMC, not backlash in the mill
[03:50:23]<Aero-Tec> there is backlash
[03:51:46]<Aero-Tec> and backlash comp is turned on
[03:52:05]<Aero-Tec> the moves are all in the same dir so backlash would not be a problem
[03:52:07]<Valen> if there is backlash you will still get a mark
[03:52:11]<Valen> fairynuff
[03:52:59]<Aero-Tec> it is winding springs
[03:53:04]<Aero-Tec> so no mark
[03:53:33]<Aero-Tec> but I do not want the waste of time stopping 2 times when making a spring
[03:57:54]-!- sumpfralle1 has quit [Ping timeout: 240 seconds][03:59:50]<Valen> bit busy at the moment so I can't really have a good look at it yet
[04:01:36]<Aero-Tec> I am thankful of any help I can get
[04:01:54]<Aero-Tec> new to EMC
[04:04:18]-!- Keknom has quit [Quit: Leaving.][04:10:31]-!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc[04:20:55]-!- Cylly [Cylly!~cylly@p54B11268.dip.t-dialin.net] has joined #linuxcnc[04:23:04]-!- Loetmichel has quit [Ping timeout: 250 seconds][04:35:07]-!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc[04:41:58]<Aero-Tec> ran out of things to try
[04:42:14]<Aero-Tec> turned off backlash comp
[04:42:30]<Aero-Tec> have G64 in the code
[04:42:43]<Aero-Tec> still stops
[04:43:01]<Aero-Tec> and have tried using G93
[04:43:10]<Aero-Tec> with G64
[04:43:47]<Aero-Tec> thought G64 was to stop the stopping
[04:47:17]<Aero-Tec> I have gone through the HAL and the INI
[04:47:29]<Aero-Tec> a few times
[04:48:45]<Valen> I think i saw something about this on the mailing list recently?
[04:50:37]<Aero-Tec> I just joined that a few days ago
[04:51:25]-!- FinboySlick has quit [Remote host closed the connection][04:52:21]-!- dhoovie [dhoovie!~kvirc@122.177.220.102] has joined #linuxcnc[04:52:26]<Valen> something about repeted moves in the same direction or something
[04:52:38]<Valen> what is making your gcode? it looks nasty
[04:55:23]-!- automata_ [automata_!~automata@122.169.55.246] has joined #linuxcnc[04:57:57]<Valen> if it jumps into / out of a sub I think it will/may stop
[04:58:09]<Aero-Tec> lol
[04:58:15]<Aero-Tec> I made the code
[04:58:19]<Aero-Tec> hand done
[04:58:21]<Valen> rofl
[04:58:26]<Valen> dude spaces are allowed ;->
[04:58:27]<Aero-Tec> was made for Mach
[04:58:46]<Aero-Tec> then added sub for counting
[04:58:55]<Aero-Tec> then maded it for EMC
[04:59:00]<Aero-Tec> moded
[04:59:21]<Valen> you don't need to set G91 every line
[04:59:28]<Aero-Tec> yes it looks like hell, but it is my little hell....LOL
[04:59:38]<Aero-Tec> I know
[04:59:53]<Valen> I'm just thinking something in there may be confusing EMC
[04:59:55]-!- schwinn434 [schwinn434!~jameslacy@CPE-76-182-158-150.natwky.res.rr.com] has joined #linuxcnc[04:59:56]<Aero-Tec> or do G1 like I did
[05:00:18]-!- pikeaero [pikeaero!~quassel@216-167-252-197.eastlink.ca] has joined #linuxcnc[05:00:23]<Valen> G1 isn't a bad idea, but G91 is a modal, so it may cause the planner to hiccough
[05:00:25]<Aero-Tec> F19000000
[05:00:27]<Aero-Tec> G1G91X-0.03B100
[05:00:28]<Aero-Tec> G1G91X-0.01B60
[05:00:30]<Aero-Tec> G1G91X-.01B500
[05:00:32]<Aero-Tec> G1G91X-1B3240 ;4680
[05:00:34]<Aero-Tec> G1G91X-0.02B530
[05:00:36]<Aero-Tec> G1G91B-860
[05:00:38]<Aero-Tec> that is the code of the code
[05:00:56]<Aero-Tec> it should have no problems doing that in one go
[05:01:09]<Valen> I suggest taking the G91 out just to rule it out
[05:01:10]<Aero-Tec> it is tight and neat
[05:01:27]<Aero-Tec> will do the G1s as well
[05:01:33]<Aero-Tec> only need one
[05:01:34]<Valen> so its stopping on each line there?
[05:01:43]<Aero-Tec> yes
[05:01:44]<Valen> we use G1's and its ok
[05:01:56]<Valen> also what version are you using?
[05:02:06]<Aero-Tec> 2.5 I think
[05:02:12]<Aero-Tec> just updated
[05:02:16]<Valen> ok
[05:02:26]<Aero-Tec> mind you that was the lathe
[05:02:42]<Aero-Tec> have to check if mill got updated
[05:03:39]<Valen> The only other thing I can think of is its the rotaty axis
[05:04:26]<Aero-Tec> G93 should fix that
[05:04:31]<Aero-Tec> but it did not
[05:05:23]<Valen> mmm sorta
[05:05:43]<Valen> 93 is just another way of speccing a feed rate isnt it?
[05:05:50]<Valen> if you used 95 then sure
[05:07:31]<Aero-Tec> G93 I am told is to be used when 2 different units are involved in a move
[05:07:46]<Aero-Tec> Inch and Degree
[05:07:59]<Aero-Tec> or what ever combo
[05:08:17]<Valen> makes sens
[05:08:18]<Valen> e
[05:08:32]<Aero-Tec> going to try your idea
[05:08:36]<Aero-Tec> BRB
[05:08:49]-!- ve7it has quit [Remote host closed the connection][05:12:24]<Aero-Tec> still stopping
[05:12:42]<Aero-Tec> G91 was not the problem
[05:12:56]<dhoovie> Yeah, I think Valen is right. It's the rotary axes. I havn't got path blending to work with a rotary axes.
[05:13:14]<dhoovie> It always stops...
[05:13:23]<Aero-Tec> I know someone that has
[05:13:25]<Valen> can you redefine your rotary axis as a linear axis temporarily?
[05:13:30]<Aero-Tec> will post vid
[05:13:44]<dhoovie> Really? sweet!
[05:13:49]<Aero-Tec> how would one do that?
[05:13:53]<dhoovie> maybe he did something in his setup
[05:14:14]<Aero-Tec> he posts how he did it on his web site
[05:14:20]<dhoovie> link?
[05:14:25]<Aero-Tec> will have to look at it
[05:14:34]<Aero-Tec> but it was threading
[05:16:50]<Aero-Tec>http://jmkasunich.com/cgi-bin/blosxom/shoptask/fusee-1.html[05:17:01]<Aero-Tec> watch the vid
[05:18:40]<Aero-Tec> he uses G64
[05:20:21]-!- tjb1 has quit [Quit: tjb1][05:21:06]<Aero-Tec> so what do you guys think?
[05:21:44]<Valen> have you tried setting a tollerence?
[05:22:38]<Aero-Tec> for G64?
[05:22:40]<Aero-Tec> yes
[05:22:41]<Valen> yeah
[05:22:43]<Valen> ok
[05:22:45]<Aero-Tec> and with out
[05:23:16]<Aero-Tec> why will G64 not work for me?
[05:23:21]<Valen> guy is too smart by half lol
[05:23:31]<dhoovie> so firstly, that was a mind blowing video
[05:23:55]<dhoovie> and I don't think he uses any angular axes.
[05:24:10]<Aero-Tec> your right
[05:24:18]<Valen> be spinde synchronised motion at best no?
[05:24:32]<Aero-Tec> for him yes
[05:24:37]<Aero-Tec> he is threading
[05:24:52]<Valen> damn quick too lol
[05:24:57]<dhoovie> if you use only linear axes, G64 works. Put one rotary axes in there and it doesn't.
[05:25:01]<Aero-Tec> G33 if mem serves
[05:25:27]<Valen> "After roughing out the part, the next step is the threading. The code to do the threading looks very similar to the roughing code, except that it uses G33 spindle-synchronized moves instead of ordinary G1 linear moves."
[05:25:38]<Aero-Tec> he sure does some hoging cuts
[05:26:22]<Aero-Tec> so all rotary axis moves stop?
[05:26:54]<Valen> that would be my sense of it at this instant, but somebody who knows more about the guts would be a better place to ask
[05:26:58]<dhoovie> I think so. But I probably don't know enough about linuxcnc to say that for certain.
[05:27:17]<Aero-Tec> that sucks
[05:27:17]<Valen> try the mailing list or here in like 12 hours or so when america is awake
[05:27:31]<dhoovie> you can browse the code for the g64 code and see if you can figure something out :D
[05:27:40]<Aero-Tec> will do
[05:27:46]<Aero-Tec> do you have a link?
[05:27:51]<Valen> to the list?
[05:28:04]<Aero-Tec> the G64 code
[05:28:24]-!- schwinn434 has quit [Ping timeout: 264 seconds][05:29:42]<Aero-Tec> you had said something about browsing the G64 code
[05:29:50]<Valen> he means the source code
[05:30:01]<dhoovie> uhm, afraid not. can download the source of linuxcnc from the site and have to find it :S
[05:30:35]<Aero-Tec> thought you meant Gcode samples
[05:30:47]<Aero-Tec> it is late here
[05:31:00]<Aero-Tec> way to late for looking at source code
[05:31:03]<dhoovie> ohh no, the source code of linuxcnc. it's a bit of a beast as well.
[05:32:05]<dhoovie> haha. yeah. if you find a solution I'm interested in it as well. but so far I'm not sure where to start either.
[05:35:56]<Valen>http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_Tp_Notes for trajectory planner notes
[05:38:41]<Valen> Aero-Tec: not a good answer but perhaps a quick one, change the rotary axis into a linear axis?
[05:39:33]<Aero-Tec> can that be done?
[05:39:58]<Valen> not in G code but if you change the ini file
[05:40:40]<Aero-Tec> one would need to figure out how, then how much to move it for the right rotation
[05:41:21]<Valen> changing to a non rotary axis is pretty straight forward
[05:41:34]<Aero-Tec> I would think so
[05:41:43]<Valen> then its just a question of translating your units
[05:42:04]<Aero-Tec> but knowing how much movement did X amount of rotation might be trick
[05:42:27]<Valen> I suggest posting your problem on the mailing list, going to bed and seeing what turns up, and if the answer is, "can't do it yet" then look at doing it this way
[05:42:34]<Aero-Tec> guess one could play with it
[05:42:34]<Valen> shouldn't be too hard, is it a stepper or servo machine?
[05:42:53]<Aero-Tec> I have posted to mailing list
[05:42:57]<Aero-Tec> user one
[05:43:07]<Aero-Tec> steppers
[05:43:29]<Aero-Tec> should I post to developer one as well?
[05:43:35]<Valen> probably not
[05:43:40]<Valen> devs read the user list
[05:43:48]<Valen> they will tell you to post there
[05:43:52]<Valen> how long ago did you post?
[05:44:16]<Aero-Tec> right about the time you diged me
[05:44:20]<Valen> actually the movement should be the same if the "scale" is the same
[05:44:57]<Aero-Tec> steps per deg
[05:45:02]<Aero-Tec> steps per inch
[05:45:09]<Aero-Tec> that should work
[05:45:13]<Valen> yeah just leave them the same so yeah
[05:45:22]<Valen> suggest trying it in a "safe" way first lol
[05:45:29]<Aero-Tec> lol
[05:45:35]<Valen> copy the config don't replace what you have
[05:45:50]<Aero-Tec> make a new config
[05:46:01]<Valen> your using stepconf arent you ;-P
[05:46:15]<Aero-Tec> the whacky rotary linear
[05:46:27]<Aero-Tec> I hand code
[05:46:41]<Aero-Tec> but base it on the wiz
[05:47:05]<Aero-Tec> run a fake wiz config and move the info over
[05:47:19]<Aero-Tec> got tiered of it over writing my changes
[05:47:32]<Valen> I think you could just copy the ini file and change the line that says rotary or linear and be done ;-> you need to change the gcode to match the axies but still
[05:48:08]<Aero-Tec> why would I need to change the gcode?
[05:48:29]<Valen> axis probably isnt going to be called B is it?
[05:48:35]<Valen> or am i smoking crack
[05:48:36]<Aero-Tec> the scale should eb the same and the axis name should be as well
[05:48:46]<Valen> its been a long time since I have dug around in the guts of it
[05:49:30]<Aero-Tec> if it is not B axis I have to redo HAL for a new axis name
[05:49:54]<Aero-Tec> B is wired to the motor for making springs
[05:49:56]<Valen> fair enough, file it under the i'm smoking crack heading lol
[05:50:04]<Valen> whats the machine anyway? got a video?
[05:50:44]<Aero-Tec> I know B is norm a rotary axis
[05:51:06]<Aero-Tec> but like you said, it should be able to be redone
[05:51:36]<Aero-Tec> will loose my 360 roll over
[05:52:04]<Valen> yeah, you can just keep going in the same direction though, only real issue is re-zeroing it
[05:52:05]<Aero-Tec> no vid
[05:52:20]<Valen> before they added that to EMC people used to have to "unwind" to do it
[05:52:54]<Aero-Tec> yea, do not want to unwind
[05:54:04]<Aero-Tec> the email list posting showed up for me
[05:54:18]<Aero-Tec> night, I am off to bed
[05:54:30]<Aero-Tec> hope to have a answer in the morn
[05:54:44]<Aero-Tec> thanks for your help
[05:55:28]<Valen> good luck
[05:55:32]<Valen> no worries
[06:03:09]-!- Fox_Muldr has quit [Ping timeout: 260 seconds][06:04:48]-!- Fox_Muldr [Fox_Muldr!quakeman@frnk-4d01cb9d.pool.mediaWays.net] has joined #linuxcnc[06:06:33]-!- hashfail has quit [Ping timeout: 244 seconds][06:10:31]-!- Vq has quit [Ping timeout: 260 seconds][06:15:03]-!- Cylly has quit [][06:15:10]-!- Loetmichel [Loetmichel!~cylly@p54B11268.dip.t-dialin.net] has joined #linuxcnc[06:19:24]-!- tjb1 [tjb1!~tjb1@74.43.49.247] has joined #linuxcnc[06:29:18]-!- neverho01 has quit [Quit: leaving][06:33:24]-!- mhaberler [mhaberler!~mhaberler@93-82-138-105.adsl.highway.telekom.at] has joined #linuxcnc[06:34:34]-!- kmiyashiro has quit [Quit: kmiyashiro][06:35:46]-!- kwallace [kwallace!~kwallace@smb-115.sonnet.com] has parted #linuxcnc[06:46:55]-!- kmiyashiro has quit [Quit: kmiyashiro][07:04:07]-!- tjb1 has quit [Quit: tjb1][07:11:57]-!- azbyin has quit [Quit: Leaving][07:33:15]-!- racycle has quit [Quit: racycle][07:51:15]-!- asdfasd [asdfasd!hdfghdfg@149.241.132.117] has joined #linuxcnc[07:55:55]-!- DJ9DJ [DJ9DJ!~Deejay@unaffiliated/dj9dj] has joined #linuxcnc[07:56:11]<DJ9DJ> moin
[08:18:15]-!- pikeaero has quit [Read error: Connection reset by peer][08:33:48]-!- yuvipanda has quit [Ping timeout: 244 seconds][08:36:14]-!- theos has quit [Ping timeout: 240 seconds][08:36:37]-!- theos [theos!~theos@unaffiliated/theos] has joined #linuxcnc[08:57:45]-!- tris has quit [Excess Flood][08:58:49]-!- emel has quit [Excess Flood][09:00:23]-!- tris [tris!tristan@camel.ethereal.net] has joined #linuxcnc[09:08:25]-!- c60_ has quit [Ping timeout: 244 seconds][09:11:39]-!- RagingCompute has quit [Ping timeout: 252 seconds][09:16:40]-!- mhaberler has quit [Quit: mhaberler][09:22:27]-!- rob_h [rob_h!~rob_h@5e046bd5.bb.sky.com] has joined #linuxcnc[10:04:20]-!- micges [micges!~micges@eeg247.neoplus.adsl.tpnet.pl] has joined #linuxcnc[10:24:57]-!- rob__H [rob__H!~rob_h@5e046bd5.bb.sky.com] has joined #linuxcnc[10:28:38]-!- yuvipanda has quit [Quit: yuvipanda][10:29:31]-!- logger[mah]_ [logger[mah]_!~loggermah@mail.mah.priv.at] has joined #linuxcnc[10:32:25]-!- _1SheYode [_1SheYode!~mooznach@bzq-84-110-0-111.red.bezeqint.net] has joined #linuxcnc[10:33:09]-!- Jymmmm [Jymmmm!~jymmm@unaffiliated/jymmm] has joined #linuxcnc[10:33:20]-!- Simon2 has quit [Read error: Connection reset by peer][10:34:10]-!- rob_h has quit [*.net *.split][10:35:59]-!- logger[mah] has quit [*.net *.split][10:35:59]-!- gambakufu has quit [*.net *.split][10:36:00]-!- Jymmm has quit [*.net *.split][10:51:11]-!- ktchk [ktchk!~eddie6929@n219079250239.netvigator.com] has joined #linuxcnc[10:58:18]-!- the_wench has quit [Ping timeout: 264 seconds][10:58:28]-!- archivist has quit [Ping timeout: 248 seconds][11:00:01]-!- Valen has quit [Quit: Leaving.][11:02:40]-!- mattswe has quit [][11:04:02]-!- matthijs has quit [][11:17:23]Jymmmm is now known as Jymmm[11:17:27]-!- archivist [archivist!~archivist@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc[11:21:21]-!- the_wench [the_wench!~the_wench@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc[11:25:34]-!- the_wench has quit [Ping timeout: 240 seconds][11:26:34]-!- archivist has quit [Ping timeout: 240 seconds][11:27:54]-!- maximilian_h [maximilian_h!~bonsai@f052037251.adsl.alicedsl.de] has joined #linuxcnc[11:27:55]-!- maximilian_h has quit [Client Quit][11:34:18]-!- yuvipanda has quit [Ping timeout: 264 seconds][11:34:18]yuvipanda_ is now known as yuvipanda[11:39:06]-!- archivist [archivist!~archivist@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc[11:53:32]-!- dhoovie has quit [Read error: Connection reset by peer][11:56:14]-!- sumpfralle [sumpfralle!~lars@c.mail.systemausfall.org] has joined #linuxcnc[12:08:35]jthornton_ is now known as jthornton[12:15:45]-!- mhaberler [mhaberler!~mhaberler@93-82-138-105.adsl.highway.telekom.at] has joined #linuxcnc[12:20:27]-!- yuvipanda has quit [Remote host closed the connection][12:23:41]-!- skunkworks has quit [Remote host closed the connection][12:25:58]zz_satyag is now known as satyag[12:36:45]-!- Jymmm has quit [Ping timeout: 265 seconds][12:41:37]-!- Jymmm [Jymmm!~jymmm@unaffiliated/jymmm] has joined #linuxcnc[12:51:31]<mrsun> sweden the land that doesnt want to exist :P
[12:51:44]<mrsun> aparently the gingerbread man is rasist and is getting banned ...
[12:51:46]<mrsun> like wtf :/
[13:38:18]-!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc[13:48:46]-!- pilla_ has quit [Remote host closed the connection][13:49:16]-!- archivist_herron has quit [Read error: Operation timed out][14:02:02]-!- archivist_herron [archivist_herron!~herron@80.175.14.110] has joined #linuxcnc[14:06:35]-!- archivist_herron has quit [Ping timeout: 241 seconds][14:09:37]-!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc[14:12:23]-!- skunkworks__ [skunkworks__!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc[14:13:02]-!- skunkworks has quit [Ping timeout: 265 seconds][14:14:37]-!- skunkworks_ has quit [Ping timeout: 264 seconds][14:19:08]-!- archivist_herron [archivist_herron!~herron@80.175.14.110] has joined #linuxcnc[14:24:43]-!- archivist_herron has quit [Ping timeout: 264 seconds][14:26:01]-!- mhaberler has quit [Quit: mhaberler][14:29:23]-!- synrat [synrat!~synrat@lnet-008-062.aecom.yu.edu] has joined #linuxcnc[14:34:02]-!- steves_logging has quit [Read error: No buffer space available][14:34:29]-!- steve_stallings [steve_stallings!~Steve@wsip-70-168-134-18.dc.dc.cox.net] has joined #linuxcnc[14:34:57]steve_stallings is now known as steves_logging[14:36:50]-!- archivist_herron [archivist_herron!~herron@80.175.14.110] has joined #linuxcnc[14:44:42]-!- syyl [syyl!~syyl@p4FD142F0.dip.t-dialin.net] has joined #linuxcnc[14:45:17]-!- FinboySlick [FinboySlick!~shark@74.117.40.10] has joined #linuxcnc[14:46:07]-!- archivist_herron has quit [Ping timeout: 252 seconds][14:55:50]-!- automata_ has quit [Ping timeout: 248 seconds][14:57:59]-!- archivist_herron [archivist_herron!~herron@80.175.14.110] has joined #linuxcnc[15:15:06]-!- zzolo has quit [Ping timeout: 264 seconds][15:19:16]-!- schwinn434 [schwinn434!~jameslacy@CPE-76-182-158-150.natwky.res.rr.com] has joined #linuxcnc[15:20:14]-!- cncbasher has quit [Ping timeout: 240 seconds][15:20:45]-!- psha[work] has quit [Quit: Lost terminal][15:21:28]-!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc[15:44:01]-!- jthornton_ [jthornton_!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc[15:44:01]-!- jthornton has quit [Read error: Connection reset by peer][15:50:08]-!- RagingComputer [RagingComputer!~RagingCom@ip98-161-50-39.om.om.cox.net] has joined #linuxcnc[15:53:07]-!- acdha has quit [Client Quit][15:54:49]-!- mhaberler [mhaberler!~mhaberler@93-82-138-105.adsl.highway.telekom.at] has joined #linuxcnc[16:00:19]-!- syyl has quit [Read error: Connection reset by peer][16:00:40]-!- syyl [syyl!~syyl@p4FD142F0.dip.t-dialin.net] has joined #linuxcnc[16:01:08]-!- kwallace [kwallace!~kwallace@smb-23.sonnet.com] has joined #linuxcnc[16:05:47]-!- mhaberler has quit [Quit: mhaberler][16:08:31]-!- bmwyss has quit [Quit: bmwyss][16:10:33]-!- holger [holger!~chatzilla@p5B360D0E.dip0.t-ipconnect.de] has joined #linuxcnc[16:18:39]-!- pingufan [pingufan!~rainer@goliath.hantsch.co.at] has joined #linuxcnc[16:22:14]-!- Nick001-Shop [Nick001-Shop!~chatzilla@69.72.53.58] has joined #linuxcnc[16:25:30]-!- holger [holger!~chatzilla@p5B360D0E.dip0.t-ipconnect.de] has parted #linuxcnc[16:32:41]-!- pingufan has quit [Quit: Konversation terminated!][16:33:01]-!- Simon2 has quit [Quit: Leaving.][16:47:48]-!- ktchk [ktchk!~eddie6929@n219079250239.netvigator.com] has parted #linuxcnc[16:49:13]Jymmm is now known as Red70sShow[16:49:15]Red70sShow is now known as Jymmm[16:51:05]-!- neverho01 has quit [Ping timeout: 255 seconds][16:53:25]satyag is now known as zz_satyag[16:54:48]-!- the_wench [the_wench!~the_wench@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc[16:59:11]-!- sumpfralle has quit [Ping timeout: 260 seconds][17:07:54]-!- zzolo has quit [Quit: zzolo][17:11:05]-!- automata_ [automata_!~automata@triband-mum-59.182.129.215.mtnl.net.in] has joined #linuxcnc[17:15:03]-!- kwallace [kwallace!~kwallace@smb-23.sonnet.com] has parted #linuxcnc[17:18:12]-!- neverho02 has quit [Ping timeout: 264 seconds][17:24:23]<Aero-Tec> mrsun: what are you going on about?
[17:25:14]<Aero-Tec> who got banned from what?
[17:26:06]<Aero-Tec> I am still dealing with no machine stopping when it should be going flat out
[17:26:27]<Aero-Tec> asking in the mailing list as well for help
[17:26:44]<Aero-Tec> so far nothing of help
[17:27:30]<r00t4rd3d> new arduino board:
[17:27:30]<r00t4rd3d>http://arduino.cc/en/Main/ArduinoBoardEsplora[17:28:16]-!- automata_ has quit [Ping timeout: 250 seconds][17:30:18]-!- mackerski has quit [Quit: mackerski][17:30:27]<jdh> google?
[17:31:01]<jdh> that's a funky looking board.
[17:31:04]<archivist> Aero-Tec, did you post the real gcode to the list
[17:31:41]<Aero-Tec> I did this morming
[17:31:57]<Aero-Tec> the non G93 version
[17:32:11]<Aero-Tec> can do the G93 version as well
[17:32:37]<archivist> it arrived on gmail 8 minutes ago
[17:32:58]<archivist> that is not like the one you posted in here yesterday, that had excess g91 I noticed
[17:33:17]-!- automata__ [automata__!~automata@triband-mum-59.182.129.215.mtnl.net.in] has joined #linuxcnc[17:34:22]-!- schwinn434 has quit [Ping timeout: 264 seconds][17:34:39]<archivist> I would recommend you dont repeat g90 if already in the mode
[17:36:08]<archivist> G0G90X0 feels dirty in the extreme
[17:41:08]<archivist> also add exactly where you think you get stops
[17:43:16]-!- Vq [Vq!~vq@81-225-108-241-no123.tbcn.telia.com] has joined #linuxcnc[17:46:12]<cradek> those extra words don't hurt anything, but like archivist I'd also appreciate more information like what you think is incorrect about the motion and where
[17:46:49]<cradek> (a minimized test case that shows the problem would also have been nice)
[17:46:49]-!- L84Supper has quit [Ping timeout: 240 seconds][17:46:54]-!- automata__ has quit [Ping timeout: 264 seconds][17:48:20]-!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc[17:48:20]<archivist> are you sure the parser wont finish the previous g0 when there is a g90 in between
[17:48:20]<cradek> that makes no difference
[17:50:31]<archivist> he is looking for best possible speed (blending)
[17:50:31]<cradek> I wonder what the intent of F19000000 is
[17:50:47]<archivist> get the rotary as fast as it can go
[17:52:35]<Aero-Tec> yes
[17:52:43]<Aero-Tec> that was exactly the idea
[17:52:54]-!- automata_ [automata_!~automata@triband-mum-59.182.129.215.mtnl.net.in] has joined #linuxcnc[17:54:44]<Aero-Tec> it should be able to do all this in one smooth move
[17:54:46]<Aero-Tec> F19000000
[17:54:48]<Aero-Tec> G1 X-0.03 B100
[17:54:48]<Aero-Tec> G1 X-0.01 B60
[17:54:50]<Aero-Tec> G1 X-.01 B500
[17:54:51]<Aero-Tec> G1 X-1 B3240
[17:55:26]<Aero-Tec> not stop at the end of each move
[17:55:59]<archivist> it may slow down but dies it really stop
[17:56:04]<archivist> does
[17:56:29]<Aero-Tec> sure looks like it does
[17:56:35]<cradek> I see slowing down but not stopping
[17:57:01]<Aero-Tec> with a open G64 it should not slow down at all
[17:57:27]<Aero-Tec> it should flat out boggy through the code
[17:58:30]<Aero-Tec> at least that is how I read the info about G64
[17:58:48]-!- IchGuckLive [IchGuckLive!~chatzilla@95-89-101-95-dynip.superkabel.de] has joined #linuxcnc[17:58:48]<IchGuckLive> hi all
[17:58:48]-!- gmouer [gmouer!~gmouer@cpe-74-65-14-255.rochester.res.rr.com] has joined #linuxcnc[17:59:03]<IchGuckLive> Aero-Tec: ? how did you came up
[17:59:42]<cradek> Aero-Tec: between which lines are you seeing a stop that you think shouldn't be there?
[18:00:10]<IchGuckLive> cradek: did he post g-code
[18:00:22]<cradek> IchGuckLive: to the mailing list
[18:00:31]<IchGuckLive> ah ok
[18:00:37]<IchGuckLive> im off the list
[18:00:44]<Aero-Tec> I have posted a paste bin version here as well
[18:01:14]<Aero-Tec> IchGuckLive: I had to go back to the old setup
[18:01:22]<Aero-Tec> both INI and hal
[18:01:26]<archivist> we still dont know where you think it is stopping
[18:01:35]<Aero-Tec> your version did not work near as well
[18:02:41]<IchGuckLive> (ROTORY TABLE STEPPER MOUNT PROFILE.NC) is this the NC
[18:03:26]-!- kwallace [kwallace!~kwallace@smb-23.sonnet.com] has joined #linuxcnc[18:04:07]<cradek> unless you answer my question I will assume any problem is caused by the misspelling ROTORY
[18:04:07]<IchGuckLive> mach3 code is bad
[18:04:43]<Aero-Tec> yes that is it
[18:04:44]<Aero-Tec> and the title means nothing
[18:05:28]<Aero-Tec> it was code from before, I turned it into starter code for hand written code I did
[18:05:54]<Aero-Tec> missed a line in the code before
[18:06:01]<Aero-Tec> F19000000
[18:06:03]<Aero-Tec> G1 X-0.03 B100
[18:06:05]<Aero-Tec> G1 X-0.01 B60
[18:06:07]<Aero-Tec> G1 X-.01 B500
[18:06:09]<Aero-Tec> G1 X-1 B3240 ;4680
[18:06:11]<Aero-Tec> G1 X-0.02 B530
[18:06:15]-!- MattyMatt has quit [Ping timeout: 240 seconds][18:06:19]-!- psha [psha!~psha@213.208.162.92] has joined #linuxcnc[18:06:29]<Aero-Tec> it is here where you notice it the most
[18:06:31]<Aero-Tec> G1 X-1 B3240 ;4680
[18:06:33]<Aero-Tec> G1 X-0.02 B530
[18:06:40]-!- MattyMatt [MattyMatt!~matt@cpc2-birk6-0-0-cust92.1-3.cable.virginmedia.com] has joined #linuxcnc[18:07:06]jthornton_ is now known as jthornton[18:07:21]<Aero-Tec> the other short small moves are harder to see as they no sooner get going and then they are stopping, so they are slow to get to full speed
[18:07:54]<IchGuckLive> get this of ;4680 and the B axius need a stop bevor returning
[18:08:08]<cradek> between those two lines X is reversing, right?
[18:08:11]<Aero-Tec> then the big run and then it comes screaming to a halt, does one more short move then reverse
[18:09:12]<IchGuckLive> B is also reversing so it has to take a litel stop
[18:09:45]<archivist> it is in g91!
[18:09:51]<Aero-Tec> no, the mode is G91, relative, it is all the same dir
[18:10:20]<cradek> doh
[18:10:22]<cradek> right
[18:10:27]<IchGuckLive> B is a wrapped rotary in your ini
[18:10:31]<archivist> have you got the x per rotation degrees the same
[18:10:48]<Aero-Tec> yes, B is wrapped
[18:10:53]<archivist> else there is a corner
[18:12:06]<Aero-Tec> no it is not, that is why it is broken into segments, to close the ends of the spring
[18:12:18]hdokes|werkin is now known as hdokes[18:12:20]<IchGuckLive>http://wiki.linuxcnc.org/cgi-bin/wiki.pl?WrappedRotaryAxes[18:12:26]<Aero-Tec> with G64 it sould not care much about the corner
[18:12:40]<IchGuckLive> Aero-Tec: did you read the behavier of a wrapped rotary on G91
[18:12:54]<archivist> you need to specify a larger tolerance I think
[18:13:03]<Aero-Tec> guess not
[18:13:08]<Aero-Tec> with G64 open like I did
[18:13:26]<Aero-Tec> it is unlimited, just go as fast as it can
[18:13:45]<Aero-Tec> I would put a limit on it if needed
[18:13:47]<cradek> I doubt tolerance mode affects these blends
[18:14:24]<Aero-Tec> there is not blend, I can see it stop, or so darn close it looks to be stopped
[18:14:33]<jthornton> I ran the file in the 9 axis sim and it seems to run smooth to me without any stopping
[18:14:49]<cradek> well I plotted the motion, and it doesn't stop
[18:15:06]<cradek> it does slow down
[18:16:22]-!- schwinn434 [schwinn434!~jameslacy@CPE-76-182-158-150.natwky.res.rr.com] has joined #linuxcnc[18:18:06]<Aero-Tec> how slow?
[18:18:58]<cradek> between lines 20 and 21 it slows down about about 40%ish
[18:19:00]<Aero-Tec> I read the info about wrapped, one can command a move greater then 360, I have done it and it works fine
[18:19:27]<cradek> I don't have wrapped turned on, but it doesn't matter in this G91 program
[18:19:28]<Aero-Tec> in G90 you can not but G91 is no problem
[18:19:41]<cradek> right
[18:20:16]<Aero-Tec> could wrapped be a bug in the system?
[18:20:17]<cradek> is your spring winder just 2 axes, X and B?
[18:20:33]<Aero-Tec> could wrapped be making it stop when it should not?
[18:20:40]<gmouer> I have a M110 code setup and working for my collet closer BUT I really want it to be M10 to be more like the standards out there. If I rename the file from M110 to M10 it no longer works. The remap document says M100-M199 and the unassigned (M10) codes are available and it does not mention any different method of setting them up. What am I missing to be able to use this working bin/bash
[18:20:41]<gmouer> file as M10 ?
[18:20:47]<Aero-Tec> yes
[18:20:47]<cradek> unlikely
[18:20:52]<Aero-Tec> the machine has 4 axis
[18:20:56]<cradek> (I don't believe that it's stopping unless you show me a plot that shows it.)
[18:21:46]<Aero-Tec> it is slowing tons more then 40% or or even to 40%, it stops or oh so close to it
[18:21:58]<cradek> ok can you elaborate on how your machine has 2 axes and also has 4 axes
[18:22:13]<Aero-Tec> how do I plot?
[18:22:13]<cradek> with halscope
[18:22:26]<Aero-Tec> and one can save it to file?
[18:22:58]<Aero-Tec> it is a knee mill, started life with X,Y,Z,A
[18:23:19]<cradek> here is what I am seeing: http://timeguy.com/cradek-files/emc/lines20-21-22.png[18:23:32]<cradek> there are no stops, but the blends are poor
[18:23:32]<Aero-Tec> but mach liked to drive Z into table or anything else in the way so Z was removed
[18:23:51]<Aero-Tec> and turned into a portable B axis
[18:24:27]<Aero-Tec> A is a large rotary table with worn drive
[18:25:07]<cradek> ok, I was picturing a dedicated spring-winding machine with only two degrees of freedom
[18:25:18]<cradek> and I had a suggestion relevant to that
[18:25:38]<Aero-Tec> it is also somewhat portable, heavy. I use it in vertical and horizontal config as needed.
[18:27:05]-!- yuvipanda has quit [Read error: Connection reset by peer][18:27:11]<Aero-Tec> cool, how did you do that?
[18:27:40]<Aero-Tec> first how did you set it up and second how did you get that pix?
[18:28:11]<Aero-Tec> I can gen one for you so you can see for your self
[18:28:52]-!- bradsimantel has quit [Quit: bradsimantel][18:28:57]<cradek> you can see the three pins I plotted in the picture. I took the screenshot with the normal screenshot-taker.
[18:30:09]<Aero-Tec> new to linux so I did not know there was a screen shot taker
[18:30:33]-!- automata_ has quit [Ping timeout: 244 seconds][18:30:46]<archivist> in applications, accessories
[18:30:51]<Aero-Tec> also do you have to time the screen shot? or can hal scope do freeze frame?
[18:31:10]<cradek> I think "corners" in XB (etc) are not as well blended as corners in XY, YZ, ZX, AB, BC, CA
[18:32:09]-!- mhaberler [mhaberler!~mhaberler@93-82-138-105.adsl.highway.telekom.at] has joined #linuxcnc[18:33:11]<gmouer> mhaberler: just the guy I need, I have a remap question
[18:33:38]<mhaberler> uh
[18:33:44]<mhaberler> go ahead
[18:34:01]<Aero-Tec> looks like X did not stop at all
[18:34:05]<gmouer> I have a m110 code setup and working for my collet closer BUT really want to use M10 If I rename the file to M10 it no longer runs
[18:34:31]<Aero-Tec> B came close but X looked to be non stop
[18:34:41]<Aero-Tec> if I read it right
[18:34:41]<gmouer> it is a bin/bash file the simply sets a pin state to true
[18:34:41]<mhaberler> I assume M10 is a non-remappable builtin
[18:34:45]<mhaberler> let me look
[18:34:59]<gmouer> M10 showed as unassigned
[18:35:40]<mhaberler> aja, just saw it
[18:36:16]<Aero-Tec> will see if I can do a hal scope for you guys
[18:36:34]<mhaberler> right. so what is 'no longer runs' - please pastebin log, config etc
[18:36:44]<gmouer> the M110 works with no ini file entries at all, would the M10 require entries in the ini file of some sort? (I tried but no go)
[18:37:08]<mhaberler> then that was not a remap
[18:37:28]<mhaberler> but you used the M100-m199 codes which are something different
[18:37:42]<gmouer> I am new, but think that is correct, I set up the M110 like the examples
[18:38:03]<gmouer> So, to use M10 would need a remap then?
[18:38:11]<mhaberler> you used this: http://www.linuxcnc.org/docs/devel/html/gcode/m-code.html#_m100_to_m199_user_defined_commands_a_id_sec_m100_to_m199_a[18:38:33]<mhaberler> do you absolutely need it to be M10?
[18:39:00]<mhaberler> yes it would, but you could call the m110 in the m10 remap procedure
[18:39:21]<gmouer> no, not absolutely, but M10/M11 is what most lathes use for collet closer and it would not require tweaking cadcam postprocessor
[18:40:13]<mhaberler> fine, so define a M10 remap as outlined here: http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_an_minimal_example_remapped_code[18:40:13]<gmouer> tried calling m110 in the m10 remap BUT think I screwed up..... used uppercase for the m10 was thinking it was the same as the M110
[18:40:20]-!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc[18:40:34]<mhaberler> and in the myprocedure.ngc you call your m110
[18:40:38]<gmouer> yes
[18:40:59]<mhaberler> well if you did no ini changes the m10 remap didnt exist
[18:41:14]<mhaberler> follow that example, and adapt it to call m110 in myprocedure
[18:41:19]<gmouer> I put the M10 into the ini rmap when I tried it that way
[18:41:27]-!- sliptonic has quit [Read error: Connection reset by peer][18:41:31]<mhaberler> you just said you did no ini changes
[18:41:54]<gmouer> tried it both ways, first simply renamed M110 to M10, then tried a remap
[18:42:07]<mhaberler> how did you try a remap
[18:42:34]<gmouer> the M110 is uppercase M, I think that is my screwup, used uppercase M for the M10 also
[18:42:50]<mhaberler> please post config
[18:43:13]<mhaberler>http://pastebin.com/ them
[18:43:23]-!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc[18:43:29]<gmouer> can't get at the machine right now to postbin the file
[18:43:37]<mhaberler> me neither
[18:43:51]<gmouer> should the m in m10 be lowercase?????
[18:44:17]<mhaberler> it does not matter except if explicitly noted in the manual; there is one such note
[18:45:07]<gmouer> I remember that M100-199 had to be uppercase, yet g code remaps had to be lowercase, no idea about M0-M99 case requrements
[18:45:26]<mhaberler> no, they dont
[18:45:49]<mhaberler> just copy and paste the manual example, and go from there - and take one step at a time
[18:45:49]hdokes is now known as hdokes|werkin[18:46:49]<gmouer> I have other remaps up and running without problem, but they are G code remaps
[18:47:07]<mhaberler> well fine, then its no different with M
[18:47:15]<gmouer> and I did a couple of M code setups in the M100+ area without problem
[18:47:26]<IchGuckLive> REMAP=M10 modalgroup=10 ngc=m10
[18:47:40]<mhaberler> AHA
[18:47:58]<gmouer> does it have to be a ngc file or can it be a bin/bash file like my M110 code?
[18:48:31]<mhaberler> again, the manual is entirely clear saying: either an ngc file or a Python function
[18:48:37]<IchGuckLive> m10.ngc
[18:48:37]<IchGuckLive> #!/bin/bash
[18:48:37]<IchGuckLive> # file to turn on parport pin 14 to open the collet closer
[18:48:38]<IchGuckLive> halcmd setp parport.0.pin-14-out True
[18:48:40]<IchGuckLive> exit 0
[18:48:51]<IchGuckLive> this shoudt work
[18:49:06]-!- motioncontrol [motioncontrol!~io@host9-49-dynamic.55-82-r.retail.telecomitalia.it] has joined #linuxcnc[18:49:12]<mhaberler> Mr IchGuckLive: I am sorry - shell code in an ngc procedure will _not_ work
[18:50:04]<gmouer> I am new so the docs are confusing sometimes, I didn't think a .ngc file could have a #!/bin/bash format in it
[18:50:04]<mhaberler> please thisregard this post, this is just extra confusion
[18:50:04]<IchGuckLive> it is working in userdifined mcodes
[18:50:15]<mhaberler> that is _not a remap_
[18:50:42]<IchGuckLive> agree
[18:50:51]-!- tjb1 [tjb1!~tjb1@74.43.55.251] has joined #linuxcnc[18:51:19]<mhaberler> gmouer: what you want is:
[18:51:31]<gmouer> the doc says both unassigned codes and M100-M199 are available for remap, that is prob where i got confused, I tried the same methods for M110 as for M10 M110 has no ini file entry and it works
[18:51:45]<mhaberler> really?
[18:52:27]<gmouer> yea, the docs said to restart linuxcnc and it will find the new M110 code in its folder, which it did, no ini file entry at all
[18:52:55]<mhaberler> that is all fine but what you actually wanted to do is remap M10 to execute your M110, not remap M110
[18:53:43]<gmouer> yes, but the doc led me to believe that M10 and M110 could be handled in the same manner
[18:53:54]<gmouer> that is why I simply tried renaming the file at first
[18:53:58]<mhaberler> no, the M100- section doesnt say that
[18:55:03]<mhaberler> just follow the example link I gave you, and make it work. Then change M400 to M10. then add your M110 to the ngc procedure and it will work.
[18:55:11]<IchGuckLive> mhaberler: can i put self.execute("M110",lineno()) into the remap o<m10> sub
[18:55:56]<gmouer> .3. Currently unallocated M-codes: These codes are currently undefined in the current implementation of LinuxCNC and may be used to define new M-codes:
[18:56:01]<gmouer> M10
[18:56:01]<gmouer> M11 M12 M13 M14 M15 M16 M17 M18 M19 M20
[18:56:01]<gmouer> M21 M22 M23 M24 M25 M26 M27 M28 M29 M31 M32 M33 M34 M35 M36 M37 M38 M39 M40
[18:56:01]<gmouer> M41 M42 M43 M44 M45 M46 M47 M54 M55 M56 M57 M58 M59 M74 M75 M76 M77 M78 M79 M80
[18:56:01]<gmouer> M81 M82 M83 M84 M85 M86 M87 M88 M89 M90
[18:56:01]<gmouer> M91 M92 M93 M94 M95 M96 M97 M98 M99All codes between M199 and M999.
[18:56:01]<mhaberler> you can, but what is the point
[18:56:01]<gmouer> this is what led me to believe it would work
[18:56:07]<IchGuckLive> then it is simple
[18:56:31]<IchGuckLive> as we call the M110 witch holds the halcmd
[18:56:50]-!- zzolo has quit [Quit: zzolo][18:56:51]<gmouer> yes, I used a halcmd in my M110 file
[18:56:52]<mhaberler> the M codes manual is quite clare that this feature works in the M100-M199 range and not elsewhere
[18:57:21]<IchGuckLive> but the Remap M10 cals the M110
[18:57:26]<mhaberler> yes, fine
[18:57:48]<mhaberler> M100-M199 is an old way of remapping, and all you can do is shell commands
[18:57:50]<IchGuckLive> so with 3 lines it is done
[18:59:46]<gmouer> guess I will have to just experiment more. The other remaps I did all work fine. One uncovered a code bug but that was fixed and now works fine also.
[19:00:10]<mhaberler> do not waste time with experiments, use the manual example
[19:00:15]<IchGuckLive> mhaberler: im still confused can i do this i the sub of the ngc or do i need to put this into a python
[19:00:34]<IchGuckLive> self.execute("M110",lineno())
[19:00:52]<mhaberler> that is a Pyhton statement, what calls it?
[19:00:53]<gmouer> the manual examples didn't prove to be a lot of help, that is why I am here
[19:01:14]<IchGuckLive> so python=m10 not ngc=m10
[19:01:43]<mhaberler> ok, let us walk through the example
[19:01:55]<IchGuckLive> up tp you
[19:02:00]<mhaberler> you write in [RS274NGC]:
[19:02:27]<mhaberler> REMAP=m10 ngc=foo.ngc
[19:02:36]<mhaberler> you create foo.ngc on some path the interpreter will find
[19:02:36]<mhaberler> it shall read:
[19:02:36]<mhaberler> o<foo> sub
[19:02:36]<mhaberler> m100
[19:02:46]<mhaberler> o<foo> endsub
[19:02:47]<mhaberler> m2
[19:03:05]<mhaberler> sorry m110 not m100
[19:03:13]<mhaberler> save files, restart linuxcnc, done.
[19:03:30]<IchGuckLive> yes shorter then mine
[19:04:02]<gmouer> pretty sure I did exactly that, with the possible exception of using upper case M's, I will try it again
[19:04:06]<mhaberler> all I did change from the manual example is change M400 to M10 and myprocedure to foo
[19:04:44]<mhaberler> split the problem in two halves:
[19:04:49]<mhaberler> first write an ngc procedure which does what you want
[19:04:56]<mhaberler> for instance, your M100
[19:05:03]<mhaberler> the name of the proecure is irrelevant
[19:05:06]<IchGuckLive> 110
[19:05:17]<gmouer> if the ngc file was named M10.ngc using upper case, that would not present a problem then?
[19:05:23]<gmouer> I got a file not found type error
[19:05:36]<mhaberler> it could, use some other name, but I dont think so
[19:06:01]<IchGuckLive> i woudt use colletopen.ngc
[19:06:02]<mhaberler> just use foo and you avoid a name collision
[19:06:05]<gmouer> ahhhhhhh that was my suspect since we started was looking for clairification
[19:06:05]<mhaberler> excellent
[19:06:46]<mhaberler> you experiment with colletopen.ngc until it does exactly what you want
[19:06:56]<IchGuckLive> foo.ngc is an error
[19:07:00]<IchGuckLive> foo
[19:07:01]<mhaberler> executie it like 'o<colletopen> call
[19:07:08]<gmouer> I will play some more and if I hit a dead end I will save the files to pastebin next time
[19:07:23]<mhaberler> (can I take a single customer at a time please ;)
[19:07:33]<IchGuckLive> Do not specify an .ngc extension
[19:08:00]<mhaberler> gmouer: forget remap for now, get the ngc procure working
[19:08:36]<mhaberler> if you can call it with 'o<whatever> call' in MDI and it does what you want, then take the next step
[19:08:43]<IchGuckLive> REMAP=m10 ngc=foo.ngc this is wrong -> REMAP=m10 ngc=foo without the ngc
[19:09:47]<mhaberler> can I quote from the manual, which is clear on the issue:
[19:09:48]<mhaberler> ngc=<ngc_basename>
[19:09:49]<mhaberler> Basename of an O-word subroutine file name. Do not specify an .ngc extension.
[19:10:08]<IchGuckLive> you got it
[19:10:44]<mhaberler> it is all there, gents - I cannot read it for you, I can only write it for you
[19:10:44]<IchGuckLive> B)
[19:11:26]<IchGuckLive> i learned alot thanks mhaberler and by for today
[19:11:51]<gmouer> respectfully, the docs are clear to a highly experienced user, but can be quite confusing to someone new to linuxcnc, aka its all clear once you know it.
[19:12:44]-!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 16.0.2/20121025205401]][19:13:20]<mhaberler> I know - it would really help if some non-programmer added a section here
[19:13:42]<mhaberler> by definition that cant be me though, but I am happy to add a contribution
[19:14:45]<gmouer> I will get it, I always do, its just that some battles are bloodier than others
[19:15:02]<mhaberler> have you probed around configs/sim/remap ?
[19:15:25]<gmouer> I have not played with sim's at all
[19:15:40]<mhaberler> it works in non-sim just alike
[19:16:02]<gmouer> I came from the mach3 world about a year ago, since have retrofitted 3 machine over to linuxcnc and love it
[19:16:14]<mhaberler> I totally agree on the 'bloody' part, retrofitting that feature onto the existing interpreter structure also qualifies as 'bloody'
[19:16:16]<mhaberler> unfortunately that shows in the configuration a bit
[19:16:45]<mhaberler> you should have seen my first attempt ;)
[19:16:50]<gmouer> I have done a few remaps successfully, so I am getting there, even HAL is now not nearly as much trouble as it once was
[19:17:31]<gmouer> I don't envy you working in the inner depths of the source code
[19:17:36]<mhaberler> the easyest approach is (and I'll add that) is: split problem - first get remap action going without REMAP=something
[19:17:44]<mhaberler> then wrap in a REMAP
[19:18:00]<mhaberler> it only occurred to me later when doing the demos
[19:18:25]<gmouer> yes, I did exactly that when I setup my g68 and g69 remaps (for a gang tooled lathe)
[19:19:07]<mhaberler> any surprises?
[19:19:29]<gmouer> a code bug which you fixed and pushed, then all worked swell
[19:19:36]<mhaberler> btw even if you have a REMAP=M10 ngc=foo
[19:19:58]<mhaberler> you still can do 'o<foo> call' to make sure the action is doing the right thing
[19:20:14]<mhaberler> a remap is a glorified way to call a NGC or Python subroutine
[19:20:25]<mhaberler> (_very_ glorified)
[19:20:26]<gmouer> yes, I have done that in the past
[19:20:28]<gmouer> good technique
[19:20:59]<mhaberler> ok, you are drafted to write the debugging section of the remapping manual ;)
[19:21:10]<gmouer> I have the M110 and M111 working and opening and closing the collet, so I am over half way there
[19:21:51]<gmouer> fortunately, I love this technical stuff so I enjoy it even when it does not go smooth
[19:22:00]<mhaberler> I probably should explain the relation of M1XX and remapping (i.e. none whatsoever)
[19:22:09]<gmouer> I think its the challenge
[19:22:50]<gmouer> yes, that relation of M1XX and remapping is probably what got me all confused
[19:23:03]<mhaberler> well I dont know who did this, but the M1XX was a cheap way to get some user-configurable code going, provided the 'code' is a shell script
[19:23:54]<mhaberler> the first implementation of remapping required C code as glue
[19:23:59]<gmouer> I thought unassigned M codes in the low number range would be handled the same as the M1XX range wrong!
[19:24:52]<mhaberler> well it's a tradeoff; I could have subsumed M1XX under remapping and would have attracted lots of flak
[19:24:57]<gmouer> remapping is a extremely powerfull tool, your work is much appreciated !
[19:25:03]<mhaberler> thanks
[19:25:30]<mhaberler> 'lots of rope' it seems; I really wish I could take some of that out
[19:25:51]<gmouer> I am spoiled with all these tools at my disposal after coming over from mach3, and they all actually work! LOL
[19:26:18]<mhaberler> geek pride and peer pressure go a long way
[19:26:49]<mhaberler> and the danger of looking like a real idiot;)
[19:27:43]<gmouer> a lathe retrofit is what finally sent me to linuxcnc, mach3 was just a lost cause, full of bugs and features that never have worked, like CSS
[19:28:48]<jdh> use Mach4!
[19:29:07]<mhaberler> Jymmm: is it you?
[19:29:16]<gmouer> oh lord! Mach4 LOL,, how many centurys will that take to get the bugs worked out, if ever
[19:29:32]<mhaberler> I wish some day people cook up more creative stuff than my examples, like profile definition and execution, roughing, finish
[19:30:01]<mhaberler> I fear these guys really bet the farm on the wrong vehicle.. very hard to make that dog hunt
[19:30:33]<gmouer> I think some more posted examples of peoples code they used would be very helpfull
[19:31:23]-!- BHSPiMonkey has quit [Ping timeout: 252 seconds][19:31:26]<mhaberler> I think some ideas I of Mach are worth considering; the better integration of interpreter and VBA (or Python in our case) for example, and easier extending of UI's but there's a lot happening here
[19:31:35]<gmouer> I have countless hours searching for sample code similar to what I want to do but rarely find much
[19:32:27]<mhaberler> I will give you some different example of 'code hunts', the one I'm currently on:
[19:32:33]<mhaberler> I have 4 (four) accounts of folks running Xenomai on the BeagleBone ARM card
[19:33:07]<mhaberler> I have one running after a hit-and-miss game, and play 'patch extortion' with the other three
[19:33:49]<mhaberler> it was the same with the LinuxCNC xenomai ports - 4 out there, usable code: very slim - no history, lots of copy & paste, yadayada
[19:34:13]<mhaberler> one would thing 'take and give' is the rule with open source
[19:34:35]<mhaberler> the 'and give' part needs patient..obnoxious reminding
[19:34:52]-!- hewball_ [hewball_!~Hewball@piksta.net] has joined #linuxcnc[19:35:25]-!- hewball has quit [Ping timeout: 246 seconds][19:36:18]<gmouer> since coming to linuxcnc from mach, I have identified some real hero's here, that put in a lot of work, of which you are one of those hero's
[19:36:30]<gmouer> and I still get into deep trouble LOL
[19:36:38]<gmouer> but less every day
[19:36:44]-!- Tom_L [Tom_L!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc[19:37:44]-!- BHSPiMonkey [BHSPiMonkey!~BHSPitMon@68-185-203-185.dhcp.dntn.tx.charter.com] has joined #linuxcnc[19:37:50]<gmouer> thanks much for the help, and your work, I am off to whip my controller into submission
[19:37:53]-!- Tom_L has quit [Client Quit][19:38:04]<mhaberler> good luck, and let me know if you get stuck
[19:38:48]-!- gmouer has quit [][19:40:14]-!- archivist has quit [Ping timeout: 240 seconds][19:41:22]-!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc[19:41:30]-!- the_wench has quit [Ping timeout: 264 seconds][19:50:49]-!- zzolo has quit [Read error: Connection reset by peer][19:50:50]zzolo_ is now known as zzolo[19:50:58]-!- sumpfralle [sumpfralle!~lars@c.mail.systemausfall.org] has joined #linuxcnc[19:51:02]-!- motioncontrol has quit [Ping timeout: 255 seconds][19:51:28]-!- micges has quit [Quit: Leaving][19:51:42]-!- motioncontrol [motioncontrol!~io@87.18.72.139] has joined #linuxcnc[19:57:39]-!- archivist [archivist!~archivist@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc[20:00:17]-!- psha has quit [Quit: Lost terminal][20:02:59]-!- vladimirek has quit [Ping timeout: 243 seconds][20:04:03]-!- bedah [bedah!~bedah@g224159177.adsl.alicedsl.de] has joined #linuxcnc[20:05:30]-!- elk has quit [Ping timeout: 245 seconds][20:07:50]-!- motioncontrol has quit [Quit: Sto andando via][20:08:31]-!- motioncontrol [motioncontrol!~io@87.18.72.139] has joined #linuxcnc[20:08:32]-!- gmouer [gmouer!~gmouer@cpe-74-65-14-255.rochester.res.rr.com] has joined #linuxcnc[20:10:06]<gmouer> mhaberler: I changed all the uppercase M's to lower case in my ini file remap statements, the ngc m10 filename, and within those files and now the remaps for M10 and M11 work nicely. Wanted to report and say thank you again
[20:10:25]<mhaberler> please copy and paste that line here so I can see what broke it
[20:10:47]<gmouer> the remap line? or the ngc file?
[20:11:19]<Jymmm> mhaberler: ???
[20:11:39]<gmouer> I will get both, brb
[20:11:44]<mhaberler> somebody was touting Mach4, and I though it could be you under a different nick
[20:12:15]<Jymmm> mhaberler: Why? I've never ever used mach.
[20:12:28]<mhaberler> just a stab in the dark
[20:13:04]-!- tjb1 has quit [Quit: tjb1][20:13:09]<Jymmm> mhaberler: Yeah, ok, but what made you think me? I've never promoted M$
[20:13:32]<mhaberler> well, you make all sorts of comments which make me laugh
[20:14:14]-!- bedah has quit [Ping timeout: 240 seconds][20:14:43]-!- bedah [bedah!~bedah@g224159177.adsl.alicedsl.de] has joined #linuxcnc[20:15:01]* Tom_itx thinks Jymmm just looks guilty[20:15:16]<Jymmm> of?
[20:16:21]<archivist> anything
[20:16:21]<Jymmm> Nah, got to be more specific.
[20:16:21]-!- sumpfralle1 [sumpfralle1!~lars@31-16-116-72-dynip.superkabel.de] has joined #linuxcnc[20:16:21]-!- wboykinm has quit [Read error: Connection reset by peer][20:16:21]<Tom_itx> it's kinda like that red headded freckle faced kid down the street that just has that look
[20:17:01]<Jymmm> Well,, it's those silent Atmel programmer types you gotta watch out for though.
[20:17:09]<Tom_itx> :)
[20:17:33]<gmouer> mhaberler: he is one to make you laugh , the remap lines from my ini file
[20:17:38]<gmouer> SUBROUTINE_PATH = /home/george/linuxcnc/nc_files/ngcgui_lib/
[20:17:39]<gmouer> REMAP=g68 modalgroup=1 ngc=g68
[20:17:39]<gmouer> REMAP=g69 modalgroup=1 ngc=g69
[20:17:39]<gmouer> REMAP=M10 modalgroup=10 ngc=m10
[20:17:39]<gmouer> REMAP=M11 modalgroup=10 ngc=m11
[20:18:22]<mhaberler> are these working or not?
[20:18:34]-!- sumpfralle has quit [Ping timeout: 250 seconds][20:18:54]<mhaberler> if REMAP=m10 didnt work but REMAP=M10 worked, than I need to fix that
[20:19:02]<gmouer> yep, nicely, I switched the upper case M's to lowercase in the ini, the file names and within the files, that fixed it
[20:19:48]<mhaberler> could you verify that saying 'REMAP=m10 …' does not break it?
[20:19:56]<gmouer> ok, I will go back out and change the the m10 to M10 in the remap statement only and see what happens, I suspect it was the M10 in the ngc file name that caused the problem though
[20:20:22]<gmouer> brb
[20:20:26]<mhaberler> the filenames - well thats clear, linux filenames are case sensitive
[20:22:52]<Aero-Tec> cradek: you still around?
[20:23:10]<andypugh> If my milling machine has a 19mm leadscrew, would it make sense to up-size the ballscrew to 25mm? I have a feeling that ballscrews have a bit less stiffness than a leadscrew.
[20:23:19]<Aero-Tec> looks like he is gone
[20:24:02]<gmouer> mhaberler: that was easy, it crashed on startup, debug info says M10 file not found
[20:24:27]<Aero-Tec> I would think ball screws are more stiff then lead screws
[20:24:27]<andypugh> Hertzian stress is way higher, I think
[20:24:27]<Aero-Tec> case hardened should make then real stiff
[20:24:35]<mhaberler> well sure thats the ngc=M10/m10 case; I was referrring to 'REMAP=M10 versus REMAP=m10'
[20:24:53]<andypugh> (or, less pretentiously, there is a lot more metal-to-metal contact in an acme-nut.
[20:25:12]<mhaberler> since the rest behind ngc= is a basename of a file, case matters
[20:25:14]-!- phantoneD has quit [Read error: Connection reset by peer][20:25:16]<andypugh> Aero-Tec: Hardening has absolutely zero effect on the stiffness of steel.
[20:25:27]<Aero-Tec> but the contact is not as tight
[20:25:33]<gmouer> that is what I changed, m10 to M10 in the remap statement ngc=M10
[20:25:33]-!- phantoxeD [phantoxeD!~destroy@a95-92-89-24.cpe.netcabo.pt] has joined #linuxcnc[20:26:13]<andypugh> I am not talking about backlash, which is clearly much greater with an acme thread, but the load/deflection curve.
[20:26:45]<Aero-Tec> try bending soft steel, then try hardened steel, I have and I know there is a huge difference
[20:27:08]<gmouer> mhaberler, so case does matter in the filename... I got confused with the uppercase M used in M1XX setups, my mistake
[20:27:36]<mhaberler> right, it should matter only in the non-rs274ngc syntax part
[20:27:52]<mhaberler> the M10 in REMAP=M10 is 'rs274ngc syntax' if you will
[20:28:19]<mhaberler> ngc=filename or python=functionname is according to linux filename or Python naming rules
[20:28:21]<gmouer> that is what threw me, file names for M110 and m11 play the rules different as far as case is concerned
[20:28:35]-!- tjb1 [tjb1!~tjb1@74.43.55.108] has joined #linuxcnc[20:29:17]<Aero-Tec> I am trying to do a hal scope like cradek did
[20:29:26]<mhaberler> ah, maybe those arent case-normalized
[20:29:26]<Aero-Tec> it is not working out like his did
[20:29:33]<gmouer> my M110 file is upper case and no file extension
[20:29:39]<andypugh> Aero-Tec: Yes. But in the elastic region the stifness is identical. The yield stress is much lower, but the Young's Modulus is completely independent of hardness, and is almost exactly the same number for every grade of steel, and only a little different for cast iron.
[20:30:31]<gmouer> mhaberler: that one won't bite me again, another lesson learned
[20:30:45]<Aero-Tec>http://timeguy.com/cradek-files/emc/lines20-21-22.png[20:31:03]<Aero-Tec> like this one
[20:31:16]<andypugh> So, for example, it doesn't really matter if you make your boring bar out of mild steel or hardened tool steel (assuming you don't bend the mild steel one, of course). If you want to make a boring bar stiffer then you need to give it a carbide core (which _is_ a lot stiffer than steel).
[20:31:19]<mhaberler> and it doesnt work if the filename is m110, not M110, right?
[20:32:07]<gmouer> didn't try the M110 with lower case, went by the example in the document and used upper case with no file extension and set to executable
[20:32:28]<Aero-Tec> so we should have carbide machines instead of cast iron ones?
[20:32:32]<mhaberler> right
[20:33:04]<andypugh> Aero-Tec: Possibly, in an ideal world. Though I am not sure how well damped they would be.
[20:33:39]<gmouer> mhaberler: comes down to confusion in the methods used for Mxx remaps and M1xx commands, different beasts which I now know
[20:34:01]<Aero-Tec> so back to my problem
[20:34:09]<mhaberler> sorry to see it bit you
[20:34:17]<Aero-Tec> there is nothing that can be done with my program stopping with each move?
[20:34:22]<andypugh> There is a "league table" of stiffness here: http://en.wikipedia.org/wiki/Young%27s_modulus[20:34:37]<toastyde1th> we don't really care about the machine stiffness per se, we care about the damping
[20:34:49]<andypugh> Beryllium looks marvellous, as it weighs nearly nothing too.
[20:34:53]<gmouer> mhaberler: I heal quickly lol, now to attach the toolchange setup on that ganglathe, thanks again
[20:35:09]<toastyde1th> as long as the machine flexes the same amount for each cut, the cut is repeatable and our process is deterministic
[20:35:25]<toastyde1th> vibration and chatter make it nondeterministic
[20:35:50]<Aero-Tec> how are the cement ones working out?
[20:35:54]<toastyde1th> which is why steel and carbide aren't used in cutting tool machine frames
[20:36:02]<andypugh> toastyde1th: Indeed, in the case of the machine frame you can just add metal. For boring bars and other space-constrained things like milling cutters then the fact that WC is twice as stiff as steel is big plus.
[20:36:04]<Aero-Tec> steel farms in cement
[20:36:24]<toastyde1th> cement/composite machine frames are in production at several very serious machine mfgs
[20:36:28]<toastyde1th> so i'd say they're working out great and damp better than cast iron
[20:36:39]<toastyde1th> andypugh, agree
[20:37:00]<Aero-Tec> steel frame
[20:37:00]<toastyde1th> the frame can still damp out any vibration coming down the carbide tool
[20:37:04]-!- gmouer has quit [][20:37:25]<andypugh> They built a huge triaxial compression testing machine where I used to work, out of reinforcd concrete. I wonder if I can find pictures ?
[20:37:43]<toastyde1th> also, Aero-Tec, you do not use steel anywhere in a machine tool if you can help it
[20:37:49]-!- sumpfralle [sumpfralle!~lars@c.mail.systemausfall.org] has joined #linuxcnc[20:37:49]<toastyde1th> forging machines, yes
[20:38:23]<toastyde1th> there are some notable ultraprecision exceptions of using steels, but they have other methods of compensation
[20:38:23]<Aero-Tec> so what do they use in the concrete ones?
[20:38:30]<Aero-Tec> they need a frame
[20:38:33]<toastyde1th> it's not "concrete" in the Quikcrete sense
[20:38:46]<toastyde1th> they cast a mold and it's an epoxy/aggrigate mix
[20:39:13]<toastyde1th> has more in common with carbon fiber and fiberglass than it does concrete
[20:39:16]<fragalot>http://www.ebay.com/itm/effective-8mm-Japan-Micro-CNC-Stepper-Motor-Screw-Linear-Guide-/181030190554?pt=LH_DefaultDomain_0&hash=item2a263d7dda[20:39:16]<fragalot> just what I always wanted!
[20:39:16]<fragalot> xD
[20:39:37]<Aero-Tec> they need machined ways and places to bolt things to and to bolt it together
[20:39:50]<toastyde1th> Aero-Tec, ever seen a surface table?
[20:39:53]<toastyde1th> they're granite
[20:40:14]-!- sumpfralle1 has quit [Ping timeout: 240 seconds][20:40:22]<toastyde1th> there's no problem making flat sections of a composite or putting bushings into it for threads, etc
[20:40:36]-!- sumpfralle1 [sumpfralle1!~lars@c.mail.systemausfall.org] has joined #linuxcnc[20:40:43]<andypugh> fragalot: Those are so cute, I have to have them!
[20:40:49]<Aero-Tec> ok, so how does that help with bolting things together?
[20:41:00]<toastyde1th> you just drill a hole into it, slather epoxy into it, and then jam a bushing into the hole
[20:41:04]<toastyde1th> just like you would any surface plate
[20:41:07]<fragalot> andypugh: :D
[20:41:38]<fragalot> any1 know of cheap DC motor with a high torque leadscrew drive? (I don't care about positioning, it just needs to move something heavy back & forth)
[20:41:39]<Aero-Tec> some how that seems like it would be a week spot
[20:41:46]<toastyde1th> it isn't
[20:41:50]-!- sumpfralle2 [sumpfralle2!~lars@31-16-116-72-dynip.superkabel.de] has joined #linuxcnc[20:41:59]<toastyde1th> and if they're that worried, they just use a long ass threaded rod
[20:42:02]<andypugh> £12, free postage? What the heck...
[20:42:21]<Aero-Tec> cool
[20:42:22]<toastyde1th> you have to remember it's not concrete and isn't brittle like concrete is
[20:42:33]<toastyde1th> the epoxy has some serious tensile strength to it
[20:42:34]-!- sumpfralle has quit [Ping timeout: 240 seconds][20:42:40]<Aero-Tec> so am I stuck with this stopping thing?
[20:42:49]-!- neverho01 has quit [Ping timeout: 244 seconds][20:42:51]<fragalot> currently considering a powered chute deflector screw motor
[20:43:41]<andypugh> Aero-Tec: The spring-maker?
[20:43:53]<Aero-Tec> yes
[20:44:24]-!- sumpfralle [sumpfralle!~lars@c.mail.systemausfall.org] has joined #linuxcnc[20:44:44]<Aero-Tec> would be a pain to have spent all this time and end up with what I started with
[20:44:46]-!- sumpfralle1 has quit [Ping timeout: 252 seconds][20:45:25]<Aero-Tec> it should just scream through the code, not stop like it does
[20:45:26]<andypugh> I am really puzzled by the problem.
[20:45:57]<Aero-Tec> was trying to do a plot to prove that it stops
[20:46:02]<andypugh> But I think that my suggestion of configuring the rotary to be the Y axis ought to circumvent the issue.
[20:46:46]<andypugh> (Whilst fully accepting that it _shouldn't_ stop)
[20:46:49]<Aero-Tec> cradek: said it did not stop for him when he did the virtual machine
[20:46:57]-!- sumpfralle2 has quit [Ping timeout: 260 seconds][20:47:32]<andypugh> After my gorceries are delivered I can try it on my real machine.
[20:47:58]<Aero-Tec> would like to just convert the B to linear if that would work
[20:48:23]<Aero-Tec> no reprogramming the HAL
[20:48:23]-!- schwinn434 has quit [Ping timeout: 265 seconds][20:48:23]-!- jd896_laptop [jd896_laptop!~chatzilla@host-89-242-142-204.as13285.net] has joined #linuxcnc[20:48:38]<Aero-Tec> would have to redo Y and B to move it to Y
[20:48:53]<andypugh> You will need to change the HAL, but it is just a case of changing axis.4. to axis.1 all the way through.
[20:49:14]-!- bradsimantel has quit [Quit: bradsimantel][20:49:32]<andypugh> (You can just copy the whole config folder to make so you don't mess up the working system)
[20:50:06]<Aero-Tec> would just give it a new config name
[20:50:35]<Aero-Tec> treat it as a whole new machine
[20:51:12]<andypugh> Exactly, yes, just make a copy of the folder as a new name, change the name of the INI file, et voila! (A stringed instrument)
[20:51:32]-!- zzolo has quit [Quit: zzolo][20:51:43]<skunkworks__> logger[psha],
[20:52:21]-!- Keknom [Keknom!~monkeky@c-76-125-214-194.hsd1.pa.comcast.net] has joined #linuxcnc[20:54:12]-!- sumpfralle has quit [Ping timeout: 255 seconds][20:54:26]-!- sumpfralle [sumpfralle!~lars@31-16-107-58-dynip.superkabel.de] has joined #linuxcnc[20:58:20]<skunkworks__> Aero-Tec, only paying partial attention... is the accelleration of you rotory axis really low?
[21:05:15]<Aero-Tec> no
[21:05:35]<Aero-Tec> 3000
[21:05:51]<toastyde1th> hey, question. what happens if the accel is too high?
[21:06:12]<Aero-Tec> I need to move it to 2000 if I have it going full speed
[21:06:17]<Aero-Tec> it shuts down
[21:06:34]-!- schwinn434 [schwinn434!~jameslacy@CPE-76-182-158-150.natwky.res.rr.com] has joined #linuxcnc[21:06:46]<Aero-Tec> been there done that
[21:06:46]<toastyde1th> from a position error?
[21:07:07]<Aero-Tec> looks like
[21:07:11]<Aero-Tec> not sure why it would
[21:07:22]<toastyde1th> makes sense
[21:07:27]<toastyde1th> if it's expecting to be somewhere and it isn't
[21:07:33]<toastyde1th> because the drive isn't keeping up
[21:07:34]<Aero-Tec> I must have some thing not right
[21:07:50]<Aero-Tec> mine is step and dir
[21:08:00]<Aero-Tec> so EMC does not have any feed back
[21:08:16]<Aero-Tec> yet if ACC is to high EMC will error out
[21:08:44]<Aero-Tec> now that I think about that, it makes no sense at all
[21:08:59]<toastyde1th> oh, if you don't have feedback i have no idea why that would happen
[21:09:12]<toastyde1th> this is what I get for never ever playing with actual machine parameters or setting up a control
[21:09:30]-!- Keknom has quit [Quit: Leaving.][21:09:55]<Aero-Tec> that's what got me scratchen my head now
[21:10:05]-!- PCW [PCW!~chatzilla@99.88.10.65] has joined #linuxcnc[21:10:38]<Aero-Tec> why would EMC shut down if the ACC is to high and there is no feed back to EMC?
[21:11:24]<Aero-Tec> the motor should just lock and make a hell of a racket and EMC should keep going like nothing is wrong
[21:11:46]<PCW> There is always feedback
[21:12:05]<Aero-Tec> with step and dir?
[21:12:05]<Aero-Tec> how?
[21:12:08]<PCW> yes
[21:12:32]<Aero-Tec> I wired it up, I know there is no feed back
[21:12:33]<andypugh> The stepgen reports back how many steps it managed
[21:12:48]<toastyde1th> that's pretty cool
[21:13:05]<PCW> yes the feedback loop is internal to the stepgen component
[21:13:50]<Aero-Tec> so why would it error out with acc being to high?
[21:14:02]<Aero-Tec> yet it can be high if speed is lower
[21:14:14]<PCW> so if the stepgen maxaccel or maxvel or sum of steplen and stepspace limit the step generation you will get a following error
[21:14:20]<Aero-Tec> if I lower the speed I can up the acc
[21:14:40]<Aero-Tec> cool
[21:15:58]<PCW> so if you dont have enough headroom (stepgen max-accel > machine maxaccel) you may get an error
[21:15:59]<andypugh> Actually, the stepgen can acccellerate arbitrarily fast. But can't manage an infinite step rate.
[21:16:03]<Aero-Tec> skunkworks__: do you think you can help me on this?
[21:16:44]<andypugh> You will, howvwever, get an error if you axis max_accel is higher than stepgen_max_accel (you will typically find both parameters in the INI file)
[21:16:59]-!- mhaberler_ [mhaberler_!~mhaberler@089144206193.atnat0015.highway.a1.net] has joined #linuxcnc[21:17:02]-!- jd896_laptop has quit [Ping timeout: 252 seconds][21:17:14]<Aero-Tec> I have a open G64 and have tried using G93 mode as well
[21:17:43]<Aero-Tec> on this axis I have them both the same
[21:17:44]<Aero-Tec> 3000
[21:18:34]-!- mhaberler has quit [Ping timeout: 255 seconds][21:18:34]mhaberler_ is now known as mhaberler[21:18:45]<Aero-Tec> I should up the stengen max
[21:18:59]-!- jd896_laptop [jd896_laptop!~chatzilla@host-89-242-142-204.as13285.net] has joined #linuxcnc[21:19:07]<PCW> yeah maybe 25% more for headroom
[21:20:06]<Aero-Tec> but that does not explain why it stops at each move
[21:21:02]<Aero-Tec> G61 and G64 seem to make no difference
[21:21:19]<Aero-Tec> I can recheck that theory
[21:21:47]<Aero-Tec> but I am sure it made no difference
[21:22:30]<Aero-Tec> will do some tweaking and get back to you guys
[21:26:24]-!- phantoneD [phantoneD!~destroy@a95-92-89-24.cpe.netcabo.pt] has joined #linuxcnc[21:26:25]-!- mhaberler has quit [Read error: Connection reset by peer][21:28:48]-!- mhaberler [mhaberler!~mhaberler@089144206193.atnat0015.highway.a1.net] has joined #linuxcnc[21:29:24]-!- phantoxeD has quit [Ping timeout: 248 seconds][21:29:41]<andypugh> Aero-Tec: F1000000 seems a very odd thing to see.
[21:30:05]<toastyde1th> he's trying to get the machine to go as fast as it can in inverse time
[21:30:22]<andypugh> Ah, OK.
[21:30:28]<skunkworks__> Aero-Tec, I am suprosed you have not gotten any folling errors with the two accellerations being the same
[21:30:31]<skunkworks__> suprised
[21:30:45]<skunkworks__> following
[21:31:04]<Aero-Tec> only when speed is high and acc is high
[21:31:19]<Aero-Tec> I can lower speed and it will not error
[21:31:54]-!- jd896_laptop has quit [Ping timeout: 240 seconds][21:33:33]<toastyde1th> have you done any accuracy tests from those accel numbers
[21:33:55]<toastyde1th> like, taking a gage block and an indicator and making sure it went the distance
[21:35:10]<PCW> Andy: freeby.mesanet.com/7i76x2_ss137.bit
[21:35:10]<PCW> 7i76x2 with V137 SSerial
[21:35:33]<andypugh> Thanks
[21:36:12]<PCW> well V 37 since I think the major version is ignored
[21:36:49]-!- acdha has quit [Quit: Leaving...][21:38:29]<Aero-Tec> I have for the other axis
[21:38:31]<Aero-Tec> not this one
[21:38:33]<Aero-Tec> ok
[21:38:43]<Aero-Tec> so I redid things
[21:38:50]<Aero-Tec> now have 3 versions
[21:38:59]<Aero-Tec> G94
[21:39:27]<Aero-Tec> oops
[21:39:34]<Aero-Tec> G64
[21:39:39]<Aero-Tec> G61
[21:39:48]<Aero-Tec> G61 and G93
[21:40:04]<Aero-Tec> I would say they all run the same speed
[21:40:47]<Aero-Tec> oops
[21:40:57]<Aero-Tec> dyslexic
[21:40:57]<Aero-Tec> G61
[21:41:03]<Aero-Tec> G64
[21:41:15]<Aero-Tec> G64 and G93
[21:41:27]<Aero-Tec> G61 seemed faster
[21:42:10]<Aero-Tec> G64 ramped down the speed and then ramped up at a much slower rate then G61 did
[21:42:26]<Aero-Tec> so it seemed and maybe way slower over all
[21:42:32]<Aero-Tec> was
[21:43:48]-!- cspanring has quit [Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121128204232]][21:44:16]<Aero-Tec> the acc is now 3000 and step gen acc is 5000
[21:44:30]<Aero-Tec> have not done any full speed testing yet
[21:46:33]<Aero-Tec> with the G64 it is just G64, nothing after it so it should be flat out fast
[21:47:46]<Aero-Tec> do you think I found a bug in the system?
[21:48:24]<skunkworks__> not exactly... G64 will go as fast as it can while still touching every segment.. Px.xxx will combine segments that fall withing x.xxx so to keep the speed up...
[21:48:26]<Aero-Tec> would love for it to be something I am doing wrong
[21:49:22]<skunkworks__> so in effect the 'segments' are longer
[21:49:40]<Aero-Tec> so what axis is P referring to?
[21:50:01]<PCW> all
[21:50:11]<Aero-Tec> X-.01 B500
[21:50:26]<Aero-Tec> well 0.15 in X is large
[21:50:46]<Aero-Tec> 0.15 in B is so tiny it would not count
[21:51:19]<skunkworks__> that is above my pay grade :)
[21:51:20]<Aero-Tec> lol
[21:51:38]<Aero-Tec> so should I do P450?
[21:52:21]<Aero-Tec> when I read the G64 info it said something about unlimited P
[21:52:22]<PCW> did you try G64 P 0.010 or some such?
[21:52:28]<JT-Shop> skunkworks__: does G64 Pn work with rotary axes?
[21:52:47]<skunkworks__> It really comes down to - the faster the acelleration - the faster the blend..
[21:52:47]<JT-Shop> I thought it was just for XYZ axes
[21:52:51]<Aero-Tec> just a plain G64 I thought opened things to as fast as possible
[21:52:59]<andypugh> It is interesting to speculate what the units of P would be with a rotary axis.
[21:53:08]<Aero-Tec> I did try it
[21:53:16]<Aero-Tec> p0.015
[21:53:21]<Aero-Tec> P0.15
[21:53:31]<Aero-Tec> can try P450
[21:54:10]<skunkworks__> I think chris made a comment that blending between linear-> rotory isn't the best - but still works
[21:55:18]<skunkworks__> <cradek> I think "corners" in XB (etc) are not as well blended as corners in XY, YZ, ZX, AB, BC, CA
[21:56:11]<skunkworks__> He is the one that would know as he re-wrote most of it. I works 100 times better than it did before
[21:56:33]<Aero-Tec> so any hints as to how to speed up the code?
[21:56:50]<Aero-Tec> seeing as the way I was trying seems not to work
[21:57:09]<Aero-Tec> the code work, just the speed seems like it could be better
[21:57:15]<cradek> you can not fix the blending by changing the gcode
[21:57:48]<cradek> the XB blend certainly is incorrect
[21:58:27]<cradek>http://timeguy.com/cradek-files/emc/xb-misblend.png[21:59:26]<Aero-Tec> P450 made no change
[21:59:57]<Aero-Tec> hello cradek
[21:59:59]<cradek> like I said at least once earlier, tolerance mode does not affect this blend
[22:00:12]<Aero-Tec> I did try to do one of them and I could not get it right
[22:00:26]<cradek> one of what?
[22:00:42]<Aero-Tec> cool hal charts
[22:01:22]<Aero-Tec> so to make this work
[22:01:35]<Aero-Tec> would making B linear help at all?
[22:01:41]<cradek> no
[22:02:04]<Aero-Tec> or do I have to rewire the axis so it is XY?
[22:02:06]<cradek> yes using X and Y would almost certainly work
[22:02:59]<Aero-Tec> would making Z and B the exact same work?
[22:03:04]<cradek> no
[22:03:07]<Aero-Tec> using the same pins and such
[22:03:21]<cradek> wait, I don't even understand your question
[22:03:44]<Aero-Tec> was hoping the motor would work as B axis and Z axis
[22:03:58]<Aero-Tec> so if I do a Z move it works
[22:04:06]<Aero-Tec> and if I do a B move it works
[22:04:12]<Aero-Tec> same motor
[22:04:14]-!- mevon__ has quit [Ping timeout: 259 seconds][22:04:16]<Aero-Tec> 2 axis
[22:04:26]<Aero-Tec> I have no Z right now
[22:04:48]<Aero-Tec> so I cold redo it to drive the motor on B
[22:04:54]<Aero-Tec> could
[22:05:23]<Aero-Tec> would save undoing B in HAL
[22:05:45]<Aero-Tec> hope I am not being a pain here
[22:05:51]<Aero-Tec> not trying to be
[22:06:05]<Aero-Tec> just had the thought
[22:06:42]-!- sumpfralle has quit [Ping timeout: 264 seconds][22:07:10]<Aero-Tec> is that too outside the box?
[22:07:27]<DJ9DJ> gn8
[22:08:24]-!- DJ9DJ has quit [Quit: bye][22:10:16]-!- JT-Shop has quit [Read error: Connection timed out][22:10:33]-!- FinboySlick has quit [Quit: Leaving.][22:11:26]-!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc[22:14:09]<andypugh> Aero-Tec: I just ran your code, and I think I might understand it.
[22:14:35]-!- motioncontrol has quit [Quit: Sto andando via][22:14:53]<andypugh> I think it is related to the X acceleration. And is a feature, not a bug.
[22:15:32]<cradek> explain?
[22:15:43]<cradek> (looks like a bug to me but maybe I'm missing something)
[22:16:01]-!- mevon__ [mevon__!~mevon@modemcable015.35-130-66.mc.videotron.ca] has joined #linuxcnc[22:16:17]<andypugh> The thing is that each move has a fixed ratio of B to X movement. when the speed of X changes the B first has to slow to that ratio for the current X speed, then they both accelerate together in lock-step
[22:17:28]<Aero-Tec> X speed should not be changing
[22:17:44]<andypugh> (And, with low acceleration and fixed tolerance, they both may need to stop before they can restart)
[22:17:45]<cradek> G1 X-0.01 B60
[22:17:45]<cradek> G1 X-.01 B100
[22:17:57]<Aero-Tec> in fact nether should B
[22:17:57]<cradek> I'm concentrating on the blend between these two moves
[22:18:28]<andypugh> Well, those should be B-only moves, so ought to blend seamlessly
[22:18:33]<cradek> andypugh is right that X or B positively must change speed during this transition, since the ratios differ
[22:18:42]<cradek> sorry, this is still G91
[22:18:48]<andypugh> Ah, OK.
[22:20:14]<Aero-Tec> would not G93 nullify that?
[22:21:25]<Aero-Tec> the acc is not so low BTW
[22:22:16]<Aero-Tec> when doing a G61 version it starts and stops fast, real fast
[22:22:28]<Aero-Tec> that is why G61 seams faster
[22:23:10]<Aero-Tec> it is flat out till it is hitting the end and stops, then is back moving again real quick
[22:23:30]<Aero-Tec> G64 ramps down slow and ramps up slow
[22:24:02]<Aero-Tec> even with G93 it still is slow starting and stopping
[22:24:31]<Aero-Tec> I could do a vid of it working so you can see for your self
[22:25:23]-!- syyl has quit [Quit: Leaving][22:25:23]<Aero-Tec> run all 3 versions and you can see how fast G61 is and how slow G64 is
[22:26:08]<Aero-Tec> or with some coaching run the HAL scope
[22:26:41]<JT-Shop> do you have the cycle timer?
[22:26:44]<Aero-Tec> I was close, had it all setup, just could not get it to trigger right
[22:27:19]<Aero-Tec> seeing as I have no idea what it is, I would say no
[22:27:38]<Aero-Tec> I know what it could be
[22:27:40]<JT-Shop> it tells you the time for each run of a program
[22:27:50]<Aero-Tec> I have a stop watch
[22:27:55]<JT-Shop>http://linuxcnc.org/docs/devel/html/man/man9/time.9.html[22:28:36]<JT-Shop> I like using time as I can never start and stop the stop watch all that well when I can find it
[22:28:45]<Aero-Tec> very cool
[22:29:24]<Aero-Tec> I can install it
[22:30:00]<Aero-Tec> I keep finding all sorts of cool things to add to EMC
[22:30:38]<Aero-Tec> seeing as it is in a sub loop
[22:31:03]<Aero-Tec> I am guessing it would not time a loop
[22:31:33]<Aero-Tec> would have to make the loop 1 time
[22:32:16]-!- skunkworks__ has quit [Read error: Connection reset by peer][22:35:27]-!- gmouer [gmouer!~gmouer@cpe-74-65-14-255.rochester.res.rr.com] has joined #linuxcnc[22:37:00]<Aero-Tec> I believe I can do the HAL part, but the Python part I am not sure what to do with that or even where to start with it
[22:37:15]<gmouer> a couple months ago there was talk about the fanuc style toolchanges for lathe patch being added to master, where can I check if this was ever done? I would love that patch but hate the idea of having to use git and compile a new copy of linuxcnc.
[22:38:16]<andypugh> It wasn't done.
[22:38:48]<gmouer> thanks Andy, any hope of it happening yet?
[22:39:28]<JT-Shop> there is a patch out there somewhere but it still has problems
[22:39:54]<gmouer> yes john, that is the patch I am speaking of, didn't read about any real problems though
[22:40:05]<andypugh> Not least being that it's a bit of a strange thing to do, to have such very different ways of handing loolchange.
[22:40:33]<JT-Shop> when you edit the tool table it adds a zillion lines with ; in each line IIRC
[22:41:18]<gmouer> ah yes John, I seen that but it was only if you edited with the tooltable editor I thought
[22:41:35]<JT-Shop> I think that is correct
[22:41:38]<gmouer> isn't there some issues with the tooltable editor beyond that anyways?
[22:41:51]<JT-Shop> not that I know of
[22:42:22]<gmouer> I am kicking around how I want to set up toolchanges etc on this gangtool lathe
[22:42:31]-!- yuvipanda has quit [Quit: yuvipanda][22:42:33]<gmouer> do you use wear offsets John?
[22:43:27]<andypugh> Aero-Tec: Do you feel interested in an experiment that probably won't help, but will satisfy my curiosity? You could try recalibrating B to work in revolutions (rather than degrees). (just multiply the scale by 360, and alter the G-code to suit). I am curious about the effect of relative magnitudes.
[22:44:06]<andypugh> The whole tool-handling thing is up for review anyway.
[22:44:59]<Aero-Tec> sure
[22:45:04]<Aero-Tec> sounds like fun
[22:45:29]<Aero-Tec> I can not see it working like you said
[22:45:44]<gmouer> I seen that mentioned too Andy, but I have a lathe retrofit finished and have to decide how I want to handle toolchanges/wear offsets and such for now until things get reworked
[22:46:38]<Aero-Tec> what theory are you using to think it may make a difference?
[22:46:39]<gmouer> that fanuc patch looked great, its different than the normal linuxcnc method but fanuc methods are pretty proven in the field
[22:47:00]<gmouer> Peter Schmid references fanuc methods a lot in his book
[22:47:14]<Aero-Tec> are you thinking that if the numbers are closer in range it may make a difference?
[22:47:46]<gmouer> right now, there are no provisions for wear offsets in the standard code, right?
[22:48:30]<andypugh> Aero-Tec: Yes.
[22:48:48]<andypugh> gmouer: Not separate from the geometry offsets, no.
[22:49:15]<Aero-Tec> will try it and get back to you
[22:49:25]<Aero-Tec> will you be around for awhile?
[22:49:34]<andypugh> Aye
[22:49:40]<icee> there's no way in g code to set a 'radius' for rotary moves is there? so you have to calculate ridiculously strange feedrates for combined inch-and-degree-moves
[22:49:54]-!- mevon__ has quit [Ping timeout: 264 seconds][22:49:58]<gmouer> ok, thanks Andy and John
[22:49:59]<Aero-Tec> did not hear back on the old setting up 2 axis on 1 motor
[22:50:57]<andypugh> icee: pretty much, yes. If you can think of a _definition_ for radius in such a move then perhaps that could change.
[22:51:42]<andypugh> Aero-Tec: My machine running your code: http://www.youtube.com/watch?v=DQlGAGt_zcM (not processed yet)
[22:52:19]<icee> I have used this before
[22:52:21]<icee>http://www.cncsnw.com/4thFeed.png[22:52:28]-!- gmouer has quit [][22:52:37]<icee> dX is really "linear distance"
[22:53:15]<andypugh> Do I risk axially-loading some 6909 bearings, or should I use a needle roller and two ball thrust bearings?
[22:53:37]<JT-Shop> how long do you need them to run?
[22:54:12]<andypugh> icee: But linear distance depends on the system knowing where the axes of rotation are. A CAM package can know that, but a G-code interpreter doesnt.
[22:54:30]<andypugh> JT-Shop: They are for my ballnut mount (rotating nut)
[22:54:46]-!- FinboySlick [FinboySlick!~shark@squal.net] has joined #linuxcnc[22:55:01]<icee> andypugh: i'm just saying, it'd be nice for me to be able to say "Hey, now after that Z move I am 2" over the center of the rotary table"
[22:55:14]<icee> and then feedrates remain in linear units
[22:55:36]<JT-Shop> I'd use angular contact ball bearings at the least
[22:55:45]<icee> a fancier definition would be
[22:55:57]<icee> "FYI the coordinates for the center of rotation are ____"
[22:55:57]<andypugh> JT-Shop: So would I, if they would fit.
[22:56:06]<JT-Shop> I see
[22:56:07]<icee> i know with multiple angular axes this starts to break down
[22:56:24]<andypugh> icee: STEP_NC might allow that, G-code is not so clever.
[22:57:08]<icee> it seems like an extension g code for "be advised: tool is ____ inches from the center of rotation"
[22:57:11]<andypugh> JT-Shop: If you can find angular contacr bearings about 2" ID and about 2.5" OD then I would use them.
[22:57:13]<icee> would be nice
[22:57:26]<andypugh> Extending G-code is hard. It's full.
[22:57:44]<JT-Shop> wow that is only a 1/4" thick
[22:58:27]<andypugh> (Well, every letter has a use, I guess there are plenty of spare G and M codes). Coordinate system axis definition could be a special gase of G10 for example.
[22:58:28]<JT-Shop> do you have room to fit a thrust bearing in there as well as the 6909's?
[22:59:03]<andypugh> I would need two thrust bearings, and at that point a needle roller looks good.
[23:04:36]<icee> what's "G07 feedrate sine curve control"?
[23:04:41]-!- bradsimantel has quit [Quit: bradsimantel][23:05:09]<andypugh> Sounds like witchcraft to me :-)
[23:05:23]<icee> sounds like it could be what we're talking about
[23:06:24]-!- Wildhoney has quit [Ping timeout: 276 seconds][23:07:34]-!- schwinn434 has quit [][23:07:44]<icee> nope
[23:08:32]<icee> i believe it lets you do a circular interpolation while not moving one of the involved axes
[23:08:40]<icee> e.g. sine wave speed of movement
[23:08:48]<icee> wonky
[23:10:47]<andypugh> I don't think we have it in LinuxCNC
[23:14:22]<JT-Shop> sure we have G7
[23:16:23]<icee> anyways, pretty pretty please to all developers-- saner feedrates for angular+linear moves would be nice <3
[23:16:34]<andypugh> As diameter mode, not "feedrate sine curve control"
[23:17:26]-!- bedah has quit [Quit: bye][23:17:30]<andypugh> icee: Seroiusly, if you can define "sane" then it might happen. But I don't think it can be done in the context of what the G-code interpreter knows. It has to be a CAM thing.
[23:18:06]<icee> so, saying "angle for axis a becomes a feedrate as if scaled by this radius" isn't sane?
[23:19:33]<icee> i mean, a lot of the time i could just pick a worst case/outer radius and be happy and leave it at that
[23:22:44]<icee> so if you say the radius == 2 inches, eag degree is .034 inches, so if you do a single rotary axis move of 20IPM you're really saying 573 degrees/min
[23:25:27]<tjb1> JT-Shop: dinner is ready honey.
[23:27:39]<andypugh> The problem is, what is the radius?
[23:28:17]<icee> the radius is something you specify in a g code before the block.. "feedrate adjustment radius for axis A == ___"
[23:28:36]<icee> then if i know my part is 2inches in diam max, i always have a sane feedrate
[23:28:38]<JT-Shop> LOL
[23:29:04]<cpresser> icee: ecm2-gcode can do math. implement it yourself :)
[23:29:49]<andypugh> There is that, there are trig functions.
[23:30:05]<icee> it is just a very annoying expression for multiaxis linear+rotary moves
[23:30:36]<andypugh> I do know where you are comng from, and it is something I have thought about a bit.
[23:30:54]<icee> which, you know, doing it this way, the "dumb way"
[23:31:05]-!- jpk has quit [Ping timeout: 255 seconds][23:31:07]<icee> you'd get slightly wrong feedrates as you machine down the part
[23:31:17]<andypugh> G-code is very, very dumb.
[23:31:26]<icee> (or have to keep adding this "hey, now pretend like the axis radius is 1.5 inches!"
[23:33:07]<andypugh> G3 X100 A 180 I 20 J 30 L30 M40?
[23:33:26]<andypugh> Ah, no, we can't use M, can we?
[23:34:44]<icee> I'm thinking like. G666 A0 R2.0 G1 X3 A180 F10
[23:35:49]-!- JT-Shop-2 [JT-Shop-2!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc[23:35:49]<icee> moves X 3 inches and rotates the table 180 degrees (assuming starting position of 0) at 10 inches per minute...
[23:35:50]-!- JT-Shop has quit [Read error: Connection reset by peer][23:35:50]-!- jthornton has quit [Read error: Connection reset by peer][23:35:54]-!- jthornton_ [jthornton_!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc[23:36:37]<andypugh> At the moment the feed rate is such that the X move is at 10 units/min and the A move finishes at the same time.
[23:38:08]<icee> my total movement across the surface is sqrt((3 inches)^2 + (pi * 2 inches)^2)
[23:39:32]<cradek> since you know that (before you write the gcode) you can calculate the right feed and use inverse time mode
[23:39:41]<cradek> think of gcode as the low level language you generate
[23:40:00]<icee> sure, that's what i've been doing
[23:40:23]<icee> it's been 6 months since i've done this, but i'm about to acively start doing it again
[23:40:35]<icee> F is only for the linear axes on emc2 though in combined moves?
[23:40:43]<icee> because i remember doing "pythagorean between degrees and inches"
[23:40:59]<icee> but i don't remember what controller that was targeting
[23:41:23]<cradek> icee: read about inverse time mode in the manual
[23:41:37]<cradek> icee: heck also read about feed rate, is very carefully described
[23:42:22]<icee> i see
[23:42:28]<icee> well, that's a lot better than the other stuff i was doing
[23:42:53]<cradek>http://linuxcnc.org/docs/html/gcode/machining_center.html#sub:feed-rate[23:43:00]<icee> yes
[23:43:01]<icee> jsut read that
[23:43:10]JT-Shop-2 is now known as JT-Shop[23:43:28]<icee> ok, cradek. i wrongly blamed emc2 for: http://www.cncsnw.com/4thFeed.png[23:43:55]<cradek> uh I have no idea what that means
[23:44:16]<tjb1> JT-Shop: Honey, are you coming in for dinner?
[23:44:26]<JT-Shop> too early
[23:44:28]<icee> cradek: some controllers, F on combined angle+linear moves.. treats the units like they are identical.. e.g. a move of 1 degree and 1 inch would be of length 1.414
[23:45:22]<cradek> in g94 you're doomed no matter what you do, because what is the unit?? the only sane thing to do is use g93 which requires you specify only time
[23:45:45]<cradek> in g94 you have to do something and you better damn well document it because it's going to bite someone no matter what
[23:46:53]<toastyde1th> programming in g94 by hand is for the brave and foolish
[23:47:06]<andypugh>http://www.youtube.com/watch?v=DQlGAGt_zcM (13 and 31 seconds)
[23:48:21]<toastyde1th> nice
[23:48:46]<andypugh> So I see a glitch, but it doesn't seem to be a full stop.
[23:49:32]<toastyde1th>http://www.youtube.com/watch?v=7ZuBZPop2NU[23:49:35]<toastyde1th> related
[23:50:40]-!- alpha1125 has quit [Quit: Computer has gone to sleep.][23:51:20]<andypugh> toastyde1th: LinuxCNC can do that.. http://www.youtube.com/watch?v=T4q8gCpeY1A[23:52:16]<andypugh> How wierd, someone stole my video? http://www.youtube.com/watch?v=vGgow60KKXM[23:52:37]-!- jeffreyd00 has quit [Quit: Page closed][23:52:44]<toastyde1th> how accurate is that c axis
[23:52:47]<toastyde1th> just curious
[23:53:03]<toastyde1th> could you live tool it?
[23:55:00]<JT-Shop> andypugh: that bearing is for your lathe ball nut?
[23:55:14]<andypugh> Mill ball-nut
[23:55:27]<JT-Shop> doing a refit on it?
[23:55:49]<adb> andypugh, vietnamien stole
[23:56:12]<andypugh> JT-Shop: Yes. Have been for 2 years..
[23:56:38]<JT-Shop> I know how that is... I've been working on my plasma table going on 5 years now
[23:58:00]<andypugh> I am just not in a major rush.
[23:58:52]<toastyde1th>http://www.youtube.com/watch?v=vyT8UTkCc4k[23:58:59]<toastyde1th> i got hit by a chip at that temp once
[23:59:04]<toastyde1th> it was unpleasant
[23:59:04]<JT-Shop> are you converting it from a manual to a CNC mill?