Back
[08:02:45] <KGB-linuxcnc> 03dgarrett 05master 09d6235 06linuxcnc 10src/emc/ 10usr_intf/touchy/filechooser.py 10usr_intf/touchy/touchy.py * touchy: regression fix (loading of file twice)
[08:02:45] <KGB-linuxcnc> 03chris 05master 13311d6 06linuxcnc 10src/emc/usr_intf/touchy/filechooser.py * Fix traceback when clicking an empty file-load slot
[08:16:54] <jepler> totally nitpicking here
[08:16:55] <jepler> + return(fn)
[08:17:09] <jepler> I prefer to see 'return fn', and don't like the syntax that makes a use of return look like a function call
[08:17:19] <jepler> now back to your regularly scheduled actual improvements to linuxcnc
[08:21:20] <cradek> you're probably right - I won't be offended if you fix it (in both places)
[10:52:55] <seb_kuzminsky> whoops, maybe i should try things out before trying to advise users about them :-/
[10:53:03] <seb_kuzminsky> thanks for correcting me, cradek
[11:02:39] <cradek> it's just one of the services I provide
[11:03:08] <cradek> I didn't answer in the first place because I wasn't really sure what he was asking :-/
[11:05:37] <jthornton> turns out increasing stepgen to 16 worked, I just didn't scroll up to see 10-15 after a show pin
[11:05:59] <cradek> oh, alphabetic sort strikes again?
[11:06:10] * jthornton feels a tiny bit embarrassed at that rookie mistake
[11:06:19] <jthornton> yea 10 comes after 1 not 9
[11:06:21] <cradek> 1 10 11 .. 15 2 3 .. 9
[11:06:31] <cradek> that's sure irritating
[11:06:56] <jthornton> at least I know what I did works
[11:07:04] * jthornton goes back to work
[11:18:47] <seb_kuzminsky> maybe we should change the stepgen numbering scheme in master to "%02d", like the hostmot2 instance numbers? then it sorts right
[11:19:38] <cradek> breaking every config to fix sort order in halcmd?
[11:19:44] <cradek> not sure if serious
[11:20:10] <seb_kuzminsky> http://chicagolionssevens.files.wordpress.com/2011/01/serious-cat.jpg
[11:20:22] <cradek> hahaha
[11:22:08] <cradek> wow, there are a lot of good "not sure if serious" images.
[11:35:26] <cradek> huh, I haven't yet been able to figure out how it sorts at all
[11:36:47] <cradek> I think the lists are sorted in memory, and halcmd just traverses them. I was expecting them to be sorted for output.
[11:38:06] <cradek> yeah hal_pin_new does a strcmp() based insertion sort
[11:41:47] <jepler> that's an odd choice
[11:43:38] <jepler> I see there are lots of places in halcmd you'd have to sort things, but...
[11:43:47] <cradek> and every other hal util
[11:45:08] <seb_kuzminsky> mozmck: here's another guy with the same robot arm (in much better shape):
http://orbitusrobotics.com/?p=501
[11:45:34] <seb_kuzminsky> i've been emailing with him, he reverse engineered the 50-pin connector already and is driving his arm with an arduino
[11:45:59] <cradek> so the question becomes: is there a simple replacement for strcmp that does numeric compare instead of alphabetic
[11:46:18] <jepler> cradek: strcoll() is in C but probably not in the kernel
[11:46:29] <jepler> it's dependent on LC_COLLATE, but there are not locales in the kernel
[11:47:48] <cradek> I'll just use popen("sort -n")
[11:47:55] <jepler> http://stackoverflow.com/questions/1343840/natural-sort-in-c-array-of-strings-containing-numbers-and-letters#answer-1344056
[11:48:09] <jepler> here's an implementation that works assuming all the numbers are strtoul-parsable
[11:48:17] <jepler> well and assuming the assertion that it works is right
[11:49:35] <mozmck> seb_kuzminsky: neat! hope it proves useful to you!
[11:49:47] <jepler> for our purposes that implementation is probably adequate
[11:51:06] <seb_kuzminsky> mozmck: heh, for some definition of useful ;-)
[11:51:30] <mozmck> :) for playing with non-trivial kinematics anyhow.
[11:51:30] <pcw_home> That would be nice (especially for things like halmeter selection menus )
[11:52:10] <cradek> keeping them sorted lets you not traverse the whole list to search for a duplicate when you're adding something
[11:52:24] <cradek> I think the sorted lists presented to the user are happy accidents
[12:33:00] <pcw_home> seb_kuzminsky: do you know offhand if a newer module version will make the hm2 driver bail?
[12:33:02] <pcw_home> Couldn't find this in the source, and will try later today (need to add a feature to muxed encoders)
[12:34:01] <seb_kuzminsky> pcw_home: yes, if the module info doesn't match what the hostmot2 driver expects it will not use that module
[12:35:41] <skunkworks> pcw_home, do you know if Micges has had a chance to work on the 7i80 driver?
[12:36:47] <pcw_home> I dont think so I think He's working on Mesaflash and aiolib
[12:36:55] <pcw_home> (ATM)
[12:37:59] <skunkworks> ah
[12:38:32] <seb_kuzminsky> pcw_home: the hm2_md_is_consistent() function implements the check
[12:38:38] <pcw_home> I think the main thing needed is a thorough rototilling of hm2 to consolidate all physical I/O in two or three places
[12:38:39] <pcw_home> (readstart read write)
[12:39:04] <seb_kuzminsky> all the subdrivers call it when they get initialized, and bail if the MD doesn't match what they expect
[12:39:48] <pcw_home> So its all = matches on revisions?
[12:39:52] <jthornton> YIKES!
[12:40:02] <KGB-linuxcnc> 03jthornton 05master 61ebd82 06linuxcnc 10src/hal/components/stepgen.c
[12:40:02] <KGB-linuxcnc> increase stepgen to 16
[12:40:02] <KGB-linuxcnc> Signed-off-by: John Thornton <jthornton@gnipsel.com>
[12:40:23] * jthornton waits for the blame list now
[12:48:53] <seb_kuzminsky> pcw_home: the subdriver calls hm2_md_is_consistent() and verifies that the md version, the number of registers, the instance stride, and the multiple registers field all match exactly the expected values
[12:49:19] <seb_kuzminsky> the subdriver can call this function multiple times to see if the MD matches *any* of the ones it knows how to deal with
[12:49:24] <seb_kuzminsky> does that answer your question?
[12:50:43] <seb_kuzminsky> jthornton: it's preferable to have the commit message match this format:
http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
[12:50:47] <pcw_home> Yes, I see it in the encoder driver, which is OK with 2 and 3 on muxed encoders
[12:50:58] <seb_kuzminsky> ie: first a subject line, then an empty line, then anything else you feel like adding
[12:51:03] <seb_kuzminsky> pcw_home: cool
[12:51:20] <pcw_home> just need to be ok with 4 (or have the firmware lie)
[12:51:31] <pcw_home> for now
[12:52:03] <seb_kuzminsky> jthornton: will you update the stepgen.9 manpage too? it still says 8 is the max
[12:52:21] <seb_kuzminsky> pcw_home: ooh, new encoder features?
[12:52:57] <jthornton> seb_kuzminsky, yes
[12:53:07] <seb_kuzminsky> thx
[12:53:29] <pcw_home> A feature needed to allow isolated muxed encoders or muxed encoders with looong cables
[12:56:31] <pcw_home> programmable sample time for muxed encoder data to allow
[12:56:33] <pcw_home> for significant delays in isolation or 2 way cable flight time
[12:56:36] <KGB-linuxcnc> 03jthornton 05master d5138ff 06linuxcnc 10docs/man/man9/stepgen.9 * Docs: update man page to 16
[12:57:34] <pcw_home> (tacked on to the top nibble (31..28) of the filter rate register)
[12:57:57] <seb_kuzminsky> thanks jthornton
[12:58:37] <pcw_home> also allows higher mux rates by 'tuning out' cable delays
[13:02:32] <jthornton> I'm glad I can help seb_kuzminsky
[13:19:35] <jepler> sweet, I just got the tracking number for my rostock max.
[13:20:23] <cradek> that was fast
[13:20:32] <jepler> yeah, they said 3-5 days lead time but I just ordered yesterday
[13:21:39] <cradek> when do you expect it now?
[13:23:07] <jepler> UPS says ground shipping time from their zip code to eastern nebraska is 2 days, so probably monday
[13:23:22] <cradek> whee
[13:23:25] <jepler> my weekend's full so it's best if it doesn't show up friday
[13:23:43] <seb_kuzminsky> fun
[13:24:20] <jepler> (friend's wedding and wife's birthday)
[14:11:16] <cradek> This is 2013 the buliten board system has been replaced with newer better technologies. We have the internet and community forums.
[14:11:37] * cradek sighs
[14:12:07] <skunkworks> heh
[14:12:22] * skunkworks uses both...
[14:13:04] <skunkworks> actually - I think linuxcnc is the first mailing list I joined.. (other than maybe yahoo groups - that is sort of like a mailing list...)
[14:14:34] <cradek> the "It's [year]!" argument always makes me smile
[14:15:47] <skunkworks> I think on the fourms they do pretty good.. If someones question isn't moving- quite a few times people will say - post on the mailing list...
[14:16:13] <cradek> this guy seems to put his question in both places at the same time
[14:16:23] <cradek> I wish people wouldn't do that particular thing
[14:16:52] <cradek> sometimes list-only-users do that too (both mailing lists at the same time) and it's bad practice
[14:17:07] <skunkworks> sure
[14:21:26] <cradek> er, to be clear, where he says "buliten board system" he means the mailing list
[14:22:03] <cradek> IMO a forum is entirely more like a BBS than a mailing list is, but whatever
[14:22:44] <cradek> and I agree BBSes were replaced with something better: usenet
[14:23:11] <cradek> and mailing lists are a lousy workaround to avoid the usenet spam
[14:48:42] <jepler> can we just go back to fidonet (-over-ipv6 or something)?
[14:50:38] <skunkworks> jepler, thanks again - The printer port reset works great for sending a clock singal to the lathe. the octal latch is transparent then.
[14:51:10] <skunkworks> dad is having a big time. Just got the encoder/index hooked up in hal. Video soon I hope.
[14:51:50] <seb_kuzminsky> skunkworks: dont bother, if it doesnt have nontrivial kinematics, jepler won't be interested
[14:52:33] <skunkworks> heh
[14:53:03] <skunkworks> jepler, seb_kuzminsky, I just posted on the list another delta kins..
[14:53:21] <seb_kuzminsky> i saw that - it's a cool demo
[15:15:09] <cradek> that's an interesting license statement:
http://kvarc.extra.hu/step/motor/emc/emckinematics.html
[15:16:03] <jepler> I would sure not incorporate that code into linuxcnc
[15:16:42] <cradek> yes certainly not
[15:17:58] <seb_kuzminsky> because of the license? or some concern about the code itself?
[15:18:10] <cradek> I only got as far as the license
[15:18:13] <jepler> because of the license
[15:19:37] <cradek> seb_kuzminsky: what are your thoughts about ja3 merge before 2.6?
[15:20:10] <seb_kuzminsky> i got bogged down trying to rebase it :-(
[15:20:38] <seb_kuzminsky> there's a bunch of sketchy commits early in the history (i'm about half way through)
[15:20:48] <cradek> ah
[15:21:02] <seb_kuzminsky> so far i've seen some of the early bogosity get cleaned up, but i dont know if it all gets cleaned up
[15:21:03] <cradek> now I remember you talking about this task
[15:22:04] <seb_kuzminsky> it's on my top-2 list for 2.6, just after the new rtos branch ;-)
[15:22:29] <seb_kuzminsky> i'm planning to work on it more before making a recommendation
[15:22:45] <seb_kuzminsky> i think there are people running it successfully, but i've never tried it
[15:23:00] <jepler> I think you may take too hard a line against merging
[15:23:27] <jepler> for long-lived topic branches the work-benefit ratio is bad
[15:23:54] <seb_kuzminsky> jepler: you think i'm being too ocd about understanding the long and sordid past of ja3?
[15:23:59] <seb_kuzminsky> ah yes
[15:24:02] <seb_kuzminsky> i think you may be right
[15:24:51] <jepler> they are super ocd about this kind of thing in git but we're not developers of source code management software...
[15:25:05] <jepler> perfect, enemy of good, etc
[15:25:08] <seb_kuzminsky> yes
[15:28:55] <seb_kuzminsky> jepler: have you run ja3? are you planning to use it for your rostock?
[15:31:30] <jepler> seb_kuzminsky: no and yes .. but I think it will be some time before I try that
[15:31:31] <jepler> my expectation is that I'll use it for awhile with the original electronics (RAMBo) until I get motivated to design some kind of mesa-based interface
[15:31:47] <jepler> rambo puts the avr on the same board with the power electronics so unfortunately it's not going to be very reusable
[15:37:29] <jepler> seb_kuzminsky: so unfortunately not in a time frame to be useful feedback on whether you should merge ja3
[15:44:32] <seb_kuzminsky> yeah, that's the situation for me too
[15:44:44] <seb_kuzminsky> i'd feel a lot more confident if i knew anyone who had experience running it for a while
[15:46:26] <seb_kuzminsky> the lack of actual experience makes me want to understand at least the endpoint of the branch (and preferably the history)
[15:50:13] <seb_kuzminsky> i started this whole robot arm project to get an excuse to play more with ja3, we'll see what the schedule for that turns out to be...
[18:45:22] <andypugh> seb_kuzminsky: You might want to talk to Viesturs, I am pretty sure he has _sold_ JA3 systems to customers.
[20:32:49] <seb_kuzminsky> zultron: what is your opinion of the current rtos-master-v0 branch?
[21:25:41] <zultron> Hi seb_kuzminsky, I haven't actually looked at it, sorry. I've been working on the universal build for quite some time.
[21:26:04] <zultron> My plan is to rebase the universal build stuff on top of that branch at some point, though.
[21:30:42] <zultron> Although that branch is based on the one I started with. It's got some other pieces that Michael pulled together, and I believe he merged master into it.
[21:32:11] <seb_kuzminsky> ah, that makes sense
[21:32:17] <seb_kuzminsky> i guess i should ask michael
[21:32:36] <seb_kuzminsky> do you know if rtos-master-v0 is still the most current rtos branch?
[21:33:17] <zultron> As far as I know, it is.
[21:33:55] <zultron> Michael might be putting a few finishing touches on my branch to make things easier to merge, whenever that starts in the next few days.
[21:34:23] <zultron> Honestly, though, I haven't been paying attention, just trying to get this thing done. :)
[21:35:03] <zultron> What're you trying to do?
[21:36:08] <seb_kuzminsky> at the hackfest i wanted to merge rtos-master-v0 into master, but michael was strongly opposed to that and asked for 2 weeks more development time before merging
[21:36:36] <seb_kuzminsky> 2 weeks was this past sunday, and i haven't heard anything from him, so i'm just trying to check up on the status...
[21:36:55] <seb_kuzminsky> sorry to bug you about it, i should really talk to him
[21:37:33] <seb_kuzminsky> bbl
[21:37:35] <zultron> Well, it's really me, actually.
[21:38:10] <zultron> Ok talk to you later. You should ask both of us, I'd say.
[21:52:42] <seb_kuzminsky> i still dont understand why ub should hold up the merge of rtos
[21:54:33] <pcw_home> is this for 2.6?
[21:54:44] <seb_kuzminsky> yeah
[21:55:46] <pcw_home> crud, need to fix some of these encoder bugs/ommisions
[21:56:13] <seb_kuzminsky> do you have things you want to get in the hostmot2 driver before 2.6?
[21:56:43] <pcw_home> If possible, some make just be backing out some additions
[21:56:54] <pcw_home> s/make/may/
[21:58:21] <seb_kuzminsky> ok cool, thanks for letting me know
[22:00:40] <zultron> The ub introduces another large changeset. The configure/build options are very different, and I'd like people to be testing those. Also, I don't want to be debugging problems that crop up in the -v0 branch while trying to get the ub done.
[22:01:38] <zultron> Is there a reason we're trying to get -v0 merged very soon?
[22:05:33] <seb_kuzminsky> well, i've been asking to merge for a long time
[22:05:54] <zultron> Yes, you have, and it's taken longer than I originally estimated.
[22:05:58] <seb_kuzminsky> mostly just to get more runtime and testing on it for the 2.6 release cycle
[22:06:11] <seb_kuzminsky> i dont mind waiting on ub! i'm not trying to rush you
[22:06:31] <zultron> I'm rushing myself, actually. :)
[22:06:41] <seb_kuzminsky> i know how long development can take, especially when you have other responsibilities like we all do
[22:07:25] <zultron> Well, the snags I've hit have been with non-RIP installation, quite a headache. That's going to be a problem with the -v0 stuff.
[22:07:58] <zultron> At least I think so; never actually tried!
[22:08:16] <seb_kuzminsky> i don't see non-rip (ie, debian-packaged) builds are a requirement for merging the rtos work
[22:08:38] <seb_kuzminsky> i think we could keep shipping sim and rtai debs for now
[22:08:40] <zultron> There are also a lot of things I fixed in the build system that are in the UB.
[22:08:57] <seb_kuzminsky> and let the buildbot test the new rtos environments in rip mode
[22:09:09] <zultron> Folks *will* run up against these, and I'm just not ready to support the -v0 branch.
[22:09:10] <seb_kuzminsky> i bet there's lots of bogosity in our current build system, thanks for fixing that...
[22:09:32] <seb_kuzminsky> ok
[22:09:49] <seb_kuzminsky> we'll wait :-)
[22:10:16] <zultron> Alright. I sure appreciate the patience. It's really, truly right around the corner. :)
[22:10:42] <seb_kuzminsky> heh ok, no rush
[22:10:45] <zultron> Most likely, the merge effort will begin on Friday.
[22:11:11] <seb_kuzminsky> let's do the merge together, i want to look at it before you push
[22:11:21] <seb_kuzminsky> and i think cradek and jepler and maybe others do too
[22:11:27] <zultron> Sure.
[22:11:39] <seb_kuzminsky> there are some things in rtos-master-v0 that absolutely cannot go into master
[22:12:29] <zultron> I have a version that's reported to build (ha ha) on my github repo:
https://github.com/zultron/linuxcnc/tree/dynload-rtapi-common-shm-ub-wip
[22:13:15] <zultron> The non-RIP build fixes aren't in there yet (and are the last piece I'm adding before I can be cajoled into giving it up).
[22:14:28] <KimK> Is there anything I can do to help you guys test? I could get another drive for my E350N system and load whatever you guys need.
[22:15:14] <KimK> Or would you rather an older motherboard?
[22:15:17] <zultron> What pieces can't go into master? Have you made a list? I remember the emc-web bit, or whatever that thing is.
[22:16:04] <zultron> KimK, if you're asking about the new code, we're not quite ready for testing. If you're asking about something else, please disregard. :)
[22:16:22] <seb_kuzminsky> yeah, after talking with you and charles at the fest we thought we'd merge it then & there, and we quickly reviewed it and found some problems
[22:16:25] <seb_kuzminsky> i have a list somewhere
[22:16:29] <seb_kuzminsky> the emcweb thing was one
[22:16:41] <KimK> OK, good luck then, I'll keep my fingers crossed.
[22:17:11] <zultron> Well, if you could dig up that list in the next couple of days I'd like to start thinking about it.
[22:17:26] <seb_kuzminsky> there were some commits by "Joe Chipcutter" which is actually Ian McMahon, i talked with him and he said that was a mistake and he was ok with rewriting the committer and author to be correct
[22:17:39] <zultron> Ha
[22:17:57] <seb_kuzminsky> iirc there were a bunch of M-files added with nothing but "FIXME" in them in nc_files or some sample directory
[22:18:09] <seb_kuzminsky> the m5i20 driver got added back in
[22:18:18] <seb_kuzminsky> ppmc got taken out
[22:18:37] <seb_kuzminsky> some api changes without matching manpage changes
[22:19:17] <zultron> Huh, those don't sound familiar to me, unless one of the apis was something I touched.
[22:19:45] <seb_kuzminsky> it was hal_create_thread(), it now takes a cpu number and sets affinity
[22:19:49] <zultron> I certainly will need to work on documentation. :(
[22:20:22] <zultron> Ah, not mine, but we can find the guilty party!
[22:20:33] <seb_kuzminsky> git blame to the rescue!
[22:21:08] <zultron> And I'll recommend we go easy on him (so that hopefully I'll get the same treatment when it comes back around to me :-O )
[22:21:49] <seb_kuzminsky> yes there's no animosity here, i'm only grateful for all the work you (and others) have put in
[22:22:02] <zultron> I'm afraid it will be quite a bit of work to sort out everything that's been changed.
[22:22:12] <seb_kuzminsky> and i want to help with the final stretch to get it merged and debugged and deployed to our users
[22:22:25] <zultron> Thanks, seb_kuzminsky. :)
[22:22:47] <zultron> Ahhh, I can surely use some help.
[22:22:47] <seb_kuzminsky> you guys are the ones doing all the work, the thanks go to you :-)
[22:23:03] <seb_kuzminsky> what can i do to help?
[22:23:45] <zultron> Well, let me finish this silly non-RIP business. Then we can start looking at what's next.
[22:24:33] <zultron> There's reviewing, merging, testing, of course, documentation, plus I've got a list of little things to fix.
[22:25:11] <seb_kuzminsky> ok, just let me know
[22:26:27] <zultron> Will do. Thanks for the support. It's pretty exciting, but still lots of work to do even after I relax my clutch on the ub....
