Back
[01:51:07] <jmkasunich> cradek: jepler: do either of you have a webcam?
[01:51:52] <jmkasunich> I'm seeing what looks like a problem in lib_png, but the rule of "if you think there is a bug in a major library, you are probably wrong" makes me want an independent test
[01:52:50] <jmkasunich> using the version of vgrabbj (framegrabber) distributed with ubuntu 6.06, when I output jpeg, everything is fine, but when I output png, red and blue are swapped
[01:53:17] <jmkasunich> I've studied the source of vgrabbj as well as the lib_png man page, it appears that they are invoking lib_png correctly
[01:53:38] <jmkasunich> when I add a lib_png call that says "treat the input as BGR instead of RGB", it works
[01:54:01] <jmkasunich> but if the data was _really_ BGR, then I'd expect the jpeg output to have swapped colors as well
[02:14:34] <jmkasunich> partial enlightnement
[02:14:57] <jmkasunich> vgrabbj's jpeg output code swaps red and blue
[02:15:27] <jmkasunich> that means the data from the camera must be BGR instead of RGB, and the vgrabbj author only fixed that for jpeg, not png
[02:27:56] <cradek> I bet you've got it
[02:29:22] <jmkasunich> it seems amazing that this hasn't been noticed before
[02:29:30] <jmkasunich> maybe everyone uses jpeg
[02:29:34] <cradek> yeah
[02:29:54] <jmkasunich> I'm checking ubuntu's trackers, no bugs files against vgrabbj
[02:30:13] <jmkasunich> the vgrabbj "upstream" site seems rather stale
[02:31:10] <jmkasunich> I have a hunch I know why no reports
[02:31:41] <jmkasunich> apparently some cameras reverse red and blue themselves, so vgrabbj has an option to reverse them
[02:32:06] <jmkasunich> if someone tests with jpeg and gets the wrong thing, it is the camera, they use the option and carry on
[02:32:15] <cradek> yeah cameras give Y+r+b in various formats
[02:32:26] <jmkasunich> if someone tests with png and gets the wrong thing, it is the code, but they blame the camera, use the option, and carry on
[02:32:40] <jmkasunich> only if you test both jpeg and png with the same camera do you realise that the code is wrong
[02:32:50] <cradek> ah
[02:33:13] <jmkasunich> in my case, I'm hacking vgrabbj, I want the image in memory for further processing, not a file
[02:33:24] <jmkasunich> but I was driving myself nuts testing
[02:34:39] <jmkasunich> I'm trying to decide if I should file a bug report against vgrabbj
[02:34:48] <cradek> why not?
[02:35:20] <jmkasunich> because it will take me some time to carefully test (for all I know, the png code is correct, and the swap he's doing for jpeg is the bug)
[02:35:34] <jmkasunich> and because the upstream dev seems to have dried up
[02:35:53] <cradek> and it's bordering on being a "who cares" bug
[02:36:32] <jmkasunich> last upstream release was several years ago, ubuntu has a 380K diff, 98% of which is packaging/automake/autoconf changes, and the last 2% is fixing some casts that cause warnings or errors on newer compilers
[02:37:58] <jmkasunich> I think to truly test this, I need to create a dummy image with areas of solid red, green, and blue in a known order, then output that image (instead of a captured image) using his jpeg and png writer routines
[02:38:08] <jmkasunich> that will tell me which writer is correct and which is busted
[02:43:05] <jmkasunich> http://packages.ubuntu.com/dapper/vgrabbj
[02:43:23] <jmkasunich> universe is the least "blessed" level isn't it?
[02:43:30] <jepler> no, "multiverse" is worse
[02:43:38] <jmkasunich> ah
[02:43:47] <jepler> good evening
[02:43:51] <jmkasunich> hello
[02:43:53] <jepler> no, I don't have a webcam
[02:44:14] <jmkasunich> at this point, I'm convinced the bug is in vgrabbj anyway
[02:44:28] <jepler> sounds like
[02:44:35] <jmkasunich> he's explicitly swapping red and blue when writing jpeg, and not when writing png
[02:45:26] <jmkasunich> the proper fix is to eliminate that file-writer specific swapping code, and have users request a swap of the captured data if they have a camera that does things backwards
[02:45:47] <jmkasunich> the problem with that is that the 95% of people who use jpeg will have to change their command lines if the fix goes in
[02:45:50] <jepler> fwiw I notice that hardy's and jaunty's versions are about the same.
[02:46:22] <jepler> no new upstream version
[02:46:26] <jmkasunich> yeah
[02:46:37] <jmkasunich> all use 0.9.6 from upstream
[02:46:46] <jmkasunich> dapper patches it to 0.9.6-2
[02:47:12] <jmkasunich> fiesty thru intrepid all patch it to 0.9.6-3
[02:47:22] <jmkasunich> jaunty 0.9.6-3.1
[02:47:36] <jmkasunich> I should see if 3.1 does anything in that area
[02:49:44] <jmkasunich> http://pastebin.ca/1312197
[02:50:24] <jmkasunich> I wonder where those bug numbers (432195, etc) are?
[02:50:41] <jmkasunich> ubuntu, debian? note that the maintainers are xxx@debian.org
[02:51:59] <jmkasunich> debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432195
[02:54:04] <cradek> whee
[02:54:29] <cradek> I'm rewriting cutter comp to be plane-agnostic, and it's almost right
[02:54:57] <jmkasunich> yay
[02:55:41] <cradek> and the code looks a LOT better. it completely sucked.
[03:00:16] <cradek> ha,
http://timeguy.com/cradek-files/emc/thats-no-arc.png
[03:00:41] <jmkasunich> cool
[03:00:55] <cradek> I bet you didn't know emc could do involute curves
[03:01:01] <jmkasunich> I didn't
[03:01:06] <cradek> (AXIS doesn't know it either, as you can see)
[03:01:10] <jmkasunich> now you need to turn that into a feature
[03:01:23] <cradek> oh right, sure I do
[03:07:36] <cradek> when I fix the swapped right/left comp for lathe, I'm going to break everyone's existing programs
[03:08:23] <jmkasunich> that sucketh
[03:08:42] <cradek> well if they used comp (does anyone?)
[03:08:55] <cradek> they will have to swap g41/g42 to fix it
[03:09:05] <jmkasunich> I generated a test image instead of trusting the camera - the image data fades from red to blue, and the vgrabbj jpeg writer stores it wrong
[03:15:44] <cradek> heh, I found the bug, on the line with "// XXX ??? "
[03:15:51] <cradek> ... which I put there yesterday or so
[03:28:46] <jepler> cradek: oops, all lathe comp was wrong always?
[03:28:56] <cradek> yes
[03:30:09] <cradek> right/left appeared correct for AXIS's view and also on lathes with the tool on the front
[03:30:27] <cradek> but I got to thinking about it when jmk and swp were talking about arcs appearing backward
[03:30:41] <cradek> arcs are backward for a reason, and so should be comp
[03:31:06] <cradek> then I got to thinking about all the minus signs in the comp code to make it work this way...
[03:31:53] <jmkasunich> woo-hoo - yellow things are no longer cyan!
[03:32:25] <cradek> which way did you fix it?
[03:32:54] <jmkasunich> I didn't fix vgrabbj at all
[03:33:02] <jmkasunich> my own stuff is derived from there
[03:33:11] <jmkasunich> I now have functions that properly write jpegs and pngs
[03:33:24] <jmkasunich> and my camera capture function has an arg that says "swap red and blue"
[03:33:31] <jmkasunich> actually camera init
[03:34:06] <jmkasunich> vgrabbj had a lot of complex stuff - it stored all config data as well as camera data and image buffers in one structure
[03:34:19] <jmkasunich> that included info about output files, ftp and timestamping, etc
[03:34:30] <jmkasunich> I pulled the camera related stuff out into "lib_vgrab"
[03:35:06] <jmkasunich> three functs:
[03:35:54] <jmkasunich> camera_init ( int width, int height, char *device_name (defaults to /dev/video), int swaprb, struct <somelinuxvideothing> tweaks )
[03:36:08] <jmkasunich> tweaks is usually null, unless you want to vary the cameras settings for brightness, etc
[03:36:24] <jmkasunich> then camera_grab(struct camera)
[03:36:31] <jmkasunich> and finally camera_free(struct camera)
[03:36:38] <jmkasunich> the init function returns a struct camera
[03:36:47] <jmkasunich> the grab function returns a pointer to the image in a buffer
[03:38:32] <cradek> have you done any of the image processing stuff yet?
[03:38:41] <jmkasunich> gonna start that now
[03:38:42] <cradek> seems like this will be a different kind of e-week where a lot of programming is involved
[03:38:52] <jmkasunich> yeah, that is their goal
[03:39:03] <jepler> stupid question -- are you CPU-constrained? if so, compressing to png and decompressing in another process may turn out to be a bottleneck
[03:39:21] <jepler> or was the whole png thing a detour and you are planning to grab and analyze in the same process?
[03:39:26] <jmkasunich> I will be cpu constrained
[03:39:28] <jepler> (a way to see the problem)
[03:39:39] <jmkasunich> but I won't be doing png output during the run
[03:39:50] <jmkasunich> the ability to output to file is only for testing
[03:40:01] <jepler> got it
[03:40:10] <jepler> as usual the good ideas have long since occurred to you when I have them
[03:40:15] <jmkasunich> I'll call camera_init, then in a loop, call camera_grab(), and pass that result to whatever processing
[03:41:50] <jmkasunich> if only I hadn't spent the whole weekend on framegrabbing, I might have actually been able to experiment with the real processing
[03:42:25] <jmkasunich> I probably could have done proof-of-principle testing with a pipe of programs passing files
[03:43:05] <jmkasunich> its particularly ironic that I spent a chunk of a day chasing the red/blue thing, since one of my first processing steps will probably be to convert to grayscale
[03:43:15] <cradek> ha
[03:43:49] <SWPLinux> you need to know the color planes to convert to grayscale
[03:43:55] <jmkasunich> ?
[03:44:02] <SWPLinux> though it isn't so important in this case
[03:44:19] <SWPLinux> gray value isn't 1/3R 1/3G 1/3B
[03:44:21] <jmkasunich> you mean weights for red, green, and blue
[03:44:26] <SWPLinux> it's like 0.42G ... yes
[03:44:51] <jmkasunich> not important in this case
[03:44:59] <jmkasunich> I'm tracking black lines on white floor
[03:45:13] <SWPLinux> I know the field will be grayscale, but out of field areas may not be
[03:45:22] <SWPLinux> yeah, it's not so important here
[03:45:30] <jmkasunich> actually, the grayscale reduction is more for speed (1/3 the data)
[03:45:55] <jmkasunich> the base algorithms are just matching new image to previous to see how I've moved
[03:46:05] <jmkasunich> that would work with color too, but would take longer
[03:46:08] <cradek> jepler: a regression test found a bug for me that was not in any of my test programs (R format comp-entry arcs)
[03:46:17] <cradek> the tests are very nice to have.
[03:47:15] <jepler> that's nice, as long as you remember to run them
[03:47:20] <jepler> and have some idea what the tests are testing when one goes wrong
[03:48:20] <cradek> in this case, I just loaded the ngc and could plainly see the wrong arc.
[03:48:52] <jepler> somebody should make a test of the canned cycles
[03:49:10] <cradek> true
[04:13:14] <cradek> and inverse time
[05:25:33] <cradek> whew
[05:25:34] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/tests/ccomp/lathe-comp/ (expected test.ngc): refactor cutter compensation to make it as plane-agnostic as possible, and fix mixed-up right/left for ZX plane.
[05:25:41] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (4 files): refactor cutter compensation to make it as plane-agnostic as possible, and fix mixed-up right/left for ZX plane.
[13:16:29] <CIA-40> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/user_intro.lyx: fix images
[13:16:29] <CIA-40> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/ (image-to-gcode.lyx mini.lyx): fix images
[13:16:30] <CIA-40> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/tool_compensation.lyx: fix images
[13:40:31] <jepler> fenn: I just changed some stuff on git.unpy.net -- can you let me know if a 'pull' still works for you?
[13:40:49] <jepler> .. I'll read back later, bbl
[14:00:33] <stustev> just read this about Samba 4 - Samba also changed its scripting language to Python which Bartlett says should be easier for administrators, and there are bindings for other tools - another reason to learn Python - just what I need, more things to TRY to learn
[14:05:23] <fenn> python is easy
[14:06:29] <fenn> jepler: this works: git clone git://git.unpy.net/offs.git
[14:06:53] <fenn> this doesn't: git clone
http://git.unpy.net/offs.git
[14:07:22] <fenn> i think that means you need to do git-update-server-info
[14:08:59] <BigJohnT> BigJohnT is now known as BigJohnTatWork
[14:28:32] <jepler> fenn: ok thanks, I'll look at it
[14:35:09] <jepler> fenn: fixed?
[15:15:43] <jepler> If base_period_nsec isn't specified, no base-thread is created. if traj_period_nsec isn't specified, it defaults to servo_period_nsec.
[15:16:01] <jepler> in our sample configs, I'd like to eliminate servo_period_nsec everywhere (or at least in trivkins machines)
[15:16:15] <jepler> and similarly I'd like to eliminate base_period_nsec in configurations that don't add anything to the thread
[15:16:21] <cradek> do you mean eliminate traj?
[15:16:27] <jepler> er yes
[15:16:33] <cradek> that sounds smart to me
[15:18:49] <jepler> huh, boss uses the awfully low SERVO_PERIOD = 200000 (it's based on motenc)
[15:34:28] <cradek> ugh. seems like inverse time feeds should change when the move is shortened
[15:42:38] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/boss/boss.hal: remove DOS line endings
[15:53:19] <cradek> jepler: I bet 5kHz isn't at all hard for a pci based system with no base thread
[15:54:45] <jepler> maybe so
[15:54:53] <jepler> it's too fast for pluto, but that's epp
[15:56:07] <skunkworks_> jepler: did you see I have had the pluto running for days now without any problems?
[15:57:14] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/boss/ (boss.hal boss.ini pid_test.hal pid_test.ini):
[15:57:14] <CIA-40> EMC: get rid of BASE_PERIOD where base thread is not used.
[15:57:14] <CIA-40> EMC: get rid of TRAJ_PERIOD when the implicit value (=1 SERV_PERIOD) is acceptable.
[15:58:27] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/boss/pid_test.hal: remove DOS line endings
[15:58:56] <skunkworks_> I do zing it every once in a while. (just quits responding) but I really have a messy setup for testing. Keeps on ticking though.
[15:59:15] <jepler> "zing it"
[15:59:15] <jepler> ?
[15:59:31] <skunkworks_> I figure static electricity
[15:59:40] <skunkworks_> or too much noise getting into it.
[16:00:09] <jepler> does it go to "dim LED" unprogrammed state?
[16:00:21] <skunkworks_> yes
[16:00:36] <jepler> huh
[16:00:44] <skunkworks_> it requires a unplug of the power before emc will see it again./
[16:00:50] <skunkworks_> to the pluto
[16:00:53] <jepler> huh
[16:01:16] <jepler> it must be in some other state than "unprogrammed but ready to receive program"
[16:02:30] <jepler> are you using a USB connector for power
[16:02:30] <jepler> ?
[16:02:55] <jepler> (hm but under that theory I think it would go to an unpowered mode ..)
[16:03:05] <jepler> (if something caued a USB over-current condition)
[16:05:10] <skunkworks_> yes - usb power
[16:07:14] <jepler> I think this isn't likely, but next time take a look in dmesg to see if there's a message about over-current on a USB port
[16:11:29] <skunkworks_> ah - neat. Will do
[16:12:33] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/sim/ (.cvsignore position_mm.txt): the position file should not be in cvs
[16:14:49] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/5axis/ (5axis.ini 5axis_sim.hal):
[16:14:49] <CIA-40> EMC: Get rid of BASE_PERIOD where base thread is not used.
[16:14:49] <CIA-40> EMC: Get rid of TRAJ_PERIOD when the implicit value (1 SERVO_PERIOD) is acceptable.
[16:14:50] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/Sherline3Axis/ (Sherline3Axis_inch.ini Sherline3Axis_mm.ini):
[16:14:50] <CIA-40> EMC: Get rid of BASE_PERIOD where base thread is not used.
[16:14:53] <CIA-40> EMC: Get rid of TRAJ_PERIOD when the implicit value (1 SERVO_PERIOD) is acceptable.
[16:14:55] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/Sherline4Axis/ (Sherline4Axis_inch.ini Sherline4Axis_mm.ini stepper_xyza.hal):
[16:14:58] <CIA-40> EMC: Get rid of BASE_PERIOD where base thread is not used.
[16:15:00] <CIA-40> EMC: Get rid of TRAJ_PERIOD when the implicit value (1 SERVO_PERIOD) is acceptable.
[16:15:02] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/SherlineLathe/ (SherlineLathe_inch.ini SherlineLathe_mm.ini):
[16:15:05] <CIA-40> EMC: Get rid of BASE_PERIOD where base thread is not used.
[16:15:07] <CIA-40> EMC: Get rid of TRAJ_PERIOD when the implicit value (1 SERVO_PERIOD) is acceptable.
[16:15:09] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/common/ (core_servo.hal core_sim.hal core_sim9.hal core_stepper.hal):
[16:15:12] <CIA-40> EMC: Get rid of BASE_PERIOD where base thread is not used.
[16:15:14] <CIA-40> EMC: Get rid of TRAJ_PERIOD when the implicit value (1 SERVO_PERIOD) is acceptable.
[16:15:24] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/dallur-thc/ (dallur-advanced.ini dallur-core_stepper.hal):
[16:15:27] <CIA-40> EMC: Get rid of BASE_PERIOD where base thread is not used.
[16:15:29] <CIA-40> EMC: Get rid of TRAJ_PERIOD when the implicit value (1 SERVO_PERIOD) is acceptable.
[16:15:31] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/demo_mazak/ (demo_mazak.hal demo_mazak.ini):
[16:15:33] <CIA-40> EMC: Get rid of BASE_PERIOD where base thread is not used.
[16:15:35] <CIA-40> EMC: Get rid of TRAJ_PERIOD when the implicit value (1 SERVO_PERIOD) is acceptable.
[16:15:37] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/demo_sim_cl/demo_sim_cl.ini:
[16:15:39] <CIA-40> EMC: Get rid of BASE_PERIOD where base thread is not used.
[16:15:41] <CIA-40> EMC: Get rid of TRAJ_PERIOD when the implicit value (1 SERVO_PERIOD) is acceptable.
[16:15:43] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/demo_step_cl/demo_step_cl.ini:
[16:15:53] <CIA-40> EMC: Get rid of BASE_PERIOD where base thread is not used.
[16:15:55] <CIA-40> EMC: Get rid of TRAJ_PERIOD when the implicit value (1 SERVO_PERIOD) is acceptable.
[16:15:57] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/etch-servo/ (etch.hal etch.ini):
[16:15:59] <CIA-40> EMC: Get rid of BASE_PERIOD where base thread is not used.
[16:16:01] <CIA-40> EMC: Get rid of TRAJ_PERIOD when the implicit value (1 SERVO_PERIOD) is acceptable.
[16:16:03] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/halui_halvcp/halui.ini:
[16:16:05] <CIA-40> EMC: Get rid of BASE_PERIOD where base thread is not used.
[16:16:07] <CIA-40> EMC: Get rid of TRAJ_PERIOD when the implicit value (1 SERVO_PERIOD) is acceptable.
[16:16:09] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/hexapod-sim/ (core_sim_6.hal minitetra.ini):
[16:16:11] <CIA-40> EMC: Get rid of BASE_PERIOD where base thread is not used.
[16:16:17] <CIA-40> EMC: Get rid of TRAJ_PERIOD when the implicit value (1 SERVO_PERIOD) is acceptable.
[16:16:19] <CIA-40> (66 lines omitted)
[16:27:50] <skunkworks_> yikes
[16:28:02] <jepler> we've already made it not an error to have a .var file that doesn't list all the so-called mandatory variables (it writes out one that does)
[16:28:24] <jepler> what about making it not an error for the var file not to exist yet (and write out all the mandatory variables at the first opportunity)
[16:33:45] <jepler> ditto for the tool table
[16:41:11] <jepler> hm, the prompt "Enter Z coordinate relative to workpiece" doesn't seem quite right for touching off "T"
[16:44:03] <cradek> in what way does it seem wrong?
[16:46:56] <jepler> what seems fishy to me is that you have to have your tool offset in order for touching off on the workpiece to work, but you have to already have touched off the workpiece in order to touch off a tool length
[16:47:06] <jepler> I guess this is where the zero-length reference tool comes in
[16:47:15] <jepler> or maybe I'm not thinking clearly
[16:48:17] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: permit touch-off of a tool not yet in the tool table
[16:48:43] <cradek> you have to know one thing to touch off another thing referencing it
[16:54:29] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/emc/rs274ngc/rs274ngc_pre.cc:
[16:54:29] <CIA-40> EMC: automatically create the var file when it doesn't exist yet
[16:54:29] <CIA-40> EMC: a common user action is to change the var filename in the inifile but not
[16:54:29] <CIA-40> EMC: create the new var file. there's no reason for emc to punish them with a fatal
[16:54:29] <CIA-40> EMC: error at startup.
[18:05:23] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/hm2-servo/ (m7i43_th.hal m7i43_th.ini): remove DOS line endings
[18:05:24] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/hm2-stepper/ (m7i43_th.hal m7i43_th.ini): remove DOS line endings
[18:06:08] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/po/ru_axis.po: remove DOS line endings
[18:06:25] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/nc_files/probe-hole.ngc: remove DOS line endings
[18:06:43] <cradek> they're everywhere!
[18:07:18] <jepler> no kidding
[18:48:09] <alex_joni> heh
[18:48:16] <alex_joni> cradek: they were
[19:29:49] <alex_joni> https://help.ubuntu.com/community/CWiiD
[19:30:03] <alex_joni> wonder when we'll see the first wii jogging CNC
[20:58:27] <cradek> Could not open command file 'core_sim_fast.hal'
[20:58:41] <cradek> jepler: ^ running sim/lathe.
[21:00:10] <jepler> oops!
[21:01:22] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/configs/sim/lathe.ini: revert accidental change
[21:26:53] <jepler> "SHMEM_KEY = 111 This value should not be changed."
[21:27:01] <jepler> ^^ is this documentation better or worse than nothing?
[21:28:02] <cradek> one might wonder what it's doing in the ini file if it's not something to configure
[21:31:45] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: VERY BIG DRO
[21:31:47] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: VERY BIG DRO
[21:37:09] <jepler> cradek: indeed
[21:38:08] <jepler> emc/rs274ngc/interp_queue.cc: In function 'int move_endpoint_and_flush(setup*, double, double)':
[21:38:12] <jepler> emc/rs274ngc/interp_queue.cc:433: warning: 'y2' may be used uninitialized in this function
[21:38:19] <jepler> cradek: I assume you saw these warnings; are they harmless?
[21:38:26] <cradek> right - fixed here, not committed yet
[21:38:31] <cradek> (I've got other changes)
[21:38:32] <jepler> ok
[21:38:34] <cradek> yes they are harmless
[21:49:47] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (4 files): detect a few plane-specific errors, start rethinking inverse-time calcs, fix compiler warnings
[21:50:46] <cradek> February 1: no new features on trunk, only stabilization.
[22:19:32] <jepler> jepler has changed the topic to: EMC2 development --
http://linuxcnc.org/ -- 2.3 schedule: February 1: no new features on trunk, only stabilization.
[22:20:02] <SWPLinux> is that supposed to include new modules too?
[22:20:09] <SWPLinux> ie, no new modules
[22:20:35] <skunkworks_> SWPLinux: how are the festivities>
[22:21:30] <SWPLinux> it;s like Festivus :)
[22:21:49] <jepler> SWPLinux: if it's "big, like hostmot2" then yes I'd want it before the feb1 deadline. if it's something smaller, then we ca n talk about specifics
[22:21:55] <SWPLinux> we went to the volunteer thing at RFK stadium (making up care packages for deployed troops)
[22:22:04] <SWPLinux> I may make an RMS calculator module
[22:22:24] <SWPLinux> that should be simple enough, but maybe not (has to buffer a bit of data, etc)
[22:22:45] <SWPLinux> we missed Michelle Obama, who stopped in for a while before we got there
[22:22:54] <SWPLinux> and Joe Biden & family
[22:23:20] <SWPLinux> but there were a few notables helping out when we were there (we stayed for 4+ hours instead of 1)
[22:23:22] <skunkworks_> Neat :)
[22:23:44] <SWPLinux> (like Nancy Pelosi, Christopher Dodd, ...)
[22:39:43] <cradek> jepler: hm, on my hardly machine, that font is ugly and the size is wrong:
http://timeguy.com/cradek-files/emc/ugly.png
[22:41:01] <BigJohnT> :) a DRO tab
[22:48:14] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: hardy doesn't have Courier New?
[22:48:57] <BigJohnT> cradek: will you drop the dro from the backplot now that you have a dro tab?
[22:49:12] <cradek> http://timeguy.com/cradek-files/emc/courier-10-pitch.png
[22:49:25] <cradek> certainly not. normal people will still want to use the old view.
[22:49:31] <BigJohnT> LOL
[22:50:04] <cradek> I didn't say that out loud did I?
[22:50:18] <BigJohnT> yep you did :)
[22:50:50] <cradek> oops
[22:50:50] <BigJohnT> looking good anyhow
[22:51:30] <BigJohnT> courier 10 looks even better
[22:51:44] <cradek> well, I think it's hideous, but it will solve a problem some people assert exists, without detracting from existing functionality.
[22:52:22] <jepler> a few minutes downtime on cvs coming up, I have to restart some systems
[22:52:50] <BigJohnT> ok doky
[23:45:04] <jepler> .. and now cvs service should be restored
[23:46:44] <jmkasunich> it is
[23:47:01] <jmkasunich> (as 6 or 7 vm's suddely load up my machine)
[23:47:11] <jepler> heh
[23:47:49] <jepler> aside from the "other stuff" taking longer than I expected, I'm also surprised at how after 10 minutes vmware still hasn't "restored the state" of the two VMs I suspended before I show down the host
[23:48:18] <jmkasunich> I've never been pleased with vmware's suspend
[23:48:25] <jepler> it's less than 1.5GB of RAM to restore, it shouldn't take that long
[23:48:29] <jmkasunich> I just shut down the vm
[23:48:39] <jepler> actually it's still not done restoring the one with 1GB RAM
[23:49:35] <jmkasunich> well, I just wasted $2.99 today
[23:50:01] <jmkasunich> bought a stick-on convex mirror from the auto-parts store for the e-week "wide angle camera" thing
[23:50:06] <jmkasunich> but it isn't wide enough
[23:51:14] <jepler> oh dear, that's a big investment down the toilet
[23:51:24] <jmkasunich> yeah
[23:51:34] <jmkasunich> I hope the larger investment today doesn't go there
[23:51:41] <jmkasunich> bought a mini-ITX mobo
[23:52:39] <jepler> that celeron was dead? or too slow?
[23:52:43] <jmkasunich> dead
[23:52:54] <jepler> too bad
[23:52:58] <jmkasunich> http://www.newegg.com/Product/Product.aspx?Item=N82E16813121359&Tpk=D945GCLF2
[23:53:11] <jmkasunich> under $100, delivered, with 512M of ram
[23:53:54] <jmkasunich> two cores, 1.6GHz
[23:54:12] <jmkasunich> and already on our wiki with very good latency score ~7uS
[23:54:27] <jmkasunich> 6.75" square
[23:55:33] <jmkasunich> anoter $72 (which I haven't spent yet) gets me a 6.3 x 1.8" power supply that will run on 6 to 24 VDC
[23:59:39] <jepler> that sounds cool
[23:59:54] <jepler> made for car or boat use or something?
