should I be able to use alias now?
[451064.914518] hm2_5i20: *** NOTE: This driver is obsolete, you should use hm2_pci instead, it works better ***
hm, is this true?
hm, the man page says yep
cradek: what is the alias for?
alias pin hm2_5i20.0.gpio.067.out iocard-1.output-screw-3
it's supposed to let you make a custom name, so your hal file is more self-documenting
sounds like a good thing
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
old name for first output screw terminal: m5i20.0.out-01 new name: hm2_5i20.0.gpio.041.out
so now I could make aliases to get something like the old names, or even more specific to my own setup
new ones are hard to read
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
seems like alias gives the best of both worlds
yes it does
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
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?
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
I think jepler has talked about that a few times
a menu that could have custom stuff on it maybe
that would be cool
throw in a "plug-ins" or "tools" directory, and at startup have AXIS add any executables in that dir to a tools menu
yeah something like that
except they're not necessarily executables
hmmm. you could actually have python scripts evaluated in the context of AXIS couldn't you
I have "part.ngc" which starts the spindle and goes from wherever it is to X0 with CSS+FPR
a lot of them could be plain gcode
ok, that gets a little more complex - that's more of a "subroutines" thing
(I think more complex because you have to handle different files differently, rather than just exec()-ing them)
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?
userspace program sends write_vars and waits for completion, then fiddles with the file contents, then sends read_vars
ugly, but probably much easier than the "right way"
what problem are you talking about?
* BigJohnT slip slides away
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
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
usually I think people are just mistaken when they think they want to do that
it would be nice to have a variable inspector that could at least view vars
consider the "active offsets" screen that Greg showed us
I agree - but your solution is not the solution to that problem
it's not a good solution, but it is a solution
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
rereading is not necessary for a variable inspector...
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
right, only for one where you want to be able to edit the numbers ;)
yay! I found a DB25M-M cable. my stacking hub came with one for stacking :)
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.
the gui has no way of getting or setting those numbers via NML - that's the root problem at the moment
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
var file save/load is one way of getting that, though as I said, it's a crappy method
getting, you are right: setting, you are wrong, MDI #1=1
#5387=2.0095 makes a lot less sense than a screen with a list of offsets for the current coordinate system(s)
well you can also MDI (DEBUG,#1) or however you spell it, if you want to see the value of a certain var
G10 L2 X2.0095 makes more sense still
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
viewing for sure, setting maybe
and you can't do that using MDI commands
even if they're automatic/hidden
can't do which?
you can't execute MDI commands while a program is running
so MDI isn't a viable method of making e.g. a live variable viewer (even without editing)
viewing vars as a program runs is an entirely different ball of mud
neither is your proposed solution!
this is why I am fishing for a statement of the problem
sorry I'm being an ass.
the problem as I see it is getting read and/or write access to variables from the bowels of EMC2
while programs are running
do you really mean you want the user to be able to write/change vars as a program runs?
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
pause doesn't take MEC2 out of auto mode, does it?
you realize that vars are internal to the interp, so the best you could do is affect them at readahead time?
that is a problem :)
anyway - not terribly important - it just popped into mind, that's all (it's not something I'm itching to "fix" tonight)
hmmm. I wonder how many updates there will be for my kiosh PC
I bet an entire OS if you want it
yep, I guess it is on 6.06
god 800x600 is painful
heh. well here's a use case: I've got a loop running and I'm wondering how many iterations remain :)
I guess I could have run in a terminal and used the (DEBUG, #xxx) method
one of them goes to the gui, one goes to stdout/stderr
the other might be (PRINT,#xxx)
is that var printing feature in 2.2.x?
the G540 seems to work nicely
if you don't mind whining stepper motors around
how is it different from the other gecko things?
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
sounds very cool
I think they're $300, so not tooo cheap
but it is a breakout board, heatsinks, and 4 microstepping/anti-resonance drives
sounds like that $300 saves you a lot of dinking
heh, except for me, looking all over town for the right DB25 cable
it is noce though - there aren't even any wires internally, it's all headers and connectors.
literally, the only wires are the ones that go to the motors and the ones you connect to the screw terminal I/O block
he should have used a centronics like only Steve S seems smart enough to do
or a male DB25, so an extender cable would work
heh - I've made myself a laser level :)
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)
a laser cone generator?
kind of a not-very-good dot
which conic section do you get on the walls? is it hyperbolae?
wolfram is so cool
this little motor seems to run nicely at ~15RPS, with 50RPS^2 accel
* seb_kuzminsky kicks CIA-42
* seb_kuzminsky kicks CIA-40
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h: protect against multiple inclusion
EMC: 03seb 07TRUNK * 10emc2/src/Makefile: added some IDROM-parsing tests
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (hm2_test.c hm2_test.h): added some IDROM-parsing tests
EMC: 03seb 07TRUNK * 10emc2/tests/hm2-idrom/ (README broken-load-test.hal check-dmesg expected test.sh): added some IDROM-parsing tests
seb_kuzminsky, was there a warning somewhere, or is that multiple=inclusion thing just for cleanliness/build speed?
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)
since hostmot2.h includes hostmot2-lowlevel.h, this was finally needed
ok, did you get a warning though? (from the double-definition of the hm2 info struct)
it failed to build, because one of the structs in hm2-llio.h ended up being defined twice
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)
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
via HAL pins?
i'd imagined via modparams
loadrt hm2_dynamic_test encoder_speed=10
oh - I'd just make something that has pins for things that would normally get input/output from/to headers
10 counts between each call to hm2_read()
that way you could use something like the sim configs use to simulate inertia, etc
(see spindle feedback in sim-lathe, I think)
ok, I leave implementation as an exercise for the reader ;)
i thought you were volunteering ;-)
I did. I volunteered you ;)
alex_joni is now known as NSA-1
NSA-1 is now known as alex_joni
seb_kuzminsky: should I be using hm2_pci instead of hm2_5i20? a message in dmesg says so.
cradek: I think hm2_pci is the preferred driver, as it supports 5i20 and 5i22 and some other pci card I can't rememeber
pc104/+ I think (4I something)
right.. also pci connected
but I think hm2_pci is only on TRUNK...
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
I believe you :)
SWPadnos: how is the gecko>
it's quite nice
I did a quick hookup with one motor (with a laser mounted on it)
had it spinning ~15RPS in short order, and no lost steps in several hundred g0x1/g0x0 loops
I think there was one lost step when I ran that loop 1000 times, after I lied to stepconf about the max latency
I didn't see a patch to stepconf yet :)
question for you: with those Goal3 systems, did you get weird video artifacts with the autodetected (SIS?) driver?
patch to detect lies?
no, patch to add 540 to stepconf
I haven't done it yet ;)
SWPadnos: are you talking to me?
skunkworks, yes, about the GOAL3+ boards
ah - yes. I think I mentioned it on here. It looked like noise on the monitor.
It gets better at lower resolutions.
and you got rid of it by using the VESA driver instead?
ok, I'll try that later.
those are really great for relatime though, I'm happy
yes - very stable it seems
~11000 max latency after running for 1/2 hour, with glxgears and the system update going
I think I ran one for atleast 9 hours with no issues
that will be the system where I try to push the G540 ;)
I can't generate more than ~25k steps/sec on the celeron 500
this one should do 50-75k I think
anyway, gotta run and meet the wife for tea
jmkasunich: sexy http://imagebin.ca/img/Ie_FJjI.png
you get turned on by strange things
some people like boats.
others by LED's: www.seekway.com.cn/e/ledsys9.htm
that is neat
or ferro fluid sculptures: http://www.youtube.com/watch?v=me5Zzm2TXh4&feature=related
EMC: 03jepler 07TRUNK * 10emc2/lib/python/rs274/interpret.py: origin offsets now have 9 values