Back
[00:54:11] <jmkasunich> SWPadnos: around?
[01:15:36] <jepler> can someone help me translate this changelog item into human?
[01:15:37] <jepler> * Allow messages produced by milltask to be localized
[01:16:08] <jmkasunich> localised = i8n, right?
[01:16:35] <jepler> some number
[01:16:47] <jepler> La commande (EMC_TASK_PLAN_STEP) ne peut etre executee tant que la machine n'est pas sortie de l'arret d'urgence et mise en marche
[01:16:51] <jepler> stuff like this
[01:17:08] <jmkasunich> thats what I thought
[01:17:20] <jmkasunich> so what are you looking for?
[01:17:22] <cradek> * Make more error messages translatable
[01:17:26] <jepler> (which will still be a kind of WTF for a French user, but whatever)
[01:17:30] <jepler> something like what cradek said
[01:18:06] <jmkasunich> in that case: "what cradek said"
[01:18:38] <jmkasunich> it's darned hard to rig a wide angle lense for a webcam
[01:18:55] <jmkasunich> "normal" lens is probably only about 8mm FL
[01:19:40] <CIA-1> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: backport from trunk: i999n of messages in milltask (thanks alex!)
[01:19:40] <CIA-1> EMC: 03jepler 07v2_2_branch * 10emc2/src/ (config.h.in configure configure.in): backport from trunk: i999n of messages in milltask (thanks alex!)
[01:19:40] <CIA-1> EMC: 03jepler 07v2_2_branch * 10emc2/src/emc/task/emctaskmain.cc: backport from trunk: i999n of messages in milltask (thanks alex!)
[01:20:31] <jepler> jmkasunich: here's one janky idea:
http://www.instructables.com/id/%2411-Super-Wide-Angle-Digital-Camera/
[01:20:42] <jepler> step 1. Go to your favorite hardware store, and buy a wide angle door viewer.
[01:20:44] <jepler> hi chester88
[01:20:51] <jepler> sorry we all slept through your visit last night
[01:20:54] <chester88> Hi Jeff
[01:21:01] <jmkasunich> jepler: clever idea
[01:21:03] <chester88> lol no problem I was up late
[01:21:15] <jmkasunich> I've been playing with the idea of a convex mirror
[01:21:33] <jmkasunich> I have a 1" ball bearing here (1" sphere)
[01:21:35] <chester88> Hey Jeff Stepconf had the step time hold number reversed
[01:21:46] <jmkasunich> but it needs to be about 1" from the lense
[01:22:10] <jepler> chester88: oops!
[01:22:29] <chester88> I can fix it just want to check what to change...
[01:22:55] <chester88> change the list or
[01:23:18] <chester88> this: self.widgets.steptime.set_value(d[2])
[01:23:22] <chester88> from 2 to 3
[01:25:18] <jepler> ["gecko201", _("Gecko 201"), 4000, 500, 20000, 1000],
[01:25:39] <chester88> all the timings are reversed
[01:25:40] <jepler> are you telling me that the gecko datasheet specifies step time as 500ns and step space as 4000ns?
[01:25:56] <jepler> (I'm not looking at the datasheet so I wouldn't know)
[01:26:31] <chester88> no telling you Stepconf displays step hold time as step time and vice vera
[01:26:51] <chester88> in trunk of course
[01:27:10] <jepler> ok, so gecko 201 datasheet specifies step time as 4000ns and step space as 500ns?
[01:28:11] <chester88> I am reading off the wiki
[01:28:16] <chester88> thats what it says
[01:28:34] <jmkasunich> what what what says?
[01:28:48] <chester88> sorry I mean the wiki says step time is 500
[01:29:05] <jmkasunich> I'm checking the gecko manual now
[01:29:10] <chester88> k
[01:29:16] <jepler> Your search - site:geckodrive.com 201 filetype:pdf - did not match any documents.
[01:29:26] <jepler> I tried that but they broke their site for search ages ago
[01:29:36] <jmkasunich> step pulse "0" time (step on falling edge): 0.5uS
[01:29:37] <chester88> check gecko 320 it works
[01:29:38] <jepler> I suppose I could check one of the other drive types listed in stepconf
[01:29:46] <jmkasunich> step pulse "1" time: 4uS
[01:30:00] <jmkasunich> so, steplen = 500nS, stepspace = 4000nS
[01:30:07] <jepler> to me tat says step time 500ns, but step output is inverted
[01:30:12] <jepler> s/tat/that/
[01:30:17] <jmkasunich> yes, active low
[01:30:39] <jmkasunich> low output = LED in optocoupler ON = step pulse
[01:30:41] <chester88> k i'm a bit confused now! lol
[01:30:47] <jmkasunich> high output = LED off = between steps
[01:31:29] <jepler> well, here's what I *intended*: the order in the timing table in stepconf should be the same as the order the items are presented to the user in the GUI
[01:32:03] <jepler> so if it says [..., 4000, 500, 20000, 1000] and the presentation order is step time, space, direction hold, setup, then it specifies step time 4000ns and step space 500ns
[01:32:07] <chester88> That would make sense
[01:32:40] <jmkasunich> is that what you see on-screen?
[01:32:46] <jepler> so if all that is what happens, except that the correct step time for gecko is 500ns, then the table should be changed
[01:32:47] <chester88> but that is not the case
[01:32:49] <jmkasunich> and is that what gets generated in the file?
[01:33:34] <jepler> well .. I'm running 2.2 stepconf at the moment
[01:33:37] <jepler> I get Step Time: 4000ns
[01:33:39] <chester88> haven't checked but i'm sure it will be wrong as self.widgets.steptime.set_value(d[2]) gets info from the wrong coloum
[01:33:42] <jepler> and in my hal file I get reset-time 4000
[01:34:05] <chester88> k hey maybe I let you sort it then. i'm just confusing things i think...
[01:34:37] <jepler> ah but I'm not the fellow who knows what the timings are :-P
[01:34:51] <jmkasunich> there are two issues here
[01:34:57] <chester88> I am referencing the wiki
[01:35:05] <jmkasunich> what is the mapping between table/gui/output files
[01:35:05] <chester88> maybe the wiki is wrong
[01:35:12] <jmkasunich> what is the correct timing for the G201
[01:35:15] <jmkasunich> only remotely related
[01:35:34] <jmkasunich> the wiki sounds like a third unrelated thing
[01:35:37] <chester88> the table and wiki are different order
[01:36:06] <jmkasunich> that's not surprising, they have nothing to do with each other
[01:36:33] <chester88> wiki saya geko 201 step time=500 stepspace=4000
[01:36:47] <jmkasunich> if stepconf's table/gui/output columns are internally consistent, then it would be reasonably to make the wiki use the same column order to avoid confusion
[01:36:51] <chester88> stepconf displays the opposite
[01:36:55] <jmkasunich> then put the proper (same) data in both stepconf table and wiki
[01:37:01] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/stepconf-timing.png
[01:37:04] <chester88> yoor missing the point
[01:37:19] <jepler> the table in stepconf says [..., 4000, 500, 20000, 1000], and that's what the GUI shows
[01:37:30] <jepler> I think stepconf is treating the values as I intended
[01:37:45] <jmkasunich> ok, so the only problem is that ONE LINE of data in the stepconf table is wrong
[01:37:53] <jepler> first number in the source (and first entry on the gui) being "step time", and so on
[01:37:53] <chester88> one says step time 500 the other says steptime 4000
[01:38:33] <chester88> no they are all reversed
[01:38:33] <jmkasunich> chester88: it sounds like none of us is communicating very well
[01:38:43] <chester88> lol I agree
[01:38:50] <chester88> let me try again
[01:38:54] <jmkasunich> what is the URL for that wiki page?
[01:39:11] <chester88> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Stepper_Drive_Timing
[01:39:22] <CIA-1> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix nonconcave arc to line with lathe tool orientation 7
[01:40:13] <chester88> What i'm saying is either the wiki is wrong or stepcong is wrong
[01:40:38] <jmkasunich> that is clearly true
[01:40:41] <jepler> what I'm saying is that stepconf is using the table as I intended, but I can't vouch for whether the numbers in the table are right
[01:40:46] <jmkasunich> but also meaningless
[01:41:05] <chester88> ok
[01:41:20] <jmkasunich> where the hell is stepconf anyway>?
[01:41:27] <jepler> src/emc/usr_intf/stepconf
[01:41:37] <jmkasunich> ty
[01:42:18] <jmkasunich> the wiki table is laid out: time/space/hold/setup
[01:42:32] <chester88> yes
[01:42:33] <jmkasunich> the stepconf GUI is laid out time/space/hold/setup
[01:43:00] <jmkasunich> the stepconf data table is laid out: time/space/hold/setup
[01:43:10] <jmkasunich> so the stepconf CODE is 100% correct
[01:43:27] <jmkasunich> but the columns of DATA in the stepconf table seem to be mixed up
[01:43:46] <jepler> the data in the stepconf table doesn't match the wiki page
[01:43:51] <chester88> k so stepconf table is wrong or the wiki is wrong
[01:44:05] <chester88> yep
[01:44:23] <jmkasunich> well, for the G201, I just confirmed that the wiki is right
[01:44:29] <jepler> but I guess jmkasunich verified that stepconf is wrong .. yeah
[01:44:36] <jmkasunich> there are also links on the wiki to the datasheets for most of the other drives
[01:44:41] <SWPadnos> oh - hi, I'm here now
[01:44:46] <jmkasunich> I think I see where this conversation went wrong:
[01:44:49] <jepler> hi SWPadnos
[01:44:50] <jmkasunich> <chester88> change the list or
[01:44:50] <jmkasunich> <chester88> this: self.widgets.steptime.set_value(d[2])
[01:44:50] <jmkasunich> <chester88> from 2 to 3
[01:44:53] <jepler> I think somebody's looing for you
[01:44:55] <jepler> looking
[01:45:07] <SWPadnos> jmkasunich was last to do so
[01:45:12] <jepler> (ugh, I hope nobody's looing for you; that would be gross and I don't think it would even work!)
[01:45:20] <jmkasunich> chester88: "change the list" was the right answer, but it got lost in the shuffle
[01:45:26] <SWPadnos> nor mooing for me
[01:45:41] <jmkasunich> changing the code is what led us astray - the code is fine
[01:45:54] <chester88> lol yes ok so we are all agreeing the list needs to be changed in stepconf
[01:45:56] <jmkasunich> SWPadnos: I was wanting to brainstorm camera stuff
[01:45:56] <jepler> I agree: change the table
[01:46:00] <SWPadnos> ok
[01:46:12] <SWPadnos> I looked over Steve's email, which reminded me of tilt-shift lenses
[01:46:14] <chester88> excellent I will do that.
[01:46:16] <jepler> (but don't bindly swap all the numbers)
[01:46:28] <chester88> yep I will confirm numbers
[01:46:29] <jepler> chester88: can you look at it in 2.2 too?
[01:46:35] <jepler> I would really appreciate it
[01:46:41] <chester88> I will sure
[01:46:42] <jepler> (and my appreciation is worth nearly something!)
[01:46:50] <jmkasunich> the stepconf numbers should come from the wiki page - at least that page has links to the datasheets, etc
[01:47:12] <chester88> lol. Well you haven't pulled my committing rights for stepconf yet lol!
[01:47:23] <jmkasunich> maybe a comment above the table that lists the field order would help avoid future confusion
[01:47:38] <chester88> yes i was going to add that too
[01:47:51] <jmkasunich> SWPadnos: interesting stuff there, but not really feasable
[01:48:04] <chester88> k thanks guys
[01:48:13] <SWPadnos> tilt-shift is, but probably not on your preferred budget :)
[01:48:31] <jmkasunich> I've been trying to figure out how to put the pixels where I want them
[01:48:48] <jmkasunich> camera pointing straight up at a shiny sphere is on option
[01:49:05] <jmkasunich> camera pointing straight down looking thru a door peephole thing is another
[01:49:20] <SWPadnos> chester88, the different geckos have different timing and polarity specs
[01:49:30] <jmkasunich> one complication since yesterday - the vehicle has to pass thru a 18" wide x 12" tall frame at the starting line
[01:49:40] <SWPadnos> (just FYI - I think you made a comment earlier "use the G340 timing, it works")
[01:49:43] <jmkasunich> SWPadnos: there are 6 gecko lines in the wiki
[01:49:53] <jmkasunich> and 5 in stepconf
[01:49:58] <SWPadnos> yep
[01:50:19] <chester88> hmm whats sounds easy to do....lol
[01:51:04] <chester88> I said use the 320 link (to the manual) it works
[01:51:06] <SWPadnos> when I was fiddling with stepconf, I wanted to put those timings into an external text file
[01:51:10] <SWPadnos> ok
[01:51:24] <SWPadnos> I was just scanning the log - I may have missed words
[01:51:39] <SWPadnos> which is fun with words like "not" or "don't" :)
[01:53:01] <jmkasunich> SWPadnos: one nice thing about aiming a camera at a convex mirror - the virtual image is inside the mirror, and is almost flat, fairly easy to focus on and cover a large DOF out in the real world
[01:53:45] <SWPadnos> it also reverses left and right (assuming it's "saddle-shaped", rather than like a spoon)
[01:54:02] <jmkasunich> I was thinking spoon/ball
[01:54:13] <SWPadnos> ok, a spoon reverses both L-R and up/down
[01:54:22] <SWPadnos> not a big deal, jus tsomething to note
[01:54:26] <jmkasunich> yeah
[01:54:54] <jmkasunich> reversing both is the same as rotating the camera 180 degrees I think
[01:55:18] <jmkasunich> I was just wondering if you had any other ideas on the subject
[01:55:37] <jmkasunich> I suppose the ideas you'd use in your work are of the "do it right, using $$$$" variety
[01:55:48] <SWPadnos> well, not too many. the entrance height restriction could be an issue
[01:55:52] <SWPadnos> heh
[01:55:55] <SWPadnos> usually
[01:56:12] <SWPadnos> I do have an Elphel camera here, plus a Micron development kit, that I can send you if you think it'll help
[01:56:15] <jmkasunich> http://www.anchoroptics.com/catalog/product.cfm?id=26 has a 62mm diameter, 17mm FL (about 34mm radius I think) convex mirror for $10
[01:56:44] <SWPadnos> the Elphel has a Xilinx FPGA in it, plus an ETrax chip running Linux
[01:57:15] <jmkasunich> if I put the back of the mirror at about 11.75" above the floor, with the camera directly underneath looking up, the effective viewpoint is about 11" up - I don't think I'll be able to do much better than that
[01:57:35] <jmkasunich> and I'll have a 360 degree panorama, less mirror supports
[01:58:08] <SWPadnos> there's a project that did that for a security camera a few years ago
[01:58:11] <jmkasunich> I don't have the time or energy to do xilinx stuff - if I can't do this with the webcam I have and software on the PC, I'm not gonna do it at all
[01:58:12] <SWPadnos> the software may be available
[01:58:41] <SWPadnos> the issue there is that you have poor resolution in the center of the frame (IIRC)
[01:59:06] <jmkasunich> actually I have great resolution in the middle of the frame, where I don't need it
[01:59:28] <jmkasunich> a 12" circle centered under the thing occupies the middle of the screen
[01:59:46] <jmkasunich> then everything from 6" out to 6" out is squished into a narrow band around the outside
[01:59:53] <jmkasunich> 6" to 6'
[02:00:12] <SWPadnos> oh right - the project I'm thinking about used a funnel-shaped (sort of) mirror
[02:00:40] <jmkasunich> that would actually be nicer, but unobtainium probably
[02:00:48] <SWPadnos> you can turn that
[02:00:53] <SWPadnos> it doesn't need to be big
[02:01:11] <SWPadnos> and you can even stick a polishing doodad in the toolholder and have the CNC do most of the polishing for you :)
[02:01:16] <jmkasunich> I can turn it, but I can't (in reasonably time and effort) give it an optical polish
[02:01:28] <SWPadnos> that's kinda true
[02:01:47] <jmkasunich> $10 for a mirror is cheap, assuming I can make it work
[02:02:00] <jmkasunich> I dunno if you read where I was testing with a 1" ball bearing
[02:02:48] <jmkasunich> I need about 12 hands to hold everything, so I can't be sure of the real situation
[02:02:49] <jmkasunich> but I
[02:03:06] <jmkasunich> I'm not encouraged by the images I get with the ball at 12" above the desk
[02:04:15] <jmkasunich> I think a larger ball radius will allow the camera to be farther from the ball (its about 1" now), but won't significantly change the nature of the floor-to-pixel mapping
[02:04:41] <SWPadnos> go to a garden store and get a shiny ball lawn ornament
[02:04:49] <jmkasunich> too many camera pixels are looking at camera, or floor directly under vehicle, and not enough at floor farther out
[02:04:55] <SWPadnos> yep
[02:05:00] <SWPadnos> that's the problem with a sphere
[02:05:25] <jmkasunich> I wonder if a cone would work
[02:05:36] <jmkasunich> (and if I could find a suitably shiny cone)
[02:05:42] <SWPadnos> it should
[02:06:17] <jmkasunich> the camera with its stock lens has a 6" wide FOV at 8" distance
[02:06:27] <SWPadnos> http://dasl.mem.drexel.edu/Hing/tutorials/omnicam/homebrew_omnicam.htm
[02:06:35] <jmkasunich> and can focus from infinity to about 2"
[02:07:21] <jmkasunich> heh - wireless camera - vendor JMK
[02:07:49] <SWPadnos> I noticed that :)
[02:08:40] <jmkasunich> the screenshots aren't impressive
[02:08:54] <jmkasunich> the cone should be closer to the camera - he's got half the pixels not hitting the cone
[02:09:11] <SWPadnos> yeah, there's a geometry problem there
[02:09:22] <SWPadnos> too close and the camera takes up too much of the frame
[02:09:28] <SWPadnos> too far and you lose too much
[02:09:34] <SWPadnos> so you cahnge the angle of the cone
[02:09:48] <jmkasunich> well, the cone is a lot better than the sphere as far as camera taking up too much
[02:09:57] <SWPadnos> but that changes the direction the camera is "looking" (from horizontal)
[02:10:01] <SWPadnos> yep
[02:10:06] <jmkasunich> in fact, with a cone, the camera is invisible
[02:10:23] <jmkasunich> unless it is very large, or the cone is very blunt
[02:10:54] <SWPadnos> relative to the distance from camera to cone
[02:11:05] <jmkasunich> if the cone had 45 degree sides (90 deg total point angle), then the center would be the horizon, and the outside would be above the horizon
[02:11:15] <SWPadnos> the big black circle in the image is the lens, I believe
[02:11:26] <jmkasunich> I think its the point of the cone
[02:11:43] <jmkasunich> a ray on the camera centerline is perfectly vertical and hits the point
[02:11:45] <SWPadnos> that would be an awfully large point
[02:11:49] <SWPadnos> yep
[02:11:55] <jmkasunich> a ray just a tiny bit off the centerline is still almost vertical
[02:12:07] <jmkasunich> if the cone is 45 degrees, that ray winds up horizontal
[02:12:17] <SWPadnos> I think you still use a relatively wide angle lens though
[02:12:29] <SWPadnos> so off-center rays tilt pretty fast
[02:12:38] <jmkasunich> yeah
[02:12:46] <jmkasunich> In my case I would want a blunter cone
[02:13:02] <jmkasunich> I have absolutely no interest in anything above the horizon
[02:13:08] <SWPadnos> yes
[02:13:16] <jmkasunich> and marginal interest in things above the floor maybe 6-8 feet away
[02:13:44] <jmkasunich> I'd like the outermost rays to be from 8' away, and the inner most ones (before the camera obscures things) from 6" away
[02:14:05] <chester88> Hey guys- should step time always be the high signal and step space be the low signal ? As SWPados pointed out some step on the falling edge some leading edge. but they give timing specs for pulse'1' and pulse'0'
[02:14:13] <chester88> i'm a little confused
[02:14:17] <jmkasunich> chester88: no
[02:14:31] <jmkasunich> step time is the pulse, step space is the spacing between pulses
[02:14:45] <SWPadnos> wait
[02:14:53] <SWPadnos> step time is always the high output from stepgen
[02:14:58] <jmkasunich> pulse width (step time) is constant, the space between the pulses gets longer and shorter as the step rate changes
[02:15:10] <chester88> gecko 203 step pulse '1' time = 1000 ns step pulse '0' =2000 ns steps on falling edge
[02:15:11] <SWPadnos> but that may need to be inverted at the parallel port to match the active step edge of the drive
[02:15:16] <chester88> that is from the manual
[02:15:35] <jmkasunich> chester88: the gecko 203 is like the gecko 201 - active low
[02:15:37] <SWPadnos> so the step time is 2000, and the port pin needs to be inverted
[02:15:48] <SWPadnos> and step space 1000
[02:16:19] <chester88> 201 steps on falling edge 203 leading edge
[02:16:26] <SWPadnos> "steps on falling edge" tells you that the step pulse is the low time in the manual, but since stepgen *always* outputs a high pulse for a step, the port pin needs to be inverted
[02:17:01] <jmkasunich> chester88: 2 mins ago you said the 203 steps on the falling edge?
[02:18:27] <chester88> sorry 201 falling edge / 203 leading edge I have the manuals open now
[02:19:56] <jmkasunich> if a drive steps on the rising edge, then it might be active high
[02:20:09] <jmkasunich> I'd attempt to figure out what state is "optocoupler LED on"
[02:20:27] <jmkasunich> if it is active high, then step_len = "1" time, and step_space = "0" time
[02:20:48] <jmkasunich> if active low, then step_len = "0" time, step_space = "1" time, and set the invert bit
[02:21:11] <chester88> ok thats what I needed. wow no wonder people have trouble :)
[02:22:43] <chester88> Wow I'm not communicating real well at all today sorry about that. Must have been up late ....
[02:22:51] <jepler> chester88: jmkasunich can answer any question in a way that requires sophistication on the part of the asker
[02:23:28] <chester88> lol. Jmk is very exact . Nothing wrong with that
[02:23:47] <chester88> as long as he gets exact info first lol
[02:25:01] <jmkasunich> heh
[02:25:09] <jmkasunich> I just fixed the links to gecko manuals on the wiki page
[02:25:31] <jmkasunich> that will last until the next time mariss bumps a revision on a manual, or redesigns his website
[02:25:58] <jmkasunich> someone (/me looks toward vermont) should add the 250 to the wiki page
[02:26:14] <SWPadnos> if only I had a manual :)
[02:26:31] <jmkasunich> http://www.geckodrive.com/upload/G251%20MANUAL.pdf
[02:26:33] <SWPadnos> the G540 inverts, so it's like one of the other drives, not the other one :)
[02:26:53] <jmkasunich> oh, so we need two wiki lines, 540 and 251
[02:27:27] <SWPadnos> yes, they're different in both timing and polarity
[02:27:36] <SWPadnos> the optos also have a little extra skew
[02:28:13] <jmkasunich> * jmkasunich goes back to the world of conical mirrors
[02:28:19] <SWPadnos> heh
[02:28:28] <SWPadnos> do you want either of the high res cameras?
[02:28:31] <jmkasunich> conical actually has a lot going for it
[02:28:35] <SWPadnos> one is ethernet, the other USB2
[02:28:37] <jmkasunich> no
[02:28:39] <SWPadnos> ok
[02:28:55] <jmkasunich> thanks for the offer
[02:29:00] <SWPadnos> sure
[02:29:06] <SWPadnos> I owe you one
[02:29:07] <SWPadnos> or two
[02:29:10] <SWPadnos> or many :)
[02:29:12] <jmkasunich> I'm not even sure I'm gonna be able to make a run at this
[02:29:27] <SWPadnos> it's a complex task
[02:29:27] <jmkasunich> I sent an email today asking if I could use a laptop, no reply yet
[02:29:46] <SWPadnos> and you're just talking about getting the image so far, not making an internal map, then solving it, then moving through it
[02:29:50] <jmkasunich> the rules say you can have a power disconnect and a single control input "start"
[02:30:52] <jmkasunich> well, I've got an algorithm roughed out that I think will build the map, and handle basic navigation (dead reckoning based on wheel revolution, tweaked each time I get an image, to avoid error integration over time)
[02:31:22] <SWPadnos> oh, cool
[02:31:49] <jmkasunich> anyway, the rules issue - they want to make sure that the vehicle learns on its own - we will hand the vehicles over to the judges before the final maze is uncovered, then the only input is pressing start
[02:32:09] <jmkasunich> I've proposed that booting, logging in, and clicking an icon is equivalent, dunno what they'll say
[02:32:53] <SWPadnos> you could put an external start button on it
[02:33:23] <SWPadnos> just boot, log in, and run the app before handing it to them, and let them hit the start button
[02:33:25] <SWPadnos> heh
[02:33:33] <SWPadnos> or, tell them that the power button is the start button :)
[02:33:33] <jmkasunich> yeah, but I'd have to boot the thing and start the program running (polling the start button) an hour before the run, and hope nothing goes wrong
[02:33:42] <SWPadnos> and have it log in automatically and run the app :)
[02:33:59] <jmkasunich> yeah, I could probably do something like that
[02:34:19] <jmkasunich> ln -s /sbin/init /home/jmkasunich/runmaze ;-)
[02:34:36] <SWPadnos> yep
[02:34:37] <jmkasunich> or something like that, I always need to read the man page for symlinks
[02:34:50] <jmkasunich> anyway, the other issue(s) are size and cpu power
[02:35:08] <jmkasunich> even a small laptop is 12" wide x 9-10" long
[02:35:16] <SWPadnos> eeeeeeepc
[02:35:25] <SWPadnos> unless you need non-USB I/O
[02:35:30] <jmkasunich> 1: no idea how well they do realtime
[02:35:49] <jmkasunich> I'm gonna use hal for the RT stuff, parport, pwmgen, encoder
[02:36:06] <jmkasunich> 2) no idea how well the webcam driver and other stuff will port
[02:36:07] <SWPadnos> if I send you an AVR32 development kit, will you port RTAI and HAL to it? :)
[02:36:22] <jmkasunich> 3) I don't have an eee$$$eee laying around
[02:36:24] <jmkasunich> no
[02:36:25] <SWPadnos> or AT91SAM7X (ARM7)?
[02:36:28] <SWPadnos> darn
[02:36:49] <jmkasunich> and the other problem with this contest is that I have that CIM jig job to do
[02:37:01] <SWPadnos> contest -> trash
[02:37:18] <jmkasunich> which has gotten to the point of needing to do stuff with the van norman, just as the temperature is dropping like a rock
[02:37:26] <SWPadnos> yeah
[02:37:37] <SWPadnos> expecting record lows here tonight/tomorrow
[02:37:45] <SWPadnos> high of -6 to +10
[02:38:21] <jmkasunich> contest would be fun, if they let me use a laptop, if I have one that is reasonably powerfull, and if I manage to get the CIM work done (or make good contest progress while its too fscking cold to work on the CIM)
[02:39:21] <jmkasunich> btw, CPU power is another reason to avoid the high res camera - more data to process
[02:41:28] <SWPadnos> well, yes and no. the higher resolution is only used at the early stages of processing - you reduce it to some other form (like vectors) as fast as possible
[02:41:40] <SWPadnos> or you do 2x2 binning if you don't need the resolution
[02:41:44] <SWPadnos> (or higher)
[02:42:09] <jmkasunich> yeah, but unless I do xilinx stuff, that data still needs transferred before I can bin it
[02:42:39] <SWPadnos> the sensors in my cameras can be set for that, it's not a CPU or FPGA task
[02:43:04] <jmkasunich> nice
[02:43:06] <SWPadnos> actually, with more time the Elphel camera could do the whole thing
[02:43:19] <SWPadnos> it has a powerful enough CPU, and there are some I/O pins inside
[02:43:38] <SWPadnos> so it could do step generation (though not with RT)
[02:43:58] <jmkasunich> what about pwm and low-res encoder counting?
[02:44:14] <SWPadnos> maybe. I don't think any FPGA pins are connected to the I/O header
[02:44:32] <jmkasunich> I have a platform from a previous contest, two motors with 64 count/rev encoders, ~50:1 worm gears, and wheels
[02:44:56] <jmkasunich> I plan to reuse that - will need to move the wheels in, they are currently about 14" apart
[02:45:15] <jmkasunich> I need to fit on a 12" wide board, with enough margin that I don't fall off and get stuck if I'm a bit off center
[02:45:16] <SWPadnos> http://sourceforge.net/projects/elphel/
[02:45:22] <jmkasunich> probably want no more than 8" spacing
[02:45:27] <skunkworks> engineer week again?
[02:45:30] <SWPadnos> ok, so the "path" is the raised surface
[02:45:33] <jmkasunich> yes
[02:45:45] <jmkasunich> yes, the track boards are 5/8" thick
[02:45:46] <skunkworks> neat :P
[02:46:51] <jmkasunich> http://wiki.elphel.com/index.php?title=10353
[02:47:00] <SWPadnos> I have the 333
[02:47:01] <jmkasunich> SWPadnos: is ^^^ what you are talking about?
[02:47:05] <SWPadnos> http://www.elphel.com/3fhlo/10333/10333b.pdf
[02:47:10] <SWPadnos> yes, but the 333
[02:47:19] <SWPadnos> the 353/363 are very cool too
[02:47:27] <SWPadnos> I don't recall if I have the 3MP or the 5MP sensor
[02:47:48] <SWPadnos> oops:
http://www.elphel.com/3fhlo/index.html
[02:47:56] <SWPadnos> easier to read than the schematic PDF
[02:48:28] <jmkasunich> the 353 runs linux on the onboard cpu - does the 333 do the same?
[02:49:15] <SWPadnos> yes
[02:49:31] <jmkasunich> so what kind of a dev toolchain is available?
[02:49:36] <SWPadnos> it's a different version of the ETrax, and a smaller FPGA (maybe 1.5MGate instead of 3)
[02:49:44] <SWPadnos> full Linux toolset
[02:49:51] <jmkasunich> (if it can be done entirely on the board, then it is a more interesting situation)
[02:49:55] <jmkasunich> gcc, make, etc?
[02:50:11] <SWPadnos> the camera has Linux on it now, and it runs a webserver and telnet (?)
[02:50:15] <SWPadnos> yes, I think sio
[02:50:17] <SWPadnos> so
[02:50:53] <jmkasunich> it's been ages since I did embedded work, I assume you edit/compile on another box, then transfer the code? or do you actually have a command line on the camera (ssh, etc)?
[02:51:13] <SWPadnos> there is a command line on the camera, but compiling isn't done there for a couple of reasons
[02:51:23] <jmkasunich> disk (or lack thereof)
[02:51:27] <SWPadnos> flash storage and speed, for starters
[02:51:45] <SWPadnos> the 353 has an IDE interface, so you could theoretically attach a hard disk to it
[02:51:54] <SWPadnos> there's even a 3x CF adapter board
[02:51:56] <SWPadnos> CF RAID
[02:52:07] <jmkasunich> but the 333 is the one you have
[02:52:12] <jmkasunich> so the only one that is interesting ;-)
[02:52:17] <SWPadnos> yep
[02:52:40] <SWPadnos> if you can use a laptop of some sort, then the other one may be more interesting though
[02:52:44] <SWPadnos> since it's USB powered
[02:53:20] <SWPadnos> the Elphel will need a power supply - it uses POE right now, but it can be powered by a DC supply if you open it up
[02:53:23] <jmkasunich> if I can use a laptop, then I will use the webcam
[02:53:37] <SWPadnos> oh, right :)
[02:53:41] <jmkasunich> the nice thing about the 333 would be if it could run standalone
[02:53:46] <jmkasunich> smaller, lighter
[02:54:00] <jmkasunich> do you know what input voltage it needs? POE is 48V isn't it?
[02:54:52] <SWPadnos> not sure. I think the internal connections would be 3.3 or 5V
[02:55:00] <SWPadnos> lemme check
[02:55:37] <SWPadnos> the lens I have is a CS mount 4.5-12mm varifocal
[02:55:38] <jmkasunich> I'll probably have a 12V gel-cell for the motors, regulation down to something lower wouldn't be a big deal
[02:56:45] <jmkasunich> I might even have some isolated brick type DC-DC converters around here
[02:57:26] <jmkasunich> basically what I need is the ability to run a userspace program that can acquire an image on demand (just a lump of pixels in memory)
[02:57:47] <SWPadnos> there's one installed
[02:57:48] <jmkasunich> then that program does a bunch of stuff with the image (and previous images, and other data)
[02:58:02] <jmkasunich> one what? brick DC-DC?
[02:58:09] <SWPadnos> a capture program
[02:58:27] <SWPadnos> you just call it and it streams an image to stdout
[02:58:48] <jmkasunich> it isn't vgrabbj is it?
[02:59:17] <SWPadnos> heh -no
[02:59:29] <SWPadnos> it's the program they use for CGI access to the camera
[02:59:48] <jmkasunich> oh
[02:59:59] <jmkasunich> that is a couple extra layers
[03:00:27] <SWPadnos> well, if you run something local to the camera, you can just run the program directly - you don't have to use the web server
[03:00:58] <SWPadnos> ok, there's a 16-pin (2x8, 2mm spacing) header on the board
[03:00:59] <jmkasunich> yeah, I'm reading on their wiki and trying to get my head around it
[03:01:30] <jmkasunich> I have a feeling that either the main guy speaks other than english, or he's just not much of a writer
[03:01:54] <jmkasunich> ah, russian
[03:02:56] <jmkasunich> heh, PHP and CGI
[03:02:59] <SWPadnos> yep
[03:03:02] <jmkasunich> not the languages I'm looking for
[03:03:10] <SWPadnos> ok, 6 of the header pins do go straight to the FPGA
[03:03:47] <jmkasunich> 50mV logic swings eh? ;-)
[03:03:56] <SWPadnos> heh
[03:04:07] <SWPadnos> 4 more to the CPU (serial lines, I think they can be used for GPIO)
[03:04:39] <SWPadnos> the raw 48V POE input, plus 2 each of GND and V33 - presumably 3.3V supply
[03:05:28] <jmkasunich> do you know how much ram there is (for the linux CPU)?
[03:05:33] <SWPadnos> understanding the full codebase (HDL plus C) is a pretty big task
[03:05:36] <SWPadnos> hmmm
[03:05:45] <SWPadnos> some megabytes, I don't recall
[03:05:52] <jmkasunich> my hope would be to ignore the HDL
[03:06:03] <jmkasunich> treat it as a webcam ;-)
[03:06:07] <SWPadnos> you won't have any access to those I/O pins unless you do
[03:06:09] <SWPadnos> ah
[03:06:16] <SWPadnos> that's what it is :)
[03:06:27] <jmkasunich> ah, bad term
[03:06:29] <SWPadnos> this is the CPU:
http://www.axis.com/products/dev_etrax_100lx/
[03:06:57] <jmkasunich> when I say "webcam" I mean "a cheap camera that plugs into a computer", not "a camera + software that appears on the web"
[03:07:30] <jmkasunich> * jmkasunich head spins
[03:07:35] <SWPadnos> there's 8M of flash and 32+16M of RAM
[03:07:48] <jmkasunich> and it's not running bloatware
[03:07:52] <SWPadnos> I don't recall which buffer is connected to the FPGA and which is for the CPU
[03:08:01] <SWPadnos> Linux kernel 2.4 or 2.6, I don't recall
[03:08:26] <jmkasunich> By default the camera runs telnetd. Login "root", password "pass". You can telnet to the camera and explore the power of a full GNU/Linux distribution.
[03:08:30] <jmkasunich> from the wiki
[03:08:34] <SWPadnos> yep
[03:08:36] <SWPadnos> done that
[03:08:48] <SWPadnos> though I'd have to plug in a different hub and put the camera back together to do it again ;)
[03:08:55] <SWPadnos> err, switch
[03:09:06] <jmkasunich> so write code on main system, compile on main system (using cross compiler tools), ftp to camera, telnet into camera and run the program
[03:09:25] <SWPadnos> yep
[03:09:44] <SWPadnos> or put the application in initscripts and wait for the external trigger signal
[03:10:06] <jmkasunich> if messing with HDL, then write (modify) that code on the main system, use the xilinx toolchain to build (shudder), then upload to camera with ftp and put "somewhere" for loading into the fpga
[03:10:29] <jmkasunich> I'm thinking of the development cycle (and learning curve) rather than the one-button-start issue
[03:10:37] <SWPadnos> hmmm. yes. I don't know the specifics of how to do that - never had to
[03:10:41] <SWPadnos> yes
[03:12:40] <SWPadnos> hmmm. I wonder which way is up
[03:12:51] <jmkasunich> doesn't matter really
[03:12:54] <SWPadnos> maybe the text on the PCB should be readable
[03:13:04] <SWPadnos> well, it's nice if you want right-side-up images
[03:13:17] <jmkasunich> picky picky
[03:13:21] <SWPadnos> when you use the 1/4-20 mount which will by definition be on the bottom :)
[03:13:56] <jmkasunich> I'll probably have it pointing at the sky anyway, with a sphere or cone mirror up there
[03:14:44] <SWPadnos> I'm just trying to reassemble the camera
[03:14:49] <SWPadnos> which has 180 degree rotational symmetry for the screws that hold the imager/lens mount to the extrusion
[03:14:57] <jmkasunich> heh
[03:15:28] <jmkasunich> what about the other boards, any clues there? connectors lined up with holes, and board-board cables not twisted, etc?
[03:15:49] <SWPadnos> yes - I think the "right side up text" is correct
[03:16:05] <SWPadnos> the back has text on the outside, and the flex cable lines up nicely with that orientation
[03:17:23] <SWPadnos> argh. flex cable connectors are a PITA
[03:17:34] <SWPadnos> they love to close when you push the cable near them
[03:18:26] <jmkasunich> wait - you said 8M of flash? that is the "disk"?
[03:18:40] <jmkasunich> that is a seriously stripped down linux
[03:19:28] <jmkasunich> I wonder if it is stripped down to the point where a high priority userspace process can do "realtime" stuff
[03:19:47] <SWPadnos> well, I wouldn't count on that. I've never gotten a scope in there to look at anythng
[03:20:24] <SWPadnos> actually, I haven't written any code for it - once the decision not to use it came through, it's been more of a curiosity than anything else
[03:20:31] <jmkasunich> counting encoders would be the critical part
[03:21:19] <jmkasunich> but at 64 counts/rev, and maybe 5000 RPM top speed, that is only 5.3KHz
[03:21:29] <SWPadnos> yeah, and with only 6 to 10 I/Os, there could be a problem
[03:21:45] <SWPadnos> you need 8 minimum, and more if you want any switches of any sort
[03:22:51] <jmkasunich> so close, and yet so far
[03:22:57] <SWPadnos> heh
[03:23:09] <SWPadnos> hmmm
[03:23:38] <jmkasunich> I was starting to get excited about it (size, weight, etc) but I think the learning curve would be just too steep
[03:23:46] <SWPadnos> http://www.via.com.tw/en/products/embedded/artigo/
[03:23:50] <SWPadnos> how abotu one of those?
[03:24:05] <SWPadnos> I think there's even a parallel port daughtercard or connector for it
[03:24:52] <jmkasunich> $$?
[03:25:02] <SWPadnos> I can loan yo umine :)
[03:25:26] <jmkasunich> is that the one you wanted an RTAPI port for?
[03:25:30] <SWPadnos> no
[03:25:54] <SWPadnos> it's a PC the size of a floppy drive
[03:26:04] <SWPadnos> the RTAPI joke was about the AVR32 or ARM chips
[03:26:16] <jmkasunich> ok, I was having some confusion
[03:26:31] <SWPadnos> I think Jymmm may have tried booting his with Ubuntu - I don't recall the outcome
[03:26:35] <jmkasunich> VIA C7 is x86 compatible, not an ARM or something like that
[03:26:40] <jmkasunich> (right?)
[03:26:42] <SWPadnos> yes
[03:26:53] <SWPadnos> 686 or something
[03:26:58] <jmkasunich> 1GHz
[03:27:05] <jmkasunich> lotso memory
[03:27:14] <SWPadnos> lemme check mine - I'm not sure what it has
[03:27:21] <jmkasunich> what kind of power input? DC, AC, wallwart?
[03:27:23] <SWPadnos> I know it's an 80GB drive or something in that range
[03:27:26] <SWPadnos> 12V DC I think
[03:27:58] <jmkasunich> I probably have a 2.5" disk around here, so I wouldn't mess up whatever is on yours
[03:28:17] <SWPadnos> I think it's XP or Vista or something, so I don't really care much
[03:28:32] <jmkasunich> I'd be tempted to do a breezy or dapper xubuntu install with our RT kernel packages
[03:28:41] <SWPadnos> oh, CE 2.0 - definitely nukable
[03:28:58] <jmkasunich> nuke with extreme prejudice
[03:29:09] <SWPadnos> the wall wart says 12V/5A output
[03:29:28] <jmkasunich> 60W max then, probably half that in practice
[03:29:34] <SWPadnos> less I bet
[03:30:02] <jmkasunich> running motor PWM off the same battery is a bit scary
[03:30:11] <SWPadnos> heh
[03:30:11] <jmkasunich> maybe some nice common mode chokes.....
[03:30:27] <jmkasunich> and a big ole cap
[03:31:20] <SWPadnos> hmmm
[03:31:34] <SWPadnos> I can send you an Artigo and a G-Rex
[03:31:41] <SWPadnos> wait - you have a G-Rex
[03:31:46] <SWPadnos> ?
[03:31:50] <jmkasunich> yes
[03:32:00] <SWPadnos> great
[03:32:02] <jmkasunich> but using g-rex is out of the question, no way it does image processing
[03:32:04] <SWPadnos> the serial command set is all you need
[03:32:07] <jmkasunich> (or do you mean for the rt stuff)
[03:32:13] <SWPadnos> no, for the RT motor /encoder stuff
[03:32:18] <SWPadnos> yes
[03:32:59] <SWPadnos> it's a heck of a lot easier than finding out how to get to the parallel port in this thing (which I think is on a daughtercard)
[03:33:13] <SWPadnos> and installing/configuring RT in the hope that it will work
[03:33:33] <jmkasunich> if our RT kernel doesn't work I would give up
[03:33:55] <SWPadnos> sim is good enough if you have a G-Rex, since serial works in userspace
[03:34:13] <SWPadnos> (and it looks like a serial port if you want it to)
[03:34:44] <jmkasunich> does it do pwm + encoder?
[03:34:57] <SWPadnos> the G-Rex will only output step/dir
[03:35:02] <jmkasunich> thats what I thought
[03:35:04] <SWPadnos> but it does do encoder input
[03:35:26] <jmkasunich> the g-rex is just too much
[03:35:50] <SWPadnos> hmmm. I disagree (unless you have servos)
[03:35:58] <SWPadnos> there's a simple serial protocol
[03:35:58] <jmkasunich> if I can use hal, then I'd go for it (either on some old laptop that I have, or the VIA pico-board)
[03:36:13] <jmkasunich> if I have to get yet another piece working, eww
[03:36:41] <jmkasunich> I have servos
[03:37:00] <jmkasunich> I've already got the motors, the encoders, the H bridges, etc, from a couple years ago
[03:37:08] <jmkasunich> it's even wired to a parport connector
[03:37:15] <SWPadnos> hmmm
[03:37:20] <jmkasunich> steppers would mean drives of some sort
[03:37:25] <jmkasunich> and mechanical work
[03:38:01] <jmkasunich> I probably can even find the hal files and PID tuning parameters
[03:38:34] <jmkasunich> in fact, thats what I should be doing now - digging for the laptop we used
[03:38:42] <SWPadnos> I'm looking for the parallel port, in case it's not on a daughtercard
[03:39:37] <jmkasunich> I read the mobo specs, parport isn't listed
[03:41:50] <SWPadnos> yeah. Jymmm looked up a lot of info just after we got them, and I think he found a parallel port daughtercard somewhere
[03:42:51] <jmkasunich> well, I hope it isn't the laptop I just found
[03:43:06] <jmkasunich> Pentium 150MHz, 48M ram
[03:43:21] <jmkasunich> lol, it has BDI-TNG on it
[03:43:46] <SWPadnos> heh
[03:44:30] <jmkasunich> I know the one I used before had breezy + xubuntu
[03:44:38] <jmkasunich> I just don't know where it might be
[03:48:31] <jmkasunich> I just found a board that steves_logging sent me a couple years ago
[03:48:44] <SWPadnos> cool
[03:48:47] <jmkasunich> 433MHz celeron, 128MB ram
[03:49:01] <SWPadnos> uncool
[03:49:32] <jmkasunich> that will run non-bloated software just fine
[03:49:40] <jmkasunich> probably faster than the CPU on that camera
[03:49:55] <SWPadnos> yes, certainly
[03:50:03] <jmkasunich> however, no USB, so I can't connect the webcam
[03:50:19] <jmkasunich> board is only 7" x 5" tho, nice
[03:50:57] <jmkasunich> has ethernet, kb, mouse, video, IDE
[03:51:23] <jmkasunich> PC104 and PC104+
[03:51:35] <jmkasunich> ohh, there is USB - header instead of connector
[03:51:54] <jmkasunich> runs on 12V
[03:52:36] <SWPadnos> oh, sounds perfect then
[03:52:41] <jmkasunich> also, parport and 2 com ports, plus one "multi-function" 16 pin header
[03:53:03] <jmkasunich> and a manual
[03:53:20] <SWPadnos> heh
[03:53:20] <jmkasunich> Teknor, Viper 830, Celeron based industrial PC, circa 1999
[03:55:02] <jmkasunich> I forget how we do breezy installs - I don't think we released a CD, we just had a kernel package
[03:55:05] <jmkasunich> maybe
[03:55:19] <jmkasunich> dapper isn't gonna like the 128M of ram
[03:55:36] <SWPadnos> what kind of RAM?
[03:55:52] <jmkasunich> I'm guessing PC100
[03:56:00] <jmkasunich> only one socket
[03:56:05] <SWPadnos> DIMM / SODIMM / SIM ... ?
[03:56:32] <jmkasunich> regular old desktop memory
[03:57:02] <SWPadnos> ok, so a single PC66 or PC100 64-bit wide DIMM
[03:57:06] <jmkasunich> socket says "SDRAM", module says P100
[03:57:11] <SWPadnos> ok
[03:57:19] <jmkasunich> (and other things - PC100 would be more clear)
[03:58:26] <jmkasunich> well lookee here
[03:58:52] <jmkasunich> hiding (mounted with back of PCB facing up) is a socket for CF card
[03:59:02] <jmkasunich> with a spacious 16MB card in it
[03:59:11] <SWPadnos> excellent
[03:59:48] <SWPadnos> http://dealnews.com/memory/prices/PC100-SDRAM/15/256MB.html
[03:59:58] <jmkasunich> I could probably get a couple GB CF card for cheap, I wonder if it would work
[04:00:20] <SWPadnos> I'd boot it up and see what the BIOS says
[04:00:31] <SWPadnos> or look at the manual
[04:01:09] <jmkasunich> given the mess on my bench, and the time, I'll try the latter
[04:01:16] <jmkasunich> gotta boot this thing tomorrow tho
[04:01:26] <jmkasunich> it sure would be nice if I could get dapper on it
[04:01:31] <SWPadnos> yeah - sounds like a good find
[04:01:48] <SWPadnos> you may be able to do the server install
[04:01:51] <cradek> dapper *will* install if there is swap
[04:02:02] <cradek> don't delete the swap partition, leave it and delete the others
[04:02:12] <SWPadnos> if there is one
[04:02:14] <cradek> the cd will use the swap to boot
[04:02:21] <SWPadnos> on the 16 MB CF card ;)
[04:02:24] <jmkasunich> "up to 128MB of sync DRAM or 256MB of registered SDRAM on one 168 pin DIMM socket"
[04:02:40] <cradek> ugh, registered
[04:02:43] <SWPadnos> heh
[04:02:47] <cradek> you won't find that in your junkpile
[04:03:09] <jmkasunich> will dapper work with 128M?
[04:03:31] <cradek> easily if you don't run gnome
[04:03:46] <jmkasunich> as in, no X, or just something lighter?
[04:04:01] <cradek> what's wrong with breezy? if it's already installed why mess it up?
[04:04:09] <jmkasunich> its not
[04:04:22] <cradek> oh, I wasn't paying attention
[04:04:27] <jmkasunich> I used breezy on the laptop that I can't find, thats why it was mentioned earlier
[04:04:32] <cradek> oh ok
[04:04:57] <jmkasunich> I'd be happy to install breezy here, but I'm not sure what we did with the RT kernel, etc
[04:05:28] <jmkasunich> this is much smaller (and about the same speed, maybe faster) that the laptop, so if it works I'd rather use it
[04:05:48] <cradek> http://www.linuxcnc.org/emc2/dists/breezy/emc2.1/binary-i386/
[04:06:18] <jmkasunich> cool - stock breezy install, then those packages, right?
[04:06:32] <cradek> yes, linux-image and rtai-modules
[04:06:47] <jmkasunich> and I have the ubuntu-5.10 iso here already
[04:06:59] <cradek> that one will definitely install - it doesn't live boot
[04:07:13] <cradek> (it takes an amazingly long time though)
[04:07:31] <jmkasunich> btdt
[04:07:37] <cradek> ha
[04:07:41] <SWPadnos> especially on a celeron <1/2 GHz writing to CF
[04:07:44] <jmkasunich> I just realized that the input is 5V, not 12
[04:07:56] <jmkasunich> SWPadnos: I'll stick a spinning disk on it for now
[04:08:02] <SWPadnos> good to note before plugging it in :)
[04:08:18] <jmkasunich> there is a 6 pin header, with 4 wired
[04:08:39] <jmkasunich> 2 gnd, 2 +5, 1 +12, 1 -12, and I didn't look closely enough
[04:08:57] <jmkasunich> the voltages are silkscreened on the bottom, and the 12's jumped out at me, the 5's are kind of obscured
[04:10:52] <SWPadnos> I wonder if the +/- 12 are necessary (for anything other than the serial ports)
[04:11:06] <jmkasunich> the supplied cable has no 12V wires, so I'm guessing not
[04:11:13] <SWPadnos> ah
[04:11:43] <jmkasunich> the other end is a disk drive power connector - any old PC power supply and I'm set - one connector to the disk, one to the board
[04:11:55] <jmkasunich> except for getting it to start up
[04:12:00] <jmkasunich> jumper in the right place
[04:12:33] <jmkasunich> that's an interesting point - full size HD needs 12V as well as 5
[04:12:53] <jmkasunich> CF is the way to go assuming the BIOS etc supports big ones
[04:15:53] <jmkasunich> very promising, and now I must walk ze dog
[04:16:00] <jmkasunich> goodnight
[04:16:07] <SWPadnos> see you
[04:35:28] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Fix stepper timing table
[04:47:40] <CIA-1> EMC: 03cmorley 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Fix stepper timing table
[04:53:49] <CIA-1> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (interp_queue.hh interp_queue.cc interp_convert.cc): in order to allow leaving comp on all the time while a tool is loaded, concave corner rapids need to be trimmed too
[10:14:46] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Change pyvcp option _xyz-button_ to remove spindle override buttons but add xyz relative position readout. General clean up of comments written to HAL files.
[10:16:52] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.glade: Change name of pyvcp option button from _xyz jog button_ to _xyz-button_ because there is no job button included
[10:18:32] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/configs/common/configurable_options/pyvcp/xyzjog.xml: changes to remove spindle override buttons and add xyz DRO display
[11:07:43] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: add code to connect the program control buttons to halui
[11:43:37] <micges> jepler: thanks for backporting i18n
[13:02:55] <micges> in axis about window can be added 2009 also
[13:08:49] <alex_joni> http://www.qtsoftware.com/about/news/lgpl-license-option-added-to-qt
[13:09:48] <micges> yay!
[13:13:43] <micges> alex_joni: I would like to have your opinion:
[13:13:58] <jepler> micges: you're welcome
[13:14:36] <jepler> micges: alex did the work of creating and testing the patch
[13:15:46] <alex_joni> only porting from TRUNK, not really much work :)
[13:15:54] <micges> alex_joni: thanks to you too
[13:16:37] <micges> alex_joni: have you tested with deb packages?
[13:16:42] <alex_joni> yes
[13:18:34] <micges> polish language is the first people asked with our machines, poor that "Joint following error" isn't as easly to i18n
[13:21:08] <micges> I have modified axis, added gcode generator to it, add tab with parameters (velocity, height , power and so)
[13:22:45] <micges> Is it sane solution to add to gcode switching between parameters (select fast burn params, process with gcode, slelect deep burn params, process with gcode) ?
[13:23:19] <micges> to make emc/axis more automatic
[13:29:34] <micges> I've started also extend original axis with tool table editor(jepler said that it would have to be another program for this but surely it will finally be included to AXIS so save time)
[13:30:00] <jepler> m1xx gcodes are intended for this kind of use -- to control settings on your machine that don't exist in our standard gcode
[13:31:09] <alex_joni> I think micges referrs to something else
[13:31:19] <alex_joni> embedding CAM into AXIS, but the description is unclear
[13:31:35] <alex_joni> micges: provide some more explanations on what you mean (text, screenshots, etc)
[13:32:35] <jepler> I was responding to the small part I thought I understood: gcode to switch burn parameters
[13:32:38] <jepler> that makes sense to me
[13:32:52] <jepler> the rest sounds very specific to micges' application, and I'm content that what he chooses to do is good for him
[13:34:12] <micges> ok I understand Mxx
[13:34:31] <micges> but when I have table 10x10 paramters what then ?
[13:34:54] <micges> select config 1 - set 10 parameters = 10x Mxx
[13:35:53] <micges> I think about config tables exist in some (very old even ) cnc controls
[13:36:41] <micges> I've embedded those table in AXIS but there are limitations
[13:37:04] <jepler> so you're just complaining?
[13:37:55] <micges> Im asking for ideas/help
[13:39:41] <jepler> M101 P1: turn on parameter set 1 (and the details of how to get 10 related numbers are up to your m101 program)
[13:40:10] <jepler> otherwise, issue 10 M1xx commands -- there's no arbitrary limit on the number of lines in a part program or limit on lines executed by mdi
[13:41:36] <jepler> but probably alex is right, I'm not grasping the problem statement yet
[13:47:15] <micges> We will back this talk,It's very important for me to know your's opinions about this, must go now
[13:47:27] <micges> thanks
[13:47:29] <micges> bbl
[14:34:58] <skunkworks_> any reason this couldn't be part of emc?
http://www.anderswallin.net/2008/04/idb-inverse-deadband-component-for-emc2/
[14:36:00] <cradek_> no
[14:36:30] <alex_joni> otoh, awallin has commit access ..
[14:36:56] <skunkworks_> ah - Maybe I will email on the list and ask him to commit it.
[14:38:54] <skunkworks_> I was playing with a bigger motor last night and noticed that it had a deadband of about -.5 to .5 (well with my scaling and such)
[14:47:30] <cradek_> I bet all motors have some of that when in current/torque mode
[14:47:37] <cradek_> cradek_ is now known as cradek
[14:48:16] <skunkworks_> yes - I wonder how the pico system takes care of that? Or can it most of the time be tuned out with a bit of work.
[14:48:44] <skunkworks_> (current mode amps)
[14:48:59] <cradek> I don't know. if it's common, maybe it should be a part of the pid component
[14:49:10] <skunkworks_> I was going to ask that.. ;)
[14:49:21] <cradek> you/we'd have to ask jmk about that
[14:50:26] <skunkworks_> looking at the code - 0 is 0.. (if I understand it right) you would not want it sitting on one side or the other sending current thru the motor
[14:52:00] <cradek> pid output will never be 0
[14:52:34] <skunkworks_> I thought during encoder 'deadband'//
[14:52:37] <skunkworks_> ...
[14:53:27] <skunkworks_> or no?
[14:53:42] <cradek> true, pid has deadband itself
[14:53:55] <cradek> it pretends error is zero
[14:53:59] <skunkworks_> right
[14:54:33] <cradek> but zero error doesn't mean pid's output is zero does it?
[14:54:43] <cradek> only that the P part is zero
[14:55:00] <cradek> the I part is constant but probably nonzero
[14:55:09] <skunkworks_> hmm
[14:55:42] <skunkworks_> I suppose it is very little current anyways.. Probably not a problem either way.
[14:56:29] <cradek> but if idb is set right, it DOES make the motor turn (barely)
[14:56:32] <cradek> I think
[14:56:34] <cradek> isn't that the point?
[14:56:46] <skunkworks_> I would set it just under..
[14:56:59] <skunkworks_> to get rid of most of the 'slack'
[14:57:13] <skunkworks_> but it will be fun to play with..
[14:57:45] <cradek> yeah, it's interesting, but it seems complex
[14:58:04] <cradek> I guess I don't really have any feel for what result it will have on tunability
[14:58:18] <skunkworks_> I suppose you didn't run into any of that with your lathe?
[14:58:31] <cradek> no, since it's velocity mode
[14:58:40] <skunkworks_> I meant the little one.
[14:58:56] <cradek> I am sure it has a lot of deadband, but it tuned up anyway
[14:59:02] <skunkworks_> ah
[14:59:24] <cradek> maybe it would have been easier with idb, I didn't try it
