Back
[00:09:12] <skunkworks> is the livecd for lucid still the same one? (missing the emc repository?)
[00:09:42] <skunkworks> (s)
[00:23:38] <skunkworks> very very rough - but seems to be working in sim. Still have some interlocking to smooth out and also need to add the spindle lock code. pretty short.
http://www.pastebin.ca/1915435
[00:25:53] <skunkworks> and everything else I have not thought of.
[00:26:50] <skunkworks> I pretty much made everything pins so I could test what is happening easier (for me)
[00:26:52] <skunkworks> :)
[00:43:52] <jthornton> I wish I understood why tool orientation has such an effect on path with cutter comp on
http://imagebin.ca/view/UhqDY72.html
[00:45:41] <jthornton> http://pastebin.ca/1915445
[01:07:24] <KimK> jthornton: You didn't post your tool table, what's the (numerical) tool orientation?
[01:08:12] <KimK> Or is it shown there and I don't see it?
[01:09:40] <skunkworks> kimk!
[01:12:45] <KimK> Hey Sam, how are you? Or should I say, hope you're feeling better? Congrats on Dad moving the axes first time with a battery charger, cool!
[01:18:41] <KimK> Oops, got to go get parts before they close, back in a while
[01:19:50] <skunkworks> heh
[01:33:55] <skunkworks> leave it to dad to see a problem. what happens when the spindle speed override is moved. ;) the way it works now is as the spindle speed is decreased though the gear threshold - it shifts ;) oops. so it looks like I have access to the spindle override pin though halui. I think I can use that to see if the spindle speed is being adjusted by that or by gcode. Then if it is adjusted by...
[01:33:57] <skunkworks> ...the override - don't shift. just let the spindle motor (vfd) change the rpm/
[01:35:04] <skunkworks> and when shifting - if the spindle override is lower - still pick the gear that is the right range for 100% override.
[01:44:20] <KimK> jthornton: And the diagrams (several) in lathe chapter 1.7 don't help?
http://www.linuxcnc.org/docview/html//lathe_lathe-user.html#r1_7
[01:45:10] <KimK> skunkworks: You're not using m-codes for gear selection?
[01:46:05] <skunkworks> yes - but the comp picks the correct gear/spindle motor speed for the cutting rpm selected
[01:47:29] <KimK> How can it know? Or do you have zero overlap in your available speed ranges?
[01:47:55] <KimK> Or is it biased toward low gear?
[01:48:00] <cradek> skunkworks: sometimes I'll pause a program (when the tool is in the air) and then turn spindle override down to zero to stop the spindle while I do something, then backup to 100%, then resume
[01:49:59] <skunkworks> so - if you say are running the spindle at say 3000rpm - the spindle motor is running at 3900rpm and the gearbox is in gear 16. NOw if I slide the override to 50 % - as it is now - the gear comp will now put the spindle into creep and shift into the correct gear for 50% OF whatever rpm was selected.
[01:51:01] <skunkworks> so - I think what I want is - if the override is used - don't shift. (only shift if the gcode commands it) (Can I know that) hmmmm...
[01:51:06] <cradek> spindle changing to creep while you're cutting seems pretty nonideal :-)
[01:51:13] <skunkworks> yes :)
[01:51:36] <KimK> cradek: Is your spindle a DC drive? Congrats BTW on your preliminary test of the "encoder-only" (no-tach) method. Any more news on that?
[01:52:42] <cradek> KimK:
http://timeguy.com/cradek-files/emc/spindle-motor.jpg
[01:52:55] <cradek> no new news - the latest news is still that it works perfectly great
[01:53:17] <cradek> I hope to measure the lag (with a real scope) but not tonight
[01:53:20] <skunkworks> I think I can know that base on what the override is set to and what the commanded speed is. if the change in commanded spindle speed doesn't follow the ratio of the spindle override - it was a commanded speed change from gcode. (does that make sense?)
[01:53:50] <cradek> oh so like commanded / override = gear selection?
[01:54:15] <skunkworks> something like that. seems doable (until I actually try...) ;)
[01:54:35] <KimK> skunkworks: Oh, I dunno, I think I prefer having the operator pick a gear and having the machine stick with that. I guess I'm old school?
[01:54:59] <cradek> that's how I like my lathe - but with 16 gears instead of 2 I'm not so sure anymore
[01:55:30] <skunkworks> heh - I can have hal pick the gear pretty easilly without thinking :)
[01:56:12] <cradek> if you hope to tap with it, you'll have a second problem
[01:56:16] <skunkworks> that is working pretty well.
[01:56:22] <skunkworks> ?
[01:56:39] <cradek> because the command changes without the override changing, and you sure don't want to switch gears for it
[01:56:51] <skunkworks> oh.
[01:56:54] <cradek> well I guess command goes from +500 to -500 and back to +500 so maybe you're fine - forget it
[01:57:24] <KimK> As long as there's a delay on "re-thinking"
[01:57:59] <skunkworks> well - yah - I think that might be workable.
[01:58:23] <KimK> Ooh, we're changing to 490... Wait, we're changing to 480... Wait, we're changing to 470...
[01:59:20] <skunkworks> I maybe need a way to ' lock ' it into a gear when needed.
[02:00:45] <skunkworks> I could have a 'don't shift' pin that when enabled doesn't shift the transmission.
[02:00:57] <skunkworks> oh this is fun :)
[02:01:58] <skunkworks> or - it only shifts from a stop.
[02:02:10] <KimK> On John's BP2 I treated his (hand-cranked) vari-drive as a five-step pulley, and he has a two-speed gearbox. So I reserved M40 and M50 for neutrals (just in case), and went low range: M41-M45 and hi range: M51-M55. Ten speeds ("gears").
[02:03:50] <KimK> You could do M41-M47 and M51-M57 if they're evenly split by a hi-lo gear. Or just start with granny at M41 and go up as they go. Either way.
[02:04:23] <skunkworks> kimk: This seems to be working.
http://www.pastebin.ca/1915435
[02:05:00] <skunkworks> when it shifts into the correct gear - what ever s word is given. automagically
[02:05:15] <skunkworks> it shifts into the correct gear - what ever s word is given. automagically
[02:05:43] <skunkworks> granted - we probably don't need all the gears - but hell - they are there....
[02:06:12] <cradek> I like the idea of only shifting once as the spindle comes on
[02:06:32] <skunkworks> cradek: that solves a lot of these problems. doesn't it ;)
[02:07:02] <skunkworks> I think I might think very hard about that solution.
[02:07:04] <cradek> yes - including letting spindle-at-speed work to keep emc from moving until the whole thing is ready
[02:07:43] <cradek> usually the only times you need to change speeds/gears on a mill is when changing tools. you have to stop the spindle to change tools.
[02:08:33] <skunkworks> I think I am conviced.
[02:08:51] <skunkworks> that shouldn't be that much of a change
[02:09:01] <KimK> Convinced of what though?
[02:09:26] <skunkworks> only shifting gears at spindle on. Not while the spindle is running.
[02:10:18] <skunkworks> after the spindle is running - if the s-word is changed - or the override is used - only the vfd changes
[02:10:30] <cradek> just be sure SO to zero doesn't trigger it (I think you can tell the difference with that smattering of hal outputs...?)
[02:10:43] <skunkworks> I will see.
[02:10:57] <skunkworks> I was thinking about that in the back of my mind.
[02:16:16] <KimK> Ha, yes, only shifting while off would be good. There's a big lathe here (1937) just sitting around because one of the operators (2 years ago?) tried to do a shift as it coasted to a stop and broke one of the shift levers(?) in the transmission. There's a big 6" or 8" cylinder of 4120 or something sitting there to make a new shift lever(?), but it remains on the to-do list, lol.
[02:16:23] <skunkworks> hmm - s0 turns the motion.spindle-on to false. darn
[02:16:36] <skunkworks> so does running the spindle override to 0
[02:16:42] <skunkworks> might have to think abou that
[02:16:49] <cradek> that's irritating
[02:17:29] <cradek> wonder who/what relies on that behavior
[02:18:05] <skunkworks> well - override probably wouldn't be a problem. I could test to see if the override is zero and do something. and rigid tapping goes from some speed to - some speed - right?
[02:18:08] <cradek> fixing/changing it would save us a hundred "I programmed M3 and my spindle didn't come on" questions over the next decade too
[02:18:31] <KimK> You could set your minimum spindle override to 1% or something, and use a halui spindle cw/ccw/off/auto switch?
[02:18:53] <cradek> yeah, or fix the stupid in emc
[02:18:57] <skunkworks> heh
[02:19:22] <skunkworks> It is getting late - and I am wondering if emc does need fixing. (or if it is me) ;)
[02:20:01] <cradek> in other news, carburetors don't work very well when there's a massive vacuum leak right under them
[02:20:03] <KimK> Ha, OK, goodnight Sam, don't want to wear you out on one of your first nights back
[02:20:19] <skunkworks> heh
[02:20:38] <skunkworks> cradek: yeck. did the seal shrink?
[02:20:39] <cradek> skunkworks: I'd love it if someone would figure out who/what it would break if that was fixed, and then fix it
[02:21:22] <cradek> skunkworks: just hoses crumbling and falling off/apart
[02:21:40] <cradek> now I bet the cruise control works too :-)
[02:22:52] <KimK> Or just fix EMC and wait for the break reports, lol? It's the "Jesuit Method": "It is always better to ask forgiveness then to ask permission."
[02:23:20] <cradek> that's fairly true if sam'd be using master anyway
[02:25:08] <skunkworks> so - if I get what you are saying - the motion.spindle-on would stay true even if the S was commanded to 0 'If' the spinde was still 'on' (m3,m4)
[02:25:34] <cradek> yes
[02:25:54] <cradek> so 'spindle on at zero speed' becomes a valid possible state, when it wasn't before
[02:26:05] <skunkworks> right.
[02:26:18] <cradek> not sure.
[02:26:31] <cradek> actually I like that it turns off when I turn it down to 0%...
[02:26:38] <skunkworks> The spindle overrride doesn't seem to have the problem of restarting the spindle - but - motion.spindle-on does go false.
[02:27:09] <skunkworks> I think I should just play with it and see if I can hack around it for now.
[02:27:55] <KimK> On at S0 (or hal tool change trickery) sounds like a very good idea, some spindles have to hold orientation for tool changes, and they don't have a shotpin or anything, they just hold position, servo-style.
[02:28:32] <skunkworks> or we need another pin :)
[02:29:05] <skunkworks> motion.spindle-active ;)
[02:29:11] <cradek> motion.spindle-on, motion.spindle-on-and-commanded-speed-is-nonzero
[02:29:35] <skunkworks> now that is just goofy. ;)
[02:37:58] <skunkworks> huh - there really doesn't seem to be any way to tell that the spindle had been commanded on when s0 is hit
[02:41:28] <skunkworks> huh - when the spindle override goes to 0% the motion.spindle-brake stays false. I can use that. I think that rigid tapping shouldn't be an issue - because it isn't commanding a S0 right? It goes from 100rpm to -100rpm. right?
[02:41:41] <cradek> yes
[02:41:54] <skunkworks> but when S0 is commanded the brake does go true. (thought I had it there for a second)
[02:42:14] <cradek> dangit you're gonna make me look at the source
[02:42:18] <skunkworks> I think I can work with that.
[02:43:24] <skunkworks> I think that might be a bug... (s0 does make the spindle brake turn on - but 0% override doesn't) But I am not going to complain ;)
[02:44:28] <cradek> oh I forgot about this swirly mess
[02:44:41] <skunkworks> heh - don't look directly at the code!
[02:44:51] <cradek> it kind of needs a rethink
[02:45:09] <cradek> the nml messages and the g codes don't really line up 1:1
[02:45:38] <cradek> for instance there's no "set the speed" message
[02:45:47] <cradek> only "turn on and set the speed"
[02:46:07] <cradek> so S100 M5 is an unrepresentable state too
[02:47:24] <skunkworks> I don't know if that is a problem though (I had already dealt with that)
[02:47:40] <skunkworks> I don't know the spindle speed until the spindle is on. Not really an isssue
[02:48:01] <cradek> yeah, but it's just bad design deep down, and it shows (has caused plenty of bugs too)
[02:48:11] <skunkworks> heh
[02:48:15] <cradek> so it needs a nontrivial fix (unfortunately)
[02:50:43] <cradek> skunkworks:
http://sourceforge.net/tracker/?func=detail&aid=2891275&group_id=6744&atid=106744
[02:53:34] <skunkworks> not a problem. Like I say - I think I can work around it. :)
[02:54:52] <skunkworks> wow - a lot to think about. :)
[02:55:51] <skunkworks> I think I have a really good direction to go.
[02:56:47] <cradek> :-)
[02:57:00] <KimK> I wondered about that the other night, for those non-trivial fixes (years to fix?) how would git have a branch that's ahead of master? Maybe (in our case) a 3.0 version or something, much further off in the future? Wouldn't that have to be a static branch, because the latest fixes from master (2.5, 2.6, etc.) might no longer be appropriate? So you'd have to, what, cherry-pick any fixes you wanted? (All fixes, really?)
[02:57:56] <cradek> a branch for a big new feature works great. we do this all the time. whenever you're ready to incorporate that feature into a branch that's going to be released, you just merge it.
[02:58:42] <cradek> or when it's done, you can just merge into master
[02:58:51] <KimK> What would you name such a branch? Or what have you named some in the past?
[02:59:00] <cradek> looking
[02:59:12] <skunkworks> there is a jointaxis branch or something like that.
[02:59:32] <cradek> locking-rotary, separate-g92, defor-format, ss-wrapped-rotary, random_toolchange
[02:59:40] <cradek> er defer-format
[02:59:49] <cradek> scroll down to the bottom here:
http://git.linuxcnc.org/gitweb?p=emc2.git;a=summary
[02:59:56] <cradek> most of those are feature branches
[03:00:14] <KimK> OK, excellent. Glad to know this feature is available. Thanks.
[03:00:57] <cradek> many of those are merged into master already, like separate-g92, ss-wrapped-rotary, locking-rotary; others are not yet (or might never be) merged
[03:01:08] <skunkworks> The S0 issue I think is a non issue. As if I command a S0 for some reason - I know I have to command the spindle back on.
[03:02:24] <skunkworks> And it looks as if the spindle override is 0 - I have a few ways to check that. (I can actually look at the spindle override in halui or that the spindle brake is still off)
[03:06:15] <skunkworks> (false)
[16:43:36] <micges> jepler: hi
[16:44:04] <micges> what was that python idle check to see overall machine performance?
[16:45:15] <jepler> umm that's not ringing a bell, sorry.
[16:45:59] <awallin_> pystones?
[16:47:52] <jepler> if that's what you meant, here's how to run it:
[16:47:53] <jepler> $ python -mtest.pystone
[16:47:53] <jepler> Pystone(1.1) time for 50000 passes = 0.53
[16:47:53] <jepler> This machine benchmarks at 94339.6 pystones/second
[16:48:16] <jepler> if you run it in a directory with 'test.py' you may get a bewildering error message instead (that's what I did the first time)
[16:49:42] <micges> jepler: yes that was it, thanks
[16:52:00] <awallin_> Pystone(1.1) time for 50000 passes = 0.62
[16:52:01] <awallin_> This machine benchmarks at 80645.2 pystones/second
[16:52:05] <awallin_> laptop...
[17:08:00] <micges> here Pystone(1.1) time for 50000 passes = 0.55
[17:08:00] <micges> This machine benchmarks at 90909.1 pystones/second
[17:49:53] <skunkworks> boy - It sure gets tricky wrapping my head around how the comp acts. (running every ms) it isn't always what I think it is going to do.
[17:51:54] <skunkworks> hey - I think I have it working again. So - it only shifts on the m5 to m3/4 transission - spindle override works down to 0.
[17:53:06] <skunkworks> it worked using the spindle brake as the 'spindle off' signal. that way the feedrate override works down to 0.
[18:15:44] <cradek> yay!
[18:26:39] <skunkworks> you're off the hook! ;)
[18:42:31] <skunkworks> So - now I think I want to shift into the correct gear for the 100% spindle override overrride. so - if the overrride is set to 50% and the spindle is turned off and then back on - as is the comp will shift into whatever gear s*override. So every time you turn the spindle off and on it will shift into a lower and lower gear ;)
[18:42:37] <skunkworks> SMOP
[18:42:53] <skunkworks> overrride override?
[18:47:18] <jepler> I don't know if there's a way to get "commanded spindle speed with no override applied"
[18:48:06] <skunkworks> I know the commanded spindle speed (with the override applied) and I know the override though halui :)
[18:48:15] <jepler> yuck, I guess you do
[18:49:00] <skunkworks> :) hack hack hack
[18:49:21] <jepler> what'll you do if the override is 0%?
[18:50:01] <skunkworks> I will have to check that.. if overide is 0 then command to vfd is zero
[18:50:18] <jepler> right, but what's the gear? With spindle override set to 0%, MDI M3 S1000
[18:50:43] <jepler> or does it not matter if the vfd is stopped -- you'll determine the gear as soon as SO is >0%
[18:50:48] <skunkworks> ah - I see - I may have to stay in current gear then.
[18:52:02] <skunkworks> As long as it doesn't do anything *stupid and it does the same thing every time - I am fine with it. :)
[20:07:29] <skunkworks> the only situation I would have to check is spindle off -> spindle on. If the FO is 0 stay in the current gear. That may be the only gotcha. (someone could have originally done 1rpm - which would be in gear 0. if they have the spindle override set to zero and start the spindle - I may have to do a gear change at that time. Not a big deal. Like jepler said - the second I am off of SO 0 - I know what the spindle rpm is
[20:08:05] <skunkworks> heh - that was rambling
[20:08:12] <skunkworks> I think I got there though
[20:30:04] <alex_joni> skunkworks: nice
[20:34:24] <skunkworks> :)
[20:51:17] <dgarr> a problem trying to open nonexisting subroutine files with mdi and a candidate patch:
http://www.panix.com/~dgarrett/stuff/mdi_sub_prob.txt
[20:53:31] <cradek> + ERS(NCE_UNABLE_TO_OPEN_FILE,settings->filename);
[20:53:40] <cradek> does this work? (I'm getting lost in those defines)
[20:53:48] <jepler> +#define NCE_UNABLE_TO_OPEN_FILE _("Unable to open file <%s>")
[20:54:12] <cradek> rs274ngc_return.hh:#define NCE_UNABLE_TO_OPEN_FILE _("Unable to open file")
[20:54:19] <jepler> I think it'll work
[20:54:33] <cradek> OH
[20:54:37] <cradek> it's later
[20:54:38] <cradek> sorry
[20:54:52] <cradek> jeez
[20:55:19] <jepler> my own personal style would probably be to get rid of the #define and put the string right with the ERS
[20:56:18] <jepler> dgarr: did you do any testing of what happens if the bad O call is in a program instead of in MDI?
[20:56:42] <dgarr> no
[20:56:52] <jepler> OK, I'll test that..
[20:57:28] <cradek> // TESTME!!! MORE THOROUGHLY !!!KL
[20:57:35] <cradek> heh
[20:58:46] <jepler> tst.ngc does not need/want an m2?
[20:58:47] <cradek> (without trying it) it looks good to me. Interp::reset resets what looks like approximately the right things
[20:59:13] <cradek> jepler: not if you're calling it with o-call
[20:59:32] <cradek> it's like just a sub declaration
[21:01:02] <jepler> dgarr: you had another patch recently regarding tool parameters and the preview. It looks like I never pushed it. Can you remind me where it is?
[21:01:06] <jepler> or is my memory wrong..
[21:02:10] <jepler> tests for me OK with loaded progams too, will push
[21:03:38] <dgarr> jepler: i believe the one you are thinking of was pushed 85c3daa66345
[21:05:18] <jepler> ah, to master only?
[21:06:11] <jepler> you haven't run into any problems in the meantime, have you?
[21:08:31] <jepler> side note: I sure was puzzled with what gitk was telling me when I did this: gitk 85c3daa663450550e9adfca5228f3636700eec73..origin/v2.4_branch
[21:08:48] <jepler> even more so because the bottom commit starts '85'
[21:11:12] <dgarr> i think today's patch is not right for the case you mentioned of a sub calling a nosuch -- it stops but withc no error message
[21:11:55] <jepler> really? in my testing, I got the expected Unable to open file <nonexistent.ngc>
[21:12:47] <jepler> oh, if it's another layer deeper in subs?
[21:14:12] <dgarr> o<tst3> sub
[21:14:13] <dgarr> (debug, tst3 calling tst1/nosuch/tst)
[21:14:13] <dgarr> o<tst>call
[21:14:13] <dgarr> o<nosuch>call
[21:14:13] <dgarr> o<tst3> endsub
[21:14:30] <dgarr> no error for nosuch with that
[21:15:10] <jepler> are you then doing MDI O<tst3> call?
[21:15:17] <dgarr> yes
[21:17:42] <Al_Smt> cradek, playin around with touchy and if you remove else:
[21:17:42] <Al_Smt> self.emccommand.auto(self.emc.AUTO_RESUME)
[21:17:42] <Al_Smt> from emc_interface.py the program would not start running when u turn off single block u would have to press cycle start again
[21:18:42] <cradek> Al_Smt: yes I bet that's right
[21:19:19] <jepler> dgarr: hm and before your change at least you get an 'EOF in file' error
[21:19:34] <jepler> in the tst3 case
[21:20:25] <Al_Smt> it would act more like a real single block should
[21:21:46] <cradek> Al_Smt: that switch does double duty as a feed hold too (which is what I mostly use it for) so I prefer it to "unhold" right away
[21:23:06] <dgarr> i imagine the reset() is too brute-force when there are multiple call levels but the code is pretty opaque to me. the worst part of the 'before' behavior is that if you mistype a mdi subroutine name you cant get it right in any simple manner
[21:26:10] <jepler> dgarr: OK, I think I'll hold off on this patch for now. Let me know if you have an improved version
[21:26:25] <dgarr> ok
[21:26:27] <Al_Smt> cradek, as long as you don't catch your shirt on it
[21:26:46] <jepler> dgarr: as to the tool patch, has that one been working for you? I see it's been a few weeks since I put it on master
[21:26:51] <jepler> I haven't heard anything, but that means nothing.
[21:28:37] <dgarr> i haven't seen anything wrong but i have been workiing with a different machine that doesn't exercise it
