"Every intelligent individual is little more than an idiot with much
potential when they are not functioning in their area of expertise."
I'm gonna have to remember that
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
yes, a tough thing to reconcile sometimes
especially when people seem soooooo clueless
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"
and I think I just about got tackled away from the keyboard at that point
I remember that
I'm sure you do
good night all
"E149: Sorry, no help for you!" -- vim
(admittedly, I provoked it into saying that ..)
jmkasunich: how is the robot coming?
heh - I can relate ;)
[01:31:49] <jmkasunich> http://jmkasunich.com/pics/mach-vision/test/mazelog-000.html
I've got a ton of init stuff done, and I just got done drawing (on paper) a test pattern
time to start the image processing in earnest now
that URL is updated every time I run a test
wow - so you created the map picture from the camera image?
heh - Ok.. that is the final plan though?
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)
that will be compared to what the camera sees to figure out where I am
notice that I positioned the camera a little off the centerline, and a little angled
my goal is to detect those deviations
ah - ok
step 1, mask off things that aren't maze - like the camera, and the frame holding up the mirror
thats what the mask image (click on initialization link) is for
step 2 will be some form of image correlation
step 1a might be needed - contrast and brightness adjustment
Very cool. Now - I can't imagine many people like you? What is the competition like?
we typically have anywhere from 7 to 20 entries, depending on how tough the contest is
it's held at lunchtime on Friday of engineering week
its mostly teams from work tho
there are probably 1000 people in the building where I work, a couple hundred are engineers
sounds like fun :)
ok - I will stop bothering you :)
less than one millisecond to apply the mask
this is on my 2.4GHz core2
I have to admit I'm baffled by this interaction between O-word subroutines and RFL
it must be tied to the fact that I don't understand how the subroutines work
how do they interact?
oh, it's a bug filed by micges
define sub; call sub; call sub; call sub
use RFL almost anywhere: run starts around last "call sub"
wonder what it should do
it should probably start where you set "run from this line"
woot! it is correctly detecting orientation errors: http://jmkasunich.com/pics/mach-vision/test/mazelog-000.html
next step (tomorrow): remove rotation error, then do x and y correlation
this is a pretty amazing project
I think I'm going to need to do some contrast enhancment
I'm really enjoying it
heh, I suspected as much - when the camera isn't centered on the "road", the angular detection suffers
a pure rotation appears as a side-to-side shift in the panorama
but a translation distorts the panorama, the part in front shifts one way, the part in back shifts the other
I think I'll wind up doing independent correlations on several chunks of the panorama
front, back, each side
maybe even 45 degree segments
I wish I didn't have to get up in the morning - it sucks to have to stop
EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix undetected line-line-line gouge caused by losing track of the endpoint
sorry for add link for pastebin, I've forgot about attachments to bugreports
I'll try more next time :)
micges: the only problem is that pastebin links go away
you can still attach lateron
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.
halcmd show pin?
did you run emc2 before that?
ah, sorry.. beeing obtuse
you still need to fix the OS
Yes, similar error when running EmC,I was just simplifying to generate an error.
and look for:
* hard memlock 8192
Yea, I have not checked that on this install. Just a sec.
No same error, do I need to reboot or restart something?
Ok, got it. Thanks.
while playing with g42 I noticed some unexpected things.
2 or more rapid moves after a g42 is in effect seem to cancel the offset
the rapid lead in move does not show up in preview
time to go to work...
[13:14:42] <BigJohnT> http://pastebin.ca/1237090
must be crosseyed this morning the real link http://pastebin.ca/1327090
I have spindle with tool changer that cannot be turned on without tool becouse it will lock
is there any way to M4 doesn't work when external singnal is enabled?
maybe you can and2 the spindle-speed-out with an inhibit HAL pin
or the DAC-enable
depending on the way you command the spindle
this is idea..
you can also set feedhold so that emc2 doesn't move further
I was thinking about iocontrol.0.tool-in-spindle pin that would be helpfull for toolchanger
but your idea is much simple
simple ideas are always better
EMC: 03tissf 07TRUNK * 10emc2/docs/src/config/emc2hal_fr.lyx: french translation update
EMC: 03tissf 07TRUNK * 10emc2/src/po/ (fr.po fr_axis.po fr_rs274_err.po): french translation update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/gcode/main_fr.lyx: french translation update
cradek_ is now known as cradek
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.
they keep sneaking in?
no, I'm fixing cases that nobody in a million years would program
only programs people programmed would program such programs
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
cradek: you should post another screenshot of one of these error cases for us to enjoy
hi seb_kuzminsky !
hi there :)
thanks cradek I didn't know if it was correct or needed to be explained a bit in the manual.
i was thinking about Gianluca Costa's email, about sending coordinates to a USB device that drives the motors
can the sai somehow be made to emit waypoints?
it currently emits "canonical commands" right?
to emit waypoints you need a trajectory planner
that's what normally eats canonical commands?
yeah, more or less
with layers and layers between
trajectory planner takes a path and generates waypoints that meet various demands/constraints
if his unknown device wants some form of lines/arcs and it does the planning, maybe sai is a starting point for him
if it truly needs waypoints he'd need "satp"
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"
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
yes, something like that
which means you end up throwing out HAL and run emcmot as a userspace app and hope for the best
(e.g., you can't use a hal net to hook a limit switch to the AXIS block)
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
path starts at the top, tool on right
also, note the correct and appropriate error message :-)
I think you should say that these are cases no human would intentionally write
um, tool on "right" (left on screen)
hand written gcode will contain all kinds of unintentional errors that would lead to unintended paths
yes they definitely don't describe the outline of a part...
that's for sure :)
I'm pleased that comp_tort seems to be helping you
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
that's nice :D
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.
"change the radius" = move the endpoints toward or away from the center a bit, using sin/cos after finding angles with atan2
alex_joni: I've looked at hundreds of these paths
cradek: I believe you.. it's probably awfull after a while
only if you see bugs - it's fun otherwise
well... I failed at installing ubuntu on a server today :/
grub didn't want to install on /dev/rd/c0d0
[18:34:57] <alex_joni> http://coolepochcountdown.com/
you find the neat stuff alex_joni
someone remind me.. does emc2 now keep the spindle running when switching modes by default?
I was looking for an option to decide that, but I don't see one
I think it's by default now
(if it has SPINDLE in it somewhere - that's what I've been looking for but not finding)
you said it did alex_joni :) so it must be so
there was an option at one point
BigJohnT: if I did, then it's settled
I just need to say it again :D
(in a way that matches my first explanation)
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
goes together with commit log "to allow run-from-line to work better, let the user set the spindle
and coolant and TLO how it's needed, using either manual or MDI, and
then don't mess it up when changing modes and resuming the program."
so that will be in 2.3, but isn't in 2.2
hmmm. maybe docs didn't work for me. I didn't notice that imagemagick wasn't installed, which disabled doc building
I am converting a programming interface to use axis (I've been using tkemc for a few years).
I wonder if this patch could be considered:
[20:21:34] <dgarr> http://pastebin.ca/1327401
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?
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
the change allows any user to add addtional hooks to their own programs (in my case tcl scripts with their own gui)
well, other than the potential confusion factor, I don't see a problem with it
what is the confusion factor you mention?
(confusion arising out of programs that look like AXIS but aren't quite the same, when support questions arise)
what are the consequences and benefits of changing the update time?
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
[DISPLAY]CYCLE_TIME, I think it is
it allows me to run at slower updates, with less cpu time, while i'm usingthe computer for multiple things
update_ms = int(1000 * float(inifile.something(..., 20))
i can study that and try to do it that way if you prefer
it would probably make more sense, since other UIs already use that method
how do you use this user_live_update? I'm trying to understand what it's used for
If I guess right, it lets dgarr's custom code (whatever it is:-P) update exactly as often as the axis backplot/dro
i have myown gui that updates many items and coordinate updates without having competing/duplicate update cycles
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
I see, thanks
it's the lock step that made sense to me
change the inifile thing and then it sounds fine to me
EMC: 03swpadnos 07TRUNK * 10emc2/docs/src/hal/pyvcp.lyx: Fix text describing radiobutton state in the sample image
ok, i'll work on that, thanks
aha! and curse you, pastebin!
gives a file with DOS line endings
I bet I've unintentionally introduced some CRLFs that way myself
well of course. Linux ysers are smarrt enough to fix it
if they know they've been sent sabotaged data
EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
EMC: the following are not new features:
EMC: * add saved files to recent file menu
EMC: * respect [DISPLAY]CYCLE_TIME
EMC: * add a hook called every time the dro is updated; for user customization
EMC: 03cradek 07TRUNK * 10emc2/tests/interp/crazy-paths/ (README expected test.ngc test.sh test.tbl test.var): new comp test
tests aren't features either
cradek: you're absolutely right about that
neither is this:
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
the tests sure are useful for interp work.
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
max velocity 25920 inches/minute?
the addition of [DISPLAY]GEOMETRY was the impetus for me to convert stuff
velocity is because of rotary axis
dgarr: oh, you're using that to preview rotary code? neat, I'm glad that feature's being used
I see the C-axis moves now
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
in 2.3 you won't have to set [TRAJ]MAX_VELOCITY
and you can set the tops of the sliders individually so they make sense
i'm using trunk for these tests
oh then you should be able to fix it
tried and failed
dgarr: cradek recently fixed Max Velocity so that it applies to linear moves only
I dunno about jog speed, however
i tried it , and again now, it reads Max Velocity of 72 in/min on the slider, maybe i'm doing something wrong
dgarr: max velocity *should* be in/minute
it does not apply to rotary moves
jogs have a separate linar and rotary setting
or should I RTFM before I OMBFM?
I might be missing something here, but I think axis_9axis.ini works correctly
until very recently the max velocity slider incorrectly influenced rotary motion. this is fixed
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?
oh, well if you're not complaining ...
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)
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!
quite possibly! I have broken and then fixed many things lately.
all to the good i'm sure
of course, my ideas are all good, just ask me
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
EMC: 03cradek 07TRUNK * 10emc2/scripts/runtests: side-by-side diff is useless