Back
[01:04:01] <tomaw> [Global Notice] Hi all. One of our sponsors appears to have had a network connectivity issue. We're working with them to get the issue resolved.
[01:42:53] <SWPadnos> hey jepler, in the debuglevel.py commit, are the messages for DEBUG_DEFAULTS and DEBUG_CONFIG swapped?
[01:46:41] <SWPadnos> hmmm. also, in linux_event.py - should BTN_9 and BTN_10 have the same constant (0x109)?
[01:47:25] <SWPadnos> oh - nevermind that last one - I didn't see the later commit
[02:44:21] <jepler> SWPadnos: I dunno about the DEBUG constants, I didn't re-check them
[02:44:27] <jepler> if they're wrong please fix and commit
[02:44:41] <SWPadnos> ok. the messages just didn't seem to match the names
[02:44:59] <SWPadnos> I'll look at it next time I've got the laptop on
[02:48:51] <jmkasunich> SWPadnos: home again?
[02:48:56] <SWPadnos> yep
[03:48:55] <cradek> NOTICE: vcp is obsoleted, please use pyvcp instead
[03:48:55] <cradek> vcp will probably be removed in version 2.2
[03:49:14] <jepler> yeah that's funny everytime I see it
[03:49:34] <jepler> part of me wants to remove it but on the other hand we have users using it and it doesn't cost much
[03:51:42] <jmkasunich> fun with image processing:
[03:51:47] <jmkasunich> http://jmkasunich.com/pics/mach-vision/test1-raw.png
[03:51:53] <jmkasunich> http://jmkasunich.com/pics/mach-vision/test1-flat.png
[03:52:23] <jmkasunich> note the dark marks on the straightedge - they're 3" apart
[03:52:44] <jepler> coo
[03:52:50] <jmkasunich> the mirror is just under 12" from the tabletop, and I can see all of a 36" yardstick plus a bit
[03:53:08] <cradek> does the yardstick still look straight if it's further from being a diameter?
[03:53:18] <jmkasunich> yes
[03:53:22] <cradek> it looks really good
[03:53:41] <jmkasunich> note the edge of the table above the yardstick
[03:53:54] <cradek> nice
[03:54:13] <jmkasunich> now I just need to do some optimization
[03:54:33] <jmkasunich> this is a totally naive inplementation, takes a sizable fraction of a second to flatten the image
[03:54:57] <jmkasunich> flattening is probalby only a few percent of the total work I want to do per frame
[03:55:42] <jmkasunich> how does one profile in the gcc/linux world
[03:55:50] <seb> gprof
[03:55:51] <jmkasunich> last time I did any profiling was in the turbo C days
[03:59:24] <SWPadnos> did you write that or use imagemagick?
[03:59:30] <SWPadnos> (looks good btw)
[03:59:33] <jmkasunich> wrote it
[03:59:44] <SWPadnos> cool
[03:59:52] <jmkasunich> it is just the first stage in a bunch of processing
[03:59:59] <SWPadnos> yep :)
[04:05:55] <jmkasunich> this is encouraging - 93% of the time is in two functions, and I already intended to eliminate them
[04:06:31] <jmkasunich> funct 1 (79%) computes the distance from the center (on the floor), given the distance from the center (on the camera sensor)
[04:07:14] <jmkasunich> funct 2 (14%) calls funct 1 repeatedly to get the distance on the sensor given the distance on the floor (the inverse of #1 - doesn't lend itself to direct calc)
[04:07:17] <SWPadnos> printf("now processing pixel at (%04d,%04d), color=(0x%02X,0x%02X,0x%02X)\n", x, y, r, g, b); :)
[04:07:57] <jmkasunich> I already planned to generate a table of maybe 100 values and slopes, and interpolate, instead of running the calcs every time
[04:08:44] <SWPadnos> or use polar coords - they may be useful anyway since you need to "rotate this much and move that far" ...
[04:08:50] <jmkasunich> I am
[04:08:56] <SWPadnos> ah
[04:09:29] <jmkasunich> for each pixel in the output (flat) image, I convert to polar, then sent the radius value thru the "floor to pixel" calc, then convert back to rectangular to get the camera pixel that the data should come from
[04:10:11] <jmkasunich> that also allows me to very cheaply rotate the image, to correct for the orientation of the vehicle relative to the world coordinate system
[04:10:42] <SWPadnos> this is 640x480 resolution?
[04:10:52] <jmkasunich> the camera image is 640x480
[04:10:56] <SWPadnos> ok
[04:11:26] <jmkasunich> the flat image is 481 x 481 (so there is a pixel at the center), at 0.08" per pixel
[04:11:42] <jmkasunich> the size and resolution of the flat image can be whatever I want
[04:11:56] <SWPadnos> you could make an image map with the color values being the x,y distance or something, then just do a pixel lookup
[04:12:10] <SWPadnos> right - you're more or less backwards raytracing, right?
[04:12:24] <jmkasunich> yes
[04:13:03] <jmkasunich> I've thought about lookup tables, and for stuff where a table is Nx1 (one row, one column, a radial line, etc) it is a win
[04:13:21] <jmkasunich> but if the table is NxM, the size of the table will probably cause cache thrashing
[04:13:41] <jmkasunich> these days, computation is so much faster than memory access, you gotta watch that
[04:13:46] <SWPadnos> heh
[04:14:11] <jmkasunich> there is one trivial optimization I should do right now
[04:14:52] <jmkasunich> if the radius (on the floor) is greater than 21", it is off the mirror (that causes the "rays" shooting out from the round output image
[04:15:05] <jmkasunich> I can detect that very early, and just write a constant value into those pixels
[04:15:25] <jmkasunich> the red pixels are another detection - where the desired pixel is outside the camera frame
[04:15:29] <SWPadnos> white (ie, not "edge marks")
[04:15:33] <SWPadnos> yep
[04:19:03] <jmkasunich> that took it from 0.87 seconds down to 0.55
[04:19:15] <jmkasunich> the lookup table will be _much_ more effective
[04:19:18] <jmkasunich> but that is a task for tomorrow
[04:23:29] <LawrenceG> jmkasunich, very cool
[04:37:16] <cradek> it's so nice when something shows 93% in the profiling output
[04:42:09] <cradek> yuck, another task problem, I think
[04:42:26] <cradek> if AXIS sends a mode switch "too soon" (?) after doing something else, it's lost
[04:42:44] <cradek> for instance, jog with wheel, stop, hit f5 right away
[04:43:52] <cradek> or hold down continuous jog arrow, hit f5 (machine does stop)
[04:44:25] <cradek> AXIS has wait_complete() in all the right places, as far as I can tell. it's not sending another message right afterward or anything.
[04:45:07] <SWPadnos> jogging with the wheel doesn't involve AXIS, does it?
[04:45:17] <cradek> nope
[04:45:25] <SWPadnos> so there's no wait_complete for it to wait for
[04:45:37] <cradek> true
[04:46:10] <cradek> poking F5 while jogwheeling reproduces the problem every time
[04:46:40] <cradek> you have to be in free mode (motion) to jogwheel
[04:46:51] <cradek> going to mdi switches to coordinated mode
[04:47:03] <cradek> the problem (whatever it is) might even be in motion I guess
[04:47:30] <SWPadnos> I wonder if AXIS can wait for in_position or something
[04:47:37] <SWPadnos> (icky, but maybe workable)
[04:47:53] <cradek> maybe
[04:48:08] <cradek> I'm not sure what's the problem and what's symptoms here
[04:48:23] <SWPadnos> yeah. me either (by a longshot :) )
[04:48:57] <cradek> I noticed this because I'm using halui.mode.is-manual to change what the jogwheel does (jogs in manual mode, otherwise changes max vel)
[04:49:30] <cradek> the irritating symptom is that sometimes when I switch to the MDI tab, the wheel still unexpectedly jogs
[04:49:44] <SWPadnos> hmmm. scan delays?
[04:49:51] <cradek> scan?
[04:50:07] <SWPadnos> uh - loop time in the userspace programs
[04:50:35] <SWPadnos> a race condition more or less, since userspace apps aren't synchronized like RT threads
[04:50:52] <cradek> hm
[04:53:33] <cradek> aside from not wanting to throw out and rewrite task, I'd sure like to throw out and rewrite task
[04:53:49] <SWPadnos> yeah, that's sure a tough dichotomy
[05:18:35] <CIA-40> EMC: 03seb 07v2_2_branch * 10emc2/src/emc/usr_intf/emclcd.cc: fix a bogus conditional test
[12:03:04] <CIA-40> EMC: 03bigjohnt 07TRUNK * 10emc2/share/axis/images/axis.ngc: add y offset so a stock stepconf config will not throw an error
[12:43:39] <CIA-40> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/man/man1/gs2.1: update man page
[12:46:17] <CIA-40> EMC: 03bigjohnt 07TRUNK * 10emc2/src/hal/user_comps/gs2_vfd.c: finish at-speed pin :)
[12:48:25] <BigJohnT> * BigJohnT heads out
[13:09:18] <jepler> I'm not sure about this change to axis.ngc
[13:09:38] <jepler> I assume it's intended to make sure that the entire drawing is to the right of X0 but I'm not sure why that's important
[13:09:52] <jepler> too bad I missed BigJohnT
[13:10:54] <archivist> for a noob you get errors when running axis.ngc
[13:12:25] <jepler> learn to use the goddamn touch off button monkey
[13:12:36] <jepler> s/button/button,/
[13:12:46] <jepler> you'll have to learn how sooner or later anyway
[13:13:28] <archivist> there is no help or obvious info at that stage
[13:14:16] <jepler> I think this all comes back to the fact that I simply hate users
[13:14:45] <jepler> oh well, time to drive to the office
[13:14:46] <jepler> bbl
[13:14:50] <archivist> :)
[13:15:12] <archivist> hey Im a user :((
[13:15:35] <jepler> then gett off this channel
[13:16:02] <archivist> nice behaviour
[13:16:49] <jepler> oh, don't take me *too* serious
[13:17:09] <jepler> for instance, I apparently lied earlier when I said I was leaving to drive to the office
[13:17:30] <Guest938> Guest938 is now known as skunkworks_
[13:17:48] <jepler> hi skunkworks_
[13:17:55] <jepler> skunkworks_: tell archivist that I'm actually quite nice, will you?
[13:17:58] <archivist> Ive just been kick banning a real bad boy a few doors down in #mysql
[13:19:00] <skunkworks_> Good morning! jepler is nice and a real person. (I have acutally met him) Although I didn't ask for ID..
[13:19:12] <jepler> with that settled i'm really leaving this time
[13:32:27] <skunkworks_> jepler: I think it came about from this
http://www.cnczone.com/forums/showthread.php?t=71680
[13:39:45] <jepler> wow too bad there's so much bad advice in that thread
[13:40:52] <skunkworks_> heh
[14:01:32] <cradek> haha #19
[14:02:23] <cradek> a few of the posts are right on
[14:02:32] <cradek> the rest, less so, to varying degrees
[14:02:46] <jepler> where's the "mark as best answer" button?
[14:03:27] <cradek> I don't agree with putting the G92 in axis.ngc. it's true it won't run without a work offset, but that is correct behavior
[14:03:53] <cradek> so many people cut that - it should be a correct program with top of material = 0
[14:04:31] <cradek> otherwise it will be very surprising
[14:04:46] <jepler> the Z travel is -.01 to 0.10
[14:06:04] <cradek> oh, the g92 moves it in Y, not Z
[14:06:10] <cradek> I'm confused as to what problem this fixed
[14:06:13] <jepler> I had trouble reading it too
[14:07:07] <cradek> now it cuts the splash screen above wherever Y happens to be...?
[14:07:20] <cradek> that can't be what he meant to do
[14:07:27] <jepler> I kinda think that's what that G92 means but I haven't tried it
[14:08:23] <cradek> yeah that's what it does
[14:09:02] <cradek> http://timeguy.com/cradek-files/emc/principle-of-most-surprise.png
[14:10:54] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/share/axis/images/axis.ngc: this was a mistake because it will run with Y being wherever the tool starts. very confusing.
[14:11:04] <cradek> I reverted it. I bet we can come up with a better fix if we know what the problem is.
[14:11:12] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/src/po/fr_axis.po: french translation - recents shortcuts
[14:12:45] <cradek> does cvsps -u not work well, or is it just me? -x gives me correct results but -u says things are new when they aren't
[14:13:02] <jepler> I haven't tried to use cvsps lately
[16:52:31] <skunkworks_> they say the number of people at the inauguration was a record but the number of people watching from tv was 2nd highest. (first place went to president regan) Someone at work here asked if they took into account internet and such... I think that is an interesting question.
[16:53:37] <SWPadnos> yep
[16:54:04] <SWPadnos> I actually listened via someones phone, it had less delay than the radio
[16:55:09] <SWPadnos> (and it was easier to make out actual words than listening directly :) )
[16:55:50] <skunkworks_> heh - could you actually see podium from your location?
[16:55:59] <SWPadnos> no
[16:56:08] <SWPadnos> but we could see the capital building
[16:57:29] <SWPadnos> if you pull up a map of DC, you can see where we were
[16:57:45] <SWPadnos> corner of 1st st NW and Louisiana Ave NW
[16:58:32] <SWPadnos> standing by the tree (near the white truck) on the right side of the pseudo-triangular building on that corner
[16:59:12] <skunkworks_> heh
[17:00:17] <SWPadnos> it was kind of funny. we took a walk around the capital on Sunday night to look at the setup
[17:00:51] <SWPadnos> the stage was several stories high and huge - we could have put several copies of my house on it
[17:01:09] <SWPadnos> they had a couple of big screens for the ticket holders to watch
[17:01:21] <SWPadnos> the left had one had some inaugural logo on it
[17:01:33] <SWPadnos> the right one had "World Series of Poker" on :)
[17:02:13] <SWPadnos> I'm sure they changed the channel before Tuesday rolled around
[17:03:02] <skunkworks_> Maybe ;)
[17:03:58] <SWPadnos> oh, and if you saw/heard on the news that there was a huge crowd of ticket-holders that weren't let in, that's where we were
[17:04:11] <SWPadnos> they started chanting something like "let us in, let us in"
[17:04:31] <SWPadnos> I said to my group, if they turn around and start coming this way, we run
[18:34:49] <jepler> I've established that EMC_DEBUG_INVALID and EMC_DEBUG_DEFAULTS are not used, so I'm going to remove them
[18:35:11] <jepler> should I leave the other bit values the same, and have 0x1 and 0x4 as unused bits? or should I move the other used bits "down"?
[18:35:29] <SWPadnos> hmmm
[18:35:54] <SWPadnos> I guess making a note that ini changes are needed and moving them may be the best solution
[18:36:05] <SWPadnos> or leaving them :)
[18:36:21] <jepler> specifying unused bits is harmless
[18:36:27] <jepler> renumbering them does needlessly break inifiles, though
[18:36:36] <jepler> so I'll remove them but not renumber
[18:36:44] <SWPadnos> ok, sluonds good to me
[18:36:49] <SWPadnos> -l
[18:39:46] <SWPadnos> heh: Results 1 - 8 of about 6 for sluonds. (0.38 seconds)
[18:40:30] <jepler> there really aren't any useful messages printed by EMC_DEBUG_IO_POINTS or EMC_DEBUG_TRAJ
[18:40:43] <jepler> oh well, no harm in leaving them even if there's only a single one
[18:41:20] <SWPadnos> IO_POINTS is probably useless with HAL around
[18:41:28] <SWPadnos> TRAJ shouldn't be (but still may be)
[18:41:42] <jepler> if (emcStatus->io.aux.estop) {
[18:41:42] <jepler> if (emcStatus->motion.traj.enabled) {
[18:41:42] <jepler> if (EMC_DEBUG & EMC_DEBUG_IO_POINTS) {
[18:41:42] <jepler> rcs_print("emcStatus->io.aux.estop=%d\n",
[18:41:42] <jepler> emcStatus->io.aux.estop);
[18:41:53] <jepler> ^^ only IO_POINTS debug left
[18:42:03] <jepler> /*! \todo FIXME */
[18:42:03] <jepler> if (EMC_DEBUG & EMC_DEBUG_TRAJ) {
[18:42:03] <jepler> printf("emcStatus->motion.traj.mode = %d\n",
[18:42:03] <jepler> emcStatus->motion.traj.mode);
[18:42:16] <jepler> ^^ both EMC_DEBUG_TRAJ are about like this (emcsh.cc, so only seen by people using tkemc/mini)
[18:42:32] <jepler> it makes a puzzle for me: what user-visible string should describe those debug bits?
[18:42:56] <SWPadnos> how do you mean?
[18:44:10] <jepler> calling EMC_DEBUG_TRAJ "Trajectory" makes me think more of the trajectory planner
[18:44:25] <jepler> not just being told what the motion.traj.mode is
[18:45:01] <SWPadnos> yep, me too
[18:45:44] <jepler> and why's it a "fixme" anyway
[18:46:06] <SWPadnos> was there an "#if 0" nearby?
[18:46:30] <jepler> not by that one
[18:46:52] <SWPadnos> ok. that looked like one of Paul's search/replace fixmes
[18:46:53] <jepler> 1.9 (paul_c 12-Jun-05): /*! \todo FIXME */
[18:46:53] <jepler> 1.1 (paul_c 15-Feb-04): if (EMC_DEBUG & EMC_DEBUG_TRAJ) {
[18:47:00] <cradek> !*#|\!~~/| fixme!
[18:47:25] <jepler> revision 1.9
[18:47:25] <jepler> date: 2005/06/12 15:46:02; author: paul_c; state: Exp; lines: +9 -10
[18:47:25] <jepler> todo tags added to all FIXME comments so that they get highlighted when auto-generating docs.
[18:47:51] <jepler> - // FIXME
[18:47:51] <jepler> + /*! \todo FIXME */
[18:48:12] <jepler> 1.1 (paul_c 15-Feb-04): // FIXME
[18:48:19] <SWPadnos> heh
[18:48:21] <jepler> so it's simply always said "fixme" since time began
[18:48:39] <SWPadnos> but now it says the new and improved todo FIXME !
[18:48:55] <jepler> not todo, \todo
[18:49:30] <SWPadnos> not a big to do
[18:49:30] <cradek> hm, I spell that "XXX"
[18:49:44] <jepler> that'll get your website blacklisted
[18:49:50] <jepler> reason forbidden: adult content
[18:49:54] <cradek> ha
[18:49:59] <jepler> your supervisor has been notified
[18:50:07] <jepler> and you will be escorted off the premises
[18:50:22] <cradek> % grep ' XXX' interp_convert.cc|wc -l
[18:50:23] <cradek> 15
[18:51:42] <jepler> huh, I didn't know there was an aborted attempt to add classicladder to emc1. Module path or alias:
[18:51:45] <jepler> oops
[18:51:50] <jepler> http://cvs.linuxcnc.org/cvs/emc/src/classicladder/?hideattic=0#dirlist
[18:52:10] <SWPadnos> emc1 had classicladder
[18:52:13] <cradek> huh, I didn't know that either
[18:52:17] <cradek> SWPadnos: ???
[18:52:25] <SWPadnos> I thought it did anyway
[18:52:29] <cradek> are you sure?
[18:52:42] <SWPadnos> but thinking about it, I don't see how you could have connected it to anything
[18:53:26] <jepler> it was converted from an unconditional print to a conditional one 7+ years ago, and the todo was first added then
http://cvs.linuxcnc.org/cvs/emc/src/emctask/emcsh.cc#rev1.17
[18:54:24] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/emcsh.cc: since 7 years 8 months ago there are better ways to monitor this morsel of status
[18:55:04] <cradek> jepler: in the old cutter comp code, it does keep the time constant when the path gets shorter/longer. this means the actual feed does change. This seems wrong to me. I think I recall that you agree it is wrong. Is that true?
[18:56:15] <cradek> for instance when cutting outside, a straight move gets changed into an arc (going around the corner) and then a straight. The current code calculates (arc length + new straight length) and sets feed (combined length * Fword).
[18:56:34] <jepler> that's certainly another interpretation
[18:56:47] <cradek> I think it should set feed to (original straight length * Fword)
[18:57:04] <cradek> (for both moves)
[18:57:21] <jepler> I think both moves should be made at the same feed rate
[18:57:34] <cradek> yes, and they are (in both systems)
[18:57:51] <SWPadnos> I think the moves should be at the originally programmed rate
[18:58:05] <jepler> what *is* the originally programmed rate, though?
[18:58:05] <cradek> SWPadnos: the rate isn't programmed, the time is
[18:58:18] <SWPadnos> oh, in inverse time mode
[18:58:19] <cradek> there isn't one, directly
[18:58:19] <SWPadnos> hmmm
[18:59:18] <SWPadnos> this may be a Stuart-type question - what's the more common assumption by CAM software
[18:59:31] <SWPadnos> or G-coders
[18:59:53] <jepler> the whole point is that you don't care to figure out the offset path
[19:00:02] <cradek> it won't matter much with cam. they will always generate nominal tool path
[19:00:04] <jepler> so how will you figure out the proper inverse time mode feed for the offset path?
[19:00:33] <jepler> therefore, the resulting feed must be the one that's appropriate for the unoffset move
[19:00:46] <cradek> to me it comes down to "you don't use inverse time mode to guarantee the program will finish in 100 seconds" but that seems to be the thing the original authors thought was important
[19:01:23] <SWPadnos> predictable timing may be necessary in some conditions, but I imagine there are more cases where surface finish and chipload are important
[19:01:25] <cradek> they did preserve the timings, no matter how much faster or slower the tool has to go when offset
[19:02:01] <SWPadnos> and jeplers reasoning is sound to me also, so I say F=(original length/programmed time)
[19:02:42] <cradek> ok, that's what I'm going to do.
[19:02:55] <cradek> and get rid of some more XXXs
[19:03:03] <SWPadnos> you porn addict you
[19:03:35] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: since 7 years 8 months ago there are better ways to monitor this morsel of status
[19:10:04] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/debuglevel.py: get rid of unused EMC_DEBUG bits
[19:10:05] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/emc/nml_intf/emcglb.h: get rid of unused EMC_DEBUG bits
[19:10:06] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: get rid of unused EMC_DEBUG bits
[19:21:54] <cradek> arg
[19:40:56] <jepler> any reason not to hard-code motmod these days ? it's another thing that seems to be a "you'll never change this inifile setting" setting
[19:41:30] <jepler> [EMCMOT]EMCMOT=motmod
[19:41:49] <cradek> iirc, it has optional arguments for num_dio num_aio
[19:42:19] <jepler> oh, you think you could write EMCMOT=motmod num_dio=3 num_aio=3?
[19:42:47] <cradek> something like that
[19:44:00] <cradek> who knows how that will expand though
[19:44:10] <jepler> indeed, i'm not sure
[19:49:47] <cradek> argh, arcs
[19:49:55] <cradek> it's always arcs
[19:50:18] <jepler> can you just forbid arcs?
[19:50:47] <cradek> CHKF((move > G_1), "Sorry, I'm too tired to finish writing this"))
[19:50:51] <SWPadnos> error: this program contains arcs, inverse time, and cutter comp. run anyway?
[19:51:24] <SWPadnos> error: this program contains G-code. run anyway? :)
[19:51:26] <cradek> CHKF((move > G_1), (_("Sorry, I'm too tired to finish writing this")))
[19:51:34] <cradek> ^ very important
[19:53:30] <skunkworks_> heh - 'running this gcode my cause the downfall of civilization'
[19:54:08] <SWPadnos> run anyway?
[19:55:30] <skunkworks_> heh
[20:02:49] <jepler> some days I think halui should have more smarts built in
[20:03:02] <jepler> 'halui.pauseresume' is as sensible as the pauseresume toolbar icon in axis
[20:03:34] <cradek> yes quite possibly
[20:03:49] <jepler> as soon as 2 people do it in hal, it would have been less time to do it in halui where you have "C"
[20:03:51] <cradek> if you light the button up with .is-paused, it would be fine
[20:04:16] <cradek> s/2/1/
[20:04:30] <jepler> will you go as low as 0.75?
[20:04:40] <cradek> probably
[20:07:33] <jepler> Thu Dec 21 16:22:12 2000 UTC (8 years, 1 month ago) by wshackle * If you put a small linear move on the same line as a large rotational move, then the rotational axis will move very fast and probably exceed following error limits. This is a result of the odd way the feedrate is defined.
[20:08:13] <cradek> I fixed that many many moons ago
[20:08:13] <jepler> (this is the check-in that "[a]dds some support for programming ABC moves with the new interpreter"
[20:08:16] <jepler> )
[20:08:21] <cradek> ah
[20:08:57] <cradek> how could 2000 have been 8 years ago? that's crazy talk.
[20:09:48] <jepler> parts of 2000 are now 9 years ago
[20:19:27] <skunkworks_> a little over 1/24 of 2000.
[20:23:16] <alex_joni> 1/24 of 2000 is 83./3
[20:23:29] <alex_joni> so you mean 1/240 probably
[20:28:59] <cradek> jepler: now that I'm trying to test something else, it keeps coming up with maxvel=0 again
[20:29:18] <jepler> cradek: that's odd
[20:30:29] <jepler> you could turn on debug of task issue to see whether something's issuing a setting of maxvel
[20:30:51] <jepler> (presumably it would be axis, though I can't imagine why)
[20:35:49] <cradek> will someone check for me: what g93 f word do I program for a 1" diameter semicircle to get 10 inch/min feed?
[20:37:12] <jepler> the arc length is pi inches
[20:37:30] <jepler> pi inch / (10 inch/minute) = 3.18
[20:37:37] <jepler> is the answer to your quiz "F3.18"?
[20:37:41] <cradek> pi/2?
[20:38:25] <jepler> 6.37, then?
[20:38:30] <cradek> sorry, diameter+semicircle is confusing
[20:38:33] <jepler> beats me, I've never programmed in G93
[20:38:39] <cradek> good, thanks
[20:38:50] <cradek> if 6.37 is the right answer, my code is at least approximately right
[20:40:24] <jepler> in 2.2.9~cvs, this gives me velocity of 10.0060 on the AXIS DRO: g93 / g0x0y0z0 / g2x1i.5f6.37 / m2
[20:40:48] <cradek> thanks
[20:41:04] <alex_joni> pi/2/10/60 gives me about 9.42 ?
[20:41:13] <cradek> the compensated arcs also give 10 now
[20:41:36] <jepler> $ units '1|2 pi inch / (10 inch/minute)' '1/minute'
[20:41:37] <jepler> reciprocal conversion
[20:41:37] <jepler> * 6.3661977
[20:42:07] <alex_joni> too complicated for this late :)
[20:44:13] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (interp_convert.cc interp_inverse.cc rs274ngc.hh): fix inverse time mode for cutter-compensated paths
[21:11:39] <cradek> jepler: you are right.
http://pastebin.ca/raw/1315668
[21:12:02] <cradek> this is what I get when starting sim/axis. I did not do anything to the gui.
[21:12:09] <cradek> it only happens 'sometimes'
[21:12:48] <alex_joni> recent TRUNK?
[21:12:55] <cradek> yes
[21:13:06] <alex_joni> I just cvs up,I'll test in jas
[21:14:25] <cradek> for now I am getting it every time.
[21:14:35] <alex_joni> (still compiling)
[21:15:04] <alex_joni> Max Velocity?
[21:15:11] <cradek> yes
[21:15:12] <alex_joni> it's 72 in/min on startup
[21:15:25] <cradek> sometimes it gets set to 0
[21:16:34] <alex_joni> not once in 6 starts
[21:17:00] <alex_joni> this is a VM , so it might be slower
[21:17:06] <cradek> I've had it dozens in a row now
[21:17:22] <alex_joni> did you change DEBUG?
[21:17:29] <cradek> yes to 0x10
[21:17:40] <alex_joni> * alex_joni tries that
[21:17:56] <cradek> it was doing it before I changed DEBUG; that's why I changed it
[21:21:15] <alex_joni> I get: pastebin.ca/raw/1315677
[21:21:24] <alex_joni> I notice the order is slightly different than yours
[21:22:15] <jepler> here's what mine gave when the problem didn't occur (it hasn't happened to me yet):
http://pastebin.ca/raw/1315680
[21:22:33] <alex_joni> yup, same as mine
[21:23:02] <alex_joni> only chris's config/machine makes MAX_VELOCITY to be sent later with a value of 0
[21:23:14] <alex_joni> cradek: you sure cvs diff -u is void?
[21:24:20] <cradek> the only changes I have from trunk are sim.var and some ngc files
[21:25:50] <alex_joni> looking at axis.py, I don't understand why it behaves it does for me & jepler
[21:25:53] <jepler> cradek: did I just imagine that you made "display units" one of the remembered things?
[21:26:06] <jepler> (it doesn't remember for me)
[21:26:15] <cradek> right, I didn't do that
[21:26:16] <alex_joni> cradek's outcome looks more inline with lines 1560 and abouts
[21:26:28] <cradek> recently I did block delete and optional stop
[21:26:52] <jepler> ah that must be what I was thinking of
[21:27:14] <jepler> cradek: tried adding a debug print of self.stat.max_velocity there by where alex mentions?
[21:28:32] <alex_joni> ~
[21:28:46] <jepler> mine doesn't print any output before the first SET_MAX_VELOCITY
[21:28:49] <jepler> I wonder if yours might
[21:29:48] <cradek> http://pastebin.ca/raw/1315687
[21:30:26] <cradek> those three prints are after line 1561
[21:30:43] <cradek> right before if time.time() > spindlerate_blackout
[21:30:51] <alex_joni> huh
[21:31:57] <alex_joni> how about right after time.time() > maxvel_blackout: ?
[21:32:27] <alex_joni> how does one debug print in python again? (print foo) ?
[21:32:35] <cradek> print "foo", foo
[21:33:41] <alex_joni> crap.. forgot to make
[21:34:32] <alex_joni> ok, it gets sent from somewhere else I think
[21:34:54] <cradek> halui???
[21:35:00] <alex_joni> no, in AXIS
[21:35:01] <cradek> I bet so
[21:35:03] <cradek> oh
[21:35:05] <alex_joni> bot some other place
[21:35:07] <alex_joni> I think
[21:35:11] <alex_joni> but it might be halui too
[21:35:32] <cradek> maybe "sometimes" means "when I run a config with halui"
[21:35:35] <alex_joni> aha
[21:35:42] <alex_joni> sim/axis.ini runs halui
[21:35:47] <alex_joni> try running without
[21:36:03] <alex_joni> but the idea is that I get SET_MAX_VELOCITY was earlier than the max_vel 1.2
[21:36:13] <alex_joni> max_vel 1.2 is printed by AXIS
[21:37:50] <cradek> it's not halui
[21:38:01] <alex_joni> old_halui_data.mv_counts is never initialized as 0
[21:38:40] <cradek> it doesn't to be initialized until counts_enable becomes true
[21:38:44] <alex_joni> right
[21:38:50] <alex_joni> just read that now :/
[21:38:51] <cradek> maybe even shouldn't be
[21:38:57] <alex_joni> ok, so halui is a red herring
[21:39:12] <cradek> yes, it's got to be AXIS
[21:40:26] <alex_joni> hmm.. I'm running sim.. wonder if that makes a difference
[21:40:39] <jepler> self.stat.max_velocity 1e+99
[21:40:40] <jepler> Issuing EMC_TRAJ_SET_MAX_VELOCITY -- (+207,+20, +9,0.000000,)
[21:40:48] <alex_joni> whee
[21:40:50] <cradek> sim here
[21:40:58] <jepler> maxVelocity -> 999999999999999967336168804116691273849533185806555472917961779471295845921727862608739868455469056.000000
[21:41:06] <cradek> uhh
[21:41:18] <alex_joni> pastebin.ca/1315689
[21:41:50] <alex_joni> jepler: maxVelocity is self.stat...?
[21:43:19] <jepler> actuall yI printed it in taskintf.cc
[21:46:50] <alex_joni> hmm.. that comes from emcmotcfg->limitVel
[21:47:13] <alex_joni> which gets initialized in motion.c: emcmotConfig->limitVel = VELOCITY
[21:47:20] <jepler> on my system it's initially 1e99 just line on chris's
[21:47:25] <jepler> but then my emc issues a "set" to 1.2
[21:47:29] <jepler> his "set"s to 0.0
[21:47:42] <alex_joni> and VELOCITY is defined as 1.0 (in emcmotcfg.h)
[21:48:07] <alex_joni> jepler: in taskintf.cc there's a testcase called if (new_config)
[21:48:18] <alex_joni> I'm not familiar with how that works, any idea what it is?
[21:48:21] <jepler> no
[21:48:34] <jepler> but I get my maxVelocity print very often, so it must often be true
[21:48:51] <jepler> int emcMotionUpdate(EMC_MOTION_STAT * stat)
[21:48:53] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/tests/interp/inverse-time-with-comp/ (README expected inverse.ngc test.sh test.tbl test.var): inverse time feed mode test
[21:48:56] <jepler> new_config = 0;
[21:48:56] <jepler> if (emcmotStatus.config_num != emcmotConfig.config_num) {
[21:48:58] <jepler> new_config = 1;
[21:49:29] <alex_joni> saw that
[21:49:45] <alex_joni> but it's a global defined as 0
[21:49:56] <alex_joni> maybe changing it to 1 changes the behaviour
[21:50:22] <alex_joni> wonder if the set_foo gets called before emcMotionUpdate()
[21:52:13] <jepler> I think the intent is that new_config should be set to 1 when one of those things is changed, and then gets set back to 0 the next time around assuming there's no additional change
[21:52:32] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc:
[21:52:32] <CIA-40> EMC: after switching out of inverse time mode, you should get an error if you do not
[21:52:32] <CIA-40> EMC: specify a feed rate with the next feed move. this error was not happening
[21:52:32] <CIA-40> EMC: because the internal model was not updated when the feed rate was zeroed.
[21:52:39] <alex_joni> right.. but ...
[21:52:59] <alex_joni> new_config should only change to 1 if emcmotConfig->config_num changes
[21:53:07] <alex_joni> and that only happens in motion.c
[21:53:21] <jepler> but because maxVelocity is continually printed for me, I think it's not working properly
[21:53:44] <alex_joni> oops.. sorry..
[21:53:59] <alex_joni> config_num changes on each emcmot_config_change() call from command.c
[21:54:36] <alex_joni> it goes on printing it?
[21:54:56] <alex_joni> try setting rtapi debug to 5, and see what motion prints
[21:55:12] <alex_joni> if there are any EMCMOT_* commands which might change config
[21:56:19] <jepler> oh, forget it
[21:56:23] <jepler> I sabotaged my own debug output
[21:56:29] <alex_joni> heh, ok
[21:57:20] <jepler> cradek: I'm curious whether this has any effect:
http://pastebin.ca/1315720
[21:57:39] <jepler> it should make axis not update sliders from stat for a second after everything has stabalized
[21:58:52] <cradek> Issuing EMC_TRAJ_SET_MAX_VELOCITY -- (+207,+20, +9,1.200000,)
[21:59:05] <cradek> yes, that changes the behavior
[21:59:26] <cradek> taking it back out, I get the bad behavior again
[21:59:27] <alex_joni> btw, I also get a 1e+99 the first time from taskintf
[22:00:07] <alex_joni> after that I see the NML from AXIS to set it to 1.2
[22:00:13] <alex_joni> I get a new_config from motion
[22:00:20] <alex_joni> and maxVelocity gets updated to 1.2
[22:00:36] <alex_joni> wonder why it's 1e+99 the first time..
[22:05:08] <cradek> hm, tool table touch off and diameter mode interact badly
[22:05:41] <jepler> probably touch off and diameter mode do in general?
[22:05:50] <jepler> or does G10 L2 ... take radius always?
[22:05:53] <cradek> could be
[22:05:56] <jepler> or did you fix it once already?
[22:05:59] <cradek> yes always radius
[22:06:00] <cradek> no
[22:06:14] <cradek> ummm
[22:06:18] <cradek> now I'm not sure what it does
[22:06:26] <cradek> the TOOL TABLE is always radius
[22:06:34] <cradek> g10 l2 might be doing the bad thing
[22:06:40] <cradek> you can tell I didn't test
[22:10:05] <cradek> bbl.
[22:12:43] <alex_joni> aha
[22:12:49] <alex_joni> found it.. finally
[22:13:07] <alex_joni> initraj.cc:125
[22:13:11] <alex_joni> vel = 1e99
[22:13:24] <alex_joni> that gets sent to motion as the TRAJ max velocity
[22:13:30] <alex_joni> motion uses it to set limitVel
[22:13:41] <alex_joni> which gets to task/stat as maxVelocity
[22:13:54] <alex_joni> AXIS reads it from there, and sends SET_MAX_VEL.. 0
[22:15:06] <alex_joni> sim/axis.ini only has a [TRAJ]MAX_LINEAR_VELOCITY (no [TRAJ]MAX_VELOCITY)
[22:15:38] <alex_joni> cradek: can you test what happens if you take jepler's patch for AXIS out, and add a sane [TRAJ]MAX_VELOCITY ?
[22:16:20] <jepler> alex_joni: but on my system it reads 1e99 and sends 1.2
[22:16:37] <jepler> why on chris's system does it read 1e99 and send 0.0, but only if there's not an extra pause involved as well?
[22:16:53] <jepler> oh well
[22:17:06] <alex_joni> it shouldn't read 1e99 imo
[22:17:08] <alex_joni> ever :)
[22:17:36] <alex_joni> motion uses the value to calculate some stuff /1e99
[22:18:01] <SWPadnos> that's valid - you can set limits for individual joints, so [TRAJ]MAX = $big just disables an overall limit
[22:18:47] <alex_joni> I bet ferror won't work right then .. maybe
[22:18:59] <SWPadnos> hmmm. good point
[22:19:03] <alex_joni> limiting ferror = maxFerror/limitVel * vel
[22:19:21] <alex_joni> if limitVel is $big, -> limiting ferror = 0
[22:19:43] <alex_joni> jmkasunich should know that part better
[22:19:55] <alex_joni> * alex_joni heads to bed
[22:19:56] <jepler> ferror is per-axis, though, so the assumed sane per-axis max velocity applies
[22:20:04] <alex_joni> this was one hell of a week
[22:20:13] <jepler> have a hell of a weekend, then
[22:20:18] <SWPadnos> hell
[22:21:41] <alex_joni> well.. I'm stuck at a customers till sat. late evening
[22:21:52] <alex_joni> then I'll grab a night train back home
[22:23:01] <alex_joni> tpSetVlimit(&emcmotDebug->queue, emcmotConfig->limitVel);
[22:24:15] <alex_joni> not sure if tp->vLimit is used
[22:26:00] <alex_joni> seems like 1e99 is safe there too
[22:26:03] <alex_joni> good night all
