Back
[00:54:55] <jmkasunich> "Every intelligent individual is little more than an idiot with much
[00:54:55] <jmkasunich> potential when they are not functioning in their area of expertise."
[00:55:02] <jmkasunich> I'm gonna have to remember that
[00:55:35] <jmkasunich> I tend to forget that they are likely intelligent individuals, when they are acting like idiots because they are in my area of expertise, not theirs
[00:55:57] <SWPadnos> yes, a tough thing to reconcile sometimes
[00:56:13] <SWPadnos> especially when people seem soooooo clueless
[00:57:19] <jepler> I'm reminded of the moment when I thought "oh, this is fun -- the mazak makes this huge "thunk" everytime I resize the window!" and jmkasunich and everyone else present thought "what the hell is that idiot doing"
[00:57:37] <SWPadnos> heh
[00:57:52] <jepler> and I think I just about got tackled away from the keyboard at that point
[00:58:16] <jmkasunich> I remember that
[00:58:38] <jepler> I'm sure you do
[01:23:48] <BigJohnT> good night all
[01:23:54] <jepler> night BigJohnT
[01:23:59] <cradek> night
[01:24:04] <jepler> "E149: Sorry, no help for you!" -- vim
[01:24:24] <jepler> (admittedly, I provoked it into saying that ..)
[01:30:55] <skunkworks> jmkasunich: how is the robot coming?
[01:31:13] <jmkasunich> slowly
[01:31:27] <skunkworks> heh - I can relate ;)
[01:31:49] <jmkasunich> http://jmkasunich.com/pics/mach-vision/test/mazelog-000.html
[01:32:14] <jmkasunich> I've got a ton of init stuff done, and I just got done drawing (on paper) a test pattern
[01:32:35] <jmkasunich> time to start the image processing in earnest now
[01:33:13] <jmkasunich> that URL is updated every time I run a test
[01:33:32] <skunkworks> wow - so you created the map picture from the camera image?
[01:33:40] <jmkasunich> I wish
[01:34:07] <skunkworks> heh - Ok.. that is the final plan though?
[01:34:11] <jmkasunich> the nice squared and contrasty one is "the maze as I know it to be" (in this case, what I know about the starting point)
[01:34:24] <jmkasunich> that will be compared to what the camera sees to figure out where I am
[01:34:46] <jmkasunich> notice that I positioned the camera a little off the centerline, and a little angled
[01:34:52] <jmkasunich> my goal is to detect those deviations
[01:34:57] <skunkworks> ah - ok
[01:35:30] <jmkasunich> step 1, mask off things that aren't maze - like the camera, and the frame holding up the mirror
[01:35:44] <jmkasunich> thats what the mask image (click on initialization link) is for
[01:36:03] <jmkasunich> step 2 will be some form of image correlation
[01:36:22] <jmkasunich> step 1a might be needed - contrast and brightness adjustment
[01:38:24] <skunkworks> Very cool. Now - I can't imagine many people like you? What is the competition like?
[01:39:02] <jmkasunich> we typically have anywhere from 7 to 20 entries, depending on how tough the contest is
[01:39:14] <skunkworks> schools also?
[01:39:17] <jmkasunich> it's held at lunchtime on Friday of engineering week
[01:39:24] <jmkasunich> some times
[01:39:29] <jmkasunich> its mostly teams from work tho
[01:39:45] <jmkasunich> there are probably 1000 people in the building where I work, a couple hundred are engineers
[01:39:45] <skunkworks> sounds like fun :)
[01:39:57] <skunkworks> wow
[01:40:23] <skunkworks> ok - I will stop bothering you :)
[01:47:54] <jmkasunich> masking working
[01:48:46] <jmkasunich> less than one millisecond to apply the mask
[01:48:55] <jmkasunich> this is on my 2.4GHz core2
[03:26:08] <jepler> I have to admit I'm baffled by this interaction between O-word subroutines and RFL
[03:26:57] <jepler> it must be tied to the fact that I don't understand how the subroutines work
[03:27:28] <cradek> how do they interact?
[03:28:10] <jepler> oh, it's a bug filed by micges
[03:28:15] <jepler> define sub; call sub; call sub; call sub
[03:28:28] <jepler> use RFL almost anywhere: run starts around last "call sub"
[03:29:17] <cradek> wonder what it should do
[03:29:36] <SWPadnos> it should probably start where you set "run from this line"
[03:29:45] <cradek> uh, right
[04:35:27] <jmkasunich> woot! it is correctly detecting orientation errors:
http://jmkasunich.com/pics/mach-vision/test/mazelog-000.html
[04:36:32] <jmkasunich> next step (tomorrow): remove rotation error, then do x and y correlation
[04:37:21] <cradek> this is a pretty amazing project
[04:37:47] <jmkasunich> I think I'm going to need to do some contrast enhancment
[04:38:45] <jmkasunich> I'm really enjoying it
[04:40:11] <jmkasunich> heh, I suspected as much - when the camera isn't centered on the "road", the angular detection suffers
[04:40:30] <jmkasunich> a pure rotation appears as a side-to-side shift in the panorama
[04:41:08] <jmkasunich> but a translation distorts the panorama, the part in front shifts one way, the part in back shifts the other
[04:42:10] <jmkasunich> I think I'll wind up doing independent correlations on several chunks of the panorama
[04:42:17] <jmkasunich> front, back, each side
[04:42:22] <jmkasunich> maybe even 45 degree segments
[04:43:05] <jmkasunich> I wish I didn't have to get up in the morning - it sucks to have to stop
[04:43:12] <SWPadnos> heh
[04:55:51] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix undetected line-line-line gouge caused by losing track of the endpoint
[07:19:46] <micges> good morning
[07:21:24] <micges> sorry for add link for pastebin, I've forgot about attachments to bugreports
[07:21:41] <micges> I'll try more next time :)
[08:07:26] <alex_joni> micges: the only problem is that pastebin links go away
[08:07:31] <alex_joni> you can still attach lateron
[08:17:34] <micges> sure thanks
[08:25:01] <ehj> Alex: I got emc compiled. Running 'realtime start' runs ok,but 'halcmd show pin' gives error 'Could not open shared memory', and 'Note: rtapi kernel module must be loaded.
[08:29:16] <alex_joni> halcmd show pin?
[08:29:21] <alex_joni> did you run emc2 before that?
[08:29:31] <alex_joni> ah, sorry.. beeing obtuse
[08:29:43] <alex_joni> you still need to fix the OS
[08:29:45] <ehj> Yes, similar error when running EmC,I was just simplifying to generate an error.
[08:30:15] <alex_joni> check /etc/security/limits.conf
[08:30:20] <alex_joni> and look for:
[08:30:25] <alex_joni> * hard memlock 8192
[08:30:40] <ehj> Yea, I have not checked that on this install. Just a sec.
[08:36:25] <ehj> No same error, do I need to reboot or restart something?
[08:41:08] <ehj> Ok, got it. Thanks.
[13:11:26] <BigJohnT> while playing with g42 I noticed some unexpected things.
[13:11:28] <BigJohnT> 2 or more rapid moves after a g42 is in effect seem to cancel the offset
[13:11:30] <BigJohnT> the rapid lead in move does not show up in preview
[13:11:32] <BigJohnT> time to go to work...
[13:14:42] <BigJohnT> http://pastebin.ca/1237090
[13:15:36] <BigJohnT> must be crosseyed this morning the real link
http://pastebin.ca/1327090
[13:35:50] <micges> I have spindle with tool changer that cannot be turned on without tool becouse it will lock
[13:36:35] <micges> is there any way to M4 doesn't work when external singnal is enabled?
[13:43:35] <alex_joni> maybe you can and2 the spindle-speed-out with an inhibit HAL pin
[13:43:40] <alex_joni> or the DAC-enable
[13:43:51] <alex_joni> depending on the way you command the spindle
[13:46:40] <micges> this is idea..
[13:50:56] <micges> thanks
[13:53:30] <alex_joni> sure
[13:53:45] <alex_joni> you can also set feedhold so that emc2 doesn't move further
[13:54:52] <micges> I was thinking about iocontrol.0.tool-in-spindle pin that would be helpfull for toolchanger
[13:55:07] <micges> but your idea is much simple
[13:55:18] <micges> r
[13:56:42] <alex_joni> simple ideas are always better
[15:32:28] <CIA-2> EMC: 03tissf 07TRUNK * 10emc2/docs/src/config/emc2hal_fr.lyx: french translation update
[15:32:28] <CIA-2> EMC: 03tissf 07TRUNK * 10emc2/src/po/ (fr.po fr_axis.po fr_rs274_err.po): french translation update
[15:32:29] <CIA-2> EMC: 03tissf 07TRUNK * 10emc2/docs/src/gcode/main_fr.lyx: french translation update
[15:55:57] <cradek_> cradek_ is now known as cradek
[16:57:35] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (interp_convert.cc interp_queue.cc): fix another corner case (haha) found by testing with random paths. also clarify errors that said "too short" but are actually more general than that.
[17:02:30] <skunkworks> they keep sneaking in?
[17:04:22] <cradek> no, I'm fixing cases that nobody in a million years would program
[17:04:40] <SWPadnos> only programs people programmed would program such programs
[17:06:55] <cradek> BigJohnT: I ran your test program and it seems right to me. when you use rapids you are seeing expected behavior when it doesn't go around the corner. there are two reasons for this (1) you don't cut with rapids, so you are away from the part, so why bother to go around imaginary corners, and (2) there is no such thing as a rapid/traverse arc, so you can't rapid around a corner even if you wanted to
[17:06:55] <jepler> cradek: you should post another screenshot of one of these error cases for us to enjoy
[17:07:40] <jepler> hi seb_kuzminsky !
[17:07:48] <seb_kuzminsky> hi there :)
[17:07:50] <BigJohnT> thanks cradek I didn't know if it was correct or needed to be explained a bit in the manual.
[17:08:36] <seb_kuzminsky> i was thinking about Gianluca Costa's email, about sending coordinates to a USB device that drives the motors
[17:08:53] <seb_kuzminsky> can the sai somehow be made to emit waypoints?
[17:09:04] <seb_kuzminsky> it currently emits "canonical commands" right?
[17:09:09] <cradek> right
[17:09:18] <cradek> to emit waypoints you need a trajectory planner
[17:09:33] <seb_kuzminsky> that's what normally eats canonical commands?
[17:09:46] <cradek> yeah, more or less
[17:09:53] <jepler> with layers and layers between
[17:10:01] <seb_kuzminsky> ok
[17:10:02] <cradek> trajectory planner takes a path and generates waypoints that meet various demands/constraints
[17:10:40] <cradek> if his unknown device wants some form of lines/arcs and it does the planning, maybe sai is a starting point for him
[17:11:01] <seb_kuzminsky> right
[17:11:11] <seb_kuzminsky> if it truly needs waypoints he'd need "satp"
[17:11:39] <cradek> yeah
[17:12:47] <jepler> this kind of system can exist (obviously; it's the direction non-linux pc cnc seems to be going) but if the real answer is "you might be able to take 25% of emc and 75% of your own code" I just find it easier to say "no, not really"
[17:13:49] <seb_kuzminsky> satp would'd mean breaking up the EMCMOT block and putting his USB device where the "AXIS *" blocks are
[17:13:53] <seb_kuzminsky> http://www.linuxcnc.org/images/stories/EMC_Control_LG.gif
[17:14:33] <jepler> yes, something like that
[17:14:53] <jepler> which means you end up throwing out HAL and run emcmot as a userspace app and hope for the best
[17:15:15] <seb_kuzminsky> i see
[17:15:43] <jepler> (e.g., you can't use a hal net to hook a limit switch to the AXIS block)
[17:16:05] <cradek> jepler: here's one that's easy to see. most of them are hard to make sense of without practice.
http://timeguy.com/cradek-files/emc/unreachable-corner.png
[17:16:37] <cradek> path starts at the top, tool on right
[17:17:00] <cradek> also, note the correct and appropriate error message :-)
[17:17:42] <jepler> I think you should say that these are cases no human would intentionally write
[17:17:46] <cradek> um, tool on "right" (left on screen)
[17:17:57] <jepler> hand written gcode will contain all kinds of unintentional errors that would lead to unintended paths
[17:18:12] <cradek> yes they definitely don't describe the outline of a part...
[17:18:20] <BigJohnT> that's for sure :)
[17:18:22] <jepler> I'm pleased that comp_tort seems to be helping you
[17:18:53] <cradek> yes it was a big help. I think I might be done now, actually.
[17:20:17] <cradek> http://timeguy.com/cradek-files/emc/wtf-but-correctly-compensated.png
[17:25:51] <alex_joni> that's nice :D
[17:25:55] <cradek> I'm a little unhappy with the numeric instability of find_turn (determine what angle the arc sweeps out). If you change the radius, you get a slightly different number. I suppose that's life though.
[17:27:19] <cradek> "change the radius" = move the endpoints toward or away from the center a bit, using sin/cos after finding angles with atan2
[17:28:05] <cradek> alex_joni: I've looked at hundreds of these paths
[17:33:07] <alex_joni> cradek: I believe you.. it's probably awfull after a while
[17:33:36] <cradek> only if you see bugs - it's fun otherwise
[17:35:08] <alex_joni> heh
[17:35:22] <alex_joni> well... I failed at installing ubuntu on a server today :/
[17:35:36] <alex_joni> grub didn't want to install on /dev/rd/c0d0
[18:34:57] <alex_joni> http://coolepochcountdown.com/
[18:38:38] <BigJohnT> you find the neat stuff alex_joni
[18:40:49] <alex_joni> someone remind me.. does emc2 now keep the spindle running when switching modes by default?
[18:41:14] <SWPadnos> I was looking for an option to decide that, but I don't see one
[18:41:27] <alex_joni> I think it's by default now
[18:41:29] <SWPadnos> (if it has SPINDLE in it somewhere - that's what I've been looking for but not finding)
[18:41:32] <BigJohnT> you said it did alex_joni :) so it must be so
[18:41:33] <alex_joni> there was an option at one point
[18:41:48] <alex_joni> BigJohnT: if I did, then it's settled
[18:41:54] <alex_joni> I just need to say it again :D
[18:42:09] <alex_joni> (in a way that matches my first explanation)
[18:42:19] <SWPadnos> I'd find your first explanation :)
[18:44:03] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/task/emctaskmain.cc.diff?r1=1.114;r2=1.115;f=h
[18:44:27] <alex_joni> goes together with commit log "to allow run-from-line to work better, let the user set the spindle
[18:44:30] <alex_joni> and coolant and TLO how it's needed, using either manual or MDI, and
[18:44:33] <alex_joni> then don't mess it up when changing modes and resuming the program."
[18:45:03] <SWPadnos> so that will be in 2.3, but isn't in 2.2
[18:45:08] <alex_joni> indeed
[20:12:58] <SWPadnos> hmmm. maybe docs didn't work for me. I didn't notice that imagemagick wasn't installed, which disabled doc building
[20:21:34] <dgarr> I am converting a programming interface to use axis (I've been using tkemc for a few years).
[20:21:34] <dgarr> I wonder if this patch could be considered:
[20:21:34] <dgarr> http://pastebin.ca/1327401
[20:23:54] <SWPadnos> the addition of the cycle time looks pretty inocuous. what kind of things are you thinking would be added in the user_live_update function?
[20:26:02] <dgarr> i have a interface that does several things -- all the functions are specific to my application which is sort of a cad/cam program for
[20:26:12] <dgarr> ornamental turning
[20:27:13] <dgarr> the change allows any user to add addtional hooks to their own programs (in my case tcl scripts with their own gui)
[20:27:46] <SWPadnos> well, other than the potential confusion factor, I don't see a problem with it
[20:28:06] <dgarr> what is the confusion factor you mention?
[20:28:09] <SWPadnos> (confusion arising out of programs that look like AXIS but aren't quite the same, when support questions arise)
[20:28:50] <jepler> what are the consequences and benefits of changing the update time?
[20:29:12] <jepler> the older GUIs have an inifile item that specifies how often they update, but axis has never paid attention to it. it would be more consistent to use the inifile item that they established, instead
[20:29:21] <jepler> [DISPLAY]CYCLE_TIME, I think it is
[20:29:45] <dgarr> it allows me to run at slower updates, with less cpu time, while i'm usingthe computer for multiple things
[20:29:51] <jepler> update_ms = int(1000 * float(inifile.something(..., 20))
[20:30:22] <dgarr> i can study that and try to do it that way if you prefer
[20:30:44] <SWPadnos> it would probably make more sense, since other UIs already use that method
[20:30:56] <cradek> how do you use this user_live_update? I'm trying to understand what it's used for
[20:31:28] <jepler> If I guess right, it lets dgarr's custom code (whatever it is:-P) update exactly as often as the axis backplot/dro
[20:31:50] <dgarr> i have myown gui that updates many items and coordinate updates without having competing/duplicate update cycles
[20:31:58] <jepler> just using root_window.after() in axisrc would already let you do nearly the same thing, but it wouldn't be in lock step with the "regular" update
[20:32:05] <jepler> istm
[20:32:53] <cradek> I see, thanks
[20:33:12] <dgarr> it's the lock step that made sense to me
[20:34:23] <jepler> change the inifile thing and then it sounds fine to me
[20:34:24] <jepler> bbl
[20:34:51] <CIA-2> EMC: 03swpadnos 07TRUNK * 10emc2/docs/src/hal/pyvcp.lyx: Fix text describing radiobutton state in the sample image
[20:35:09] <dgarr> ok, i'll work on that, thanks
[20:59:04] <dgarr> try2:
http://pastebin.ca/1327439
[21:05:24] <jepler> aha! and curse you, pastebin!
[21:05:42] <jepler> wget
http://pastebin.ca/raw/... gives a file with DOS line endings
[21:06:20] <jepler> I bet I've unintentionally introduced some CRLFs that way myself
[21:06:36] <SWPadnos> well of course. Linux ysers are smarrt enough to fix it
[21:07:04] <jepler> if they know they've been sent sabotaged data
[21:09:04] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[21:09:04] <CIA-2> EMC: the following are not new features:
[21:09:04] <CIA-2> EMC: * add saved files to recent file menu
[21:09:04] <CIA-2> EMC: * respect [DISPLAY]CYCLE_TIME
[21:09:04] <CIA-2> EMC: * add a hook called every time the dro is updated; for user customization
[21:11:54] <dgarr> Thanks!
[21:15:13] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/tests/interp/crazy-paths/ (README expected test.ngc test.sh test.tbl test.var): new comp test
[21:15:46] <cradek> tests aren't features either
[21:17:02] <jepler> cradek: you're absolutely right about that
[21:17:15] <cradek> neither is this:
[21:17:18] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: stay above line-to-arc "h" shape just like we stay above the arc-to-line one
[21:22:48] <cradek> the tests sure are useful for interp work.
[21:23:46] <dgarr> example of my application integrated with axis -- i can create gcode file and transfer with onepush, display running time, program line,etc:
[21:23:48] <dgarr> http://imagebin.ca/view/g5-MwN.html
[21:24:45] <cradek> neato
[21:25:46] <cradek> max velocity 25920 inches/minute?
[21:25:51] <dgarr> the addition of [DISPLAY]GEOMETRY was the impetus for me to convert stuff
[21:26:02] <dgarr> velocity is because of rotary axis
[21:26:15] <dgarr> its degrees/minute
[21:26:18] <jepler> dgarr: oh, you're using that to preview rotary code? neat, I'm glad that feature's being used
[21:26:18] <dgarr> actually
[21:26:30] <jepler> I see the C-axis moves now
[21:31:54] <dgarr> i have to set [TRAJ]MAX_VELOCITY >= [AXIS_5]MAX_VELOCITY but it displays in linearunits/min -- minor problem, seems like a lot of work to change
[21:32:29] <cradek> in 2.3 you won't have to set [TRAJ]MAX_VELOCITY
[21:32:48] <cradek> and you can set the tops of the sliders individually so they make sense
[21:32:49] <dgarr> i'm using trunk for these tests
[21:33:08] <cradek> oh then you should be able to fix it
[21:33:26] <dgarr> tried and failed
[21:33:30] <cradek> see configs/sim/axis_9axis.ini
[21:38:05] <jepler> dgarr: cradek recently fixed Max Velocity so that it applies to linear moves only
[21:38:08] <jepler> (I think)
[21:38:18] <jepler> I dunno about jog speed, however
[21:38:21] <dgarr> i tried it , and again now, it reads Max Velocity of 72 in/min on the slider, maybe i'm doing something wrong
[21:39:11] <cradek> dgarr: max velocity *should* be in/minute
[21:39:16] <cradek> it does not apply to rotary moves
[21:39:33] <jepler> [TRAJ]MAX_LINEAR_VELOCITY ?
[21:39:33] <cradek> jogs have a separate linar and rotary setting
[21:39:44] <cradek> yes
[21:39:49] <jepler> or should I RTFM before I OMBFM?
[21:40:01] <cradek> I might be missing something here, but I think axis_9axis.ini works correctly
[21:41:50] <cradek> until very recently the max velocity slider incorrectly influenced rotary motion. this is fixed
[21:41:52] <dgarr> but, if i remember, to obtain to the max velocity for a rotary axis, i have to set [TRAJ]MAX_VELOCITY >= the max velocity specified for the fastest rotary axis and the display is confusing since it reads in/min where i set it because of needed degreees/minute -- i'm not complaining, i think it may be unusual case with a fast rotary axis?
[21:42:22] <SWPadnos> oh, well if you're not complaining ...
[21:42:24] <SWPadnos> :)
[21:42:32] <cradek> dgarr: now you don't have to set [TRAJ]MAX_VELOCITY at all, just for the reason you describe (it made no sense with differing units)
[21:50:33] <dgarr> ok, i just tested removing [TRAJ]MAX_VELOCITY and it seems to work (sim)-- it must have been changed after I first tried it? thanks again!
[21:52:25] <cradek> quite possibly! I have broken and then fixed many things lately.
[21:52:39] <dgarr> all to the good i'm sure
[21:52:59] <cradek> of course, my ideas are all good, just ask me
[22:02:32] <dgarr> application view with deleted [TRAJ]MAX_VELOCITY showing correct (linear) Max Velocity and side cutting example
[22:02:34] <dgarr> http://imagebin.ca/view/2czydh.html
[22:16:10] <jepler> cool
[22:16:10] <jepler> bbl
[23:05:13] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/scripts/runtests: side-by-side diff is useless
