Back
[01:02:04] <jmkasunich> btw, spindle orient is good for more than just toolchanging
[01:02:52] <jmkasunich> for example, using a boring head, when you get to the bottom you orient so you can retract without scoring the side of the bore
[01:04:13] <seb_kuzminsky> jmkasunich: dont you have to move the table to avoid scoring the bore?
[01:04:30] <jmkasunich> yeah - but without orient you don't know which way to move it
[01:04:40] <seb_kuzminsky> oh yeah
[01:07:56] <SWPadnos> there's also the use of a lathe spindle as an indexer ...
[01:08:10] <SWPadnos> (or something like that)
[01:33:46] <cradek> I think we have a cycle that bores down, then goes into pause, waits for the user to orient the spindle, and then rapids out
[01:34:03] <cradek> or something :-)
[01:34:28] <cradek> I just use g85 that bores both ways
[01:35:38] <cradek> nominations are over!
[01:40:24] <jmkasunich> did we get at least 5?
[01:41:03] <SWPadnos> 7 I think
[01:41:44] <cradek> yes, 7
[01:43:09] <jmkasunich> grr, I hate /sys
[01:43:27] <jmkasunich> or something
[01:43:42] <cradek> what is /sys?
[01:44:01] <jmkasunich> I used to be able to plug in my webcam and /dev/video0 would magically appear, I could do snapshots, etc
[01:44:18] <jmkasunich> now it doesn't
[01:44:26] <jmkasunich> and I have no clue where to start figuring it out
[01:44:42] <SWPadnos> dmesg
[01:44:49] <jmkasunich> /sys is the new-fangled thing that does a lot of what /dev used to do
[01:45:03] <jmkasunich> [20990742.288000] usb 3-2: new full speed USB device using uhci_hcd and address 3
[01:45:16] <SWPadnos> hmm
[01:45:22] <SWPadnos> nothing else?
[01:45:27] <SWPadnos> (related)
[01:45:30] <jmkasunich> lsusb says: Bus 003 Device 003: ID 04fc:504b Sunplus Technology Co., Ltd Aiptek, 1.3 mega PockerCam
[01:45:46] <jmkasunich> nothing else at all (I did dmesg -c first)
[01:45:53] <SWPadnos> hmm
[01:46:00] <cradek> probably no module matches it then
[01:46:04] <SWPadnos> this is the one you used at the workshop?
[01:46:10] <cradek> do you know what modules used to work?
[01:46:18] <cradek> oh, I recall you compiled it
[01:46:19] <jmkasunich> btw, that's not my typo, it comes across as "Pocker" cam
[01:46:24] <cradek> ha
[01:46:26] <SWPadnos> heh
[01:46:29] <SWPadnos> didn't even notice
[01:46:40] <jmkasunich> oh, duh
[01:46:47] <jmkasunich> I'm sure I've upgraded kernels a few times
[01:47:10] <jmkasunich> I wish drivers like this woule be in the mainstream kernel
[01:47:12] <cradek> rebuild rebuild
[01:47:18] <cradek> some are...
[01:47:33] <jmkasunich> probably in 8.04, but not 6.06
[01:48:02] <jmkasunich> I think my brain is rotting from lack of use - I don't even know where to start with the rebuild
[01:48:04] <SWPadnos> don't worry - there shouldn't be too many more kernels for that
[01:48:12] <jmkasunich> * jmkasunich looks around
[01:48:15] <SWPadnos> cd /path/to/downloaded/driver
[01:48:22] <cradek> make
[01:48:27] <SWPadnos> then make -C /path/to/kernel/source
[01:48:31] <SWPadnos> or something like that
[01:48:32] <cradek> no, just make
[01:48:39] <cradek> kbuild you know
[01:49:06] <SWPadnos> I thought there was still something for making just a single external module
[01:49:06] <jmkasunich> less READ_AND_INSTALL ;-)
[01:49:27] <SWPadnos> I might have had it backwards anyway though - go to the kernel source dir nad make -C /path/to/module
[01:49:34] <SWPadnos> reading the docs is cheating
[01:50:22] <jmkasunich> "The driver should compile and run successfully against most stable versions of
[01:50:22] <jmkasunich> the official Linux 2.6.x kernel upto version 2.6.11"
[01:50:29] <jmkasunich> jmkasunich@mahan:~$ uname -r
[01:50:29] <jmkasunich> 2.6.15-53-686
[01:50:43] <jmkasunich> methinks maybe I need to download a fresher one
[01:51:37] <cradek> no, don't
[01:51:46] <cradek> that's the dapper kernel
[01:52:06] <jmkasunich> fresher driver, not fresher kernel
[01:52:19] <cradek> oh, right
[01:53:55] <jmkasunich> maybe not
[01:54:01] <jmkasunich> http://mxhaard.free.fr/news.html
[01:54:15] <jmkasunich> latest version there is from 12/24/2007, which is what I have
[01:54:34] <cradek> well if it worked before...
[01:54:37] <SWPadnos> FIX sysfs for kernel upto 2.6.23
[01:54:48] <SWPadnos> that's one of the comments, so maybe the readme is out of date ...
[01:55:29] <SWPadnos> and the one below it mentions a MAKEFILE flag change for 2.6.24
[01:55:44] <SWPadnos> or Makefile even
[01:56:54] <jmkasunich> jmkasunich@mahan:~/gspcav1-20071224$ dmesg
[01:56:54] <jmkasunich> [20992086.228000] usb 3-2: new full speed USB device using uhci_hcd and address 5
[01:56:54] <jmkasunich> [20992086.372000] /home/jmkasunich/gspcav1-20071224/gspca_core.c: USB GSPCA camera found.Sunplus FW 2
[01:56:54] <jmkasunich> [20992086.372000] /home/jmkasunich/gspcav1-20071224/gspca_core.c: [spca5xx_probe:4275] Camera type JPEG
[01:56:54] <jmkasunich> [20992086.372000] /home/jmkasunich/gspcav1-20071224/gspca_core.c: [spca5xx_getcapability:1249] maxw 640 maxh 480 minw 176 minh 144
[01:56:57] <jmkasunich> woo-hoo
[01:58:58] <jmkasunich> camera works
[01:59:12] <jmkasunich> now if I can just make it work on a ancient laptop
[01:59:21] <jmkasunich> engineering week approaches
[01:59:37] <jmkasunich> this time, the task is to navigate a maze
[01:59:49] <jmkasunich> black lines on a white floor
[02:16:02] <jepler> cradek: no good deed goes unpunished:
[02:16:03] <jepler> Anchors used in gcode.html but not defined in gcode_main.html:
[02:16:03] <jepler> 'sub:G7,-G8:-Set'
[02:17:01] <SWPadnos> hey. 640x480 isn't 1.3 mega - is the pockercam not reporting something correctly?
[02:17:09] <SWPadnos> it's 0.3 mega
[02:17:31] <jmkasunich> who knows
[02:17:41] <SWPadnos> you aren't getting all your megas
[02:17:58] <jmkasunich> maybe they count R, G, and B separately
[02:18:02] <SWPadnos> heh
[02:18:07] <SWPadnos> that's still 0.9 megas
[02:18:08] <jmkasunich> nah, that still isn't enough
[02:18:26] <jmkasunich> I'm not even getting 640x480 right now
[02:20:14] <jmkasunich> 1.3M would be something like 1300*975
[02:20:24] <SWPadnos> 1280*960 is common
[02:20:39] <SWPadnos> or 1280x1024 if it's 5:4 aspect
[02:20:52] <SWPadnos> (that's the standard 1.3M screen resolution)
[02:21:02] <jmkasunich> 1280x960 is 640x480 * 2
[02:21:09] <SWPadnos> yep, about 1.2+change
[02:21:15] <SWPadnos> so they may round up
[02:21:24] <jmkasunich> ISTR that the camera can take stills at the higher res, and video at the lower
[02:21:41] <SWPadnos> ok, that's common
[02:22:19] <SWPadnos> it's possible that in video mode, they use a full RGGB quad for a single pixel, to avoid having to filter each color plane separately
[02:22:42] <jmkasunich> could be
[02:23:01] <jmkasunich> sending the proper options to vggrabbj let me grab a 640x480 frame
[02:23:35] <SWPadnos> that's probably all the real data the imager takes anyway
[02:23:58] <SWPadnos> no point multiplying the data by 3 just so you can compress it again
[02:24:16] <jmkasunich> yeah
[02:24:42] <jmkasunich> I can get 320x240, 352x288, and 640x480 from it
[02:25:07] <SWPadnos> interesting middle resolution there
[02:25:14] <SWPadnos> 1/2 of 704x576
[02:25:20] <SWPadnos> (in each dir)
[02:25:39] <jmkasunich> -i <imagesize>
[02:25:39] <jmkasunich> Sets the imagesize of input device, where imagesize is one of:
[02:25:39] <jmkasunich> sqcif= 128x96, qsif = 160x120,
[02:25:39] <jmkasunich> qcif = 176x144, sif = 320x240,
[02:25:39] <jmkasunich> cif = 352x288, vga = 640x480,
[02:25:40] <jmkasunich> svga = 800x600, xga = 1024x768,
[02:25:42] <jmkasunich> sxga = 1280x1024, uxga = 1600x1200,
[02:25:48] <jmkasunich> vggrabbj man page
[02:25:59] <SWPadnos> ok. sxga is 1.3MP
[02:26:08] <SWPadnos> cif is about iphone res ;)
[02:27:02] <jmkasunich> next step is to mess with the vggrabbj source, get images into memory where I can mess with them
[02:27:29] <jmkasunich> I'm probably in way over my head
[02:27:37] <SWPadnos> can vggrabbj write to stdout?
[02:27:50] <jmkasunich> yeah
[02:27:57] <jmkasunich> jpg, png, and one other format
[02:28:03] <SWPadnos> even if it can't, you can use imagemagick to do a wicked sharpen on the image
[02:28:18] <SWPadnos> low difference threshold, high gain
[02:28:31] <SWPadnos> err - edge detect I mean
[02:28:42] <SWPadnos> you may be able to define your own kernel too, I'm not sure
[02:29:07] <SWPadnos> once you do that, there are tools to convert to vector
[02:29:21] <SWPadnos> one of those might be able to be coerced into making a line drawing
[02:29:22] <jmkasunich> we're going to be looking for solid black lines on a solid white background
[02:29:37] <SWPadnos> yep, except that they'll be shades of gray in the sensor :)
[02:29:40] <jmkasunich> image to vector is the hard part - any hints as to what tools
[02:29:47] <SWPadnos> hmmm
[02:29:55] <jmkasunich> I'm assuming some kind of thresholding will be needed
[02:30:21] <SWPadnos> I don't remember the name - I think one of the drawing programs like xfig can do it though
[02:30:40] <SWPadnos> imagemagick might - it can export to svg - I don't know if it can vectorize though
[02:30:53] <jmkasunich> that seems like a hard problem in general
[02:31:02] <SWPadnos> thresholding is what I was talking about for the sharpening kernel
[02:31:07] <jmkasunich> ah
[02:31:27] <jmkasunich> I've been thinking about mounting the camera 18-24" up, facing down/forward
[02:31:44] <SWPadnos> relatively high difference threshold, since you don't want gray gradatyions to show up, but very very high gain, so the high side becomes pure white and the low side pure black
[02:31:53] <SWPadnos> yes, you'll have to do a perspective correction
[02:31:57] <SWPadnos> which imagemagick can do
[02:32:04] <jmkasunich> do some sort of perspective correction - map from camera pixels to "map" pixels, where the map is the floor, with maybe a 1/4" grid
[02:32:10] <SWPadnos> you'll be able to flatten the image wth some keystone correction
[02:32:33] <jmkasunich> the trick for moving from camera to map will be knowing my position and orientation
[02:32:49] <jmkasunich> any given frame will only tell me a small part of the overall map
[02:33:00] <SWPadnos> how big is it expected to be?
[02:33:07] <SWPadnos> the maze
[02:33:08] <jmkasunich> 50 x 20 feet, approx
[02:33:30] <jmkasunich> 1 foot wide "track", with 3/4" wide stripes on both edges and centerline
[02:33:53] <SWPadnos> ok, that's not too bad
[02:34:09] <jmkasunich> intersections will be no closer than two feet, so there will be exposed floor between parallel track sections
[02:34:21] <SWPadnos> so you want at least 1/4"/pixel resolution or thereabouts
[02:34:25] <jmkasunich> yeah
[02:34:49] <SWPadnos> is it expected to be on a grid?
[02:35:06] <jmkasunich> not a small map - 50' x 20' at 1/4" is 2.3e6 pixels
[02:35:08] <SWPadnos> ie, there either is or is not an opening on the left this foot
[02:35:19] <jmkasunich> that isn't exactly clear
[02:35:20] <SWPadnos> that's only a few times what you have
[02:35:22] <SWPadnos> ok
[02:35:45] <SWPadnos> you could do 1"/pixel and still have it work, if you can get the whole thing in the depth of field
[02:36:10] <SWPadnos> it would be funny to raise a camera to 6' or so, snap one picture, then lower the camera and navigate the maze :)
[02:36:14] <jmkasunich> I can't believe I could clearly see the whole maze at once
[02:36:27] <SWPadnos> no, it seems unlikely
[02:36:32] <jmkasunich> well, maybe from 6-8'
[02:36:47] <SWPadnos> it depends on which side you start on
[02:37:00] <SWPadnos> 50' depth of field would be difficult for that camera I think
[02:37:14] <SWPadnos> if you could control zoom it would be better
[02:37:21] <jmkasunich> I believe we have 5 minutes to explore, we are timed based on fastest run from start to finish, scoring encourages exploring and then running back to the start for a speed run (based on memory)
[02:37:33] <SWPadnos> I have a couple of 3 or 5 MP cameras you could try
[02:37:52] <SWPadnos> can you explore by running over "walls"?
[02:37:53] <jmkasunich> not just DOF - noise, background, contrast, etc will all get iffy the farther away I try to look
[02:37:59] <SWPadnos> yep
[02:38:30] <SWPadnos> by that I mean drive straight ahead X feet, regardless of whether you cross a black line
[02:38:41] <jmkasunich> I think - there was a FAQ published today that said there is no penalty for leaving the track
[02:38:50] <SWPadnos> ok
[02:38:54] <SWPadnos> that's better
[02:39:02] <SWPadnos> in theory anyway :)
[02:39:07] <jmkasunich> although it seems like that would let you just ignore the maze and go to the end as the crow flies (after you identify the end)
[02:39:34] <SWPadnos> or is that "no penalty for leaving the maze"?
[02:39:35] <jmkasunich> however, the track is 1/2 or 3/4" thick, so the bump would be rough
[02:39:40] <SWPadnos> ah
[02:39:50] <jmkasunich> the track is the maze
[02:39:56] <SWPadnos> so the 4WD wins the day
[02:40:17] <jmkasunich> they are going to have "boards", 12" x ??", with the lines on them
[02:40:19] <SWPadnos> ok, so you can run all around it, ie "leave" it, but that probably doesn't say anything about running over walls
[02:40:26] <SWPadnos> ok
[02:40:29] <jmkasunich> no walls, the edges of the board are the walls
[02:40:48] <SWPadnos> right
[02:41:17] <SWPadnos> what I mean is that "leaving the track" probably means "going outside the outer boundary of the maze", not leaving the paths inside the maze
[02:41:28] <jmkasunich> I have (from a previous contest) two wheel mechanisms, 64 count/rev encoders driving worm gears (maybe 50:1?) driving wheels
[02:41:48] <SWPadnos> ok, so you can drive and steer
[02:41:48] <jmkasunich> oh - I'm not sure how much room there will be outside the outer boundary
[02:41:54] <jmkasunich> probably full of spectators
[02:42:07] <SWPadnos> so no penalty for hitting spectators - cool! ;)
[02:42:32] <jmkasunich> I'm hoping I can do moderate dead reckoning, but I'm sure I will have slip and other errors
[02:43:12] <jmkasunich> so a second aspect of the imaging would be to match what I see "now" with what I saw "earlier", to correct my position/orientation estimates
[02:43:40] <jmkasunich> gonna need a frickin cray
[02:44:14] <cradek> jmkasunich: opencv
[02:44:21] <SWPadnos> you mean a watch, right?
[02:44:28] <SWPadnos> or an ipod
[02:44:33] <jmkasunich> yeah, google found that - haven't read much yet
[02:45:01] <jmkasunich> I wish I could use my work laptop for the brain - core 2 and pretty fast
[02:45:04] <jmkasunich> but it runs windows
[02:45:31] <cradek> can it boot from cd?
[02:45:33] <jmkasunich> my linux laptops are all ancient - 600MHz or less
[02:45:44] <jmkasunich> good question
[02:45:54] <cradek> or better, usb (so you have persistence)
[02:46:00] <cradek> I hear that's getting easier to use
[02:47:12] <SWPadnos> http://en.wikipedia.org/wiki/List_of_raster_to_vector_conversion_software
[02:48:30] <SWPadnos> I think some EMC-related person did something with
http://potrace.sourceforge.net/
[02:48:35] <jmkasunich> I wonder how important/usefull a vector representation is for this? would a pixelated map with a modest grid work?
[02:48:35] <SWPadnos> maybe fenn?
[02:48:59] <SWPadnos> probably, and you don't need the vector representation, just knowledge of where the vectors would be
[02:49:05] <cradek> I've used potrace (long ago)
[02:49:20] <SWPadnos> but since there are programs that will output a vector image, they may be easier to use
[02:50:56] <jmkasunich> I think the chain would be: camera image (including keystone distortion,etc) -> using approx position and orientation, convert to world coordinates (~1/4" grid on the floor) -> merge new images with old, revising estimated position/orientation in the process -> use raster-vector to actually solve the maze (recognizing intersections, etc)
[02:52:04] <jmkasunich> all intersections are T, except for the goal, which is a + (and that is the only way to identify the goal)
[02:52:15] <SWPadnos> oh. that's useful
[02:52:48] <SWPadnos> so you have only 4 kinds of "cell"
[02:53:15] <SWPadnos> oh, 5
[02:53:23] <SWPadnos> no openings (dead end), open front, open L/R/F, open left, open right
[02:53:42] <SWPadnos> duh
[02:53:44] <SWPadnos> 7
[02:53:59] <SWPadnos> no, 8 - hey, they're all there :)
[02:54:14] <SWPadnos> (and 16 if you kep track of what's behind you
[02:54:16] <SWPadnos> )
[02:54:18] <SWPadnos> +e
[02:54:31] <SWPadnos> I like this potrace option: -t, --turdsize n - suppress speckles of up to this size (default 2)
[02:54:45] <jmkasunich> I think I want my map to be in world coordinates, not "me" coords
[02:54:55] <jmkasunich> IOW, X and Y, rather than left, right, ahead, behine
[02:54:56] <jmkasunich> d
[02:55:18] <SWPadnos> if there's a grid, you can make a map (e.g., a 50x20 array) with constants that represent which sides are open
[02:55:34] <SWPadnos> for that grid cell
[02:56:00] <jmkasunich> I'm not sure if there are distinct cells, or if they might have track segments that are 17", 39" etc, long
[02:56:18] <SWPadnos> right, that was the question I was asking about earlier
[02:56:37] <SWPadnos> how big is the robot expected to be?
[02:56:52] <jmkasunich> any size that fits on the track
[02:57:10] <jmkasunich> they have photocells across the start and finish, so it can't be much wider than the track
[02:57:34] <jmkasunich> I think they promised 2-3" clearance (for vehicles that want to run feelers on the sides of the track)
[02:58:03] <jmkasunich> the finish junction will have photocells set diagonally, so you can enter from any arm and break the beam
[02:58:27] <SWPadnos> ok
[03:11:11] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/ (stepconf.py stepconf.glade): Adda optional desktop launcher we'll see how that works. Fix spindle display option to use an absolute and scale component if necessary. Still need to decide to add halui or remove tool number display
[03:13:51] <SWPadnos> you know, there should be a way to tell EMC that your spindle can't reverse
[03:14:01] <SWPadnos> so it can error if there's an M4 in a program
[03:14:38] <jmkasunich> there are a lot of "capabilities" that a specific machine may or may not have, that the canonical machine always has
[03:14:45] <SWPadnos> yes
[03:14:46] <jmkasunich> like spindle encoder
[03:14:56] <SWPadnos> I guess my statement could be more generic then :)
[03:15:37] <SWPadnos> actually, spindle speed MIN_LIMIT and MAX_LIMIT would be nice
[03:15:47] <SWPadnos> which would also take care of reversal
[03:16:24] <jmkasunich> depends - MIN_LIMIT could be "slowest" or "fastest reverse"
[03:16:30] <SWPadnos> true
[03:35:52] <SWPadnos> wow - this looks like a nice drawing program:
http://www.xaraxtreme.org/
[04:12:28] <cradek> SWPadnos: net dangit motion.spindle-reverse axis.0.amplifier-fault
[04:12:43] <SWPadnos> heh
[04:12:58] <SWPadnos> that would have some of the desired effects
[04:13:28] <SWPadnos> or be more confusing: net ha! motion.spindle-reverse motion.feedhold
[04:13:39] <cradek> evil
[04:13:44] <SWPadnos> heh
[04:13:50] <cradek> actually, if you have at-speed hooked up, you get somethign like that
[04:37:26] <CIA-1> EMC: 03cradek 07TRUNK * 10emc2/configs/sim/ (6 files): tweaks for lathe config, including spindle-at-speed
[04:39:42] <steves_logging> logger_dev, bookmark
[04:39:42] <steves_logging> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-01-13.txt
[04:45:03] <SWPadnos> cradek, in the 'near' component, is there a reason other than divide by zero to check for scale>1?
[04:45:18] <cradek> ummmmm
[04:45:22] <SWPadnos> is that intended to disable the ratio check?
[04:45:30] <cradek> ummmmm
[04:45:33] <SWPadnos> heh
[04:46:33] <SWPadnos> minor silly optimization: change the comparison to use only multiplication as follows:
[04:46:35] <SWPadnos> if((scale > 1 && in1 <= in2*scale && in2 <= in1*scale) || fabs(in1-in2) <= difference)
[04:46:48] <SWPadnos> which means the scale>1 is no longer needed, unless there's another reason for it
[04:47:52] <cradek> either that expression is write-only or it's too late in the day
[04:47:58] <SWPadnos> heh
[04:48:23] <cradek> I don't see what <1 would mean that you might want
[04:48:55] <SWPadnos> I took part of the existing expression:
[04:48:56] <SWPadnos> in1/scale <= in2
[04:48:58] <SWPadnos> and multiplied both sides by scale to get :
[04:48:59] <SWPadnos> in1 <= in2*scale
[04:49:19] <SWPadnos> I would remove the scale check entirely, or make it scale <=0
[04:49:38] <cradek> but I think if it's <1 both expressions will never be true
[04:49:53] <SWPadnos> that seems true
[04:49:55] <SWPadnos> :)
[04:49:58] <cradek> it's true the scale check is not needed
[04:50:03] <SWPadnos> so the scale check is a shortcut
[04:50:08] <cradek> but changing it to some other number would only muddy the waters
[04:50:30] <SWPadnos> right - leave it alone or remove it
[04:50:31] <cradek> the default settings should give a strict equality test
[04:50:39] <SWPadnos> yes, they appear to
[04:50:43] <SWPadnos> (this late in the day)
[04:50:49] <cradek> let's not change it tonight
[04:50:50] <cradek> :-)
[04:50:56] <SWPadnos> ok by me
[04:51:09] <SWPadnos> I know the replacement expression is mathematically equivalent
[04:51:32] <SWPadnos> and that divides still take significantly longer than multiplies (39 cycles instead of 3, IIRC)
[04:51:51] <SWPadnos> and that multiplications never cause divide by zero errors :)
[04:51:59] <SWPadnos> (not that those can happen here anyway)
[04:52:35] <cradek> if I ever need 36 extra cycles I'll start optimizing here
[04:52:39] <SWPadnos> heh
[04:52:46] <SWPadnos> per instance!
[04:53:58] <SWPadnos> sorry - my microcontroller experience always makes me see things like a/b > c/d as things that really want to be a*d > c*b
[04:54:19] <SWPadnos> even though it's less obvious looking
[04:54:30] <cradek> no problem, it's true it's better
[04:54:44] <cradek> watch the signs though - I think you can accidentally flip the comparison
[04:54:52] <cradek> or no?
[04:54:57] <SWPadnos> you can, but I didn't
[04:55:13] <SWPadnos> multiply both sides by b*d
[04:55:40] <SWPadnos> and the inequality / equality remain the same
[04:56:04] <cradek> even if b is negative?
[04:56:15] <SWPadnos> I think so
[04:56:31] <cradek> I think not
[04:56:31] <SWPadnos> the only case where it should blow up is b=0 or d=0
[04:56:48] <cradek> 1*1 > 1*-1 (true)
[04:56:56] <cradek> 1/-1 > 1/1 (false)
[04:57:26] <SWPadnos> hmmm
[04:58:07] <SWPadnos> so that's why all my embedded software doesn't work!
[04:58:10] <cradek> hahaha
[04:58:20] <cradek> so yeah, don't change "near" tonight :-)
[04:58:28] <SWPadnos> well OK then ;)
[05:02:23] <SWPadnos> ah - we know scale is positive because of the check for scale > 1 ;)
[05:42:24] <steves_logging> KimK - I sent you a private message about Panasonic servos at CNC Workshop
[05:59:05] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Fix pyvcp sample options: add mdi section to ini , if spindle encoder then scale output
[06:01:02] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/configs/common/configurable_options/pyvcp/ (xyzjog.xml spindle.xml): fix pin type in spindle.xml change border in xyzjog
[06:39:46] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: opps missed a pin name fix for spindle override
[07:47:41] <alex_joni> I wonder why spindle override needs to come from pyvcp?
[07:48:10] <alex_joni> I thought AXIS has a slider for that if spindle is activated
[08:03:12] <SWPadnos> it's making connections for halui
[08:07:04] <alex_joni> I saw that.. but.. why?
[08:07:33] <alex_joni> imo that will only cause frustration for users who actually want to connect it to some physical pins
[08:08:14] <SWPadnos> oh right - I have no idea why he's connecting pyvcp to halui
[08:08:46] <SWPadnos> it may just be an example that does something noticeable
[08:15:53] <alex_joni> I don't think that's the purpose of stepconf
[08:16:50] <alex_joni> to be an "example that does something noticeable"
[08:21:15] <SWPadnos> indeed
[08:28:55] <alex_joni> ha
http://www.theregister.co.uk/2009/01/13/top_25_programming_errors/
[08:29:17] <SWPadnos> hah! it is a sample :)
[08:29:30] <SWPadnos> /example
[08:33:35] <SWPadnos> on that note - good night
[09:28:54] <alex_joni> see ya
[09:34:58] <chester88> Hey Alex
[09:46:12] <alex_joni> hi chester88
[09:46:57] <chester88> Hey i saw you online Thought you might want to talk some more about what i was doing in Stepconf
[09:47:16] <chester88> Or do you want to use it more first
[09:47:43] <alex_joni> well.. I must admit I haven't started it yet :)
[09:47:49] <alex_joni> only reading commits lately
[09:48:00] <chester88> No problem.
[09:48:26] <alex_joni> just wanted to share my concearn that it might get too .. friendly, allowing people to bite themselves
[09:48:28] <chester88> Yes I gathered that. As I said the samples could be changed to anything
[09:49:18] <chester88> I know what your getting at but I don't think it's that bad yet. They can chose not to use any samples
[09:50:42] <chester88> It seems alot of people learn from hacking a working example-that is what I was trying to provide.
[09:51:44] <chester88> I can see the complication it adds to stepcong and that is why I was looking to separate the extra hal code by using The hal command idea (or any other idea)
[09:55:15] <alex_joni> right.. well, let's wait and get some more feedback
[09:55:25] <chester88> K sounds good
[09:55:41] <alex_joni> all of the US guys are probably asleep atm
[09:55:52] <chester88> where are you?
[09:55:55] <alex_joni> .ro
[09:56:04] <chester88> ?
[09:56:07] <alex_joni> GMT + 2
[09:56:09] <alex_joni> romania
[09:56:20] <chester88> ahh I'm in Canada
[09:56:29] <alex_joni> http://en.wikipedia.org/wiki/.ro
[09:56:30] <chester88> it's 2 am
[09:56:42] <alex_joni> close to noon here
[09:57:24] <chester88> well that's unfair you are wide awake in this fight lol!
[09:57:52] <alex_joni> well.. pseudo-busy at work though
[09:57:59] <alex_joni> (should level things out)
[09:58:31] <chester88> lol ok . Well actually i'm going to bed soon anyways
[09:59:09] <chester88> Thanks for offering your opinion
[13:01:43] <Guest859> Guest859 is now known as skunkworks_
[13:54:47] <steves_logging> steves_logging is now known as steve_stallings
[14:56:24] <CIA-1> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: typo
[17:24:07] <micge1> hello all
[17:26:27] <micges> I asked some time ago about kinematic with xz linear and y was rotary
[17:27:09] <micges> jepler said that can't be done until joint will have velocity constrains or so
[17:29:54] <micges> jepler: is your patch to periods has some influence on this topic ?
[17:31:00] <jepler> no
[17:33:14] <micges> anyway I must write this module becouse of problems with my configration and things that must be done to use this machine (changing scale due to position and so)
[18:56:48] <SWPadnos> man, it's too darned funny to be typing an email, and have the response from jmkasunich come in with the exact same wording
[18:56:51] <SWPadnos> (at least in part)
[18:58:16] <BigJohnT> heh
[18:58:36] <SWPadnos> and the rest was similar enough that I didn't bother :)
[18:58:49] <micges> he reads in minds (and types faster:)
[18:58:58] <SWPadnos> sometimes
[18:59:04] <SWPadnos> we're usually in a dead heat :)
[18:59:26] <micges> heh
[20:15:48] <steve_stallings> steve_stallings is now known as steves_logging
[20:43:24] <jepler> was there any competing "relative angular" proposal to the crazy one where A+90 and A-90 went to the same place but with differing directions of travel?
[20:44:49] <jepler> well, besides the buggy one I tried to do once: G0 the short way, G1 the way the emc does now
[20:45:03] <cradek> sadly nothing else seems like a 'standard'
[20:45:40] <micges> maybe config option to angular be "wrapable" ?
[20:45:57] <cradek> micges: the question is how should it work
[20:47:39] <cradek> jepler: did "no sign specified" go positiveward, or was it a third behavior?
[20:48:22] <jepler> cradek: oh god, I hope it wasn't a third behavior!
[20:48:32] <cradek> * cradek sighs
[20:48:42] <cradek> my kingdom for a spec
[20:48:48] <micges> in my opinion when wrap enable there must be (configurable) position that when emc pass is it will zero position
[20:48:54] <micges> or so
[20:49:26] <micges> no sign might be default to plus like everything else
[20:49:34] <micges> just my opinion
[20:53:22] <jepler> I envisioned that the joint position will continue to be just like now-- if the gcode makes it turn 1000 revolutions then the joint position will be about 1000*360.
[20:54:22] <jepler> but this relative rotary axis mode doesn't require the user to keep track of that -- write A-90 if you want to turn to 90 degrees by going clockwise (or whichever way the sign goes)
[20:55:07] <cradek> jepler: I agree with that implementation, especially now that we have doubles
[20:56:00] <micges> good night all
[20:56:08] <jepler> good night
[20:56:49] <cradek> jepler: what is the catch? it doesn't sound that hard to me today
[20:57:10] <jepler> cradek: offsets?
[20:57:19] <jepler> cradek: new modal group?
[20:57:19] <cradek> hmm
[20:57:44] <cradek> yeah, offsets
[20:57:50] <cradek> back to "no spec"
[21:04:14] <jepler> right now is +A counterclockwise?
[21:04:25] <jepler> huh I thought there was a section in gcode_main.html that talked about this
[21:04:49] <jepler> oh bigjohnt made it a separate document:
http://linuxcnc.org/docs/html/common_machining_center.html
[21:05:11] <jepler> 'angular position increases without limit (goes towards plus infinity) as the axis turns counterclockwise'
[21:12:48] <LesNewell_> Just a thought - what about having a code that simply resets the axis to within 360 degrees.
[21:13:09] <LesNewell_> say you start at 0 and do 3.5 turns. Issue the code any you are at 180 degrees.
[21:14:00] <LesNewell_> Ideal for synchronized threading etc
[21:14:20] <jepler> LesNewell_: that's a tiny bit like what I tried to do, with "G0 A..." being that "reset" plus a movement to the next spot where you wanted to start..
[21:14:39] <cradek> you can already do that with G10
[21:14:47] <cradek> well, something like it
[21:15:07] <LesNewell_> Not really, because you then have to work out where you are.
[21:15:24] <jepler> G0 X1 Y0 Z0; G1 Z10 A9999; G0 Z.99 Z0; G1 Z10 A9999
[21:15:41] <jepler> er, G0 X.99 Z0 A0
[21:15:47] <jepler> if that makes any sense
[21:15:51] <cradek> oh right, you don't easily have current position
[21:16:09] <cradek> I was thinking about how easy g10 l2 p1 a[position % 360] would be
[21:16:57] <jepler> .. adding a code to fetch the current position into the probing parameters wouldn't be hard ..
[21:17:13] <cradek> yeah, but ick
[21:19:12] <LesNewell_> jepler: I can't think of anything against your idea though having a separate reset gives you more control.
[21:22:27] <cradek> although I don't think the typical scheme (sign gives direction) is that great, I'm against doing anything atypical/emc-specific
[21:22:29] <jepler> the main problem that I recall was that emc assumed every rotary axis was wrapped -- this probably isn't true of the rotary axes on a 5-axis machine. so it would try to go outside the machine constraints to get from -180 to 180 (say)
[21:23:00] <cradek> yeah this definitely needs to be per-axis
[21:27:35] <jepler> "this" being my alternate idea, or the signed motion idea that stuart has told us is "standard"?
[21:28:08] <cradek> any scheme for wrapped axes has to be per-axis
[21:28:39] <cradek> even max5 has one that wraps and one that doesn't
[21:30:09] <jepler> but you can still program every move that makes sense for the non-wrapped axis in the stuart mode
[21:31:31] <cradek> that's true but the nonstuart would be more natural for something that only moves part of a circle
[21:33:40] <jepler> so you're saying there are 6 gcodes in 3 modal groups, or are you saying that the meaning of G1 A-90 in stuart's mode is dependant on the inifile?
[21:33:49] <jepler> I don't like either of those things very much
[21:34:44] <cradek> I was thinking inifile to choose between the two modes of operation for a particular axis (current mode and stuart mode)
[21:44:31] <jepler> cradek: I wrote some words:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?WrappedRotaryAxes
[21:47:21] <SWPadnos> does Gcode allow for anything other than degrees for specifying angles (such as radians or grads)
[21:47:23] <SWPadnos> ?
[21:47:33] <jepler> SWPadnos: we don't have modal codes for angular units
[21:47:49] <SWPadnos> yeah, I didn't remember seeing any
[21:48:08] <jepler> right now in principle it's only degrees, though I don't think anything bad happens if you lie and make 1 = 1 radian or 1 = 1 grad
[21:48:12] <SWPadnos> but I confused myself when thinking about the fact that ini files still have units for angular axes
[21:48:20] <jepler> it's true, they do
[22:32:51] <skunkworks_> hmm - that isn't good
[22:33:06] <skunkworks_> probably a windows update ;)
[23:19:56] <cradek> jepler: "The sign of a nonzero number is ... if it is zero."
[23:20:35] <jepler> oops
[23:20:51] <cradek> not just being pedantic - I really don't undrstand what you meant
[23:21:53] <cradek> I bet strtod() can't tell us +0 vs -0
[23:22:03] <cradek> have to handle the sign separately
[23:22:28] <cradek> block.a_flag, block.a_number, block.a_sign
[23:22:54] <cradek> block.a_sign_flag ugh
[23:25:44] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/signed.c
[23:25:51] <jepler> g++ signed.c && ./a.out -1 +1 -0 +0 0
[23:25:56] <jepler> signbit() is defined in c99
[23:26:21] <cradek> oh hey
[23:28:03] <cradek> btw, I'm ready to go anytime
[23:28:50] <jepler> come on over if you want to help us assemble the blinds
[23:28:53] <jepler> it needs a smart person
[23:32:51] <cradek> how can I resist that -- oh, I know
[23:33:26] <jepler> pretty please? (from Ingrid)
[23:33:39] <cradek> oh you're serious? ok then.
[23:55:17] <jmkasunich> heh