Back
[00:04:12] <skunkworks> I think I re-encoded it because it was too big. But I did it some how in ubuntu (time lapse video)
[01:21:51] <dmwaters> {global notice} Good day all, I need to do a bunch of rerouting to prep for an outage tomorrow. If all goes well, this should not take long. Any further messages about this will be given in wallops, '/mode your_nick w' to see them. Thank you for your patience, and thank you for using freenode!
[02:13:50] <seb_kuzminsky> hello again
[02:14:24] <seb_kuzminsky> jmkasunich: are you around?
[02:20:07] <jmkasunich> hi
[02:34:56] <jmkasunich> ?
[02:35:58] <seb_kuzminsky> uh hi sorry
[02:36:27] <seb_kuzminsky> ok i'm here
[02:36:38] <jmkasunich> ditto
[02:36:39] <seb_kuzminsky> i wanted to ask you about upci & bfload...
[02:36:55] <jmkasunich> what about them?
[02:36:57] <seb_kuzminsky> upci doesnt do config space access
[02:37:15] <seb_kuzminsky> a recent problem with the 5i20 on some (older?) bioses needs config-space access to fix
[02:37:25] <jmkasunich> oh - bummer
[02:37:31] <seb_kuzminsky> yeah it sucks
[02:37:39] <jmkasunich> upci was an attempt to avoid dealing with config space and all that crap
[02:37:58] <seb_kuzminsky> i've got a bugfix program that uses libpci (from pciutils) that seems to fix it
[02:38:26] <seb_kuzminsky> how would you feel if i ported bfload from upci to libpci?
[02:38:58] <jmkasunich> trying to remember why I didn't use libpci in the first place
[02:39:08] <seb_kuzminsky> i was sort of wondering the same thing
[02:40:57] <jepler> availability of libpci on some terrible old system we "support"?
[02:41:24] <jmkasunich> I think it was more a case of libpci having a complex and poorly documented api
[02:41:32] <jmkasunich> http://jmkasunich.com/cgi-bin/blosxom/software/user-space-pci-04-17-07.html
[02:41:51] <jmkasunich> libpci = sledgehammer for killing gnats
[02:41:56] <seb_kuzminsky> heh
[02:42:57] <seb_kuzminsky> i was pretty pleased with the libpci interface. i mean i've seen better, but i've seen worse...
[02:43:44] <jmkasunich> I'm looking at a google search on "libpci documentation" and finding no description of the API
[02:44:44] <jmkasunich> ok, found it
[02:44:44] <seb_kuzminsky> hm, i didnt look for any docs, i started with the 32-line example program tweaked it into what i needed
[02:44:44] <jmkasunich> http://mj.ucw.cz/pciutils.shtml
[02:44:56] <seb_kuzminsky> seems pretty straight forward
[02:45:07] <jmkasunich> a quick read of that page seems to imply _only_ config space access
[02:47:11] <seb_kuzminsky> hm, yes i think you're right
[02:47:17] <SWPadnos> one quick thing before I head off to bed: please don't remove pci_read and pci_write. they're useful debugging tools
[02:47:41] <seb_kuzminsky> ok, libpci can't replace upci
[02:47:48] <seb_kuzminsky> both are needed
[02:48:05] <SWPadnos> they just let you twiddle bits and look at registers without having to recompile drivers, or even while HAL is running a new driver
[02:48:11] <jmkasunich> what exactly is the problem that requires config space access?
[02:49:03] <seb_kuzminsky> the card's PCI Command register in the Config space is set incorrectly by the BIOS (or Linux kernel, I'm not sure)
[02:49:28] <seb_kuzminsky> both memory and i/o access to the card are disabled
[02:49:43] <seb_kuzminsky> so it shows up in the lspci list and /proc/pci etc, but you can't talk to the card
[02:50:40] <seb_kuzminsky> ugh brb
[02:50:51] <jepler> can setpci do what you need?
[02:50:54] <jepler> (commandline)
[02:51:35] <jmkasunich> I wonder if the "command" field is the one on line 59 of
http://cvs.linuxcnc.org/cvs/emc2/src/hal/utils/upci.c?annotate=1.1
[02:52:33] <jmkasunich> it sure looks like setpci can set the command register
[02:52:43] <seb_kuzminsky> setpci can do it
[02:53:46] <seb_kuzminsky> jmkasunich: looks like line 59 is it
[02:53:59] <seb_kuzminsky> can upci write the cfg_info?
[02:54:36] <seb_kuzminsky> brb again
[02:54:47] <jmkasunich> the current api doesn't have a "write to config space" call
[02:54:52] <jmkasunich> but that could be fixed I suppose
[02:55:16] <jmkasunich> well, maybe
[02:57:29] <seb_kuzminsky> ok im back
[02:57:31] <seb_kuzminsky> sry
[02:57:37] <jmkasunich> looks like upci gets the cfg info by reading "/proc/bus/pci/<bus><dev><func>"
[02:57:49] <jmkasunich> no idea if that is writable or not (probably need to be root to write it)
[02:59:15] <jmkasunich> oops, I mean "/proc/bus/pci/<bus>/<dev>.<func>"
[02:59:47] <jmkasunich> upci will probably break the next time the kernel guys decide to re-arrange everything
[03:00:04] <seb_kuzminsky> so maybe adding "write to config space" function to upci is the way to go...
[03:00:56] <jmkasunich> comparing the list of config space registers in the setpci man page to the fields of the upci struct - the setpci list is _much_ bigger
[03:01:07] <jmkasunich> upci apparently only looks at a small subset
[03:01:14] <jmkasunich> it happens to contain the field you want....
[03:01:22] <seb_kuzminsky> there's a small standard header at the beginning of the config space
[03:01:41] <seb_kuzminsky> the pci extensions (pci-x, cardbus, pci-express, etc) all have extended headers
[03:03:39] <jmkasunich> are you thinking in terms of extending bfload to transparently do whatever fixing is needed?
[03:04:24] <seb_kuzminsky> yes, just like the LASxBRD fix of a couple weeks ago
[03:04:35] <seb_kuzminsky> check for the problem, if it's detected then warn and fix it
[03:05:31] <jmkasunich> so setpci isn't an ideal solution - you want something you can call from bfload, not another executable
[03:06:13] <seb_kuzminsky> i'd prefer to have it linked in, but i'd shell out if that's what was needed
[03:06:35] <jmkasunich> so the options are:
[03:06:44] <jmkasunich> 1) use libpci instead of or in addition to upci
[03:07:03] <jmkasunich> 2) use setpci (shell out) in addition to upci
[03:07:25] <jmkasunich> 3) extend upci to support writing some config regs
[03:07:37] <seb_kuzminsky> 1) would have to be "in addition to"; or we'd lose pci_read & pci_write and blockram access
[03:08:02] <jmkasunich> right
[03:08:25] <seb_kuzminsky> i like 3 best i guess
[03:08:35] <seb_kuzminsky> 1 seems like less work but a cruftier product
[03:09:05] <jmkasunich> at the moment the struct with the command field in it is private to upci.c, not exported to upci.h
[03:09:21] <jmkasunich> (on purpose - my goal was to avoid the coder from worrying about config space stuff)
[03:09:42] <seb_kuzminsky> normally you dont have to mess with it - only when something goes wrong and you need to fix it
[03:12:38] <seb_kuzminsky> hm
[03:13:04] <jmkasunich> extending upci seems an awful lot like reinventing setpci
[03:13:32] <seb_kuzminsky> heh yeah: 4) extend libpci to allow BAR access ;-)
[03:13:41] <jmkasunich> bar?
[03:13:51] <jmkasunich> you mean memory and I/O regions?
[03:13:58] <seb_kuzminsky> base address registers, the card's address spaces
[03:14:02] <jmkasunich> ah
[03:14:02] <seb_kuzminsky> yes
[03:15:21] <seb_kuzminsky> well maybe 1 isnt that bad... use libpci for config and upci for bar
[03:15:32] <seb_kuzminsky> duplicates the scanning code
[03:15:50] <jmkasunich> does it?
[03:16:17] <jmkasunich> use upci to find the card, and libpci only to perform the bug workaround
[03:17:02] <seb_kuzminsky> libpci makes a struct pci_dev to act as a handle for the card you want to poke the config space on
[03:17:13] <jmkasunich> upci can return the bus/dev/func data for the card(s) it finds. I bet you can use that to access
[03:17:14] <jmkasunich> oh
[03:17:21] <seb_kuzminsky> you get the pci_dev by pci_scan_bus() or pci_get_dev()
[03:17:55] <seb_kuzminsky> libpci's pci_get_dev() takes domain, bus, dev, func
[03:17:58] <jmkasunich> where are you reading this info about libpci?
[03:18:36] <seb_kuzminsky> /usr/include/pci/pci.h
[03:18:52] <seb_kuzminsky> in pciutils-dev
[03:19:30] <seb_kuzminsky> i feel like we got two wheels and neither one is round ;-)
[03:19:36] <jmkasunich> yeah
[03:20:07] <seb_kuzminsky> i wonder what the pciutils guys would say about bar access
[03:21:26] <jmkasunich> looking in pci.h, I don't see a way to write the pci_dev struct back to the hw
[03:21:37] <jmkasunich> pci_get_dev gets you one
[03:21:47] <jmkasunich> I assume you then modify a field or fields
[03:21:52] <jmkasunich> but then how do you write it back?
[03:22:04] <seb_kuzminsky> you use pci_write_{byte,word,long}()
[03:22:15] <jmkasunich> duh
[03:22:36] <jmkasunich> I was confusing those with my versions, which access the regions, not the config space
[03:22:44] <seb_kuzminsky> there's #defined constants in header.h
[03:22:51] <seb_kuzminsky> to help you find the register offsets
[03:23:12] <seb_kuzminsky> yeah, the unfortunate name similarities between libpci and upci would make for a confusing mashup
[03:25:58] <jmkasunich> I wonder if it makes sense to add "upci_cfg_read_u8(int devnum, __u32 offset)" and "upci_cfg_write_u8(int devnum, __u32 offset, __u8 data)"
[03:26:22] <jmkasunich> (and the versions for other data sizes)
[03:26:48] <seb_kuzminsky> that would solve the problem i've got right now and seems pretty clean
[03:27:04] <seb_kuzminsky> how would that interact with the cached cfg_info struct?
[03:27:13] <jmkasunich> damned if I know ;-)
[03:27:19] <seb_kuzminsky> lol
[03:27:54] <jmkasunich> cached meaning inside upci.c? the devices[MAX_DEVICES] array?
[03:28:33] <seb_kuzminsky> yeah... hm, it looks unused
[03:28:43] <jmkasunich> I don't think the cfg_info is cached
[03:28:49] <jmkasunich> device_info is
[03:29:43] <seb_kuzminsky> oh, it's not cached, you're right
[03:30:10] <seb_kuzminsky> dev_info has a cfg_info, but it's not initialized?
[03:30:49] <jmkasunich> that seems odd
[03:31:17] <jmkasunich> huh, I wonder why I put that in there
[03:31:26] <jmkasunich> probably thought I needed it
[03:31:50] <jmkasunich> but it looks like I copy all the needed pieces out of config space to the main upci_dev_info struct
[03:32:17] <jmkasunich> only ss_vendor_id and ss_device_id
[03:32:17] <seb_kuzminsky> right
[03:32:42] <seb_kuzminsky> ok, 3) now looks like this:
[03:32:50] <seb_kuzminsky> pull cfg_info out of dev_info
[03:33:03] <seb_kuzminsky> add functions to read & write cfg registers (similar to libpci's)
[03:33:08] <seb_kuzminsky> PROFIT!!1!
[03:33:14] <jmkasunich> heh
[03:33:34] <seb_kuzminsky> wanna thumb wrestle for the work? ;-)
[03:34:08] <jmkasunich> the main diff between libpci's functs are that I'd use devnum to refer to the device, instead of struct pci_dev or bus/dev/func
[03:34:27] <seb_kuzminsky> brb
[03:35:10] <jmkasunich> does the winner of the thumb wrestle match get to do the work, or get to see someone else do it?
[03:35:45] <jmkasunich> it's 11:35 here, and I have plans tomorrow evening
[03:36:30] <seb_kuzminsky> winner gets to choose who does the work
[03:36:39] <seb_kuzminsky> j/k, i'll do it
[03:36:48] <jmkasunich> thanks ;-)
[03:37:06] <seb_kuzminsky> maybe later this week or next week sometime
[03:38:37] <jmkasunich> I assume that the write functions will require being root or setuid root
[03:38:44] <jmkasunich> (bfload is the latter IIRC)
[03:38:53] <seb_kuzminsky> yes and yes
[03:39:30] <seb_kuzminsky> ok jmk thanks for your advise
[03:39:36] <seb_kuzminsky> have a good night :-)
[03:39:40] <jmkasunich> you're welcome
[03:39:48] <jmkasunich> thanks for doing the hard part
[03:40:30] <seb_kuzminsky> meh, good code is easier than good design
[03:40:59] <seb_kuzminsky> on a totally different topic (if you're not too sleepy), i'm thinking of asking the coverity folks to run their static checker on emc2
[03:41:31] <jmkasunich> I don't see anything wrong with that
[03:42:01] <seb_kuzminsky> swp said it was discussed and rejected some time ago
[03:42:26] <jmkasunich> long enough ago that I have only a vague memory of it
[03:42:45] <jmkasunich> I would suspect that we'll get a long list of stuff, 99.9% of which is false alarms
[03:43:05] <jmkasunich> (because we do kernel stuff, or any number of other things)
[03:43:08] <seb_kuzminsky> we just started using coverity at work, their false positives are way down
[03:43:14] <seb_kuzminsky> they cut their teeth on the linux kernel
[03:43:33] <seb_kuzminsky> but yeah, emc2 with rtai & nml is pretty funky, who know how well it'll work
[03:43:38] <seb_kuzminsky> maybe just sim for starters
[03:43:47] <jmkasunich> I don't really know enough about coverity to intelligently discuss it
[03:44:00] <seb_kuzminsky> i'll try it and see how it goes
[03:44:01] <jmkasunich> but I certainly have no objection to letting them look at it
[03:44:09] <seb_kuzminsky> ok good :-)
[03:48:19] <jmkasunich> time to walk the dog and then sleep
[03:48:21] <jmkasunich> goodnight
[03:48:31] <seb_kuzminsky> good night
[13:27:22] <cradek> jepler: your changing the splash screen on the mazak got me thinking. AXIS could remember what file was loaded last and reload that.
[13:35:12] <jepler> cradek: yeah I suppose it could
[13:35:29] <jepler> I have also been thinking about a "recent" menu; many programs have that.
[13:38:54] <cradek> that would be cool too.
[14:35:42] <rayh> cradek, got a clue about a file named axis_big_dro that is mentioned in the wiki?
[14:37:20] <cradek> % locate big_dro
[14:37:20] <cradek> /usr/local/src/emc2.trunk/src/emc/usr_intf/axis/etc/axis_big_dro
[14:37:39] <cradek> are you asking where to get it, or what it is, or something else?
[14:38:33] <cradek> (looks like it's in cvs but not in the deb)
[14:41:01] <rayh> Someone on cnczone suggested it might be used for large lettering when using the axis display.
[14:42:18] <cradek> yes I think that's its purpose
[14:42:46] <rayh> Okay. Thanks.
[14:43:41] <jepler> I suspect that may be out of date
[14:43:49] <jepler> *Togl.font: -*-courier-bold-r-*-*-25-*-*-*-*-*-*-*
[14:43:58] <jepler> this is the setting I have: ^^
[14:44:35] <jepler> or maybe either one works
[14:48:23] <cradek> this is what I get when I use that file as-is:
http://timeguy.com/cradek-files/emc/big-allright.jpg
[14:48:44] <jepler> maybe that's a bit too big
[14:49:06] <cradek> possibly.
[14:49:23] <rayh> okay.
[14:54:01] <rayh> How do you ask axis to use such a file?
[14:54:26] <cradek> xrdb -merge thefile
[14:56:18] <rayh> thanks
[15:05:11] <fenn> i was hoping to do some kind of contrast overlay mode so you could see the toolpath preview through the lettering
[15:06:22] <seb_kuzminsky> jmkasunich: are you here?
[15:06:36] <cradek> he's almost never here in the daytime
[15:06:43] <seb_kuzminsky> whatta slacker....
[15:10:31] <BigJohnT> cradek: did you figure out the limits warning?
[15:11:35] <BigJohnT> I went out to my shop last night and didn't get the warning anymore since the last time I upgraded
[15:11:54] <cradek> BigJohnT: I found a minimal program that reproduces the problem and attached it to the bug report.
[15:12:18] <BigJohnT> I saw that but didn't have time to try it...
[16:41:22] <dmwaters> {global notice} Good day all, In a few minutes I'm going to be rebooting one of our main us hubs. This will mean some splitting, but things should come back together rather quickly. Thank you for your patience, and thank you for using freenode!
[18:07:42] <jepler> hm here's an interesting bug: in mdi with the machine far from the toolchange position, program t1m6, then before it reaches the toolchange position program t2m6. You get a pop-up: Queue is not empty after tool change
[18:09:37] <cradek> interesting
[18:10:02] <cradek> that queue check is before the interp resetting by reading the position - wherever the tool change leaves it
[18:10:31] <cradek> resynching, not resetting
[18:39:36] <alex_joni> jepler: whee.. thank you soo much :)
[18:40:12] <jepler> alex_joni: yeah yeah
[18:40:33] <cradek> ?
[18:40:35] <alex_joni> I mean it ;)
[18:40:40] <alex_joni> cradek: stl support in vismach
[18:40:56] <jepler> now I want to see you use it for something good
[18:41:05] <cradek> I thought you meant the task bug report!
[18:41:10] <alex_joni> hmm.. I might just do
[18:43:41] <cradek> Issuing EMC_TOOL_LOAD -- (+1105,+12, +0,)
[18:43:41] <cradek> Issuing EMC_TRAJ_SET_OFFSET -- (+223,+84, +0,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,)
[18:43:44] <cradek> Issuing EMC_TASK_PLAN_SYNCH -- (+516,+12, +0,)
[18:43:48] <cradek> ^^ get warning
[18:43:56] <cradek> Issuing EMC_TOOL_LOAD -- (+1105,+12, +0,)
[18:43:56] <cradek> Issuing EMC_TASK_PLAN_SYNCH -- (+516,+12, +0,)
[18:43:56] <cradek> Issuing EMC_TRAJ_SET_OFFSET -- (+223,+84, +0,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,)
[18:43:59] <cradek> ^^ no warning
[18:44:28] <cradek> jepler: you are right, splitting the line changes the order of those messages
[18:44:44] <jepler> cradek: interesting! I wonder what that means for the bug ..
[18:46:50] <cradek> if I knew what TASK_PLAN_SYNCH is supposed to do ...
[18:47:12] <jepler> we're talking about a gcode like this, right? T1M6G43H1
[18:47:22] <cradek> yes
[18:47:30] <cradek> http://sourceforge.net/tracker/index.php?func=detail&aid=2000329&group_id=6744&atid=106744
[18:47:41] <alex_joni> cradek: synch is supposed to sync task with canon
[18:47:45] <jepler> rs274 prints the same thing whether it's split or not
[18:47:46] <jepler> READ => T1M6G43H1
[18:47:46] <jepler> 4 N..... SELECT_TOOL(1)
[18:47:46] <jepler> 5 N..... STOP_SPINDLE_TURNING()
[18:47:46] <jepler> 6 N..... CHANGE_TOOL(1)
[18:47:47] <alex_joni> but don't ask me what exactly that means
[18:47:48] <jepler> 7 N..... USE_TOOL_LENGTH_OFFSET(0.0000 12.7000 0.0000)
[18:47:50] <jepler> READ => T1M6
[18:47:53] <jepler> 8 N..... SELECT_TOOL(1)
[18:47:55] <jepler> 9 N..... STOP_SPINDLE_TURNING()
[18:47:58] <jepler> 10 N..... CHANGE_TOOL(1)
[18:48:00] <jepler> READ => G43H1
[18:48:03] <jepler> 11 N..... USE_TOOL_LENGTH_OFFSET(0.0000 12.7000 0.0000)
[18:48:24] <alex_joni> how about G43H1T1M6 ?
[18:48:33] <cradek> that's good because the one-line and two-line versions should be the same.
[18:48:39] <cradek> M codes on a line run before G codes
[18:48:59] <jepler> yeah, order on the line does not affect the meaning of gcode
[18:51:00] <alex_joni> ok, that's good I think
[18:54:18] <jepler> $ rs274 -t tool.tbl -v emc.var -g <(echo T1M6G43H1; echo M2)
[18:54:21] <jepler> $ rs274 -t tool.tbl -v emc.var -g <(echo T1M6; echo G43H1; echo M2)
[18:54:29] <jepler> weird, I don't see a USE_TOOL_LENGTH_OFFSET in the output of the first one
[18:58:47] <skunkworks_> wait - ken was at the fest?
[18:59:14] <cradek> yes unfortunately he left the same day you came
[18:59:40] <skunkworks_> aw
[18:59:48] <skunkworks_> have you met him before?
[18:59:58] <cradek> nope, just last week
[19:00:17] <alex_joni> aww.. running out of battery :/
[19:00:21] <alex_joni> see you guys tomorrow evening
[19:01:14] <jepler> see you alex_joni
[19:01:17] <jepler> but you didn't fix task yet!
[19:01:26] <alex_joni> yeah.. well.. task stayed home
[20:10:12] <cradek> well I failed to find the right place to stick an emcTaskPlanSynch(whatever)
[20:10:24] <cradek> even so, I'm not sure if that would fix it or not.
[21:00:26] <jepler> seb_kuzminsky: sure
[21:00:31] <seb_kuzminsky> great!
[21:00:50] <seb_kuzminsky> i've been thinking about upci vs libpci, neither is what's needed
[21:00:59] <seb_kuzminsky> but libpciaccess does everything i need
[21:01:12] <seb_kuzminsky> it's from x.org
[21:01:41] <jepler> I notice it's not packaged for ubuntu 6.
[21:01:48] <seb_kuzminsky> it's in hardy but i'm not sure if the gutsy has it - ah ok
[21:01:59] <jepler> 6.06 that is
[21:02:07] <seb_kuzminsky> so we'd have to include a version in emc2, at least until our supported distros caught up...
[21:02:11] <seb_kuzminsky> how does that make you feel?
[21:02:46] <seb_kuzminsky> we already do include a pci access library, it's just homegrown and partial: upci
[21:03:10] <seb_kuzminsky> seems better to use something more widely used
[21:03:24] <jepler> the installed-size of libpciaccess0 is pretty small
[21:03:28] <jepler> I'm checking whether it trivially builds on 6.06
[21:03:48] <seb_kuzminsky> cool
[21:04:03] <seb_kuzminsky> the source is ~240 KB
[21:04:03] <jepler> here's the wrinkle that I see: up to now we have never required an additional package for a minor-version update
[21:04:18] <seb_kuzminsky> yes...
[21:04:27] <jepler> so for 2.2.x I'd say do anything but that (forcing the user to type 'setpci' even)
[21:04:42] <seb_kuzminsky> if we include it for gutsy, we could use it for hardy too and avoid the explicit outside dependency
[21:04:54] <jepler> for 2.3, that sounds fine
[21:04:55] <seb_kuzminsky> forcing the user to type setpci implies a dependency on pciutils
[21:05:36] <jepler> that's not installed on a standard ubuntu desktop machine? I have it and don't recall installing it.
[21:05:40] <jepler> (but who knows)
[21:06:17] <seb_kuzminsky> in hardy, ubuntu-minimal depends on it
[21:06:20] <seb_kuzminsky> not sure about gutsy etc
[21:06:43] <jepler> yes, on dapper too
[21:06:52] <jepler> (don't care about gutsy)
[21:06:58] <seb_kuzminsky> right
[21:08:21] <skunkworks_> woo whoo I found the pumagui.py and visimach.py. (yes it took me a bit)
[21:08:25] <seb_kuzminsky> ok, so libpciaccess is ok for 2.3, but 2.2 is restricted to pciutils (& could even use libpci, gross as that is)
[21:10:13] <seb_kuzminsky> thanks jeff, i'll clear it with jmk too before changing anything
[21:10:22] <jepler> yes, unless somebody else has concerns about that
[21:10:34] <seb_kuzminsky> sure
[21:23:10] <micges> jepler: If I remember correctly the same bug (about queue) is while doing g38.2 probe from MDI and while moving enter another MDI command
[21:24:06] <micges> (I saw this only twice long time ago)
[21:37:50] <micges> error is: Queue is not empty after probing
[23:08:35] <BigJohnT> cradek: did you find out what the problem is with me getting a developer checkout?
