Back
[04:03:25] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[12:50:07] <JT-Dev> G41/42 can now be done in G18? it seems like the docs are wrong...
[12:50:24] <JT-Dev> ho hi ho hi it's off to work I go
[12:58:17] <jepler> JT-Dev: yes, you can do it in the XZ plane as well.
[12:58:41] <jepler> it looks like YZ is not yet supported but is more a matter of tedious programming than basic architectural impossiblity
[12:59:53] <jepler> afaik this was true in 2.3 as well
[13:17:21] <cradek> yes we could also add uv/vw/wu planes if we cared to. the cutter comp code is now largely plane-agnostic and it's just minor tedium to add support for other planes.
[13:17:38] <jepler> well, there's more than tedium to adding uvw arcs
[13:18:00] <cradek> that's true
[13:18:09] <cradek> (ugh)
[13:26:08] <JT-Work> ok, I just read back so I can at least add XZ plane to cutter comp in the manuals
[14:20:05] <jepler> I haven't been paying attention to #emc or the web-bbs. are there any other substantial problems with 2.4 that have popped up yet?
[14:39:52] <cradek> I've only seen the ppmc and tool table/tooledit/tkemc stuff
[15:11:12] <JT-Work> the tool table edit in axis in lathe mode does some funny conversion on the front angle and back angle
[15:11:27] <cradek> dgarr fixed that already
[15:12:32] <JT-Work> ok, I missed that
[15:32:24] <dgarr> jepler: i verified drawpix works on t23/hardy/savage_drv so i file a bug report for xserver-xorg-video-savage -- thanks for your help
[15:32:29] <jepler> dgarr: you're welcome
[15:33:12] <dgarr> for comment: add button to reload tool table:
http://www.panix.com/~dgarrett/stuff/0001-tooledit-conditionally-add-button-to-write-file-AND-.patch
[15:33:54] <jepler> oh dang -- I saw that go by last time but didn't even look
[15:34:15] <jepler> without looking first, I think it's probably a reasonable idea. who wants to write the tool table but not have emc use it?
[15:37:29] <jepler> some UI guides suggest that if there's nothing in the program a user can do to make a a control perform a function, the control should be removed from the window instead of disabled.
[15:39:05] <dgarr> on the other hand, the disabled button could remind the user to start emc
[15:39:23] <Jymmm> jepler: I have a comment on that if your interested.
[15:39:56] <jepler> dgarr: hm, so if you have a long-running tooledit the button will enable and disable when appropriate? I guess that's OK
[15:40:04] <jepler> Jymmm: sure, go ahead
[15:40:19] <dgarr> jepler: yes, that is the intent
[15:40:53] <jepler> dgarr: does it actually work to load emc.so; emc_init multiple times?
[15:41:44] <dgarr> i think it only loads it once -- the first transition from null pid to valid pid
[15:42:38] <jepler> dgarr: I'm thinking about: start tooledit; start and stop emc; start emc again
[15:42:45] <jepler> it'll load and init the second time you start emc
[15:42:48] <jepler> (won't it?)
[15:43:53] <Jymmm> jepler: If a control or menu list item isn't currently available (currently in the wrong mode, etc), I like to have the control visable but disabled (dimmed), as persons usually become acustom to where a control is as they learn the system, even if it's not available. The disabled/dimmed lets them know it's still there, just not available at the moment. When hiding/showing controls, it can become confusing as to "where is that darn thing".
[15:43:53] <Jymmm> It's kind like knowing a store does carry a product, just currently "out of stock", you don't necessarily remvoe the product from display, just inform them it's not available at the moment.
[15:44:39] <Jymmm> excuse the redundancy
[15:45:09] <dgarr> jepler: on the second time pid is not null so it doesn't try to reload
[15:45:29] <jepler> dgarr: wasn't it the empty string during the time emc was shut down?
[15:45:32] <dgarr> i think
[15:45:53] <dgarr> maybe i'm wrong, i tested and it seems to work so maybe you can load multiple times
[15:47:27] <jepler> dgarr: OK, so the scenario I asked about works (whatever is going on under the hood)?
[15:47:32] <jepler> in that case, enable/disable makes sense to me
[15:47:37] <dgarr> just tested--- it seems to work
[15:49:05] <dgarr> it does load emc.so again
[15:50:20] <dgarr> i don't know if there are side-effects to that, i looked with lsof and there is only one emc.so referenced for the tooledit process
[15:52:14] <jepler> I wouldn't be surprised if there was a memory leak in emc_init but probably that can be done dozens of times before the memory leak is an actual problem
[16:06:39] <dgarr> i modified the patch at the link so it only loads emc.so once
[16:13:48] <jepler> and it still tests OK?
[16:13:51] <jepler> * jepler can't test anything at the moment
[16:16:35] <dgarr> yes tests ok for me, but i would recommend your test before incorporating
[16:18:01] <jepler> wow, I'd kill for a camera with these specs: 16-bit data channel; 7080fps; 6.4 megapixel. but actually, it's a gaming mouse with a stupid name.
http://www.overclock3d.net/reviews/input_devices/roccat_kone_3200dpi_gaming_mouse/1
[16:25:35] <SWPadnos> heh
[16:25:51] <SWPadnos> 6.4 megapixel[s/second processing rate]
[16:26:06] <dgarr> jepler: oops -- more tests, there were some problems; it works better loading emc.so each time, changed patch at link bacck to original
[16:26:17] <dgarr> git commit --amend is pretty useful
[16:26:51] <jepler> dgarr: OK
[16:27:12] <jepler> dgarr: I'll do a test later to see whether the memory leak is significant or not
[16:27:25] <dgarr> ok -- thanks again
[16:27:40] <jepler> as usual, remind me if I don't seem to remember..
[16:27:45] <dgarr> np
[16:29:29] <jepler> I was complaining the other day that 'git am' should take a url. It's easy enough to do with a git alias, though it has to have a different name than the built-in command. $ git config alias.amu
[16:29:33] <jepler> !f() { wget -O- $@ | git am -; }; f
[18:17:01] <jepler> It's pretty clear that the future is gtk, or at least it's not tk
[18:17:24] <jepler> I'm considering rewriting the config chooser and splash screen as gtk apps
[18:17:30] <jepler> pygtk, probably
[18:17:33] <jepler> any thoughts?
[18:19:06] <cradek> my thought is yay
[18:19:27] <cradek> I don't think the tk tree works very well (could be our code of course, I have no idea)
[18:19:59] <jepler> there are some things about pickconfig that are just bugs and could be addressed as bugs if we wanted
[18:20:04] <jepler> that program hasn't had a lot of love lately
[18:20:11] <cradek> yeah
[18:20:31] <cradek> do you have a different vision for it, or would you make it look and work pretty much the same except for bugs?
[18:21:42] <jepler> I don't have a new / different design in mind
[18:22:35] <jepler> on the other hand, there have got to be improvements to be made
[18:22:45] <cradek> for one thing, I can imagine it having something like a "create new" button that gives you stepconf (or pncconf)
[18:23:15] <jepler> yes .. or an "edit" button if it can identify that a config is pncconf/stepconf-generated
[18:23:25] <cradek> that too
[18:23:58] <cradek> it's not a particularly standard paradigm so I'm struggling to come up with modern apps that work this way
[18:24:42] <jepler> I *hope* most of our users discover things like "add shortcut to desktop" and don't see pickconfig at every startup of emc
[18:24:43] <cradek> the mozilla profile chooser thingy
[18:24:56] <cradek> yes, I do too
[18:25:18] <cradek> but, some machines have two configs (I know of two people with shoptasks who do this)
[18:25:45] <jepler> there's the thing you get if you run "ooffice" without specifying a file -- it helps you to choose what kind of document to create or what template to use.
[18:26:34] <jepler> (as opposed to 'oowriter' which starts with a new text document by default)
[18:44:41] <JT-Work> now that 2.4 is released do I still only need to update the dev manual or do I need to update both dev and 2.4?
[18:46:52] <jepler> it depends
[18:47:38] <jepler> when you start adding new feature documentation that'll go on master only, obviously.
[18:48:05] <jepler> until you start doing that, I think it makes more sense to do doc improvements (like correctly documenting that cutter comp is available in XZ) on the 2.4 branch
[18:48:32] <jepler> (and those improvements will get into master by 'git merge')
[18:48:45] <JT-Work> ok, anything I do on 2.4 will get put into ... ok thanks
[18:49:26] <JT-Work> you answered my question before I could type it :)
[18:49:45] <jepler> but once you're documenting new features the merges will start conflicting more .. and if we switch to 10.04 for lyx on master (as I think/hope we will) then they'll probably never work out. at that point we'll have to reexamine what makes sense
[18:49:57] <jepler> (not making many doc changes for 2.4 is one answer to that)
[18:51:26] <JT-Work> until 10.04?
[18:53:23] <jepler> I mean, at some point you'll want to start editing the master documentation on ubuntu 10.04 (since emc 2.5 won't be on ubuntu 8.04 if it follows the "about a year" release schedule)
[18:56:01] <JT-Work> Ok, I need to start looking for a few parts to build another desktop from all the stuff I have laying about for that.
[18:56:25] <jepler> it can wait
[18:57:42] <JT-Work> ok
[19:11:58] <jepler> if tooledit is turning into a zombie, isn't it the fault of whatever started it, not the fault of tooledit itself?
[19:12:50] <dgarr> it seem to behave differently with axis and with tkemc, i added updates at the exit point and the zombies were not created (if i remember correctlly)
[19:26:47] <jepler> reading the tcl source it looks like at each [exec] it's supposed to try to reap all outstanding processes
[19:27:13] <jepler> so if you run tooledit, close it, and run one again it should reap the first one at that time
[19:27:16] <jepler> but before that it'll be a zombie
[19:27:54] <jepler> so this will rarely leave a zombie, because true almost always exits before the check: >>> t.eval("exec true &")
[19:28:15] <jepler> this will usually leave one zombie, reaped at the next exec after the time is up: >>> t.eval("exec sleep 10 &")
[19:28:19] <jepler> and this will usually leave several zombies
[19:28:23] <jepler> >>> for i in range(5): t.eval("exec sleep 5 &")
[19:33:19] <jepler> .. and a way to reap the zombies is t.eval("exec true")
[19:34:26] <cradek> that is very bizarre.
[19:35:07] <jepler> and it still doesn't match the behavior our user saw
[19:35:29] <cradek> jepler: can't you t.something(sigchild whatever, SIG_IGN)?
[19:37:23] <jepler> .. (is tooledit being started with tcl [eval] in axis, or with os.system or the like)
[19:39:07] <jepler> (aha, it's spawned with os.spwanvp and never waited!)
[19:39:20] <dgarr> i may be remembering a different problem altogether:
http://www.panix.com/~dgarrett/stuff/z.txt
[19:58:21] <jepler> I think this'll fix the axis zombie problem:
http://emergent.unpy.net/files/sandbox/0001-axis-avoid-leaving-lots-of-zombie-processes.patch
[20:03:11] <dgarr> that patch seems like a good idea, and after some reading, i'm confused: are zombies a problem other than they appear in the process table? e.g., aren't the resouces for the zombied process released?
[20:19:48] <aystarik> dgarr, no resources can not be released until process sends its exit status to parent, or parent tells kernel 'not interested'...
[20:34:47] <andypugh> Could the rtapi.conf.in file pre-add the rtapi_smi.ko lines, commented out?
[20:35:35] <andypugh> It's something of a bother having to re-edit it after a make.
[20:36:52] <andypugh> (One problem with this is that there is a missing environment variable or whatever the correct term is that means that it isn's as simple as adding a line like all the others, it needs changes to the makefile too)
[20:51:51] <jepler> I'd sure consider changes that make it easier to enable rtai_smi.ko.
[20:52:34] <jepler> (every "make" shouldn't rebuild rtapi.conf.in, though--only if you're running configure again, or running 'make clean' or something like that)
[20:56:45] <andypugh> rtapi.conf.in remains the same, but I think a fresh rtapi.conf is created from it each time?
[20:57:05] <andypugh> I might well be wrong, that wasn't what I was testing.
[20:57:14] <jepler> oops, I meant rtapi.conf
[20:58:14] <andypugh> Aye, thinking about it, it shouldn't be remade by a simple "make"
[20:58:58] <andypugh> As I said, it wasn't what I was testing. I was just reminded of it by the thread on the other channel.
[21:48:36] <Azurra> hello!
[21:49:00] <Azurra> im making a delta robot, here is the build
http://img17.imageshack.us/img17/5926/deltarende01.png
[21:49:10] <Azurra> i need to implement a kinematics controller
[21:49:38] <Azurra> can someone help me how to customise or the way that i need to go to implement that in emc
[21:49:47] <Azurra> i think that i need to know the HAL struture right
[21:50:17] <Azurra> and i need to configure the motors, signals and the kinematics (forward and inverse)
[21:51:37] <micges> did you read kinematics part of docs as alex_joni told you yesterday?
[21:51:53] <andypugh> Try the #emc channel, there are more people there, and it is a more appropriate forum.
[21:52:21] <andypugh> Unless you are writing a kinematics module, then perhaps here is good.
[21:52:53] <Azurra> i need to write that kinematics module
[21:53:27] <Azurra> the tripod program found in emc have other kinematics
[21:54:37] <andypugh> Have you looked at the other kinematics source files? They seem reasonably simple.
[21:56:31] <micges> Azurra: on that page there is info about adding own kinemtaics modules:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ContributedComponents
[21:57:36] <Azurra> i will study that, thankyou
[21:59:09] <micges> sure
[21:59:21] <micges> inform us about progress with kinematics
[21:59:28] <andypugh> There's not a _lot_ there about how to do it.
[22:00:19] <micges> andypugh: on top of page - how to compile external kinematics
[22:00:29] <micges> bottom how to use it
[22:00:36] <andypugh> But if you look in /src/emc/kinematics the kinematics files are all much the same with about 10 lines of maths to define the joint relationships.
[22:01:03] <micges> more less agree
[22:05:46] <Azurra> I already set the mathematical model of the kinematics. need to know how to implment that in emc. its a tripod, initially with three degrees of
[22:05:46] <Azurra> freedom X Y Z and three rotary joints. the mechanical design and the image that already
[22:05:46] <Azurra> spent
[22:06:46] <andypugh> Possibly start with tripodkins.c and tweak it to suit?
[22:07:25] <Azurra> I want to use the graphical interface of the existing tripod in emc to jogging or
[22:07:26] <Azurra> interpret the G code, but im lokking how to
[22:07:26] <Azurra> configure the new kinematics there.
[22:08:05] <Azurra> that kinematics are usefull in other types of mechanisms
[22:08:19] <Azurra> i will look this file .c
[22:08:23] <Azurra> thanks
[22:08:42] <micges> Azurra:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ContributedComponents#How_to_compile_and_install_a_component
[22:09:08] <micges> kinematic is hal component
[22:09:38] <andypugh> Can you write a kinematics module as a .comp?
[22:09:44] <Azurra> i think yes
[22:10:22] <Azurra> in the HAL pdf saids that the kinematics (forward and inverse) are components
[22:11:28] <Azurra> int kinematicsForward(const double *joint, EmcPose *world, const KINEMATICS_FORWARD_FLAGS
[22:11:28] <Azurra> *fflags, KINEMATICS_INVERSE_FLAGS *iflags)
[22:11:46] <Azurra> int kinematicsInverse(const EmcPose * world, double *joints, const KINEMATICS_INVERSE_FLAGS
[22:11:46] <Azurra> *iflags, KINEMATICS_FORWARD_FLAGS *fflags)
[22:12:18] <Azurra> and a home function too
[22:12:19] <Azurra> int kinematicsHome(EmcPose *world, double *joint, KINEMATICS_FORWARD_FLAGS *fflags,
[22:12:19] <Azurra> KINEMATICS_INVERSE_FLAGS *iflags)
[22:12:40] <micges> Azurra: do you have forward and inverse math for your kins?
[22:12:43] <Azurra> how the components .comp works?
[22:13:03] <Azurra> i need to wirte that in C and load in emc in order to adjust in HAL config?
[22:13:50] <andypugh> comp is a tool for creating components with a bit less C-coding. I am not sure that you can write kinematics models with it though.
[22:13:51] <andypugh> http://linuxcnc.org/docs/html/hal_comp.html
[22:14:23] <micges> it should be possible to write kins in *.comp file but it was not tested
[22:15:14] <Azurra> micges yes i have the math
[22:16:39] <micges> do you have emc sources on pc? via git?
[22:17:03] <Azurra> i had installed the 8.04 ubuntu with the emc2 installed
[22:17:06] <Azurra> not compiled
[22:17:10] <jepler> I recommend to write the kinematics as a .c file but compile and install using the comp program: [sudo] comp --install mykins.c
[22:17:14] <Azurra> i dont have the sources yet
[22:18:00] <jepler> you could look at rotatekins as an example of a full kinematics file without a lot of extra junk. I just checked that it will compile and install in this way.
http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/kinematics/rotatekins.c;h=d9f85990ebba51ac9193bcef70632e8602fd7223;hb=HEAD
[22:18:30] <Azurra> i will look that jepler thank you
[22:19:52] <jepler> you're welcome. bbl
[22:20:27] <Azurra> jepler, compiling that with the source of emc will able me to set my kinematics in the hall, its that?
[22:20:30] <Azurra> hal *
[22:21:06] <Azurra> but surely, with my custom functions
[22:21:11] <Azurra> that i will write
[22:21:56] <micges> Azurra: do you have any config created to use with your kins?
[22:22:36] <jepler> I'm not sure if I understand the question you're asking. A kinematics module can export HAL pins or parameters that affect the behavior of the kinematics. for instance, tripodkins is a generic kinematics in which several distances must be specified. tripodkins is an example of this, allowing the specification of Bx Cx and Cy parameters.
http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/kinematics/tripodkins.c;h=d871d7b
[22:23:02] <jepler> in this way, it supports a whole family of machines with different geometries but the same general system of control
[22:25:55] <Azurra> i think that could be help, i will look that thank you jepler
[22:28:12] <andypugh> I am looking for a good example of a hal file that uses a kinematics module.
[22:28:33] <andypugh> http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=configs/stepper-gantry/kinematics.hal;h=af58abd8f16e01a88bba1dfb29201625d62827b5;hb=HEAD
[22:29:16] <andypugh> Is a very brief example of how you can set parameters using pins exported by a kinematics module. (In this case very simply defining which joints share an axis)
[22:31:01] <Azurra> i will look that thanks andy
[22:43:34] <dgarr> jepler: fyi i found i needed to export EMC2_TCL_DIR from emc-environment so that emc.so can be located for both packaged versions and rip. when you test the patch you will probably want to see it follows the correct methods
[22:43:43] <dgarr> amended:
http://www.panix.com/~dgarrett/stuff/0001-tooledit-conditionally-add-button-to-write-file-AND-.patch
[23:26:30] <SWPadnos> I hope that worked
[23:26:35] <SWPadnos> logger_dev, bookmark
[23:26:35] <SWPadnos> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-05-12.txt
