Back
[01:18:43] <cradek> should I be able to use alias now?
[01:24:53] <cradek> [451064.914518] hm2_5i20: *** NOTE: This driver is obsolete, you should use hm2_pci instead, it works better ***
[01:25:05] <cradek> hm, is this true?
[01:25:34] <cradek> hm, the man page says yep
[01:25:36] <cradek> hmmm
[01:26:51] <BigJohnT> cradek: what is the alias for?
[01:27:54] <cradek> alias pin hm2_5i20.0.gpio.067.out iocard-1.output-screw-3
[01:28:14] <cradek> it's supposed to let you make a custom name, so your hal file is more self-documenting
[01:28:28] <BigJohnT> ok :)
[01:28:47] <BigJohnT> sounds like a good thing
[01:29:00] <cradek> it came from my complaint about the generic names in hostmot2 being much harder to use than the old names that assumed you had certain daughter cards plugged into it
[01:29:37] <cradek> old name for first output screw terminal: m5i20.0.out-01 new name: hm2_5i20.0.gpio.041.out
[01:30:01] <cradek> so now I could make aliases to get something like the old names, or even more specific to my own setup
[01:30:25] <BigJohnT> new ones are hard to read
[01:30:48] <cradek> yes but their benefit is that they don't assume what's plugged in to the mesa card - you have full power over what it does
[01:31:05] <cradek> seems like alias gives the best of both worlds
[01:31:08] <BigJohnT> cool
[01:31:14] <BigJohnT> yes it does
[01:32:02] <cradek> if you want to use the same three daughter cards, you could use my hal file to load the aliases. it's kind of like 'personalities' for the driver, but the complexity doesn't have to be inthe driver
[01:33:05] <BigJohnT> cool
[01:35:51] <BigJohnT> do you think there is a way to call a python g code generator from the tool bar based on an ini file entry is possible?
[01:40:43] <cradek> not currently
[01:40:51] <BigJohnT> ok
[01:41:47] <cradek> it would be nice to have something like that - where the gcode or gcode generating filter is run without disturbing which program is currently loaded
[01:42:06] <cradek> I think jepler has talked about that a few times
[01:42:17] <cradek> a menu that could have custom stuff on it maybe
[01:42:34] <BigJohnT> that would be cool
[01:42:41] <SWPadnos> throw in a "plug-ins" or "tools" directory, and at startup have AXIS add any executables in that dir to a tools menu
[01:43:18] <cradek> yeah something like that
[01:43:26] <cradek> except they're not necessarily executables
[01:43:42] <SWPadnos> hmmm. you could actually have python scripts evaluated in the context of AXIS couldn't you
[01:43:47] <cradek> I have "part.ngc" which starts the spindle and goes from wherever it is to X0 with CSS+FPR
[01:44:04] <cradek> a lot of them could be plain gcode
[01:44:20] <SWPadnos> ok, that gets a little more complex - that's more of a "subroutines" thing
[01:44:55] <SWPadnos> (I think more complex because you have to handle different files differently, rather than just exec()-ing them)
[01:46:27] <SWPadnos> just had a thought on vars and synchronization. wouldn't a pair of NML commands, read_vars and write_vars, solve most of the problem with userspace access to the var file?
[01:46:58] <SWPadnos> userspace program sends write_vars and waits for completion, then fiddles with the file contents, then sends read_vars
[01:47:19] <SWPadnos> ugly, but probably much easier than the "right way"
[01:50:24] <cradek> what problem are you talking about?
[01:54:15] <BigJohnT> * BigJohnT slip slides away
[01:56:50] <SWPadnos> oh sorry - the one about insuring that programs that want to mess with var file contents do so in a way that (a) doesn't get overwritten by emc and (b) gets noticed by emc in a timely manner
[01:59:13] <cradek> I'm not sure what the actual problem is that people want to solve by reading and writing the var file, so I hesitate to guess the right solution to the problem
[01:59:25] <cradek> usually I think people are just mistaken when they think they want to do that
[02:00:25] <SWPadnos> it would be nice to have a variable inspector that could at least view vars
[02:00:39] <SWPadnos> consider the "active offsets" screen that Greg showed us
[02:00:49] <cradek> I agree - but your solution is not the solution to that problem
[02:00:53] <SWPadnos> heh
[02:01:04] <SWPadnos> it's not a good solution, but it is a solution
[02:01:41] <SWPadnos> if you can insure that the var file contains reasonably current information, and that information can be re-read by EMC2 on command, it should work
[02:02:12] <cradek> rereading is not necessary for a variable inspector...
[02:02:15] <SWPadnos> again, not ideal - ideal would be a request for a particular var or group of vars to be read or written from EMC2, regardless of whether they're in the vra file
[02:02:27] <SWPadnos> right, only for one where you want to be able to edit the numbers ;)
[02:03:12] <SWPadnos> yay! I found a DB25M-M cable. my stacking hub came with one for stacking :)
[02:03:26] <cradek> I still think the var file is for the interpreter to save state. it is a very craptacular user interface. if viewing/editing numbers directly is needed, we should add it to the gui.
[02:04:00] <SWPadnos> the gui has no way of getting or setting those numbers via NML - that's the root problem at the moment
[02:04:05] <cradek> but, I'm more interested in what use cases require the viewing/editing of these numbers, and I'd want to seek a solution there
[02:04:16] <SWPadnos> var file save/load is one way of getting that, though as I said, it's a crappy method
[02:04:21] <cradek> getting, you are right: setting, you are wrong, MDI #1=1
[02:04:54] <SWPadnos> #5387=2.0095 makes a lot less sense than a screen with a list of offsets for the current coordinate system(s)
[02:04:56] <cradek> well you can also MDI (DEBUG,#1) or however you spell it, if you want to see the value of a certain var
[02:05:12] <cradek> G10 L2 X2.0095 makes more sense still
[02:06:15] <SWPadnos> well, any vars can be set, and some can be viewed, with G-code. the trouble is that someone may want to do that in auto mode
[02:06:22] <SWPadnos> viewing for sure, setting maybe
[02:06:29] <SWPadnos> and you can't do that using MDI commands
[02:06:38] <SWPadnos> even if they're automatic/hidden
[02:07:08] <cradek> can't do which?
[02:07:25] <SWPadnos> you can't execute MDI commands while a program is running
[02:07:32] <cradek> definitely not
[02:07:47] <SWPadnos> so MDI isn't a viable method of making e.g. a live variable viewer (even without editing)
[02:07:51] <cradek> viewing vars as a program runs is an entirely different ball of mud
[02:08:01] <cradek> neither is your proposed solution!
[02:08:03] <SWPadnos> heh
[02:08:13] <cradek> this is why I am fishing for a statement of the problem
[02:08:45] <cradek> sorry I'm being an ass.
[02:08:46] <SWPadnos> the problem as I see it is getting read and/or write access to variables from the bowels of EMC2
[02:08:54] <SWPadnos> while programs are running
[02:09:38] <cradek> do you really mean you want the user to be able to write/change vars as a program runs?
[02:09:41] <SWPadnos> there are any number of reasons why some might want to do this, regardless of whether they're the only way or even if they're a smart way of getting something done
[02:09:43] <SWPadnos> yes
[02:10:06] <SWPadnos> pause doesn't take MEC2 out of auto mode, does it?
[02:10:09] <SWPadnos> EMC2
[02:10:11] <cradek> you realize that vars are internal to the interp, so the best you could do is affect them at readahead time?
[02:10:24] <SWPadnos> that is a problem :)
[02:11:06] <SWPadnos> anyway - not terribly important - it just popped into mind, that's all (it's not something I'm itching to "fix" tonight)
[02:15:06] <SWPadnos> hmmm. I wonder how many updates there will be for my kiosh PC
[02:15:09] <SWPadnos> kiosk
[02:15:41] <cradek> I bet an entire OS if you want it
[02:15:55] <SWPadnos> heh
[02:16:24] <SWPadnos> yep, I guess it is on 6.06
[02:17:46] <SWPadnos> god 800x600 is painful
[03:55:04] <SWPadnos> heh. well here's a use case: I've got a loop running and I'm wondering how many iterations remain :)
[03:55:25] <SWPadnos> I guess I could have run in a terminal and used the (DEBUG, #xxx) method
[03:59:24] <cradek> one of them goes to the gui, one goes to stdout/stderr
[03:59:33] <cradek> the other might be (PRINT,#xxx)
[03:59:41] <SWPadnos> is that var printing feature in 2.2.x?
[03:59:47] <cradek> not sure
[03:59:55] <SWPadnos> the G540 seems to work nicely
[04:00:09] <SWPadnos> if you don't mind whining stepper motors around
[04:00:12] <cradek> how is it different from the other gecko things?
[04:00:57] <SWPadnos> single package with 4 axis drives (50V, 3.5A), some isolated I/O (including charge pump and 0-10V spindle output), direct parallel port connection
[04:01:14] <cradek> sounds very cool
[04:01:17] <SWPadnos> yep
[04:01:27] <SWPadnos> I think they're $300, so not tooo cheap
[04:01:47] <SWPadnos> but it is a breakout board, heatsinks, and 4 microstepping/anti-resonance drives
[04:02:01] <cradek> sounds like that $300 saves you a lot of dinking
[04:02:24] <SWPadnos> heh, except for me, looking all over town for the right DB25 cable
[04:02:44] <SWPadnos> it is noce though - there aren't even any wires internally, it's all headers and connectors.
[04:02:46] <SWPadnos> nice
[04:03:06] <SWPadnos> literally, the only wires are the ones that go to the motors and the ones you connect to the screw terminal I/O block
[04:04:52] <cradek> he should have used a centronics like only Steve S seems smart enough to do
[04:05:42] <SWPadnos> or a male DB25, so an extender cable would work
[04:06:38] <cradek> ouch, yeah
[04:08:40] <SWPadnos> heh - I've made myself a laser level :)
[04:09:10] <SWPadnos> I stuck a laser on the motor so I can see if it's off by looking at the spot on the wall (10' away)
[04:14:23] <cradek> a laser cone generator?
[04:14:38] <SWPadnos> kind of a not-very-good dot
[04:14:50] <cradek> which conic section do you get on the walls? is it hyperbolae?
[04:15:10] <SWPadnos> hmmm
[04:15:21] <cradek> yep
[04:15:27] <cradek> wolfram is so cool
[04:15:35] <SWPadnos> heh
[04:17:45] <SWPadnos> this little motor seems to run nicely at ~15RPS, with 50RPS^2 accel
[05:03:09] <seb_kuzminsky> * seb_kuzminsky kicks CIA-42
[05:03:26] <seb_kuzminsky> * seb_kuzminsky kicks CIA-40
[05:03:27] <CIA-40> ow
[05:03:37] <seb_kuzminsky> buildmaster: hello
[05:03:37] <buildmaster> yes?
[05:33:50] <CIA-40> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h: protect against multiple inclusion
[05:35:03] <CIA-40> EMC: 03seb 07TRUNK * 10emc2/src/Makefile: added some IDROM-parsing tests
[05:35:03] <CIA-40> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (hm2_test.c hm2_test.h): added some IDROM-parsing tests
[05:35:04] <CIA-40> EMC: 03seb 07TRUNK * 10emc2/tests/hm2-idrom/ (README broken-load-test.hal check-dmesg expected test.sh): added some IDROM-parsing tests
[05:41:38] <SWPadnos> seb_kuzminsky, was there a warning somewhere, or is that multiple=inclusion thing just for cleanliness/build speed?
[05:43:29] <seb_kuzminsky> i just added hm2_test, which wants to include both hostmot2.h (for the address offset #defines) and hostmot2-lowlevel.h (for the llio struct)
[05:43:51] <seb_kuzminsky> since hostmot2.h includes hostmot2-lowlevel.h, this was finally needed
[05:44:23] <SWPadnos> ok, did you get a warning though? (from the double-definition of the hm2 info struct)
[05:44:30] <SWPadnos> just curious
[05:46:36] <seb_kuzminsky> it failed to build, because one of the structs in hm2-llio.h ended up being defined twice
[05:46:46] <SWPadnos> ok, thanks
[05:47:21] <SWPadnos> I didn't notice any static vars or anything, so the struct was the only thing I could see that should have caused a problem (though the function definitions at the end could also)
[05:47:47] <seb_kuzminsky> next i want to make a dynamic hm2 test, where the fake llio makes it look like an encoder is turning or a stepgen is stepping
[05:48:03] <SWPadnos> via HAL pins?
[05:48:14] <seb_kuzminsky> i'd imagined via modparams
[05:48:30] <seb_kuzminsky> loadrt hm2_dynamic_test encoder_speed=10
[05:48:42] <SWPadnos> oh - I'd just make something that has pins for things that would normally get input/output from/to headers
[05:48:44] <seb_kuzminsky> 10 counts between each call to hm2_read()
[05:48:52] <seb_kuzminsky> hm
[05:49:09] <SWPadnos> that way you could use something like the sim configs use to simulate inertia, etc
[05:49:20] <SWPadnos> (see spindle feedback in sim-lathe, I think)
[05:49:30] <seb_kuzminsky> cool idea
[05:49:48] <SWPadnos> ok, I leave implementation as an exercise for the reader ;)
[05:50:16] <seb_kuzminsky> i thought you were volunteering ;-)
[05:50:24] <SWPadnos> I did. I volunteered you ;)
[05:50:27] <seb_kuzminsky> heh
[13:09:53] <alex_joni> alex_joni is now known as NSA-1
[13:10:18] <NSA-1> NSA-1 is now known as alex_joni
[15:54:33] <cradek> seb_kuzminsky: should I be using hm2_pci instead of hm2_5i20? a message in dmesg says so.
[19:00:10] <alex_joni> cradek: I think hm2_pci is the preferred driver, as it supports 5i20 and 5i22 and some other pci card I can't rememeber
[19:03:09] <SWPadnos> pc104/+ I think (4I something)
[19:03:57] <alex_joni> right.. also pci connected
[19:04:34] <alex_joni> but I think hm2_pci is only on TRUNK...
[19:05:26] <alex_joni> hmm.. nope, on 2.2.x too
[19:05:53] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/mesa-hostmot2/hm2_pci.c?graph=1
[19:06:14] <SWPadnos> I believe you :)
[19:14:25] <alex_joni> bbl
[19:23:45] <skunkworks> SWPadnos: how is the gecko>
[19:23:47] <skunkworks> ?
[19:37:49] <SWPadnos> it's quite nice
[19:38:12] <SWPadnos> I did a quick hookup with one motor (with a laser mounted on it)
[19:38:31] <skunkworks> heh
[19:38:43] <SWPadnos> had it spinning ~15RPS in short order, and no lost steps in several hundred g0x1/g0x0 loops
[19:38:50] <skunkworks> nice
[19:39:12] <SWPadnos> I think there was one lost step when I ran that loop 1000 times, after I lied to stepconf about the max latency
[19:39:19] <skunkworks> heh
[19:39:31] <alex_joni> I didn't see a patch to stepconf yet :)
[19:39:48] <SWPadnos> question for you: with those Goal3 systems, did you get weird video artifacts with the autodetected (SIS?) driver?
[19:39:50] <SWPadnos> heh
[19:39:55] <SWPadnos> patch to detect lies?
[19:40:16] <alex_joni> no, patch to add 540 to stepconf
[19:40:33] <SWPadnos> I haven't done it yet ;)
[19:40:53] <skunkworks> SWPadnos: are you talking to me?
[19:41:03] <SWPadnos> skunkworks, yes, about the GOAL3+ boards
[19:41:36] <skunkworks> ah - yes. I think I mentioned it on here. It looked like noise on the monitor.
[19:41:49] <skunkworks> It gets better at lower resolutions.
[19:41:53] <SWPadnos> right, ok
[19:42:05] <SWPadnos> and you got rid of it by using the VESA driver instead?
[19:42:09] <skunkworks> yes
[19:42:16] <SWPadnos> ok, I'll try that later.
[19:42:25] <SWPadnos> those are really great for relatime though, I'm happy
[19:42:45] <skunkworks> yes - very stable it seems
[19:42:48] <SWPadnos> ~11000 max latency after running for 1/2 hour, with glxgears and the system update going
[19:42:56] <skunkworks> I think I ran one for atleast 9 hours with no issues
[19:43:11] <SWPadnos> that will be the system where I try to push the G540 ;)
[19:43:30] <SWPadnos> I can't generate more than ~25k steps/sec on the celeron 500
[19:43:36] <SWPadnos> (without lying)
[19:43:36] <skunkworks> heh
[19:43:51] <SWPadnos> this one should do 50-75k I think
[19:44:20] <SWPadnos> anyway, gotta run and meet the wife for tea
[19:44:23] <SWPadnos> bbl
[19:44:44] <skunkworks> see you
[20:22:34] <skunkworks> jmkasunich: sexy
http://imagebin.ca/img/Ie_FJjI.png
[20:39:16] <jmkasunich> you get turned on by strange things
[20:39:46] <skunkworks> some people like boats.
[21:15:10] <alex_joni> others by LED's: www.seekway.com.cn/e/ledsys9.htm
[21:15:39] <alex_joni> (err..
http://www.youtube.com/watch?v=Aj3_v7xCyJ0&feature=related)
[21:17:36] <skunkworks> that is neat
[21:21:07] <alex_joni> or ferro fluid sculptures:
http://www.youtube.com/watch?v=me5Zzm2TXh4&feature=related
[21:57:37] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/lib/python/rs274/interpret.py: origin offsets now have 9 values
