Back
[00:02:37] <cmorley> mozmck: patch pushed to 2.7 - thanks!
[01:32:28] <seb_kuzminsky> :q
[09:29:05] <seb_kuzminsky> the shopbot i was doing wood working on a few years ago was donated to the boulder hackspace & moved in last night
[09:29:09] <seb_kuzminsky> it mostly still works
[09:29:30] <cradek> cool!
[09:29:32] <seb_kuzminsky> it's a dual-motor gantry with steppers & encoders
[09:34:54] <mozmck> lot of that configuration out there.
[09:35:16] <mozmck> cmorley: thanks!
[09:35:58] <cradek> since the stepgens can work fine in velocity mode, you can even have index homing with that setup now, right?
[09:36:24] <mozmck> well, dual stepper gantry, but encoders on that are not common that I've seen.
[09:36:55] <mozmck> I guess you can. Why would it matter if it is velocity mode?
[09:37:09] <cradek> with position mode you can't home to index
[09:37:57] <cradek> the stepgens don't know how to do the position jump that's involved - only motion knows how
[09:38:52] <mozmck> what is the position jump that is involved? I don't understand how the details work I guess.
[09:39:12] <cradek> not sure I do either
[09:39:31] <cradek> when an encoder module gets index, it resets its reported position to zero
[09:39:34] <mozmck> well shoot, I was hoping to learn something!
[09:39:45] <cradek> motion watches for this during index homing and handles it gracefully
[09:40:46] <mozmck> I guess this the encoder software module? Wouldn't that be a problem even while running then?
[09:40:47] <cradek> stepgens (in position mode) also maintain an internal idea of position that doesn't have this ability, so if you index home with stepgens in position mode, the stepgen and encoder positions become very different
[09:42:07] <cradek> with encoders, the index reset can happen in the hal driver or the hardware or whatever, but no matter how it works, the thing reported on the hal pin zeroes at index
[09:44:58] <mozmck> that's interesting. why do the encoders reset to zero?
[09:45:45] <seb_kuzminsky> 2.7.0~pre5 is on its way to linuxcnc.org
[09:45:57] <seb_kuzminsky> (i got distracted by the shopbot and didnt do it last night)
[09:46:16] <cradek> they have to either do that, or report two positions or an offset or something
[09:46:20] <cradek> seb_kuzminsky: yay!
[09:46:59] <cradek> so I guess it's one of a couple ways it can work, and it's the one we picked for hal
[09:47:06] <seb_kuzminsky> mozmck: the goal is to report the location of the index pulse, so that you can home to it (or orient the spindle for tapping/threading)
[09:47:06] <cradek> "we" haha
[09:47:34] <seb_kuzminsky> cradek: "we" might try to pick up your gantry homing branch this summer
[09:47:42] <mozmck> I see. I guess I assumed the index would just be ignored unless you wanted it for something, and the encoder count could just keep going up and down.
[09:47:57] <cradek> mozmck: oh it is! it only resets when you request it
[09:48:15] <mozmck> oh, I see, that seems to make more sense to me.
[09:48:30] <mozmck> I envisioned it resetting every round all the way down the table.
[09:48:30] <seb_kuzminsky> also, do "we" still leave linuxcnc in joint mode after homing? seems like a bad idea on nontrivkins machines, and easy to fix by just switching to world after homing
[09:48:42] <seb_kuzminsky> mozmck: that would be confusing!
[09:48:56] <mozmck> yes, and I was confused!
[09:49:19] <mozmck> I will definitely help on the gantry homing as much as I can.
[09:49:24] <seb_kuzminsky> one of the guys at the hackspace said he thought his H-bot switched to world mode automatically after homing and i got all flustered
[09:49:33] <seb_kuzminsky> mozmck: cool
[09:49:45] <seb_kuzminsky> oh, i should send out the announcement email
[09:49:55] <seb_kuzminsky> oh and update the irc topic and about a million webpages
[09:50:04] <mozmck> I hope to start a lot sooner on that though. Had a lot of sidetracks here, but that is normal.
[09:50:07] <cradek> I still haven't fixed my homing thing like I said I would
[09:50:21] <cradek> peter sent me a new driver card for it
[09:50:33] <mozmck> I should have a 4x4' plasma table in my shop in the next couple of weeks.
[09:50:52] <cradek> hackfest at mozmck's!
[09:51:01] <seb_kuzminsky> woo!
[09:51:05] <cradek> no wait, at seb's! because it's closer.
[09:51:29] <mozmck> :) That would be fun, but my shop right now is 26' x 30', and you wouldn't think everything that is in there would fit.
[09:51:34] <seb_kuzminsky> depends, do you prefer sawdust or molten metal fumes
[09:51:47] <mozmck> I have both :)
[09:51:49] <cradek> wait, my place is even closer
[09:55:10] <mozmck> cmorley: I forgot to mention, but I also made Gscreen default to "Follow System Theme" instead of 'Redmond'
[09:56:30] <mozmck> oh, ha, looks like he saw that and pulled it out.
[09:57:57] <kwallace> I'm starting to look at the G76 threading code in order to produce an error if it calls for an X velocity beyond the .ini max. Has this been an issue before?
[10:01:34] <cradek> if you need to solve that problem, that's the wrong layer. you should do it anytime you have spindle-synced motion in the traj planner
[10:01:45] <cradek> the interpreter knows nothing useful
[10:05:46] <cradek> it's very easy to know when your spindle-synced motion is falling behind, it's much less clear what you should do when you see that is happening
[10:06:56] <seb_kuzminsky> you could slow the spindle down, or throw an estop
[10:07:19] <seb_kuzminsky> i'd better stop playing with linuxcnc and go to work
[10:07:25] <cradek> slowing the spindle down is an interesting idea
[10:08:26] <cradek> stopping can be really bad
[10:08:28] <seb_kuzminsky> i'm really grateful to skunkworks, pcw_home, cradek, cmorley, and rob ellenberg for all the testing & fixing that went into this release cycle
[10:08:32] <seb_kuzminsky> you guys rock
[10:08:35] <seb_kuzminsky> bbl
[10:08:36] <cradek> yay us!
[10:10:21] <cradek> I think you can abort in one very particular place: when you're waiting at the beginning of a spindle-sync move you can look at the spindle speed *then* and abort if you think it's too fast *then*
[10:10:53] <cradek> I think you had better not abort once you choose to start a move, even if the speed increases etc
[10:11:34] <cradek> that limited solution might help people avoid most problems
[10:12:55] <cradek> it already waits for atspeed, in that spot - you could do a more complex sanity check.
[10:13:09] <cradek> kwallace: ok, brain dump over
[10:14:18] <kwallace> So far, I have a check in the UI that throws an error if the operator tries to post a conversational with a bad G76.
[10:15:15] <kb8wmc> cradek: good morning to you...I have not talked to you in a long time, so I thought I would just give you a shout...won't keep you as I know you are busy...
[10:15:20] <kwallace> Thank you for the brain dump.
[10:15:23] <cradek> kwallace: I don't understand what that means
[10:15:40] <cradek> kb8wmc: hey!
[10:19:42] <kwallace2> Damn ISP.
[10:20:06] <cradek> boo
[10:20:09] <kwallace2> It means that if an operator tries to fill in a threading conversational screen that produces a bad X velocity it will prevent the screen from saving and loading the file.
[10:20:35] <cradek> (do you mean Z?)
[10:20:40] <cradek> usually it's Z
[10:20:57] <kwallace2> Crud, yes.
[10:21:14] <kwallace2> No wonder it doesn't work.
[10:21:18] <cradek> heh
[10:22:17] <cradek> I guess if you're generating the S command and the G76 command and you know the Z maxvel right there in the gui, you can prevent some overtly wrong invocations
[10:22:28] <cradek> but that's a really weak fix
[10:23:41] <cradek> would be nice if it also worked for g33 and g33.1 and later when you have your spindle override set differently or you're on a machine without spindle speed control
[10:24:04] <kwallace2> Like you said, it's better to catch it at a low level, but we also want to error out as early as we can.
[10:27:39] <cradek> yes "don't [use the program to] write inappropriate gcode" and "don't try to make motions you can't make" are both useful approaches
[10:27:59] <cradek> of course I'm more interested in the second because it's so much more general
[10:29:07] <skunkworks> kwallace2, still pretty positive reviews of pathpilot.. (most everyone is just giddy about soft limits.. :) )
[10:29:32] <cradek> haha
[10:29:47] <kwallace2> What? I've always had soft limits.
[10:29:56] <skunkworks> mach didn't..
[10:30:05] <skunkworks> or it didn't work well..
[10:30:59] <skunkworks> kwallace2, someone had the same issue as you where the over travel limit was within the soft limit..
[10:31:22] <skunkworks> he adjusted the physical limit.
[12:24:27] <mozmck> Why is there a max velocity slider? I guess it allows to cap the max velocity without slowing down everything like feed override?
[12:27:47] <pcw_home> max velocity bounds all axis motion
[12:28:13] <pcw_home> feed rate does not affect G0
[12:28:59] <mozmck> Ok, but there is also a rapid override...
[12:29:51] <pcw_home> yeah so you have all options
[12:29:54] <mozmck> I assume that changes the G0 speed
[12:29:59] <pcw_home> yes
[12:31:01] <mozmck> So Max Velocity just changes overrides the bound, but feed override slows all feeds except G0, and rapid override slows only G0
[12:31:35] <pcw_home> thats my understanding from poking at it
[12:31:40] <mozmck> ok
[12:31:48] <mozmck> I think we need more sliders ;)
[12:33:07] <seb_kuzminsky> add a slider to change the number of sliders
[12:33:52] <pcw_home> sebastian gave me a recursion headache
[12:34:51] <seb_kuzminsky> add a slider to reduce max headache
[12:35:25] <seb_kuzminsky> installing the wheezy linux-image-rt.deb on precise, then building linuxcnc from source works just fine
[12:35:58] <seb_kuzminsky> the wheeze linuxcnc-uspace.deb does not install because of version skew on some dependencies between wheezy and precise
[12:46:16] <skunkworks> pcw_home, do you change anyting in the make menuconfig?
[12:46:26] <skunkworks> (wheezy)
[12:46:48] <pcw_home> with a stock wheezy iso, no
[12:48:26] <pcw_home> I have a working .config if you like ( I ran into troubles doing the same on Ubuntu 14.04 and copied my working .config over)
[12:49:11] <pcw_home> (I should trim some of the 100s of unused drivers but it works)
[12:51:54] <skunkworks> Make gives me kernel/irq_work.c in function 'irq_work_needs_spu'
[12:52:23] <skunkworks> hirq_work_list undeclaired
[12:52:38] <pcw_home> The great thing is that the 3.18 kernel fixed the occasional crash on my home ubuntu 14.04 machine at high interrupt rates
[12:52:40] <pcw_home> This is a intel graphics driver bug that only seems to affect certain machines there was a really ugly watchdog type workaround
[12:52:41] <pcw_home> that was removed at some point but re-instated in 3.18
[12:53:44] <pcw_home> did you try my script? (I havent...)
[12:54:08] <pcw_home> where do you get the error?
[12:55:00] <skunkworks> running make. - Yes your direction from the list
[12:56:16] <pcw_home> did patching succeed?
[12:57:27] <skunkworks> yes
[12:57:32] <skunkworks> I can go throught the steps again
[12:57:41] <skunkworks> just to make sure I didn't miss anyting
[12:58:29] <pcw_home> might also go through make menuconfig and check that it makes some kind of sense
[12:59:54] <skunkworks> I could try your .conifg
[13:15:45] <pcw_home> hmm seems to work here, at least so far
[13:15:46] <pcw_home> (did you save when you ran menuconfig?)
[13:16:27] <skunkworks> yes
[13:16:57] <skunkworks> I have booted the rtai kernel - that shouldn't be a problem..
[13:20:00] <pcw_home> not sure... the config stuff is pretty strange, pretty sure I always built under preemt-rt
[13:20:55] <pcw_home> freeby.mesanet.com/rtconfig might be worth trying
[13:21:23] <pcw_home> (rename to .config )
[13:29:48] <skunkworks> I have reboot rt just for grins
[13:47:29] <skunkworks> pcw_home, seem to be getting further
[13:47:40] <skunkworks> with your conjfig
[13:47:44] <skunkworks> ick
[13:51:53] <pcw_home> I think there were some complaints about nvidia drivers but I didn't care (dont have nvidia)
[13:53:49] <skunkworks> wow - this takes a while... ;
[14:04:40] <pcw_home> removing some of the hardware support would help :-)
[14:20:13] <pcw_home> ok built and installed on the laptop, not tested yet
[14:49:21] <mozmck> cmorley: you around?
[16:07:23] <Roguish> pcw_home: THANK YOU VERY MUCH FOR THE HELP. MESANET is the greatest!!!!!
[16:10:43] <skunkworks> :)
[19:57:33] <cmorley> mozmck: Gscreen needs rapid override added - it wasn't available at the time I built it.
[20:54:35] <mozmck> cmorley: I'm working on adding that.
[20:55:51] <mozmck> I took the gaxis.glade file and am moving things around and I think it will make a good base for my screen.
[22:42:21] <pcw-laptop> latest preemt-rt on laptop:
[22:42:22] <pcw-laptop> http://ibin.co/1uWVS6xV3Nif
[22:42:24] <pcw-laptop> Not bad, though I notice you cannot switch to battery power without terrible latency
[23:59:38] <cmorley> mozmck: That's great - sometime when I get back to it I would generalize a bunch of the routines in gscreen or move them out to the handler files.. maybe after your work we can look at filling out the docs to help others with customizations.