Back
[00:24:45] <skunkworks> Congrats everyone!
[00:25:33] <skunkworks> Does this mean I need to supply the donuts?
[00:28:44] <skunkworks> (being the lowest common demonimator?)
[00:29:19] <SWPadnos> yes
[00:29:26] <skunkworks> ;)
[00:29:29] <SWPadnos> coffee should be provided by BigjohnT
[00:29:32] <SWPadnos> :)
[01:22:16] <jepler> skunkworksemc: thank you
[01:24:52] <skunkworks> :)
[01:40:53] <cradek> holy crap, all the same people!?
[01:41:57] <cradek> skunkworks: thanks, I think you would have been a good choice too.
[01:42:49] <skunkworks> eh - bigjohn has done a ton more than me...
[01:43:00] <skunkworks> I am more of a jester..
[01:43:16] <skunkworks> :)
[01:43:25] <cradek> there were no bad choices, only good
[01:43:43] <cradek> I lost no sleep about it.
[01:48:26] <skunkworks> The board is strong. this last year was very exciting.
[11:45:40] <christel> [Global Notice] Hi all, I'm going to need to take down services (Nick,Chan,MemoServ etc) for a few moments to apply a tiny little fix. It shouldn't take more than a couple of minutes and I'll let you know when they're back up again. Apologies for the inconvenience and have a good day!
[11:49:57] <christel> [Global Notice] Hi all, as promised I return services to you, I'm all done and they're nearly as new! Have a good day and thank you for using freenode.
[12:45:45] <alex_joni> morning BigJohnT
[12:46:15] <BigJohnT> morning alex_joni
[12:52:15] <alex_joni> doing a full rebuild of the linux-image packages takes quite a while
[13:18:22] <alex_joni> real 134m45.876s
[13:18:22] <alex_joni> user 399m1.520s
[13:18:22] <alex_joni> sys 65m56.510s
[13:44:07] <skunkworks_> paul is a really good instigator.. Is that something you are born with? Some sort of class? (at least he tries to be)
[13:46:52] <skunkworks_> Good Morning! :)
[13:52:36] <cradek> hi skunkworks_
[13:52:41] <cradek> I'm sure it's a gift
[13:53:09] <skunkworks_> heh
[13:55:17] <cradek> I just verified that his email is in the list the board sent to michael. if that is his accusation (he doesn't say what it is, actually) he is wrong. but, maybe he has a much larger conspiracy in mind.
[13:55:42] <skunkworks_> I am sure.
[13:56:34] <skunkworks_> what other list would there be? I just don't understand.
[13:57:02] <skunkworks_> are you supposed to get every users email also?
[13:57:05] <skunkworks_> ;)
[13:57:06] <cradek> I won't guess what his conspiracy theory is. who knows.
[13:58:07] <jepler> I dunno, but here's what not to do if you have something constructive to contribue to make the emc board election better and more fair. 1: read announcement of nominations and say nothing. 2: read announcement that ballots have been sent and say nothing. 3: read announcement of results, and scream bloody murder
[13:58:28] <cradek> (I'm hope michael doesn't have to deal with him)
[13:59:24] <cradek> jepler: but coincidentally and surprisingly, that's just what you might choose to do if you're a troll trying to spread FUD around!
[14:02:03] <alex_joni> logger_dev: bookmark
[14:02:03] <alex_joni> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-02-05.txt
[14:07:03] <The_Ball> is there a display that is suitable for a touch screen display (800x600). I haven't tried tkemc yet but that looks the part
[14:12:54] <skunkworks_> cradek: now that there is a tab for dro in axis - maybe a tab for a keyboard? ;)
[14:13:26] <skunkworks_> "Slippery Slope" ;)
[14:14:34] <skunkworks_> and a web browser...
[14:18:51] <The_Ball> skunkworks, like your thinking
[14:37:23] <cradek> skunkworks_: don't be ridiculous
[14:55:27] <skunkworks_> heh ;)
[14:59:39] <cradek> the way the BOSS does mdi with a limited (numeric only) keypad is kind of clever
[14:59:52] <cradek> it says G? and you type 01 enter
[15:00:12] <cradek> then it knows G01 takes X,Y,Z,F and prompts you for each one (you can leave them blank if you don't want that word specified)
[15:00:39] <cradek> then, once through all the letters, you can review the command and press execute
[15:01:04] <cradek> so you really don't need a full keyboard
[15:01:38] <cradek> if I wanted a touchscreen only gui I'd try something similar to that. I think you couldn't have a full keyboard on a touchscreen.
[15:01:55] <cradek> (they work bad enough for just a few buttons)
[15:03:03] <skunkworks_> our fanuc has a numeric keypad with letters. so you first press the key with the letter you want - then it turns to a number pad
[15:10:22] <pcw> Big John - minor manual typo ini_config.lyx line 2277: mm should be inches
[15:17:10] <BigJohnT> ok pcw
[15:19:16] <BigJohnT> pcw: can you give me a couple of words of text from that line?
[15:20:09] <pcw> desired units of mm
[15:20:44] <BigJohnT> and 10 revs/inch gearing, and desired units of mm, we have
[15:21:11] <BigJohnT> thanks pcw
[15:21:49] <BigJohnT> hmmm it is in there twice
[15:36:14] <pcw> heres another in the same file: units on the I gain are volts per machine unit per second
[15:36:15] <pcw> should be something like : units of I gain are volts per machine unit second
[15:39:19] <BigJohnT> the first one sounds right to me... but I'm not sure that I don't know everything I don't know about that yet :)
[15:40:31] <pcw> the formula is right but not the words in the I section (the "per" is wrong)
[15:41:10] <BigJohnT> ok
[15:41:45] <pcw> * compare with "D"
[15:41:58] <cradek> I was reading a patent last night and everything that should have been expressed in formula was spelled out in sentences. it made it very hard to understand. if we can display the formula, maybe just remove the words.
[15:42:14] <SWPadnos> BigJohnT, the I term is multiplied by the integral of machine units of error over time, so the resulting unit (of the integration) is machine units * seconds
[15:42:39] <SWPadnos> and since the result of multiplying by IGain is volts, IGain has to be "volts / (machine units * seconds)
[15:42:51] <SWPadnos> most people just call it I though :)
[15:45:23] <BigJohnT> ok
[15:46:50] <jepler> start of a program to convert the output of "rs274" back into gcode--a possible basis for gcode preprocessors that correctly understand all gcode syntax:
http://emergent.unpy.net/files/sandbox/unsai.py
[15:46:58] <jepler> doesn't do much yet, but it does do G0 and G1 moves
[15:49:18] <cradek> neat!
[15:50:05] <SWPadnos> I can see people liking rotatecnc and flipcnc from that ncutils dir
[15:50:12] <SWPadnos> and shift, for that matter
[15:51:01] <cradek> a rewrite of them in jepler's style would be so much better. ad-hoc parsing of gcode with strstr() is a bad way to approach the problem.
[15:51:36] <SWPadnos> oh, for sure
[15:51:37] <cradek> although, even jepler's style will unroll loops and subroutines for instance
[15:51:45] <jepler> every approach stinks
[15:51:52] <cradek> (but, it'll actually work)
[15:52:01] <jepler> they just have different, interesting smells
[15:52:08] <cradek> true true
[15:52:40] <SWPadnos> heh
[15:52:49] <SWPadnos> sniff sniff ... ancient brie
[15:52:53] <cradek> shift? wtf?
[15:54:18] <SWPadnos> man. dealing with all legal g-code is really a mind boggling problem (unless you don't mind screwing up the original text)
[15:54:42] <fenn> affinematrixcnc
[15:54:49] <cradek> it's not a hard problem if you just use the interpreter
[15:54:57] <SWPadnos> oh, there's an idea
[15:55:06] <cradek> that's what jeff just did
[15:55:19] <SWPadnos> just the fact that you can have spaces anywhere is an issue
[15:55:49] <SWPadnos> for regexp things anyway
[15:56:15] <SWPadnos> so, here's a cron question
[15:56:15] <cradek> http://www.codinghorror.com/blog/archives/001016.html
[15:56:58] <SWPadnos> it looks like the way to make a program "stay running" is to set it up as a * * * * * cron job, and have the program (script) itself check to see if it's already active
[15:57:15] <cradek> yeah I wish there was a good way to do that
[15:57:30] <SWPadnos> is there a way to have cron monitor processes and keep them running (or some other program, similar to the way init does things)
[15:57:57] <cradek> I wish cron had "if this program is still running, it's an error" and "if this program is still running, just do nothing"
[15:58:08] <SWPadnos> yep, that would be nice
[15:58:09] <cradek> not that I know.
[15:58:10] <jepler> tempting: if [ -z "`pidof program`" ]; then program --args &; fi
[15:58:28] <SWPadnos> yep. that's what I've been looking at
[15:58:28] <cradek> yeah, that's all there is to it, but ick
[15:58:41] <SWPadnos> probably in the script, but maybe in the crontab
[15:58:53] <jepler> cradek: his regular expression is wrong
[15:59:07] <cradek> pidof is not smart enough to return only your own processes
[15:59:08] <jepler> cradek: it will permit stuff inside <a> tags that shouldn't be
[15:59:27] <cradek> pgrep -u is smart enough
[15:59:32] <jepler> a "-u" option to pidof would be obvious
[15:59:47] <cradek> yep
[16:01:24] <jepler> if ! pgrep -u myuid program; then program -- args &; fi
[16:05:20] <jepler> (ah, in the "full program" he has additional checking of <a> tags that is not in the basic regular expression he showed there)
[16:06:43] <fenn> http://linuxcnc.org/docs/ should have a link to 2.3
[16:07:35] <cradek> they are still /devel until we branch
[16:08:09] <fenn> oh
[16:13:41] <SWPadnos> hey pcw, have you ever considered replacing the power connectors on your daughtercards with a pair of screw terminals?
[16:13:55] <BigJohnT> fenn: the bottom link is to 2.3
[16:14:59] <pcw> SWP: Yes, the -TA series have screw terminal power conns (and all terminal blocks included)
[16:15:42] <pcw> (and wider spacing of TBS so you can actually pull then TBs off without being a tough-guy)
[16:17:19] <SWPadnos> ok, cool
[16:28:55] <seb_kuzminsky> good morning guys
[16:29:03] <SWPadnos> hiya
[16:31:55] <cradek> hi seb
[16:33:05] <cradek> pcw: neat - the only complaint I had about using the -T boards was I had to pull the strip off to access the screws. is the TA the same or is it a different kind of screw?
[16:33:26] <BigJohnT> hi seb
[16:34:11] <SWPadnos> cradek, you can use shorter terminal blocks, but you need to be careful plugging them in
[16:34:15] <pcw> The TA use top screw/side entry plugs
[16:34:35] <cradek> pcw: perfect, I will get those next time
[16:34:53] <pcw> (also plugs are 3x8 so are easier to pull off)
[16:35:06] <cradek> one of these days I will retrofit the mill...
[16:35:24] <cradek> if only it would croak I'd do it now
[16:35:35] <SWPadnos> * SWPadnos chants "angled socket for the outer connector"
[16:37:17] <pcw> SWP: We had to buy a gazilion of the plugs so they are unlikely to change
[16:37:23] <SWPadnos> heh
[16:37:55] <SWPadnos> the plugs would be the same, it's the board-mount sockets I'm chanting about
[16:38:19] <cradek> pcw: will the base 5i20 be available for a while? It's enough for me and I like how it's so much cheaper
[16:38:31] <SWPadnos> the 5i22 isn't much more
[16:38:35] <SWPadnos> err, 5i23
[16:39:03] <pcw> We have no plans on obsoleting the 5I20
[16:39:04] <SWPadnos> $229 instead of $199, 400k gate FPGA, 3 connectors
[16:39:05] <pcw> many non-EMC customers
[16:39:11] <cradek> oh, ok
[16:39:20] <cradek> huh, I thought the 5i20 was MUCH cheaper than that
[16:39:43] <SWPadnos> the 5i23 is the expensive one, $369 or $429 depending on FPGA sice (1M and 1.5M gates)
[16:39:50] <SWPadnos> s/sice/size/
[16:40:07] <cradek> you mean 22
[16:40:12] <SWPadnos> yes, yes I do
[16:40:33] <cradek> another plug is nice, but I won't need it on the mill
[16:40:42] <SWPadnos> operator panel :)
[16:40:46] <jepler> cradek: lots less 'misc stuff' than the lathe
[16:40:47] <jepler> ?
[16:40:54] <cradek> jepler: yeah, lots less
[16:41:03] <cradek> it's really quite simple in comparison
[16:41:21] <SWPadnos> which is funny, considering that it has an extra servo and all
[16:41:35] <SWPadnos> and limit/home switches ...
[16:41:35] <cradek> one limit switch and one home switch per axis
[16:41:44] <SWPadnos> ok, home is -limit?
[16:42:00] <cradek> no, both limits are one switch
[16:42:06] <SWPadnos> oh, right - there's a cam doohicky that hits the same switch at either end
[16:42:09] <cradek> right
[16:42:39] <pcw> We _may_ have cheaper (no bridge) PCI and PCIE cards this year if I get a round to-it
[16:42:41] <pcw> plus some 2m gate 144 I/O cards
[16:42:53] <SWPadnos> hmmmmm
[16:43:07] <SWPadnos> config EEPROM on the cards, I presume?
[16:43:20] <pcw> Yes
[16:43:44] <cradek> I have no complaint about your prices - the stuff works great for me. if you fixed the screw problem, that's icing on the cake.
[16:43:49] <SWPadnos> that will be cool
[16:44:12] <BigJohnT> while your here pcw what is the P1 plug on the 7i31?
[16:44:22] <pcw> PCIe version will use PCIe-PCI bridge with 4 GPIO bits so it can be bootstrapped
[16:44:30] <SWPadnos> power
[16:44:39] <SWPadnos> don't connnect a floppy power cable to it :)
[16:45:09] <BigJohnT> :)
[16:45:21] <SWPadnos> unless you first remove the 12V wire
[16:45:40] <SWPadnos> and make sure the 5i20 is configured for 5V
[16:46:15] <pcw> No its our pre 3.5" floppy power connector weve used for 15+ years
[16:46:17] <pcw> 1 +5
[16:46:18] <pcw> 2 GND
[16:46:20] <pcw> 3 GND
[16:46:21] <pcw> 4 +5
[16:46:23] <pcw> connect floppy power = asplode PC
[16:46:39] <BigJohnT> have you let the magic smoke out of one SWPadnos ?
[16:46:42] <SWPadnos> no
[16:46:49] <pcw> Slowly removing it from everthing
[16:46:51] <SWPadnos> I noticed it before plugging anything in :)
[16:47:39] <SWPadnos> I just had the thought of making a little power supply board that plugs into your connector, and takes maybe 9-36V in via screw terminals
[16:48:58] <pcw> Normally they aux power connector are not needed
[16:48:59] <pcw> Only when you can supply enough power for encoders etc through the flat cable
[16:49:12] <BigJohnT> ok, thanks
[16:49:32] <pcw> We should probably just remove it from the 7I31
[16:50:05] <SWPadnos> yeah, the anyIO or daughtercard would need power, not the 7i31
[16:50:42] <pcw> * copy&paste PCB error
[16:50:46] <SWPadnos> though adding the 7i31 could make the total draw too high to run the "card under test", so having it on the 7i31 allows you to do a slightly less invasive test
[16:50:47] <SWPadnos> heh
[16:51:30] <SWPadnos> incidentally, the second 50-pin header might be nice on some of the other cards as well
[16:52:09] <SWPadnos> using the 7i33 for example, if I want to use only 3 servo axes and the rest for GPIO, it's a real pain to break out the few pins needed
[16:52:54] <cradek> SWPadnos: just add another IDC to the cable...?
[16:53:13] <SWPadnos> sure, that's an option
[16:53:14] <cradek> seems better than making the board bigger and more expensive
[16:53:19] <pcw> Yeah its usually a space issue
[16:53:37] <SWPadnos> but you probably need to cut and/or move some wires around
[16:55:06] <pcw> I'd just split the cable before terminating the 7I33 end 50 pin receptacle
[16:55:35] <SWPadnos> I guess it's a PITA no matter how you s(p)lice it :)
[16:56:21] <pcw> yeah, its where the flexibility of the FPGA I/O ends
[16:56:27] <SWPadnos> heh
[16:58:35] <pcw> Sebastian?
[16:58:37] <pcw> What do you think of the idea of some module IDs being "hints"
[16:58:38] <pcw> that a certain range of I/O pins are preconfigured for a certain type
[16:58:40] <pcw> of daughter card?
[17:00:05] <SWPadnos> loadrt ... p1=7i31 p2=7i33
[17:01:22] <cradek> I think a dedicated person could set up the equivalent of this using only hal aliases
[17:01:52] <SWPadnos> that's true once the pins have been created
[17:01:52] <cradek> it would keep the complexity out of the driver (whether that's good or bad I can't say)
[17:02:49] <pcw> Well i was thinking an i/o pin range as being more generic
[17:02:51] <pcw> this is mainly for complicated cards (say 7I65) that have very specific
[17:02:52] <pcw> requirements (BSPI on some pins MuxedEncoder on others etc)
[17:03:44] <cradek> ah, you have more in mind than I do. I was thinking about how people using the old 5i20 driver are going to have a hard time updating to hm2 because the pin names are much more obscure
[17:05:19] <SWPadnos> too bad sed can't do math (?)
[17:05:20] <pcw> Yeah, at least dropping the P? is a good thing for hostmot2 card-card config file compatibility
[17:05:20] <jepler> a "5i20_compat.hal" file using alias might be a nice contribution
[17:05:54] <jepler> load hm2_pci with 4 encoder+pwm and alias everything to hal_m5i20 naming
[17:06:33] <SWPadnos> how does the older naming work?
[17:06:50] <pcw> Yes, that would be a good starting point for someone upgrading
[17:06:56] <SWPadnos> I know the connector number is in there, is the other number the pin or the "consecutive GPIO" number?
[17:07:27] <cradek> old naming is directly the screws on the 7i3x cards
[17:07:29] <jepler> SWPadnos: I dunno, and you can look at the hal file as easily as me
[17:07:31] <cradek> it assumes which cards you have
[17:07:52] <SWPadnos> oh right, 1 servo card, 2 GPIO cards
[17:07:56] <cradek> right
[17:08:07] <cradek> it's very simple
[17:34:34] <seb_kuzminsky> pcw: my initial reaction is opposed... it seems to me to build too much deployment-specific information into the firmware
[17:35:12] <seb_kuzminsky> it seems better to get that information from the user and supply it to the driver somehow (i dont know exactly how though)
[17:35:44] <SWPadnos> seb_kuzminsky, I don't know if you saw the conversations with motioncontrol in the last couple of days
[17:35:58] <SWPadnos> the problem he thought he had wasn't there
[17:36:05] <seb_kuzminsky> i didnt see it
[17:36:11] <SWPadnos> oh
[17:36:18] <seb_kuzminsky> was it here on #emc-devel?
[17:36:21] <SWPadnos> using two cards, the second one wasn't seen
[17:36:27] <SWPadnos> no, #emc
[17:36:47] <seb_kuzminsky> but then it turned out to not be a problem after all and the second card appeared?
[17:36:53] <SWPadnos> yes, but ...
[17:37:23] <SWPadnos> the config string is supposed to be an array of strings, but I didn't see how that happens
[17:37:51] <SWPadnos> and there were times when I loaded the driver, got no error messages or anything, and had no HAL objects exported
[17:38:18] <seb_kuzminsky> hm that sounds strange
[17:38:37] <SWPadnos> yeah. I don't recall what was in dmesg
[17:38:44] <seb_kuzminsky> here's an example of how the config argument to the hm2_foo drivers is an array of strings:
[17:38:46] <seb_kuzminsky> http://highlab.com/~seb/lots-of-pins
[17:39:00] <SWPadnos> I'll look at it more, but just mull over what could be wrong in config line parsing
[17:39:06] <seb_kuzminsky> not sure if that works so well when there's spaces in the per-array-entry strings...
[17:39:39] <SWPadnos> right, I thought spaces could be (part of) the problem
[17:39:47] <alex_joni> seb_kuzminsky: what happens if you chenge the board order?
[17:40:01] <seb_kuzminsky> then you have to change the order of the config strings to match
[17:40:07] <SWPadnos> in the end, using config="firmware ... num_encoders=4 ...,firmware=... blah blah" worked
[17:40:24] <seb_kuzminsky> hm2_5i20.0 is the first one handed to the driver by the linux hotplug system, hm2_5i20.1 is the second one etc
[17:40:25] <alex_joni> so how do I know what the card order is?
[17:40:28] <SWPadnos> with or without a space after the comma
[17:40:50] <alex_joni> in your example there's a 5i20, 5i22, and 4i68
[17:40:55] <seb_kuzminsky> the driver detects and numbers different anyio boards separately, so if you have one 5i20 and one 5i23, it's always hm2_5i20.0 and hm2_5i23.0
[17:41:12] <seb_kuzminsky> but the first one found gets the first config string etc
[17:41:14] <alex_joni> say I have a 5i20 and a 5i23
[17:41:26] <alex_joni> and I want to load them both with hal_pci
[17:41:38] <alex_joni> do I supply the 5i20 firmware first or the 5i23?
[17:41:46] <seb_kuzminsky> alex_joni: it depends :-(
[17:42:00] <seb_kuzminsky> on what order the kernel hotplug wants to give them to you in
[17:42:01] <alex_joni> I know it does, the question was more like.. how do I find out?
[17:42:16] <alex_joni> just try & mix and match till it works?
[17:42:22] <seb_kuzminsky> i dont know a better way than "try it one way and if it doesnt work try it the other"
[17:42:37] <alex_joni> ok, that answers my question :)
[17:43:02] <alex_joni> maybe starting up without any firmwares could show a list of probed boards
[17:43:11] <seb_kuzminsky> i *think* the hotplug system is repeatable in the order it gives boards to drivers (same each time it loads), but i dont know how to predict the order apriori
[17:43:13] <alex_joni> or something like that
[17:43:42] <SWPadnos> the driver prints a lot of stuff, maybe if "config" is blank, it should print a board list
[17:43:53] <seb_kuzminsky> alex_joni: currently starting without firmware makes the driver assume the boards already have firmwares and it tries to initialize them
[17:44:03] <SWPadnos> hm2_pci: found board 0: 5i23-1.5
[17:44:10] <SWPadnos> hm2_pci: found board 1: 5i20
[17:44:15] <seb_kuzminsky> s/22/23/
[17:44:26] <alex_joni> he always mixes those
[17:44:28] <SWPadnos> s/23/22/ :)
[17:44:39] <alex_joni> good thing he has a couple of each?
[17:44:39] <seb_kuzminsky> s/s/22/23//s/23/22//
[17:45:03] <alex_joni> s/\([b-p]\)\(|\{0,1\}\)\([0-9x]\)a\(|\{0,1\}\)\([0-9x]\)\([b-p]\)/\1\2\3\6\4\5a/g
[17:45:36] <seb_kuzminsky> at driver load time, it currently already lists all boards it finds, and what name it gives each one
[17:45:36] <SWPadnos> s!22/23!23/22!
[17:45:49] <seb_kuzminsky> that's independent of whether the board(s) actually successfully initialize or not
[17:46:02] <alex_joni> seb_kuzminsky: ah, right.. than that should be enough
[17:46:05] <SWPadnos> ok. the dmesg is long, so I don't see it all ;)
[17:46:06] <seb_kuzminsky> so we sort of already get that info, though not in the most convenient format
[17:46:14] <alex_joni> simply run loadrt hal_pci, and then you get the info
[17:46:23] <seb_kuzminsky> right :-/
[17:46:27] <alex_joni> that's what humans are for, parsing and interpreting
[17:46:36] <alex_joni> I'm happy with that
[17:46:52] <seb_kuzminsky> yay :-D
[17:47:04] <seb_kuzminsky> ok wait there were some bug reports up in my irc buffer
[17:47:06] <alex_joni> seb_kuzminsky: I only have one 5i20 on a shelf
[17:47:06] <seb_kuzminsky> * seb_kuzminsky reads back
[17:47:28] <alex_joni> so this is not an issue for me, but wanted to know in case users pop up in #emc
[17:47:47] <seb_kuzminsky> <SWPadnos>: and there were times when I loaded the driver, got no error messages or anything, and had no HAL objects exported
[17:47:47] <SWPadnos> ok, it does report what it finds, but only as the boards are configured and HAL objects exported
[17:48:32] <seb_kuzminsky> if a board is detected but fails to configure (because it doesnt have firmware and you didnt ask it to load some using config="firmware=foo.bit") it should be listed with a "failed to init"
[17:48:58] <SWPadnos> I think a concise list at the beginning would be good for determining board order
[17:49:08] <seb_kuzminsky> SWPadnos: that's not easy to do
[17:49:18] <seb_kuzminsky> at "the beginning" there are no boards
[17:49:25] <SWPadnos> right, you get "hotplug" events when the driver is loaded
[17:49:39] <seb_kuzminsky> then over time the board hotplug callback gets called zero or more times (^^ right)
[17:50:24] <SWPadnos> hmmm
[17:50:35] <seb_kuzminsky> i think i had the hm2_pci driver emit the pci address as well as the hm2 name it gave each board
[17:51:20] <SWPadnos> it prints the address at the start of initialization, and the name at the end
[17:51:29] <seb_kuzminsky> i'm more concerned about the report above about it failing to do anything at loadtime
[17:51:48] <seb_kuzminsky> it should enumerate all the anyio boards and say *something* about each one
[17:51:58] <SWPadnos> the name is only printed because the message is "hm2_5i20.0: initialized ..."
[17:52:00] <seb_kuzminsky> including the pci address, and whether or not it initialized it
[17:53:02] <seb_kuzminsky> i see on feb 1 motioncontrol got the encoder vel warning in 2.2.8
[17:53:29] <seb_kuzminsky> that's fixed in trunk
[17:54:02] <SWPadnos> hmmm. I wonder if the "nothing shows up" problem occurs when the board hasn't yet been programmed, and the firmware mane is unrecognized or something
[17:54:09] <SWPadnos> name
[17:54:30] <seb_kuzminsky> in that case it should say "found a board (at PCI addr foo) but failed to initialize it, no firmware??"
[17:55:10] <SWPadnos> yeah, and the component should fail to load, right?
[17:55:14] <seb_kuzminsky> no
[17:55:19] <SWPadnos> ah-ha
[17:55:27] <seb_kuzminsky> at that point its already loaded successfully
[17:55:35] <SWPadnos> right, since init is done by hotplug
[17:55:38] <seb_kuzminsky> yep
[17:55:44] <SWPadnos> ok, so that's probably the problem
[17:55:52] <SWPadnos> messages go to dmesg
[17:56:03] <SWPadnos> nothing is printed on the terminal
[17:56:08] <SWPadnos> the component loaded fine
[17:56:12] <seb_kuzminsky> that's awkward isnt it... :-(
[17:56:24] <SWPadnos> and no pins exist, so emc bombs later with errors about nonexistent pins / functions ...
[17:56:25] <SWPadnos> yes
[17:56:47] <seb_kuzminsky> new_pin("hm2_5i20.0.failed-to-init") ;-)
[17:56:53] <SWPadnos> heh
[17:57:14] <seb_kuzminsky> ok i found some stuff from motioncontrol on feb 3
[17:58:02] <SWPadnos> ideally, hal_ready shouldn't be called until all initialization has been done, including doing configuration of all specified cards
[17:58:18] <SWPadnos> but I don't know if that's even possible
[17:58:40] <seb_kuzminsky> i think it's possible, but i think it's working against the hotplug system rather than with it
[17:59:17] <SWPadnos> do you know if the driver will get hotplug events before it has finished "module_init"
[17:59:30] <SWPadnos> (after hotplug_register, but before "I'm done now")
[17:59:41] <seb_kuzminsky> i think it won't, but i'm not sure... hold on i'll check
[18:00:00] <SWPadnos> hotplug actually works against us
[18:00:28] <SWPadnos> we want a stable system, defined by our hal files
[18:00:38] <SWPadnos> not one that may change over time, as hardware is plugged/unplugged
[18:00:46] <SWPadnos> these are opposite goals
[18:01:10] <SWPadnos> the only common feature is that both EMC and hotplug want to be able to load firmware
[18:01:37] <seb_kuzminsky> firmware loading and hotplug are separate facilities in linux, you can have either one without the other
[18:01:46] <SWPadnos> yay! :)
[18:02:30] <SWPadnos> I thought the whole reason for using hotplug was to have access to request_firmware?
[18:03:22] <seb_kuzminsky> the reason for using hotplug is that that's what the kernel people are recommending these days for dealing with pci devices
[18:04:04] <SWPadnos> ah, ok
[18:04:29] <seb_kuzminsky> they're working on unifying all the pci-ish busses, and hotplug is the interface they chose for it
[18:05:02] <SWPadnos> sure, and there's also support for PCI hotplug, so it makes sense
[18:05:11] <seb_kuzminsky> exactly
[18:07:27] <SWPadnos> too bad it's the opposite of useful to us :)
[18:08:25] <SWPadnos> http://pastebin.ca/1328188
[18:08:34] <SWPadnos> lots-o-pins :)
[18:09:13] <seb_kuzminsky> :-)
[18:09:27] <pcw> Sebastian: I guess a command line hint would do as well but it would duplicate hardwired information in the FPGA config
[18:09:52] <SWPadnos> oh, I should have restricted that to hm2*
[18:10:43] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/hal/halmodule.cc: better support for assigning longs to hal pins. related to SF#2569072 but may not totally fix it.
[18:10:44] <SWPadnos> only 418 pins when I do that :)
[18:10:54] <seb_kuzminsky> what does the fpga know about the daughter boards? i thought nothing - if that's not true then my initial reaction is probably wrong
[18:11:14] <alex_joni> seb_kuzminsky: you didn't run halui :)
[18:11:23] <alex_joni> err.. SWPadnos
[18:11:37] <alex_joni> stupid tabcomplete doesn't read my mind..
[18:11:44] <seb_kuzminsky> one of those "s" guys anyway ;-)
[18:11:47] <SWPadnos> darned stupid tab complete
[18:12:05] <alex_joni> some days I wonder why it won't complete words I'm typing
[18:12:14] <alex_joni> like typ<tab>
[18:14:29] <pcw> Sebastian: It does implicitly because of pinouts, for more complicated daughtercards I think it
[18:14:30] <pcw> might be appropriate to know a little more (its just a hint and can be ignored)
[18:15:03] <seb_kuzminsky> SWPadnos: looks like maybe pci_get_device() can be made to iterate over all the currently connected devices, avoiding hotplug
[18:15:12] <pcw> (lots of free module IDs)
[18:16:03] <SWPadnos> seb_kuzminsky, ok. I wonder if it would keep the same order like hotplug is supposed to
[18:16:23] <SWPadnos> seems likely, since that's probably how hotplug gets the card info in the first place :)
[18:16:34] <seb_kuzminsky> SWPadnos: no idea, all the docs i've seen say "dont rely on the ordering"
[18:16:39] <SWPadnos> heh
[18:17:07] <seb_kuzminsky> pcw: is the 7i65 the impetus for this?
[18:17:10] <SWPadnos> pcw, any chance of sticking a serial number in the EEPROM on these cards?
[18:17:48] <seb_kuzminsky> and silkscreening the serial number on the board ;-)
[18:18:08] <SWPadnos> or making a utility to check/set/blink LEDS for a specific serial number (or PCI ID)
[18:19:08] <seb_kuzminsky> lol, morse code the sn out the leds
[18:19:39] <pcw> Yes mainly but also 7I48, though it can be mostly transparent
[18:19:40] <pcw> 7I65 does have an EEPROM (for A-D cal)
[18:19:56] <pcw> (AD- DA)
[18:21:45] <seb_kuzminsky> flexible stuff like this really benefits from all the components being able to identify themselves
[18:21:55] <seb_kuzminsky> i realize that that adds complexity and expense :-(
[18:22:17] <pcw> Thats the problem...
[18:22:25] <seb_kuzminsky> but if the hardware can't be probed and identified we're stuck telling the computer what it is, which gets hairy too
[18:23:09] <pcw> That was kind of my idea of the hint (7I65 on IO pins 24..47)
[18:23:23] <pcw> (then enable or not)
[18:24:22] <seb_kuzminsky> but what if the user would prefer to plug it into io 0-23? because they're on a stepper maching maybe
[18:25:27] <seb_kuzminsky> we could have different firmwares with different hints, but that's just another way of the user providing the hint
[18:25:31] <pcw> If the hardware was there (on pins 0..23), there would be another hint
[18:27:27] <pcw> * if I had it to do all over I'd put a EEPROM on all daughter cards
[18:30:17] <pcw> * with a common access method for probe
[18:31:01] <pcw> bbl
[18:31:09] <seb_kuzminsky> i'll think about it peter
[18:31:11] <seb_kuzminsky> ttyl
[18:32:03] <pcw> Maybe it can be done in the existing framework
[18:32:05] <pcw> #7i65s=n
[18:32:24] <seb_kuzminsky> maybe something like that can work
[18:32:47] <seb_kuzminsky> currently you get the *first* n instances of the module you request, there's no way to say "gimme encoders 0, 1, 4 and 7"
[18:33:33] <seb_kuzminsky> seems we'd want to specify *where* the 7i65's are connected, in addition to how many there are
[18:33:40] <pcw> #7I65s=n.io00..23
[18:33:42] <pcw> You would be stuck with the aggregate # of encoders/dacs
[18:33:53] <pcw> Really BBL
[18:34:29] <seb_kuzminsky> something like that should work, but note that the user specifies it all; it doesnt use any hints from the firmware
[19:06:55] <PCW> Sebastian: hint could validate user choice
[19:27:08] <seb_kuzminsky> PCW: i'm not sure, does the driver still talk to the 7i65 via 8xPWM, 8xencoder, etc? or is it totally different?
[19:30:56] <PCW> No, 7I65 has SPI DACs, SPI ADCs SPI enables and Muxed encoders
[19:30:58] <PCW> (though the muxed encoders should be trivial to support just another module ID)
[19:31:14] <seb_kuzminsky> ok i see
[19:31:39] <jepler> does muxing the encoders decrease the maximum count rate much?
[19:31:53] <PCW> Maybe to 4 MHz max
[19:32:33] <PCW> (4 m counts/sec)
[19:32:45] <seb_kuzminsky> PCW: does it have a single spi with all the devices on the 7i65, or one spi per device on the 7i65?
[19:32:55] <PCW> Single
[19:33:29] <seb_kuzminsky> one spi for all the spi-stuff on the 7i65, plus all the non-spi stuff on the 7i65
[19:33:38] <seb_kuzminsky> (muxed encoders etc)
[19:33:39] <seb_kuzminsky> ok
[19:34:12] <PCW> There's a buffered SPI interface in the FPGA (BSPI) so writes dont need to wait
[19:34:27] <seb_kuzminsky> i see why you want some sort of shorthand to say "P2 has a 7i65 on it" rather than breaking everything out into fine-grained configurations
[19:37:15] <PCW> Could be just a command line hint
[19:37:16] <PCW> to avoid all the pin twiddling in HAL
[19:37:18] <PCW> The 7I65 will need quite a bit board specific setup
[19:37:20] <PCW> (SPI channel descriptor setup etc)
[19:37:28] <seb_kuzminsky> will the driver poll the ADCs on the 7i65, or does the 7i65 push it?
[19:37:53] <seb_kuzminsky> * seb_kuzminsky doesnt know spi...
[19:39:49] <jepler> in the SPI I know the slave clocks data onto the MISO (master-in slave-out) line as the master clocks SCK (serial clock) line
[19:40:03] <jepler> that's on AVRs -- I don't know that the mesa cards work like that
[19:40:31] <seb_kuzminsky> is spi full duplex? there's a "mosi" line next to the miso?
[19:42:36] <SWPadnos> data is often clocked in and out at the same time
[19:42:47] <SWPadnos> so yes, it is capable of being full duplex
[19:43:02] <seb_kuzminsky> so maybe the 7i65 sends you the adc values as you send it the dac values
[19:43:23] <SWPadnos> that would be more efficient than doing separate transfers
[19:43:32] <seb_kuzminsky> but the hm2 spi interface is buffered so you dont have to wait to clock out the dac values, so it seems like you'd be "one cycle behind" on adc values
[19:43:53] <SWPadnos> like serial, there are TX and RX pins. the only addition to serial are clock and chip select (for the most part)
[19:44:23] <SWPadnos> you always have the latest data, it just isn't from "now"
[19:44:32] <SWPadnos> it's from the last full SPI transfer cycle
[19:45:01] <SWPadnos> which could be maybe 20 microseconds old, depending on clock rate and how much data has to be trasnferred in total
[19:54:48] <PCW> The A-D and DAC need separate SPI transactions, probably the easiest thing would be for the A-D data to always be 1 sample time late
[19:55:01] <alex_joni> jepler: do you remember anything about the additions to emc2 regarding NURBS ?
[19:55:39] <alex_joni> I mean, where the code might be ..
[19:56:41] <seb_kuzminsky> PCW: you mean one servo-period late?
[19:56:51] <SWPadnos> one SPI cycle late
[19:57:12] <SWPadnos> unless the SPI cycle is triggered by the driver reading/writing something
[19:57:50] <seb_kuzminsky> at the end of each servo loop, the driver would put the new dac values in the bspi buffer, and it would put read-requests for the adc values
[19:57:51] <PCW> One servo period
[19:58:14] <SWPadnos> ok, so the transfer would only be done under software control?
[19:58:31] <jepler> alex_joni: xemet (or somebody) worked on it for research. I have no idea where any actual patches are. It's certainly not in CVS.
[19:58:59] <alex_joni> right.. thought you might have seen a copy
[19:59:04] <alex_joni> I also remember it was xemet
[19:59:07] <PCW> ( the read requests might be semi auto - one write to autosend)
[19:59:09] <PCW> Yes SWP for now its software
[20:00:41] <SWPadnos> iok
[20:00:43] <SWPadnos> ok
[20:00:52] <fenn> alex_joni: it was on pastebin and his homepage for a while (emc2cnc.altervista.org)
[20:01:01] <SWPadnos> for my analog boards, I used a state machine that continually refreshed the data
[20:01:32] <SWPadnos> all the driver had to do was read the AD results registers or write the DAC settings registers
[20:01:58] <PCW> Right, this is not for general DAQ use its really made for motion control
[20:02:32] <SWPadnos> well, the write could certainly be dependent on software, but having the read free-running might be a good thing
[20:02:40] <alex_joni> fenn: I'm there now, can't seem to find it though
[20:02:54] <SWPadnos> the driver then just reads the latest data, even though it might be a few microseconds old
[20:03:13] <fenn> alex_joni: i thought i saved it from pastebin but i cant seem to find it
[20:03:59] <PCW> Right, but its not possible with the 7I65 (shared SPI interface)
[20:04:35] <SWPadnos> yeah. I guess you'd have to keep everything or nothing running
[20:04:38] <fenn> i guess i should look for files from 2008-01-03
[20:05:50] <PCW> (well maybe possible with arbitration and sends interrupt A-D task)
[20:21:27] <alex_joni> heh, started looking for NURBS, ended up with talk about early AXIS
http://www.linuxcnc.org/old-www/irclogs/2005/%23emc.freenode.20050529.log
[20:22:22] <fenn> has anyone just emailed manfredi and asked?
[20:23:06] <SWPadnos> the horror
[20:23:16] <fenn> xemet@hotmail.com
[20:23:45] <SWPadnos> here's the annoying part. after a google search for "xemet nurbs", this is the summary:
[20:23:56] <SWPadnos> "My Proxxon MF70 CNC machining a NURBS made Tux using a modified version of EMC2. ... you can find it here: xemet(dot)altervista(dot)org/c nc ..."
[20:24:08] <SWPadnos> just a few more characters in the summary and I'd have it :)
[20:24:25] <fenn> wait wait! i've almost got my command line sorted: find -mtime 9576 -not -newer 9000 or something
[20:26:05] <alex_joni> whoa.. can't believe it's here
[20:26:07] <alex_joni> http://www.pastebin.ca/640476
[20:26:17] <alex_joni> almost 2 years later
[20:26:20] <SWPadnos> http://www.pastebin.ca/640476
[20:26:22] <SWPadnos> heh
[20:26:25] <SWPadnos> just found it too :)
[20:26:35] <alex_joni> from here:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2007-07-31.txt
[20:26:42] <SWPadnos> the default used to be no expiration
[20:26:48] <SWPadnos> yep
[20:33:55] <micges> hello all
[20:35:54] <SWPadnos> hi
[20:35:56] <micges> anyone knows any plans about implementing SPINDLE_RETRACT canon call ?
[20:36:24] <micges> and what is it used for (docs are unclear)
[20:37:05] <SWPadnos> not without reading for a while
[20:41:08] <micges> retract means moving where? up? left? down?
[20:41:27] <micges> I think its up but how far
[20:41:40] <alex_joni> micges: now you know why it's not implemented
[20:41:50] <alex_joni> that way would be way too machine specific
[20:42:19] <micges> but how usefull...
[21:05:54] <SWPadnos> I see codes for tailstock spindle retract, nothing for a "regular" spindle
[21:06:22] <SWPadnos> I can't see it being useful on a mill, since Z (or W) position would be a better way of controlling this
[21:08:12] <micges> what is tailstock ?
[21:08:25] <jepler> micges: part of a lathe
[21:08:34] <SWPadnos> the holder opposite from the spindle end (the headstock) on a lathe
[21:09:13] <micges> in polish tailstock->konik :D
[21:09:24] <SWPadnos> what's a headstock? :)
[21:10:00] <alex_joni> konik podporowy szlifierki
[21:10:12] <micges> cool
[21:10:26] <SWPadnos> or konik podporowy szlifierka for the ladies :)
[21:10:40] <micges> lathes are not well know by me :)
[21:10:42] <alex_joni> maybe wrzeciennik for tailstock?
[21:11:07] <micges> lathe->tokarka
[21:11:16] <alex_joni> I meant headstock
[21:12:34] <skunkworks_> rfl seems to have made tom happy :)
[21:12:44] <SWPadnos> yeah, I'm sure
[21:12:55] <SWPadnos> I wonder if JonE is using TRUNK :)
[21:13:02] <alex_joni> he usually does
[21:13:07] <SWPadnos> err, no
[21:13:09] <alex_joni> various versions of TRUNK though :)
[21:13:20] <SWPadnos> heh, like 10 year old TRUNK? :)
[21:13:28] <alex_joni> yeah.. something like that
[21:13:38] <jepler> "it was called TRUNK back when I last updated"
[21:13:38] <alex_joni> would have guess less than 10y
[21:13:49] <alex_joni> it was called HEAD back then
[21:13:59] <SWPadnos> maybe it was 8 years old when he finally upgraded to EMC2
[21:14:04] <jepler> if you have actual work to do, updating cvs may not be the right thing to do
[21:14:06] <SWPadnos> that version from 1998 or 1999
[21:14:24] <SWPadnos> exactly, unless there's a bugfix you need
[21:14:55] <alex_joni> unless you prefer to apply a patch
[21:15:59] <micges> I've asked about retract becouse I have material with holes made by stopping spindle in material not above it
[21:16:36] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/tests/halmodule.0/ (README expected test.sh): new test
[21:17:40] <micges> I added MDI call after EASCAPE to move up a few mm but sometimes it is execurted too late after c.abort()
[21:22:38] <jepler> let me see if I understand what you're asking for: when the operator hits "abort" (but of course not "estop"!), you want a preprogrammed move like G53G0Z0 before the spindle is stopped?
[21:23:39] <micges> G0 Z1 specifically but yes
[21:24:13] <micges> if Z0 is the level of material
[21:25:29] <jepler> I don't think that's at all related to SPINDLE_RETRACT, whatever exactly SPINDLE_RETRACT is
[21:26:08] <jepler> "things that happen at abort time" are pretty much entirely separate from "things the interpreter does", like making canon calls such as SPINDLE_RETRACT
[21:27:01] <micges> right :P
[21:27:21] <jepler> and this is certainly not a "one size fits all" item
[21:27:43] <jepler> for instance, when cutting a T-slot on a mill, that move would be a terrible one to do!
[21:28:01] <alex_joni> or when rigid tapping :)
[21:28:30] <micges> whats rigid tapping ?
[21:28:31] <jepler> what if the user aborts between a tool change (which probably takes place more than 1" above top of material) and the return to cutting? would the tool move down?
[21:28:51] <jepler> micges: putting a thread on a hole with a tapping tool
[21:28:56] <alex_joni> micges:
http://www.youtube.com/watch?v=vNn-Yr7it5s
[21:29:55] <jepler> lathes also offer multiple different scenarios for "how to get the tool safely away from the work"
[21:30:08] <jepler> depending on whether you're doing an inside or outside operation, for starters
[21:30:28] <jepler> IOW I wouldn't want to touch this feature with a ten foot pole
[21:31:10] <jepler> for it to make sense for more than a tiny proportion of people, it probably needs the same thing tool changing really needs: the ability to specify a series of (possibly conditional) movements
[21:31:54] <jepler> lots of programming to be done there, by somebody
[21:32:37] <jepler> bbl
[21:33:27] <micges> can be done simmilar to homing sequence in motmod (I think)
[21:35:33] <micges> as rack tool changer is impossible now due O call errors
[21:36:13] <micges> I'll try to add this somehow to EMC
[21:36:54] <micges> (this make no sense I'm tired)
[21:36:58] <micges> good night all
[21:50:31] <alex_joni> jepler: that's fun: set f 89884656743115795386465259539451236680898848947115328636715040578866337902750481566354238661203768010560056939935696678829394884407208311246423715319737062188883946712432742638151109800623047059726541476042502884419075341171231440736956555270413618581675255342293149119973622969239858152417678164812112068608 8.98846567431e+307
[21:50:43] <alex_joni> I wonder if you typed that :D
[22:32:59] <jepler> alex_joni: no, I didn't
[22:33:03] <jepler> mv output expected; cvs commit
[22:36:55] <cradek> I just did a bunch of lathe work using trunk. everything is working great.
[22:39:02] <cradek> I like how you can switch between AXIS's manual and mdi tabs without messing anything up
[22:39:30] <cradek> also, you can type a long mdi command, then hit F9-F12-F12 to turn the spindle on, then F8 for coolant, then hit enter and run the mdi
[22:40:05] <cradek> but I would like some facing/boring/turning cycles...
[23:01:54] <cradek> too bad about that cutoff date that's in the past...
[23:55:05] <CIA-2> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/spy_vars_gtk.c: Fix display of variable names in var window. Change the name of the signed integersvars to analog variables which makes more sense