Back
[00:33:58] <L84Supper> anyone have recommendations for a CNC shop in the midwest to mill some 6063 flat stock?
[00:42:49] <dan1mal> i'm not midwest, but i can do it
[00:42:55] <dan1mal> i'm socal
[00:53:44] <L84Supper> close enough
[00:54:01] <L84Supper> 1-100 x 19 different parts
[00:54:01] <L84Supper> +/- 0.0015 tolerance stuff, pretty basic but having trouble finding a decent shop
[00:54:32] <dan1mal> how big?
[00:54:41] <dan1mal> tollerance shouldnt be an issue
[00:55:52] <L84Supper> largest piece is ~2" x 8" x .25", some are only ~1"x1" x.25"
[00:56:12] <dan1mal> oh not a problem at all
[00:56:25] <L84Supper> yesh, am getting crazy high bids
[00:57:00] <L84Supper> don't they knew we're in a recession
[00:57:21] <dan1mal> they're trying to pay the rent with 1 job
[00:57:26] <L84Supper> sp knew/know
[00:58:18] <dan1mal> if you want, shoot me a print and i'll quote it for you
[00:58:32] <dan1mal> are you supplying material or am i?
[00:58:47] <L84Supper> actually quoted me $315 for a rectangle ~1"x1" x.25"
[00:59:01] <dan1mal> haha wow
[00:59:16] <L84Supper> yes, nuts
[00:59:21] <dan1mal> that's amazing
[00:59:24] <jmkasunich> maybe they think 6063 is gold
[00:59:42] <jmkasunich> how many pieces was that quote for?
[01:00:05] <dan1mal> 1 probably
[01:00:09] <L84Supper> maybe, I can supply the stock, it's all made from .125, .250 and .500 flat stock
[01:00:33] <L84Supper> the 10 piece was ~110
[01:00:34] <jmkasunich> $300 is what, 6 hours at $50/hour
[01:00:54] <L84Supper> not sure, I can even generate the CAM files
[01:01:15] <L84Supper> maybe they were going to make them all by hand
[01:01:18] <jmkasunich> I can see it taking quite a few hours for the first one, when you consider all the little stuff like paperwork, programming, fixturing, shipping, etc
[01:01:35] <L84Supper> I could file a piece by hand in under 6 hrs
[01:02:19] <L84Supper> not when it's 19 different pieces at 10- 100 per month for each
[01:03:03] <L84Supper> surprised with the midwest, lots of shops just didn't bid
[01:03:13] <jmkasunich> I'm just saying that the first piece is always gonna be expensive because of overhead
[01:04:05] <L84Supper> must have old machines since they whinned about +/- 0.0015, they wanted to be sure it's not 0.015 we need :) heh
[01:04:08] <dan1mal> i have very little overhead because i'm a small shop, so it just makes my jaw drop at some of the quotes my customers have been getting
[01:04:28] <L84Supper> have a website?
[01:04:30] <dan1mal> .0015" isnt hard to hold
[01:04:43] <L84Supper> yes, I know, I build machines
[01:04:47] <dan1mal> it's not up yet, i've been too busy (thankfully)
[01:04:59] <L84Supper> we're just not a shop, we're a lab
[01:05:24] <dan1mal> i build machinery as well
[01:05:38] <dan1mal> but for manufacturing
[01:05:58] <dan1mal> and assembly
[01:06:00] <jmkasunich> L84Supper: what do the parts look like?
[01:06:23] <jmkasunich> just profile mill the outside? or drill holes? tapped holes? how many setups would be needed, etc?
[01:06:46] <dan1mal> here's my email if you want to send a print or model: d.wilcox@imp-mfg.com
[01:07:44] <L84Supper> milled sides, with some tapered areas + M3 holes and taps
[01:08:12] <dan1mal> tapered areas?
[01:08:25] <jmkasunich> like, tapered end mills? or 5-axis work?
[01:09:12] <L84Supper> 3-axis movement is all that required
[01:09:15] <dan1mal> 5 axis i cannot do
[01:09:22] <dan1mal> oh ok
[01:09:49] <L84Supper> can you view iges?
[01:09:56] <dan1mal> yes
[01:10:05] <dan1mal> any format will do, i have solidworks
[01:10:06] <L84Supper> I'll send some iges in a sec
[01:10:32] <L84Supper> have native for that as well, we run just about everything but heeks so far
[01:11:15] <dan1mal> as long as it's 2008 or older, or you backsave it, that will work
[01:14:39] <L84Supper> you have mail
[01:14:45] <dan1mal> ok brb
[01:24:17] <dan1mal> what exactly do you need a .0015" tollerance on?
[01:24:59] <dan1mal> and is it +-.0015 or +-.00075?
[01:25:33] <L84Supper> +-.0015
[01:26:20] <L84Supper> the parts all fit together with slots and the distance between them is critical
[01:26:29] <Jim> Jim is now known as Guest79364
[01:26:47] <L84Supper> I'll send you a jpg of the assemblies
[01:27:11] <dan1mal> that will help
[01:29:35] <L84Supper> you have more mail
[01:36:09] <gtom> anybody involed in hm stepgen.c?
[01:36:26] <dan1mal> so you're making 10-100 of these assemblies a month?
[01:36:46] <L84Supper> not yet, but will be soon
[01:37:13] <gtom> hi
[01:37:39] <L84Supper> dan1mal : going to private
[01:40:20] <dan1mal> gotcha
[02:33:19] <jmkasunich> woo hoo - fixed my 25 year old microwave
[02:33:25] <jmkasunich> should be good for another 25 now ;-)
[03:47:32] <Jymmm> jmkasunich: replaced the relay, huh?
[04:25:51] <dan1mal> w00t got my spindle working, thanks to you guys
[04:41:12] <KimK> Congrats, dan1mal
[04:41:36] <KimK> you did all the work
[05:35:52] <A4ndy> hallow
[05:36:00] <A4ndy> :)
[05:36:33] <A4ndy> Why EMC2 do not support DSL (Damn Small Linux)
[05:37:01] <A4ndy> is it because the downward kernel?
[05:41:55] <A4ndy> Damn small EMC2 is sound nice...
[06:30:48] <Spida> is anybody here using brl-cad? is it usable?
[07:01:06] <alex_joni> Spida: it's certainly usable, but personally I found it has a too long learning curve
[07:01:17] <alex_joni> you can check out #brlcad for specific questions though
[07:04:48] <alex_joni> it's been deeloped for more than 25 years now, so it should be quite capable ;)
[07:39:06] <Jymmm> alex_joni: So has Man kind, that's not saying very much.
[07:57:37] <alex_joni> mankind is quite capable :P
[07:57:44] <alex_joni> btw, seen google wave?
[08:01:01] <alex_joni> Jymmm:
http://www.youtube.com/watch?v=v_UyVmITiYQ
[08:33:44] <Jymmm> alex_joni: Interesting. I can't fnish it all tonight, but I'll look at the rest tomorrow.
[08:44:14] <alex_joni> I found it interesting to watch
[09:24:07] <micges> good morning
[09:25:37] <Spida> alex_joni: what are you using?
[09:39:18] <alex_joni> Spida: depends ;)
[09:39:27] <Spida> on what?
[09:39:33] <alex_joni> on what I need to do
[09:39:48] <alex_joni> if it's only CAD work, or I need CAM afterwards, etc
[09:39:52] <alex_joni> 2D, 3D
[09:39:53] <alex_joni> etc
[09:40:10] <alex_joni> at work I use Alibre for 3D (CAD and very seldom CAM)
[09:40:21] <alex_joni> for 2D I use various freewares + sheetcam as CAM
[09:43:30] <Spida> Alibre is payware, isn
[09:43:32] <Spida> t it?
[09:53:54] <alex_joni> they have a free (limited) version
[09:53:58] <alex_joni> but I have the pay version
[10:31:27] <Spida> alex_joni: is there a description of the free version somewhere? I just found that its like the professional for the first 30days, and then downgrades to some unspecified xpress version...
[10:32:42] <alex_joni> there was, but they changed the website lately, so I'm not sure
[10:34:59] <Spida> is gcam (
http://gcam.js.cx/index.php/Main_Page) known/usable?
[10:38:55] <archivist> the writer was a dev on brlcad for a while
[11:00:48] <anonimasu> Spida: it limits the assembly size..
[11:01:02] <Spida> to what?
[11:01:48] <anonimasu> five unique parts
[11:02:16] <anonimasu> and no 2d drawings
[11:02:22] <anonimasu> and no boolean operations..
[11:02:30] <anonimasu> adn no lofting/shelling/helix/sweep
[11:02:44] <anonimasu> but well, you can live without thoose..
[11:02:57] <anonimasu> I have the expert version and, they arent the most critical
[11:03:04] <anonimasu> for most stuff
[11:05:16] <Spida> no booleans?
[11:05:41] <anonimasu> yeah
[11:06:17] <anonimasu> no joining of solid parts..
[11:06:26] <anonimasu> or substraction
[11:06:32] <anonimasu> though, if you depend on thoose to make your parts(unless you make mold cavities, then you are a fossil, leftover from a 3d program..
[11:07:36] <Spida> no, certainly no fossil, I just started thinking aboud cad/cam/...
[11:07:55] <anonimasu> :)
[11:08:06] <Spida> I did some electro-cad with eagle, and some parts from the brl-cad tutorial...
[11:08:13] <Spida> but thats it.
[11:08:17] <anonimasu> alibre is very much like solidworks
[11:08:46] <anonimasu> :)
[11:10:41] <Spida> so just to see if I have understood correctly: the workflow would be to design some part in brl-cad, use gcam to get toolpaths, and execute it with emc on some hardware?
[11:12:53] <anonimasu> yeah
[11:16:10] <anonimasu> brl-cad seem insanely hard to learn
[11:18:43] <Spida> anonimasu: in what respect? using the command window?
[14:21:10] <skunkworks> cradek:
http://imagebin.ca/img/bJwu5k.png
[14:21:39] <skunkworks> that is when I don't get my line-up pins right ;)
[14:29:08] <skunkworks> I need to get motivated. time to get back to the garage work.
[14:29:44] <archivist> * archivist hands a cup of motivation to skunkworks
[14:30:02] <cradek> haha I think you might have the board rotated a bit...
[14:32:06] <skunkworks> I drilled the line up pins by hand ;)
[14:32:38] <skunkworks> I am almost done with my first cup of motivation
[14:32:50] <skunkworks> I think it may take 2.5 or more
[14:33:45] <cradek> I need some of that too
[14:34:00] <archivist> and me
[14:34:01] <cradek> I still haven't fixed rotated non-xy arc previews
[14:34:53] <anonimasu> Spida: in respect to being clunky like they are still back where cad programs were maybe 10 years ago..
[14:35:05] <skunkworks> It took me a second to figure out the specifics.. I thought it was a new gcode - not an extention of g10. (the systems.ngc didn't have the coordinate systems set)
[14:35:20] <skunkworks> as you can see from mdi ;)
[14:35:57] <cradek> systems.ngc was a learning aid for AXIS's touch off
[14:36:16] <cradek> but there is no rotation equivalent (how should it work?)
[14:36:40] <skunkworks> ah - I just reconized if from your computer at the fest :)
[14:38:45] <skunkworks> hmm - good point. It will work as is.. It is similar on how I set the tool length at first (changing g10) but that causes issues with preview as it doesn't get changed at runtime. (you have to re-load the program)
[14:39:28] <skunkworks> unlike tool length setting like you do in the eagle ulp
[14:40:23] <skunkworks> I don't know if I am making sense this early in the morning
[14:41:55] <JanVanGilsen> Can somebody help me to get the [AXIS_N]HOME and HOME_OFFSET parameters to hal pins?
[14:48:21] <jepler> JanVanGilsen: home and home offset are in nml, so the shortest route to having them in hal pins is probably to add them to halui
[14:48:44] <jmkasunich> JanVanGilsen: are you trying to change those values on the fly?
[14:48:58] <jepler> er, maybe I'm mistaken -- I was looking at class EMC_AXIS_SET_HOMING_PARAMS which is to set them, not to show them
[14:49:23] <cradek> JanVanGilsen: can you back up and say what problem you are trying to solve?
[14:49:35] <jepler> I take it back, I don't think they can be read through stat
[14:50:14] <JanVanGilsen> yes, my puma arm has a potentiometer on each joint giving a aproximation of the absolute position
[14:50:23] <skunkworks> jmkasunich: did your table make it to you?
[14:50:32] <jmkasunich> skunkworks: yes
[14:50:35] <skunkworks> :)
[14:51:20] <jmkasunich> JanVanGilsen: so what are you trying to achieve? you want to use the pot + index to home without actually going all the way to a home switch?
[14:52:00] <JanVanGilsen> there is no home switch :)
[14:52:40] <jmkasunich> is there an index?
[14:52:57] <JanVanGilsen> the aproximate position will be rounded down to get te "real" position of the next index pulse
[14:53:16] <skunkworks> hmm - nice..
[14:53:26] <skunkworks> JanVanGilsen: did you end up replacing the encoders then?
[14:53:37] <JanVanGilsen> no they work fine :)
[14:53:45] <skunkworks> they have an index also?
[14:53:57] <JanVanGilsen> yes
[14:54:10] <skunkworks> huh - I need to look at mine. interesting
[14:54:59] <skunkworks> interesting idea - look at pot - figure out where the arm is and where the next index should be then.
[14:55:03] <JanVanGilsen> if you want, i can copy the pinout of my encoders :)
[14:55:33] <jmkasunich> JanVanGilsen: you are in slightly unexplored territory
[14:55:35] <JanVanGilsen> The goal is to prevent unpredictable moves during the homing process
[14:55:57] <jmkasunich> the "right" way to home your machine would involve changing the actual homing code in EMC, but that isn't simple to do
[14:56:25] <jmkasunich> tweaking the homing parameters so that EMC thinks it is running its normal homing process could work
[14:57:21] <JanVanGilsen> Then i only have to write a hal component that desides where the next index pulse would be
[14:57:51] <skunkworks> are they ttl? - I thought they output a 'sinewave' greycode that would have to be run thru a comparator.
[14:58:41] <skunkworks> (assuming we have similar arms)
[14:59:41] <JanVanGilsen> In my controller, the encoder signals are connected to a shmitt-triger/inverter witch outputs ttl levels
[15:00:01] <skunkworks> ah - ok. We didn't get any of the control.
[15:00:01] <jmkasunich> skunkworks: yours is a Puma, maybe JanVanGilsen has a puma (IOW, puma is a generic description of the arm geometry, not the brand name)
[15:00:28] <JanVanGilsen> My arm is a real Unimation Puma robot :)
[15:00:34] <skunkworks> same here.
[15:00:49] <JanVanGilsen> i'll check build date :)
[15:00:51] <jmkasunich> ok, then probalby you and skunkworks have the same thing (more or less)
[15:01:04] <jmkasunich> JanVanGilsen: I assume you've read
http://www.linuxcnc.org/docview/html//config_ini_homing.html
[15:01:30] <JanVanGilsen> 26 JUN 1985
[15:01:53] <jmkasunich> you basically want to do index only homing, but with HOME_OFFSET (and possibly HOME) set after reading the potientometer. is that correct?
[15:01:58] <JanVanGilsen> Yes i did read it.
[15:02:13] <JanVanGilsen> correct
[15:04:05] <jmkasunich> I wish we had made a giant leap and used HAL params (or pins) for all motion controller config items
[15:06:33] <jmkasunich> since we didn't, I think you will have to write some C or C++ to solve your problem
[15:08:28] <jepler> yes, I think sending a EMC_AXIS_SET_HOMING_PARAMS nml message will modify HOME_OFFSET and HOME
[15:09:01] <jepler> that message isn't exposed in python, so your other choice is C++
[15:09:11] <jepler> or to expose it in python
[15:09:11] <jmkasunich> does that message have a way to modify _only_ those params? or will the sender need to know the existing values of all the other params?
[15:09:13] <JanVanGilsen> could this be done from a Hal component?
[15:09:28] <jmkasunich> JanVanGilsen: it would have to be a user-space hal component
[15:09:46] <jmkasunich> the other approach would be to hack the motion controller to get HOME_OFFSET from a hal pin
[15:11:11] <jmkasunich> I don't know which approach is more perverse
[15:11:13] <JanVanGilsen> skunkworks: My robot came with a giant pile of "electrical and mechanical drawings"
[15:11:40] <skunkworks> wow - you would be able to home it a ton more accurite than it ever did in the original controller. It only used the pot voltage.
[15:12:02] <jmkasunich> it had an index pulse but didn't use it? that seems dumb
[15:12:22] <skunkworks> I got most of the manuals... I will have to see if i have some of the encoder schematics.
[15:12:29] <JanVanGilsen> My countroller does use the index
[15:12:52] <skunkworks> hmm - interesting. either I missed it in my manual - or mine didn't.
[15:13:17] <skunkworks> I would think former. ;)
[15:13:21] <jmkasunich> ok, lets talk about exactly how to do this in EMC2 (I'm a bit pressed for time, I have errands to do)
[15:13:40] <jmkasunich> you want to read the pot (I assume you have some A/D converter, and a hal driver for it)
[15:14:08] <jmkasunich> you want to compute the position of the nearest index pulse from that A/D reading
[15:14:17] <jmkasunich> you want to set that position as HOME_OFFSET
[15:14:38] <jmkasunich> you must either do this constantly except when homing is actually in progress, or you must do it once just as homing starts
[15:16:33] <JanVanGilsen> yes
[15:16:51] <jmkasunich> there is also an ambiguous area - if you happen to be very very close to an index pulse when you start homing, the analog value might tell you the location of the index pulse that you are 0.0001 rev away from, or the one that you are 1.0001 rev away from
[15:17:21] <JanVanGilsen> yes
[15:17:32] <jmkasunich> with regular index homing, you make your home switch (or marks on the table, if doing index-only homing) about 0.5 revs away from the index to avoid that
[15:17:48] <jmkasunich> how do you intend to address the ambiguity problem?
[15:18:52] <JanVanGilsen> if the potentiometer is read when the joint is at the index, this shouldn't be a problem.
[15:19:28] <jmkasunich> so you want to read the pot and generate the HOME_OFFSET value just as the index is reached?
[15:19:39] <jmkasunich> that rules out sending NML messages to set HOME_OFFSET
[15:20:01] <jmkasunich> since NML messages can only be sent from user space (non-realtime) code
[15:20:21] <jmkasunich> if you need to read the pot at a specific instant, it needs to be realtime
[15:21:10] <JanVanGilsen> so a hal pin would be best?
[15:21:26] <jmkasunich> probably
[15:21:32] <jmkasunich> do you know C?
[15:22:16] <skunkworks> couldn't you read the pot while not moving? calculate where the next index pulse should be - set the home offset and then home?
[15:22:24] <JanVanGilsen> Not wel, I understand it a bit :)
[15:22:26] <jmkasunich> skunkworks: no
[15:22:54] <JanVanGilsen> not if you close to the index pulse
[15:22:58] <skunkworks> ah
[15:23:21] <jmkasunich> because of the ambiguity problem, you must either "read just after detecting the index", or "read well before detecting the index", and the latter is impossible if you are already very close
[15:24:15] <jmkasunich> JanVanGilsen:
http://cvs.linuxcnc.org/cvs/emc2/src/emc/motion/homing.c?annotate=1.2
[15:24:40] <jmkasunich> the homing code is a state machine
[15:24:48] <jmkasunich> you can probably follow it by reading the comments
[15:24:57] <jmkasunich> for index only homing, it starts at line 581
[15:26:37] <jmkasunich> you will want to read the pot just as it transitions from HOME_INDEX_SEARCH_WAIT to HOME_SET_INDEX_POSITION
[15:26:41] <jmkasunich> unfortunately that is impossible
[15:27:13] <jmkasunich> since that transition takes place entirely within the motion controller, no other code gets a chance to run between those states
[15:28:30] <jmkasunich> the only solution I see is to have a hal component that is always reading the pot, and always calculating the offset
[15:29:05] <JanVanGilsen> That wouldn't be verry hard..
[15:29:06] <jmkasunich> and to add code to the motion controller right before line 661, that will read a newly added HAL pin to get the home offset
[15:29:51] <jmkasunich> you would also want to read that newly added pin just before line 606
[15:31:02] <JanVanGilsen> I would also need to set the HOME parameter to be the same as home_offset, else the joint will move to home at the end of the homing
[15:31:49] <jmkasunich> that would be at line 690
[15:32:13] <jmkasunich> oh, wait, that won't work
[15:32:45] <jmkasunich> I think the kinematics code will be unhappy if you go randomly changing home
[15:34:18] <jmkasunich> is it important that you not move (much) when homing?
[15:34:53] <jmkasunich> there is some logic in the motion controller, especially for non-trivial kinematics, that requires all joints to be homed or "at home" before you can change to coordinated mode, etc
[15:35:41] <jmkasunich> the logic is complex, and I'm not sure what cases require you to be "at home" vs simply "homed"
[15:36:12] <JanVanGilsen> Yes, robots usually have a lot of stuff in their work area, uncontrolled moves like that are dangerous
[15:36:49] <alex_joni> jmkasunich: I think the code requires to be homed
[15:37:04] <alex_joni> for kinematics BOTH you can switch to joint mode, move some joints, then switch back to world
[15:37:14] <alex_joni> (at least it worked at one point that way ;)
[15:37:23] <jmkasunich> alex_joni I think it depends on whether you have kins BOTH or INVERSE_ONLY
[15:37:38] <jmkasunich> and I don't know which one pumakins has
[15:37:47] <alex_joni> it has both iirc
[15:37:49] <jmkasunich> and too lazy/rushed to look
[15:37:57] <jmkasunich> ok, that might make things better
[15:38:17] <alex_joni> but whoever needs to use it will probably have to work it out ;)
[15:38:23] <jmkasunich> but I'd still be worried about changing joint->home on the fly, without fully understanding the implications
[15:39:15] <jmkasunich> one way to avoid the final move would simply be to skip it
[15:39:58] <jmkasunich> change line 667 so it doesn't switch to state HOM_FINAL_MOVE_START, instead goes direct to HOME_FINISHED
[15:40:27] <jmkasunich> and also change HOME_FINISHED - line 736 needs to say AT_HOME_FLAG(joint,0) since you aren't neccessarily at the home position
[15:42:46] <JanVanGilsen> If I'm not going to write something that is going to be committed, i could just replace joint->home with joint->home_offset
[15:43:14] <jmkasunich> you mean at line 690?
[15:43:42] <jmkasunich> that would work, but you'll still need to change line 736, since you won't be AT_HOME when you finish
[15:44:49] <JanVanGilsen> true
[15:45:21] <jmkasunich> anyway, those are details - it sounds like you are managing to understand the homing code, is that correct?
[15:45:47] <jmkasunich> the other changes you'll need to make are to create a new pin (or pins), I can try to show you where that stuff is
[15:45:57] <jmkasunich> then I have to go away for a while
[15:45:58] <JanVanGilsen> Yes but not how i need to get the hal pin into it
[15:46:23] <JanVanGilsen> thx
[15:47:26] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/motion/mot_priv.h?annotate=1.78
[15:47:40] <jmkasunich> this file is where hal pin/params are declared
[15:47:49] <JanVanGilsen> i think it would be best to make something that could be comitted...
[15:48:10] <jmkasunich> that will be much more complex - what works for you will break other people's machines
[15:48:25] <jmkasunich> something that works for you _and_ for other people is a lot harder to figure out
[15:48:38] <jmkasunich> and I certainly can't spend that much time today
[15:48:57] <jmkasunich> lets focus on "how to add a new hal pin to the motion controller" right now, OK?
[15:50:09] <jmkasunich> are you looking at
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/motion/mot_priv.h?annotate=1.78 >?
[15:50:32] <jmkasunich> the structure starting at line 34 has all pins (and params) associated with a single joint
[15:51:30] <jmkasunich> around line 75, you'd add "hal_float_t *home_offset; /* WPI */"
[15:51:39] <JanVanGilsen> Yes, that's clear
[15:51:50] <jmkasunich> that gives you a memory location for the pin, but doesn't make it visible in hal
[15:52:16] <jmkasunich> next file:
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/motion/motion.c?annotate=1.126
[15:52:57] <jmkasunich> the block from line 676 thru line 680 exports the jog-scale pin
[15:53:03] <jmkasunich> you'd want to duplicate that for your new pin
[15:53:22] <jmkasunich> changing the name in line 676, and the variable name in line 677
[15:53:36] <jmkasunich> that exports the pin to HAL
[15:55:55] <jmkasunich> JanVanGilsen: follow so far?
[15:56:01] <JanVanGilsen> yes
[15:56:25] <jmkasunich> I'm trying to figure the best way to read the pin
[15:56:34] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/motion/control.c?annotate=1.153
[15:56:53] <jmkasunich> most joint-related hal pins are read starting at line 492 in that file
[15:57:57] <jmkasunich> but if you do it there, joint->home_offset will continue to change as the machine runs after homing
[15:58:05] <jmkasunich> I'm pretty sure you don't want that
[15:59:28] <jmkasunich> the actual read from HAL to the joint structure will look something like line 503 or 504
[15:59:56] <jmkasunich> you'll probably want to do that in the actual homing code, as we discussed earlier (homing.c)
[15:59:58] <JanVanGilsen> i don't think thats a problem, the offset should be changed if i home the joint a second time...
[16:00:29] <jmkasunich> yes, if you home a second time
[16:00:41] <jmkasunich> but not every time you move the arm one motor revolution
[16:01:04] <jmkasunich> process_inputs() runs every servo period
[16:02:05] <JanVanGilsen> so i'll need to acces &(emcmot_hal_data->joint[joint_num]) in the homing.c
[16:02:32] <jmkasunich> yes
[16:03:01] <jmkasunich> I would copy line 367 of control.c into homing.c
[16:03:30] <jmkasunich> then copy line 495 of control.c into homing.c
[16:03:52] <jmkasunich> then you can use joint->home_offset = *(joint_data->home_offset); at line 661 of homing.c
[16:04:44] <jmkasunich> I have to go now - it sounds like you have a good idea of what to do. I will be back later, or someone else can help if you run into problems
[16:04:46] <JanVanGilsen> ok, that seems to cover it all :)
[16:05:12] <JanVanGilsen> Thank you verry much =)
[16:05:28] <jmkasunich> maybe we should think about making all those things into HAL pins for version 2.4....
[16:07:10] <tlab> this onboard video card requires xorg-server 1.6 or greater, and it's saying I have 1.4.0.90, how hard is this going to be to upgrade?
[16:54:01] <tlab> any of you use jaunty and emc?
[16:54:39] <alex_joni> nope ;)
[16:57:48] <bglackin> http://www.doughtydrive.com/machine%20demo.html
[16:57:57] <bglackin> nice little 5 axisa
[17:04:27] <bglackin> Kirk - Some video with 0 backlash A and B/C axes. NOt allot of info on how he does it (except for the order form...
[17:04:32] <bglackin> http://www.doughtydrive.com/download.html
[17:17:57] <tlab> this onboard intel video card sucks
[17:24:23] <kirk_wallace> Hello, I have been playing with IRC "/" commands, I hope I didn't cause any trouble.
[17:26:08] <notranc> Hi Kirk, no problem, you just rebooted my system
[17:26:41] <kirk_wallace> (leg pulled?)
[17:26:53] <notranc> :-)
[17:26:55] <archivist> right off
[17:27:28] <kirk_wallace> Any IRC short cuts that would be handy?
[17:28:19] <notranc> what do you use to talk IRC? I use Konversation and don't see a need for playing with commands much
[17:29:14] <archivist> I use xchat and its up 24/7
[17:29:40] <kirk_wallace> I found "/help", but it didn't reveal much. I use Mibbit.com.
[17:30:07] <archivist> proxy services are not so good
[17:30:28] <archivist> and liable to get banned to to bad users
[17:30:34] <notranc> tried man irc?
[17:30:36] <archivist> due to
[17:31:19] <kirk_wallace> I'll check Konversation, xchat
[17:32:44] <Spida> kirk_wallace: try irssi, if you like terminals
[17:32:51] <notranc> I use KDE all the time and that's why I use Konversation. Allows for diff identities for different channels, I like this feature
[17:33:47] <kirk_wallace> I did notice a tip saying "don't type in / commands that other people tell you to enter, unless you know what the command does.
[17:35:46] <notranc> that's always a god advice. OR you could be advised to "rm -rf /etc" as root but that's for other less advanced channels
[17:36:51] <kirk_wallace> Sometimes the conversation can go pretty quickly, so I thought there may be some short cuts. I guess there is no real magic involved.
[17:37:20] <kirk_wallace> notranc: So you can get to someone's shell through IRC?
[17:38:01] <notranc> well, I was joking but just like any other streaming connection to the net makes it possible for security issues
[17:39:09] <archivist> getting into someones shell would be a very bad security problem,
[17:39:09] <kirk_wallace> Oops, not thinking, you have to advise the person to open a terminal, dooh. The / commands can do damage though?
[17:39:38] <notranc> you can exchange files between the users and that makes it possible to bring in virus. We are talking about Windows mostly. However, if one were to download a shell script that would change /bin/passwd for example, you can imagine what that could do to your system
[17:40:00] <kirk_wallace> Yes.
[17:41:25] <kirk_wallace> I looked at the Dourty drive videos. My guess is that they are a two set belt drive. Fine for routers, but I don't know about a mill.
[17:42:11] <archivist> yup ok for wood and plastic
[17:42:21] <notranc> that site needs some work or it's designed for NotFirefox browser. I could not see all things properly.
[17:42:48] <notranc> he has a link to
http://www.cnc-toolkit.com which has more interesting stuff
[17:44:07] <kirk_wallace> What should I know about IRC Topic?
[17:44:43] <archivist> it what way?
[17:44:46] <archivist> in
[17:45:58] <kirk_wallace> I see it mentioned, but I don't know how it would affect anything I do.
[17:46:51] <archivist> topic is for new users to a chan
[17:47:09] <archivist> some chans point to rules
[17:47:38] <kirk_wallace> Oh so it could be like a README.
[17:48:01] <notranc> this is EMC channel so I expect related stuff. Off topic sometimes boring away. I've seen some very funny links from people on this chan.
[17:48:50] <notranc> s/Off topic sometimes boring away/Off topic sometimes takes boring away/g
[17:49:00] <archivist> some chans we have to control off topic
[17:49:30] <kirk_wallace> Is this the topic - "Welcome! EMC (Enhanced Machine Controller) is a linux-based ope... "
[17:50:08] <notranc> I believe so Kirk
[17:52:05] <kirk_wallace> Well, I've had my coffee, now I have a tool changer to fix. Thanks for the info. Ciao.
[17:55:44] <notranc> anybody at or going to
http://makerfaire.com/? There were CNC and laser machines last year. I expect the same this year.
[17:56:01] <tlab> where is it?
[17:56:12] <notranc> San Mateo CA
[17:56:21] <tlab> lol not me
[17:56:51] <archivist> whos paying my air fare?
[17:57:19] <notranc> Ask for stimulus package
[17:57:58] <tlab> I'm in IN, that's to far
[17:58:35] <notranc> There is a chain of Maker Faire so you might find one closer to your home.
[17:58:48] <archivist> heh Im in the UK
[17:59:46] <notranc> archivist, hop on Virgin and you'll make it for tomorrow?
[18:00:03] <tlab> I'm poor and unemployed atm anyway
[18:00:38] <archivist> I would rather spend the moneys on hardware over here, Im nearly unemployed
[18:01:03] <notranc> maker faire is very interesting place where you might get ideas for getting out of poverty in case the Prez won't do it for you
[18:01:18] <notranc> I'm unemployed too.
[18:01:28] <tlab> I'm going to school, that will get me a job hopefully
[18:01:51] <notranc> tlab, that's good. Need to learn all your life.
[18:02:07] <tlab> ya
[18:02:11] <tlab> I enjoy it
[18:03:16] <notranc> that's the idea.
[18:03:19] <tlab> 1.5 years left and I'll have my BS degree
[18:03:31] <tlab> in Electrical Computer Engineering Technology
[18:04:12] <archivist> boss is selling the site here. so I become unemployed but can take a few toys home
http://www.archivist.info/cnc/works2008/
[18:04:20] <notranc> that's very good.
[18:04:34] <roh> better than unemployed without tools
[18:05:17] <tlab> ya you could be like me, ten years at chrysler and nothing to show pretty much
[18:05:38] <archivist> only a little, one needs capital to advertise and get work in
[18:06:34] <tlab> my first 4-5 years at chrysler, everything I worked on dated from ww2
[18:06:55] <roh> * roh learned that advertising only gets one the kind of massmarket customers which is pain and no gain. better specialize and be know for what special thing you can do and get jobs via people who know what youre good at.
[18:06:57] <notranc> advertizing is cheap. Websites etc. Just need to find niche and sell it worldwide.
[18:07:17] <archivist> small gears
[18:07:27] <tlab> the out of spec column on parts would be full of numbers
[18:08:41] <archivist> tlab, we have a 1910 ish machine here
[18:09:05] <tlab> probably makes better parts that what we used lol
[18:09:22] <notranc> I noticed that some machines were not up to safety standards :-)
[18:10:04] <notranc> just need to add stepper, safety guards, and EMC and you have a modern CNC machine.
[18:10:23] <archivist> http://www.collection.archivist.info/searchv10.php?srcdata=title&srcprog=searchv10.php&searchv4page=1&errlev=0&searchstr=garvin
[18:10:23] <colin_> saftey gaurds :P
[18:10:43] <archivist> we dont want no safety here
[18:10:46] <colin_> you normally spend half a day removing the saftey crap from commercial machines just to make them usefull
[18:10:47] <tlab> we machined transmission cases for chrysler
[18:11:11] <tlab> I knew a guy that said a case landed at his feet, came from 10-15 feet away
[18:11:46] <tlab> chipped the concrete
[18:12:31] <colin_> i once managed to make a big corea mill throw about 2-300kg of tooling block through the saftey doors
[18:12:31] <colin_> that was fun
[18:12:42] <tlab> imagine a transfer bar pulling 20-30 pallets with cases, stopping at a station after each pull
[18:12:56] <archivist> I had a saw throw parts of my bench many feet away at someone else
[18:13:15] <colin_> lol
[18:13:45] <notranc> you guys are dangerous. I have to put up digital shield.
[18:14:17] <tlab> I came back from break, found 4-5 pallets on the floor at the robot, each pallet is probably 500lbs+
[18:14:17] <colin_> lol thats not that dangerous
[18:14:35] <colin_> trying to start a jet engine with a broom stick and a can of propane in a saudi desert
[18:14:37] <colin_> now thats dangerous
[18:14:45] <tlab> f that
[18:14:51] <notranc> that's beacuse robot protested you did not take him with you for a break
[18:14:58] <tlab> broom stick? no metal stick?
[18:15:09] <geo01005_home> colin_: Any luck with the kinematics?
[18:15:16] <tlab> robot was stopped, transfer kept pushing pallets on the floor
[18:15:39] <colin_> geo01005, iv had a little look at them
[18:15:47] <colin_> im just trying to work on a vismach model
[18:15:55] <colin_> i take it i need one without an A3 offset ?
[18:16:08] <geo01005_home> a robot?
[18:16:18] <geo01005_home> or kinematics for your bigger arm?
[18:16:46] <colin_> either
[18:17:02] <colin_> i was just going to convert existing cad files from the ABB site into vismach objects for speed
[18:17:11] <colin_> but they have A3 offsets
[18:18:05] <geo01005_home> Well the Js-10 dosn't have an A3 offset, so yeah it would need to be changed in vismach.
[18:18:39] <geo01005_home> It looks like the kinematics for the ABB robots are easier than the puma kins.
[18:18:55] <colin_> yeah
[18:19:04] <colin_> the only difference is the offset on the base
[18:19:20] <colin_> its forward of center instead of to the side
[18:20:46] <tlab> would it be stupid to try and install emc on jaunty?
[18:20:57] <geo01005_home> There is no left or right position, every joint in the bot lines on a plane.
[18:21:21] <colin_> yup
[18:21:30] <tlab> yup to me?
[18:21:36] <colin_> no
[18:22:23] <geo01005_home> I also think that I have never seen a ABB bot like that with the "elbow" below the "hand"
[18:22:41] <geo01005_home> so there is only one solution.
[18:23:00] <geo01005_home> rather than 12 or 16 or whatever it is with a puma bot.
[18:24:10] <colin_> yeah
[18:24:10] <tlab> we had several of these bots at chrysler
http://www.nachi-fujikoshi.co.jp/eng/rob/hand/index.html
[18:25:15] <colin_> the arms normally come from above
[18:25:37] <colin_> i think they do different types of bot for shelf mounting ect
[18:27:10] <geo01005_home> Yes, but at leas the robot that you showed the picture of is that way.
[18:27:39] <geo01005_home> And I believe that any of them with a four bar mechanism on the back with be the same way.
[18:30:59] <geo01005_home> Anyhow, good luck with the vismach model.
[18:31:39] <tom3p> JanVanGilsen: the idea you present is like heidenhain's 'distance coded' scales. there's many reference marks along the scale, homing is never more than 2cm motion.
[18:32:12] <tlab> I'm half tempted to try emc on jaunty
[18:34:14] <cheiron> i'm (constantly) trying to setup a slave-master installation (aka remote gui) with emc2-trunk and nml (i am unable to use x window forwarding or vnc because of my hardware)
[18:34:42] <cheiron> i'm not sure how to setup the ini file on the master (gui) side.
[18:35:08] <cheiron> if possible i want to use axis instead of tkemc
[18:35:19] <cheiron> any hints?
[18:35:23] <jmkasunich> tlab: to use EMC (for real, controlling a machine), you need a realtime kernel
[18:35:36] <jmkasunich> we have such kernels already built for dapper and hardy
[18:35:49] <jmkasunich> for jaunty, you get to build it yourself - which is neither easy nor fun
[18:35:57] <tlab> ya, can't I recompile for jaunty with rtai?
[18:36:14] <jmkasunich> you would have to compile a kernel for jaunty, with the rtai patches
[18:36:22] <jmkasunich> _then_ you compile emc for that kernel
[18:36:27] <jmkasunich> recompiling emc is the easy part
[18:36:35] <tlab> I've been recompiling kernels for a week now trying to get everything right, and manually install rtai and emc
[18:36:44] <tlab> I just don't know it it will all work on jaunty
[18:37:20] <jmkasunich> if the rtai kernel works (big if), then EMC should work
[18:37:36] <jmkasunich> but you are on your own when it comes to compiling the rtai kernel
[18:38:44] <tlab> well I don't even have hardware yet, so I guess it wouldn't hurt to try it
[18:38:59] <jmkasunich> whatever floats your boat
[18:39:12] <tlab> ya lol
[18:39:22] <tlab> was just wondering if anyone had done it
[18:39:28] <jmkasunich> personally I'm thrilled that I've never had to compile a rtai kernel (been working on EMC for 5 years now...)
[18:39:59] <tlab> I like to piddle with stuff, it's my downfall
[18:40:32] <colin_> i love the fact emc comes on a live cd
[18:40:50] <colin_> couldnt make it any easier to setup an emc machine
[18:42:04] <tlab> I'm bad about wanting the newest and fastest
[18:42:30] <colin_> is that really important for an emc installation ?
[18:42:40] <tlab> probably not
[18:42:45] <colin_> reliability surley is more important
[18:43:44] <tlab> sometimes newer is more reliable
[18:44:05] <tlab> besides hardy hates my video card
[18:44:24] <colin_> upto you if you want to do it
[18:44:41] <tlab> I can always reinstall everything
[18:44:42] <roh> tlab get a cheap radeon7000 or 9000 without fan (passive cooling)
[18:44:59] <roh> reliable, cheap and supported by good and free drivers.
[18:45:00] <tlab> all I have is 1 pci slot
[18:45:06] <jmkasunich> newest is not best for machine control
[18:45:08] <JanVanGilsen> tom3p: it would be wonderfull if somebody with coding experiance could figure out a way to incorperate such a homing sequence
[18:45:12] <tom3p> a pdf on installing rtai on various ubuntus
http://www.pdf-search-engine.com/guia-kubuntu-pdf.htmll
[18:45:12] <jmkasunich> there is a reason they call it the bleeding edge
[18:45:24] <roh> tlab uh.. slow box? grab a matrox
[18:45:31] <roh> G450 or so
[18:45:35] <tlab> it's a new intel atom 330
[18:45:48] <tlab> dual core, so I had to add that support
[18:46:05] <jmkasunich> tlab: somebody has built an rtai smp kernel for the atom
[18:46:06] <tom3p> JanVanGilsen: jmkasunich outlined the sequence needed, and yes it requires skills that i've not practiced in years ;)
[18:46:22] <tlab> ya, but it doesn't work with the video card worth a crap
[18:46:37] <tlab> I've tried that kernel, running it now.. even modified for it
[18:46:44] <jmkasunich> what video card? you mean the onboard video?
[18:46:52] <jmkasunich> I've run that kernel, it works fine
[18:47:10] <roh> tlab uh.. i see.. so its onboard intel graphics?
[18:47:26] <tlab> ya
[18:47:43] <roh> they are quite ok usually.. but yes.. hardy could be too old
[18:48:11] <jmkasunich> I jumped to a conclusion - I have the intel D945GCLF2 mobo with atom 330, and the hardy + rtai + SMP kernel works fine
[18:48:20] <jmkasunich> maybe tlab has a different mobo with the atom chip
[18:48:27] <tom3p> JanVanGilsen: it requires an encoder with many 'Z' over the trvael, so rotary encoders and distance coded encoders are candidates
[18:48:46] <tlab> jmkasunich: what are your latency tests?
[18:48:58] <tlab> how about glxgears ?
[18:49:06] <jmkasunich> it's been a couple months since I played with it, I think it was about 15uS
[18:49:13] <tlab> thats the same mobo I have
[18:49:26] <tlab> the wiki shows 6-7k
[18:49:38] <jmkasunich> I think the wiki is a bit optimistic
[18:49:50] <tlab> well part of it could be SMI
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?FixingSMIIssues
[18:49:55] <tlab> but I dunno
[18:49:55] <jmkasunich> but 15uS is still pretty good
[18:49:55] <roh> we use 18 usec since 16 were too les
[18:49:56] <roh> s
[18:50:37] <tlab> but SMI off can cause overheating
[18:50:40] <tlab> so unreliable
[18:52:48] <tlab> http://intellinuxgraphics.org/index.html has newer video drivers but require newer version of X
[18:53:21] <JanVanGilsen> I could imagine a cnc with some scale along the axis so the offset should be entered by hand, or an gray-code encoder to get an absolute position
[18:54:48] <JanVanGilsen> some kind of incacurate way to estimate the next encoder position :)
[18:55:51] <jmkasunich> JanVanGilsen: I've thought about that too
[18:56:11] <jmkasunich> would be nice for lathes, where you can't neccessarily go all the way to the headstock (hit chuck) or the other end (hit tailstock)
[19:18:51] <Jymmm> Heh.... micro GPS modules on all joints and use them for positionng =)
[19:22:57] <JanVanGilsen> cubecorners on each joint with a "laser" :)
[19:22:58] <archivist> 100ft accuracy in the vertical plain
[19:24:26] <JanVanGilsen> oh sorry, that would give a relative position
[19:28:06] <Jymmm> archivist: you mean my micro gps?
[19:28:20] <archivist> yes
[19:28:54] <Jymmm> archivist: Actually, there would be ref point on each machine making ht eaccuracy nuts to butts
[19:28:58] <archivist> circle of error on gps is a egg shape
[19:29:32] <Jymmm> archivist: I just can't recall the name if it.
[19:29:56] <Jymmm> archivist: land surveyors use it which gives them accuracy in inches
[19:30:05] <anonimasu> differential gps
[19:30:28] <Jymmm> anonimasu: that souns right. there's a land based thingy
[19:30:39] <archivist> still not good enough
[19:30:48] <Jymmm> lol, f yu say so
[19:30:53] <Jymmm> if you
[19:31:00] <Jymmm> bah I hate this kybd
[19:31:41] <anonimasu> oh, dgps isnt it, there's another system they run in paralell
[19:32:54] <Jymmm> Yeah, Trimble has t
[19:32:57] <Jymmm> it
[19:32:58] <anonimasu> with a radio base station
[19:33:03] <Jymmm> right
[19:34:30] <Jymmm> With RFID chips being abundant, I'd suspect that they could be used for positioning in some aspect
[19:37:01] <JanVanGilsen> Differential GPS?
[19:37:31] <Jymmm> JanVanGilsen: It uses the satellites AND a known land based tranmitter
[19:39:05] <Jymmm> http://en.wikipedia.org/wiki/Differential_GPS
[19:39:43] <JanVanGilsen> I was suggesting that that was the name you where looking for ...
[19:40:12] <Jymmm> But there is another system that allows one to setup their own land based system for position accuracy. Say for a new constructon site, etc.
[19:40:29] <Jymmm> Maybe WAAS
[19:40:41] <Jymmm> I just dont recall.
[19:49:52] <bglackin> WAAS is what Trimble pushes - You set up a radio transmitter over a known point - then rove to 2 additional known points and viola - .5" accuracy
[19:50:31] <bglackin> Topcon uses DGPS - use a cellphone to dial into the nearest transmitter for position correction in your area
[19:50:44] <archivist> horizontal maybe
[19:50:59] <archivist> vertical is still well off
[19:50:59] <bglackin> WAAS needs 6+ satelaittes for accuray - DGPS need >14 for it to get decent accuracy
[19:51:19] <bglackin> On WAAS - +/- 0.5"
[19:51:42] <archivist> the error is not the same h to v
[19:51:43] <bglackin> Used to due surveys on mine sites all the time - it was spot on
[19:53:10] <bglackin> if your known points for setting up the iste are good - your accuracy (assuming satelite availability) is +/- .1' on Z - even better on h
[19:53:26] <bglackin> forgot it was in decimal feet
[19:53:39] <bglackin> iste = site
[19:53:53] <archivist> still barn door for machining
[19:54:06] <anonimasu> I hope the EU makes their own system operable soon
[19:54:23] <anonimasu> like fire up the last 40 sattelites
[19:54:24] <anonimasu> :D
[19:54:25] <bglackin> For fine grading with a bulldozer - its high accuary )
[19:55:03] <anonimasu> err last 25..
[19:55:39] <bglackin> GPS on grading equipment has eliminated a roughing step in heavy construction work - you can go right to finish grade - big cost and time saver
[19:55:53] <Jymmm> One could toss 3 transmitters on a machine (instead of using satellites). I figure if you can get .1" accuracy from something that's 20,000+ feet up, you can do far better when it's only 20 feet away
[19:56:27] <bglackin> Some sites use a laser ceiling
[19:56:46] <bglackin> accuracy is limited to the laser quality and setup
[19:56:54] <bglackin> and distance to laser
[19:57:18] <bglackin> mining for work - router hobby )
[19:57:47] <bglackin> the laser ceiling only provides Z control though
[19:58:43] <Jymmm> That's why I thought of RFID chips to be used in some fashion...
http://www.google.com/search?q=RFID+positioning&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a
[19:58:55] <Jymmm> they are cheap and abundant
[20:41:54] <alSMT> does TOOL_CHANGE_POSITION use G53 or does it use the active offset?
[21:53:49] <alex_joni> acemi: I think G53, but it should be explained in the manual
[21:54:57] <acemi> G53 is nice
[21:58:14] <Jymmm> 38C is nicer
[22:00:05] <alex_joni> we had 35C earlier this week
[22:00:13] <alex_joni> on wednesday to be precise
[22:00:19] <alex_joni> then 15C the next day
[22:03:16] <Jymmm> alex_joni: Breastessesssesss
[22:04:24] <alex_joni> err .. what?
[22:04:27] <alex_joni> ah
[22:06:01] <Jymmm> lol @ alex_joni
[22:06:11] <alex_joni> it's late over here :P
[22:06:31] <Jymmm> alex_joni: I know you recently got married and all, but did you totally forget what those are/were?
[22:06:52] <alex_joni> not _that_ recent ;)
[22:06:57] <alex_joni> 2yr+
[22:07:41] <Jymmm> That long, damn
[22:07:45] <Jymmm> time flies
[22:09:13] <Jymmm> Is anyone aware of a voice recorder that can still continue to record,even while a portion of what has been recorded already is played back?
[22:09:47] <archivist> echo machine
[22:09:59] <archivist> it had a tape loop
[22:11:38] <Jymmm> I'm speaking of something that can be placed n your pocket
[22:11:40] <Jymmm> in
[22:11:44] <archivist> a picture
http://birmingham.gumtree.com/birmingham/57/37942657.html
[22:12:41] <Jymmm> I guess the simplest solution would be to just carry two voice recorders instead.
[22:12:49] <Jymmm> Not ideal though
[22:14:31] <archivist> would be easy enough to do now with memory and A?D and counters to read from a different location
[22:16:09] <Jymmm> I've found most of the personal vice recorders pretty lacking in features.
[22:16:16] <Jymmm> s/vice/voice/
[22:16:28] <Jymmm> Some timestamp, some don't
[22:16:50] <Jymmm> some save as seperate files, others as a continous file
[22:18:03] <Jymmm> The idea is that you could be recording 24hours a day, but have the ability to playback a portion for purposes of review as needed, but still not itterupt the recording process.
[22:18:13] <Jymmm> itterupt
[22:18:21] <Jymmm> bah
[22:19:58] <alex_joni> Jymmm: this looks nice:
http://www.olympusamerica.com/cpg_section/product.asp?product=1369
[22:20:42] <Jymmm> looking...
[22:21:22] <alex_joni> good night all
[22:26:05] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[23:02:01] <bglackin> Jymmm: I has a cheaper Olympus purchased about 1 year ago. Can do 8 hours of continous recording.
[23:02:48] <bglackin> when I stop and start a new recording - its a seperate file. Recording quality was good and the files were accessed by any music type player
[23:03:01] <bglackin> for what it is worth.......
[23:29:07] <maddash> I'm having some trouble with generating a zero-crossing signal that corresponds to a 60Hz AC signal. When the voltage levels get close to 0V, the signal that I generate becomes unstable
[23:30:26] <maddash> btw, the AC signal ranges from +/-3.3V
[23:31:12] <maddash> I'm thinking of adding an external hysteresis circuit, but I need to know: Will adding this extra circuitry cause the comparator that I'm using to "suck" more power from the AC signal?
[23:34:45] <dan1mal> dan1mal is now known as Danimal
[23:35:13] <archivist> depends, technically yes, but if impedances are within reason, you wont notice
[23:50:35] <Danimal> so another n00b question from me...so i got my spindle turning on and off, and now i want to control my vfd. Someone mentioned that i could use a optocoupler driven off my 5i20/7i42 to avoid having to get a DAC. Now, would i use a pwmgen to output a signal to the optocoupler? or would that just be a gpio?
[23:51:56] <Danimal> or neither?
[23:53:12] <archivist> pwmgen so you can vary the speed
[23:53:33] <Danimal> ok thats what i thought, just wanted to be sure
[23:55:16] <Danimal> pwmgen.N.value float in?
[23:55:44] <jmkasunich> man pwmgen
[23:57:59] <Danimal> manual is kinda greek to someone with no background in this stuff
