#emc | Logs for 2005-11-29

Back
[00:01:06] <rayh> right that's why we need to start with an ini read and emc.run
[00:01:14] <SWPadnos_> yep
[00:01:33] <rayh> I suppose an emc2 guru could figure out how to do all that through halcmd.
[00:01:46] <SWPadnos_> I suppose ;)
[00:01:47] <rayh> I get a type mismatch message.
[00:01:53] <SWPadnos_> where?
[00:01:58] <rayh> let me switch machines on irc
[00:02:11] <SWPadnos_> I gues sI could just try loading it myself too ;)
[00:02:53] <rayh-emc2> type mismatch 'ppmc.0.encoder.00.index' <- 'Xindex'
[00:02:56] <anonimasu> hello
[00:03:02] <Jacky^> hi
[00:03:18] <SWPadnos_> hm - that looks like it's trying to go the wrong firection
[00:04:09] <SWPadnos_> oops - I'll have a fixed driver in a few minutes
[00:05:23] <rayh-emc2> k
[00:06:03] <SWPadnos_> I was about to add the spindle stuff, and I noticed that some of the utility functions I want aren't there :(
[00:07:42] <rayh-emc2> utility functions?
[00:08:31] <CIA-5> 03swpadnos * 10emc2/src/hal/drivers/hal_ppmc.c: Fixed type for index pins (was u8, now changed to bit)
[00:08:44] <SWPadnos_> yeah - the spindle output is an 8-bit port on P8
[00:08:59] <SWPadnos_> I wanted to just export the u8, and use external components for scaling
[00:09:03] <SWPadnos_> but there aren't any
[00:09:32] <SWPadnos_> so I'm writing a conversions.c, similar to blocks.c, but with type conversions and scaling stuff
[00:09:50] <SWPadnos_> I need to talk to jmk first, just to be sure my plan fits with his
[00:12:18] <rayh-emc2> I see. Thanks for the fix. I'll up and test again.
[00:12:24] <SWPadnos_> sure
[00:15:07] <SWPadnos_> ok - I see that the estop stuff isn't connected correctly
[00:16:09] <rayh-emc2> It runs and I can see the ppmc pins with show.
[00:16:29] <SWPadnos_> yeah - but turning the machine on doesn't do anything with SSR8
[00:16:36] <SWPadnos_> which it should, IMO :)
[00:17:18] <rayh-emc2> Right.
[00:17:36] <rayh-emc2> If this was a traditional stepper setup, ie no encoder feedback
[00:17:53] <rayh-emc2> we would loopback the stepgen to the encoder?
[00:18:33] <SWPadnos_> ok - I just haven't attached any motion-related pins / signals
[00:18:51] <SWPadnos_> motion.0.enable isn't connected to anything
[00:19:08] <rayh-emc2> I was admiring the easy ability to run steppers with encoder feedback.
[00:19:51] <SWPadnos_> actually, with the USC, you just flip dipswtiches 1-4, and the encoder feeback will count step pulses
[00:20:25] <rayh-emc2> Okay. could it be done the other way as well?
[00:20:42] <SWPadnos_> should be - you don't need to use the encoder inputs for positioning
[00:20:49] <SWPadnos_> you could attach an MPG to one
[00:20:55] <SWPadnos_> or a spindle speed encoder
[00:21:39] <rayh-emc2> If you set the dip switches for feedback then you could use the feedback for something else?
[00:21:52] <SWPadnos_> no - the switches change what the encoder counts
[00:22:01] <SWPadnos_> encoder inputs count, I should say
[00:22:14] <SWPadnos_> with the switches set for counting step outputs, the encoder inputs are dead
[00:22:40] <rayh-emc2> okay. I think I see
[00:23:00] <SWPadnos_> hmmm - actually, software loopback as you described may not work so well
[00:23:17] <SWPadnos_> there would be round-off errors
[00:23:53] <rayh-emc2> oops. Wouldn't that also affect real encoder feedback.
[00:24:27] <SWPadnos_> well - yes. it means that the encoder feedback can't be decoupled from axis output for any axis that's in use
[00:24:54] <SWPadnos_> so you could use encoder input 4 as a spindle speed input, as long as you're only using 3 axes of step output
[00:25:06] <SWPadnos_> the count mode is set indivicdually by the dipswitches
[00:25:20] <SWPadnos_> (separate switch for each channel)
[00:32:56] <SWPadnos_> ok - so you need some portions of core-servo in there as well, like the PID setups
[00:35:14] <rayh-emc2> Is it possible to use all of core-servo
[00:35:27] <SWPadnos_> it looks as though it is
[00:35:52] <SWPadnos_> I just had it load core_servo, then ppmc_io, and saw no erros
[00:36:06] <rayh-emc2> Then I can just start core_servo from the ini file before I start ppmc_io
[00:36:22] <rayh-emc2> Got it and it works fine.
[00:36:26] <SWPadnos_> I did uncomment and fix the line in ppmc_io that actually loads the module
[00:36:27] <SWPadnos_> cool
[00:36:51] <rayh-emc2> I saw that stg was still there.
[00:36:59] <rayh-emc2> and in the top comments.
[00:36:59] <SWPadnos_> yep - my bad ;)
[00:37:21] <SWPadnos_> I'll correct that when I commit the changes I'm about to describe
[00:37:47] <rayh-emc2> k
[00:37:55] <rayh-emc2> I'll watch
[00:38:19] <SWPadnos_> you need to make a couple of other links - the [XYZ]pos-fb signals should be connected to ppmc.-.encoder.0[012].position
[00:40:27] <SWPadnos_> also, scaling parameters for the feedback channels need to be there
[00:44:42] <SWPadnos_> do you know if setting HAL stuff from the ini file is still working?
[00:45:08] <rayh-emc2> Should be.
[00:45:28] <SWPadnos_> 'bin/halcmd setp ppmc.0.encoder.00.scale [AXIS_0]INPUT_SCALE' didn't work for me
[00:45:58] <SWPadnos_> calims that inifind is deprecated, and tells me that the ini file variable wasn't found
[00:46:01] <SWPadnos_> claims
[00:47:37] <SWPadnos_> it is cool to watch the AXIS plot follow as I crank the motor around by hand ;)
[00:48:11] <cradek> it's the most complex DRO in the world?
[00:48:44] <rayh-emc2> The inifind dep report is something that paul_c a bit ago for BDI
[00:48:47] <SWPadnos_> it is when I'm looking at it on a dual Opteron with 4G RAM, dual 1920x1200 LCDs, and sing remote X over a 100mbut ethernet link ;)
[00:49:09] <rayh-emc2> I shows up on a BDI start but does not stop the reading of ini variables.
[00:49:29] <SWPadnos_> nope, but I still get the error message about "ini parameter not found"
[00:49:57] <SWPadnos_> I did this from a different terminal than I ran emc from - maybe there's an environment var
[00:51:17] <rayh-emc2> I see that petev coded by hand in m5i20_motion.hal
[00:52:17] <SWPadnos_> Hi John
[00:52:30] <rayh-emc2> setp scale.0.gain [SPINDLE]HIGH_GEAR_RATIO
[00:52:41] <jmkasunich> hi
[00:52:43] <rayh-emc2> I what Jmk used in mazak
[00:52:51] <rayh-emc2> Hi john
[00:53:07] <jmkasunich> doin' spindle stuff?
[00:53:09] <SWPadnos_> yeah - I'm thinking there's some environment thing that is there in the emc.run context, but not in other terminals
[00:53:23] <SWPadnos_> yep - got a couple of questions though
[00:53:28] <jmkasunich> shoot
[00:53:29] <rayh-emc2> setp motenc.3.enc-00-scale [AXIS_0]INPUT_SCALE
[00:53:32] <SWPadnos_> right now, we're working out core ppmc hal files
[00:53:57] <jmkasunich> ok (just looking at commit msgs now)
[00:54:10] <SWPadnos_> actually - is there an environment var or something that tells halcmd where to get ini file variables from?
[00:54:28] <jmkasunich> uhhhh
[00:54:31] <SWPadnos_> I tried to use halcmd in "interactive" mode, and it can't find the ini vars
[00:54:42] <SWPadnos_> 'bin/halcmd setp ppmc.0.encoder.00.scale [AXIS_0]INPUT_SCALE' didn't work for me
[00:54:46] <jmkasunich> I think you have to pass it the name of the ini on the cmd line
[00:55:06] <SWPadnos_> ok - I'll add the commands to ppmc_motion.hal, then commit that
[00:55:19] <jmkasunich> -i <inifile>
[00:55:37] <jmkasunich> bin/halcmd with no args tells you that ;-)
[00:55:46] <SWPadnos_> so it does ;)
[00:55:55] <SWPadnos_> doesn't matter, since I need the inverse of the value anyway
[00:56:02] <SWPadnos_> reciprocal, that is
[00:56:10] <jmkasunich> you do?
[00:56:14] <jmkasunich> what are you doing?
[00:56:31] <SWPadnos_> yep - position = counts / (counts/unit)
[00:56:33] <jmkasunich> (because we changed the original definition of encoder scaling to deal with just that situation)
[00:56:46] <SWPadnos_> oh - well I didn't ;)
[00:56:52] <jmkasunich> ah...
[00:57:04] <jmkasunich> an encoder block should take a scale number that is counts/unit
[00:57:15] <SWPadnos_> ok - then invert internally
[00:57:15] <jmkasunich> so it divides, not multiplies internally
[00:57:25] <SWPadnos_> ok - I can do that as well
[00:57:35] <jmkasunich> that way you don't have scale numbers like 0.0000013325223135534123
[00:58:13] <SWPadnos_> you mean like 0.03937007874016?
[00:58:13] <jmkasunich> my initial encoder component did that, I soon saw the error of my ways
[00:58:29] <jmkasunich> yeah
[01:00:41] <jmkasunich> sometimes I'd like to be able to do expressions in halcmd
[01:00:48] <SWPadnos_> yes!
[01:00:55] <jmkasunich> 1/<some-ini-var>
[01:01:03] <jmkasunich> or <some-ini-var>*1.05
[01:01:04] <SWPadnos_> both mathematical and regexp
[01:01:18] <jmkasunich> regexp?
[01:01:34] <jmkasunich> I was thinking of math, to generate values for setp and sets commands
[01:01:36] <SWPadnos_> regular expressions, like halcmd show pin *motion*0[012]*
[01:01:45] <jmkasunich> regexp would be for filtering lists?
[01:01:48] <jmkasunich> ok
[01:01:51] <SWPadnos_> in a big way
[01:02:08] <SWPadnos_> different application, of course, but still expressions
[01:02:10] <jmkasunich> both of those seem like a lot of re-inventing though
[01:02:17] <SWPadnos_> no - use the regexp library
[01:02:31] <SWPadnos_> you can use bc (the command-line calculator) to do calculations
[01:02:59] <jmkasunich> how would halcmd invoke it? fork or something?
[01:03:00] <SWPadnos_> there's an arbitrary-precision math library as well - I don't remember the name
[01:03:10] <SWPadnos_> that's possible
[01:03:24] <jmkasunich> it isn't the mathematical evaluation that is tricky, it's parsing expressions
[01:03:29] <jmkasunich> we don't need arb precision
[01:03:49] <SWPadnos_> bc does the expression stuff as well, though not ini var replacement
[01:03:56] <jmkasunich> but we might need to parse [FOO]BAR*10.0+[BAX]BLAT
[01:04:23] <jmkasunich> or even sqrt(2)*[FOO]BAR
[01:04:26] <SWPadnos_> I'm sure there's an expression library around. if there isn't, I'll find the source to my old expression plotter
[01:04:40] <jmkasunich> btw, halcmd also excepts env vars
[01:04:45] <SWPadnos_> cool
[01:04:50] <jmkasunich> $name = env var
[01:04:57] <jmkasunich> [sect]name = ini var
[01:05:01] <SWPadnos_> nice
[01:05:10] <jmkasunich> anything else is expected to be a valid constant
[01:05:58] <jmkasunich> would be nice to be able to refer to hal stuff too
[01:06:09] <SWPadnos_> actually - bc also supports named variables, so it may be possible to do a piped version of bc for any calculation needs
[01:06:13] <jmkasunich> use the existing value of a param (or pin) in an expression
[01:08:36] <SWPadnos_> http://lists.boost.org/Archives/boost/2001/08/16088.php
[01:08:51] <SWPadnos_> just search for "infix expression parser" or the like
[01:09:24] <jmkasunich> and get a thousand hits?
[01:09:38] <SWPadnos_> 77400, actually
[01:09:42] <jmkasunich> heh
[01:09:55] <SWPadnos_> funny - one [ackage is called LARD
[01:09:57] <cradek> you could include SIOD
[01:10:28] <jmkasunich> nice thing about bc is that it is pretty ubiquitous.... I hate dependencies
[01:10:29] <SWPadnos_> scheme = bad
[01:10:58] <SWPadnos_> (since nobody here knows it)
[01:11:03] <SWPadnos_> (or almost nobody)
[01:11:15] <jmkasunich> any expressions should look "normal" to users
[01:11:24] <jmkasunich> sorry, no RPN
[01:11:29] <SWPadnos_> that's why you use "infix" in your searches
[01:11:30] <jmkasunich> ;-)
[01:11:37] <cradek> SWPadnos_: IMO halcmd should not parse regexps. What's wrong with using grep?
[01:11:43] <SWPadnos_> RPM is "postfix"
[01:11:55] <SWPadnos_> grep doesn't work in an interactive halcmd "shell"
[01:12:19] <cradek> oh
[01:12:26] <jmkasunich> and with grep, you have to be clever if you want the regexp to apply only to the name, not to the entire line
[01:12:27] <SWPadnos_> also, if used externally, it can't tell where the text is, without using more advanced regexps
[01:12:39] <jmkasunich> (although I regularly use halcmd show | grep myself)
[01:12:43] <cradek> I fear this kind of bloat guys
[01:13:02] <SWPadnos_> there should be two halcmds soon (hold off a sec, jmk)
[01:13:12] <SWPadnos_> one should be the library or bindings
[01:13:13] <jmkasunich> ;-)
[01:13:19] <SWPadnos_> the other the actual shell
[01:13:33] <SWPadnos_> the library will interface to any old program you cant to throw at it
[01:13:54] <SWPadnos_> and the shell will be as bloated as necessary to make it user-friendly, since that's what shells are for - users
[01:14:06] <SWPadnos_> the library, of course, being as lean as possible
[01:14:11] <SWPadnos_> (ok jmk - go ahead ;) )
[01:14:17] <cradek> will you use readline while you're at it?
[01:14:21] <jmkasunich> halcmd was originally concieved as a thin wrapper over the HAL API
[01:14:22] <SWPadnos_> I would in the shell
[01:14:40] <jmkasunich> maybe we want it to return to those roots, and invent another tool called halsh
[01:14:53] <SWPadnos_> readline, getopt, anything else that makes it "normal" and / or "easy"
[01:15:08] <SWPadnos_> sure - that may make sense
[01:16:14] <jmkasunich> what bugs me about some of these shellish enhancements
[01:16:25] <jmkasunich> it's like we're trying to turn halcmd into bash
[01:16:38] <jmkasunich> might be more efficient to somehow let bash do hal
[01:16:49] <cradek> my thoughts exactly
[01:16:53] <jmkasunich> (efficient in the "not reinventing the wheel" sense)
[01:17:04] <SWPadnos_> or hal-mc :)
[01:17:13] <jmkasunich> so how does one extend bash
[01:17:15] <cradek> then you get stuff like $(($FOOBAR*10)) for free
[01:17:38] <jmkasunich> I get tired of typeing bin/halcmd all the time, I just wanna type setp <name> <value>
[01:17:55] <cradek> alias setp='bin/halcmd setp'
[01:18:08] <jmkasunich> I suppose
[01:18:08] <cradek> PS1='halsh> '
[01:18:09] <SWPadnos_> alias setp='bin/halcmd setp'
[01:18:15] <SWPadnos_> right
[01:19:19] <cradek> we already have inivar
[01:19:31] <jmkasunich> gotta cross check hal commands against bash and general unix commands, look for overlap
[01:20:05] <SWPadnos_> alias lp='bin/halcmd show pin'
[01:20:15] <cradek> you could do some preliminary setup in bash and then source your hal file
[01:20:20] <SWPadnos_> ls would be an issue though ;)
[01:20:52] <jmkasunich> I'd make my aliases match the original hal commands, no lp or ls
[01:21:00] <jmkasunich> just show
[01:21:05] <rayh-emc2> At the mazak, I wrote a small tk script that did a lot of that stuff.
[01:21:16] <rayh-emc2> enter the command and press go
[01:21:38] <jmkasunich> sounds like "halsh" could be a script full of "alias" commands
[01:21:40] <cradek> I think bash sounds like a great fit for something that you want to act like a shell
[01:21:49] <rayh-emc2> I don't quite understand why we need to do that in c
[01:21:49] <jmkasunich> run it, and you have a hal shell
[01:22:04] <cradek> jmkasunich: exactly
[01:22:08] <cradek> rayh-emc2: do what in C?
[01:22:13] <SWPadnos_> jmk - do the ppmc stepgens also need the output scale in steps/user unit?
[01:22:19] <jmkasunich> ray: I know C... when all you have is a hammer (you fill in the rest)
[01:22:35] <jmkasunich> they are that way already
[01:22:46] <jmkasunich> set scale to 1000 (steps/in)
[01:22:46] <Jacky^> night
[01:22:52] <SWPadnos_> ok - I was asking because I'm editing a hal file :)
[01:22:53] <Jacky^> Jacky^ is now known as Jacky^afk
[01:22:53] <jmkasunich> command 1.45, and get 1450 hz
[01:22:59] <rayh-emc2> * rayh-emc2 shuts up about shell scripts
[01:23:22] <rayh-emc2> What about subdirectories in configs?
[01:23:26] <SWPadnos_> rayh-emc2: shell scripts or tk scripts work great when you already have a utility to actually do the work
[01:24:07] <SWPadnos_> also, what about changing directories?
[01:24:10] <rayh-emc2> I thought that is what halcmd was
[01:24:25] <jmkasunich> yes
[01:24:46] <SWPadnos_> it is, btu that's why the tk scripts worked - there was a C program to do the heavy lifting, and a tk program to provide an interface to it
[01:24:49] <jmkasunich> these guys have just convinced me that code for math expressions doesn't need to be in halcmd (I think)
[01:25:01] <cradek> yay
[01:25:06] <jmkasunich> except:
[01:25:07] <cradek> or regexps?
[01:25:18] <jmkasunich> that is harder
[01:25:21] <jmkasunich> but back to math
[01:25:25] <cradek> sorry
[01:25:45] <jmkasunich> if I want to set a param to 90% of an env var, bash can do that (using bc if needed)
[01:25:57] <cradek> very true
[01:26:01] <jmkasunich> but if I want to set a param to 90% of an ini var, it gets messier
[01:26:24] <cradek> that's what inivar is for
[01:26:32] <cradek> we already have that ability
[01:26:39] <jmkasunich> you can do `inifile -ini <file> -sect <section. -var <varname>`, but that just sucks
[01:26:49] <jmkasunich> compared to [sect]var * 0.90
[01:26:51] <SWPadnos_> you could do something silly like read in the entire ini file, and set environment vars to all section.var values
[01:27:00] <cradek> you could wrap it in something nicer
[01:27:03] <SWPadnos_> then it's all section.var
[01:27:09] <SWPadnos_> or $section.var
[01:27:15] <cradek> or as SWP says, parse the whole ini with bash
[01:27:19] <jmkasunich> face it, I wasnt to turn hal into a full blown scripting language
[01:27:27] <jmkasunich> with variables and flow control and the lot ;-)
[01:27:32] <SWPadnos_> yes, but do you want it to be bash scripting language?
[01:27:46] <jmkasunich> dunno, this is all wild speculation
[01:27:51] <SWPadnos_> that'll be great for unix-y people, but not for most integrators
[01:27:53] <SWPadnos_> yep
[01:28:09] <jmkasunich> I sat down to begin writing the PWM section of the ppmc driver
[01:29:04] <jmkasunich> "'bc `inifile -ini <file> -sect <section. -var <varname>` 8 0.90 " isn't exactly "normal people friendly" either
[01:29:30] <jmkasunich> oops
[01:29:34] <SWPadnos_> oh no - it sucks also
[01:29:42] <jmkasunich> "bc `inifile -ini <file> -sect <section> -var <varname>` * 0.90 "
[01:29:56] <jmkasunich> [sect]var * 0.90 is much nicer
[01:30:04] <SWPadnos_> or sect.var * 0.90
[01:30:20] <jmkasunich> I used [] to say "get this from ini file"
[01:30:44] <jmkasunich> foo.bar would mean "get this from HAL param foo.bar"
[01:30:56] <SWPadnos_> either way - the [] is usually used to denote array subsets though, and that could be useful
[01:31:14] <SWPadnos_> (I'm not sure how yet, but it could be)
[01:31:19] <jmkasunich> they could coexist
[01:31:35] <jmkasunich> a string starting with [ is a ini reference
[01:31:47] <jmkasunich> a string followed by [ is an array member
[01:31:48] <SWPadnos_> it makes the parser somewhat more complex
[01:31:58] <SWPadnos_> actually, sect[var] would fit nicely
[01:32:11] <SWPadnos_> since the var is essentially an array element in the section
[01:32:16] <jmkasunich> true
[01:32:37] <cradek> with bash you would have the easiest time with $SECTION_VAR or $SECTION.VAR
[01:32:40] <SWPadnos_> for expressions, ini(sect,var) would also be fine
[01:32:41] <jmkasunich> the [sect]var is because the syntax of the inifile puts the section name in []
[01:32:49] <cradek> square brackets are special
[01:32:56] <SWPadnos_> yes
[01:33:27] <jmkasunich> I kinda like ini(sect,var)
[01:33:54] <jmkasunich> oh, this reminds me...
[01:34:13] <jmkasunich> betcha didn't know the other acceptable format for setp commands ;-)
[01:34:32] <jmkasunich> bin/halcmd ppmc.0.someparam = value
[01:34:36] <jmkasunich> no setp needed
[01:34:40] <SWPadnos_> man - you're a prick ;)
[01:35:04] <SWPadnos_> (now he tells me)
[01:35:17] <jmkasunich> bin/halcmd help setp
[01:35:22] <jmkasunich> its documented
[01:35:54] <SWPadnos_> actually, it says "don't use = on the command line"
[01:36:10] <jmkasunich> thats because bash might interpret it, depends on the situation
[01:36:15] <SWPadnos_> yep
[01:36:22] <jmkasunich> I figured it would be more usefull in files
[01:36:35] <SWPadnos_> or hte "shell"
[01:36:36] <SWPadnos_> the
[01:37:01] <jmkasunich> do bin/halcmd help linksp
[01:37:23] <SWPadnos_> well - only if RT is started ;)
[01:37:36] <jmkasunich> yeah, that is an annoyance
[01:38:15] <SWPadnos_> incidentally, there is a way around that
[01:38:18] <jmkasunich> is shmem management was better, I'd be tempted to put realtime start in my etc/initrd tree
[01:38:26] <jmkasunich> s/is/if/
[01:38:48] <cradek> new navigation changes in AXIS - get your cvs snapshot hot off the presses
[01:39:09] <SWPadnos_> oooh - I will.
[01:39:15] <cradek> man do we need testers
[01:39:19] <jmkasunich> me lobbies cradek to put axis in emc2 cvs
[01:39:27] <cradek> we're getting close to wanting to do a major release
[01:39:28] <jmkasunich> so I only have to do one cvs up and make
[01:39:31] <SWPadnos_> is there a tarball, or do I need cvs access?
[01:39:46] <cradek> http://axis.unpy.net/index.cgi-files/downloads/nightly/axis-latest.tar.bz2
[01:40:09] <SWPadnos_> ok - is that actually the most recent (autogenerated after each cvs commit or something)?
[01:40:12] <cradek> jmkasunich: we may talk about that soon
[01:40:15] <SWPadnos_> or is it from last night?
[01:40:15] <cradek> SWPadnos_: yes
[01:40:19] <SWPadnos_> cool
[01:41:30] <SWPadnos_> ok - that worked! I now get 0.1 inch on my $5000 DRO when I turh the motor shaft one revolution by hand ;)
[01:41:57] <jmkasunich> yay!
[01:42:02] <cradek> SWPadnos_: I think you're missing the point of cnc here...
[01:42:14] <SWPadnos_> what do you mean?
[01:42:19] <SWPadnos_> :)
[01:42:25] <cradek> typically ... the computer controls the machine
[01:42:40] <cradek> not that there's anything wrong with your way of doing it...
[01:42:41] <SWPadnos_> well - I control the computer - I'm just eliminating the middleman
[01:42:42] <jmkasunich> baby steps, first turn it by hand, then turn it by motor, then mill Michealanglo's David
[01:48:04] <CIA-5> 03swpadnos * 10emc2/configs/ (ppmc_motion.hal ppmc_io.hal): Fixed ppmc_io.hal file, added ppmc_motion.hal. These get information from the ini file where possible.
[01:48:56] <CIA-5> 03swpadnos * 10emc2/src/hal/drivers/hal_ppmc.c: Changed encoder scaling to directly use INPUT_SCALE units from ini files.
[01:49:11] <SWPadnos_> ok - rayh-emc2 try cvs up now
[01:49:37] <rayh-emc2> on the way
[01:50:01] <SWPadnos_> you'll need to load core_servo, ppmc_motion, and ppmc_io from the emc.ini file
[01:50:04] <jmkasunich> hi pete
[01:50:05] <rayh-emc2> I got m5i20 running in a subdirectory of configs.
[01:50:09] <petev> hi john
[01:50:32] <SWPadnos_> there's another place where bash would be useful - globbing
[01:51:27] <daveland> anyone online ?
[01:51:34] <cradek> plenty of us
[01:51:50] <daveland> Am I Interupting?
[01:52:08] <SWPadnos_> nope
[01:52:18] <rayh-emc2> Hi Dave long time no hear.
[01:52:27] <daveland> Can I ask a question about compiling emc1
[01:52:33] <cradek> of course
[01:53:30] <daveland> Thanks... I compiled it many years ag... I have the BDI 4.30 install up and I have a few errors when I try to comopile rcslib is rcslib needed still?
[01:53:38] <CIA-5> 03jmkasunich * 10emc2/src/hal/drivers/hal_ppmc.c: cleaned up some unused I/O functions
[01:54:14] <rayh-emc2> The bdi's emc is a mixture of emc and emc2.
[01:54:31] <rayh-emc2> I don't think a plain emc will compile for the 2.6 kernel.
[01:54:55] <jmkasunich> no, emc1 will not compile for kernel 2.6
[01:54:58] <rayh-emc2> there are some deb src's out there somewhere.
[01:55:03] <daveland> OK I kind of got that from the confi warning message on the rcslib... So just ignore rcslib?
[01:55:30] <jmkasunich> you have to ignore emc1 completely if you are running kernel 2.6
[01:55:46] <jmkasunich> there is a BDI-4 specific build that is mostly emc1, that does run on 2.6
[01:55:52] <jmkasunich> but I don't know much about it
[01:56:00] <jmkasunich> it should already be on your BDI disk
[01:56:09] <jmkasunich> why do you want to recompile?
[01:56:17] <daveland> ok.. So is BDI 4.30 on kernel 2.6.12.6-magma a emc1 or emc2 deived tree?
[01:56:17] <jmkasunich> did you need to change something?
[01:56:28] <jmkasunich> mostly emc1 derived
[01:56:34] <jmkasunich> with libnml from emc2
[01:56:39] <jepler> daveland: it is a combination of emc1 and emc2. nobody but paul_c really knows how it is put together
[01:56:41] <jmkasunich> and part of emc2 build system
[01:57:07] <daveland> I am compling a new driver for some custom hardware. quad encoder bd + dacs
[01:57:18] <jepler> several of us have tried but failed to follow these wiki instructions for rebuilding the version of emc that is on bdi 4.30: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?BDI-4_Install
[01:57:42] <jmkasunich> * jmkasunich encourages daveland to try emc2
[01:57:51] <jmkasunich> it is friendlier to custom hardware, IMHO
[01:57:57] <daveland> I tried the wiki as well and itt seems to be incomplete
[01:58:34] <daveland> I am not adverse to rying EMC2 I was just starting to read the docs... I was just familliar with EMC1 from the good old days!!
[01:58:43] <jmkasunich> understood
[01:58:53] <jepler> If you want to use emc1 as the basis for your work, you might be better off using bdi-live rc46.
[01:59:01] <rayh-emc2> IMO the last tag I saw on sf for bdi is 4.27
[01:59:32] <jmkasunich> bdi-4.anything needs 2.6
[01:59:55] <jmkasunich> bdi-4.anything higher than 27 uses magma, which might entail some additional changes
[01:59:57] <jepler> I don't remember the details but I was able to rebuild the version of emc that was on the disc, as well as build the emc1 HEAD of that time, without much trouble. The source for everything was in several "tar" files. I did have to do a hard-drive install, however.
[01:59:57] <cradek> daveland: I agree that you shouldn't put any new work into the bdi4-emc branch. it's dead.
[02:00:38] <jmkasunich> emc1 HEAD still builds on BDI-Live rc 46
[02:00:51] <jmkasunich> and on BDI-TNG and -2.18, if you are so inclined
[02:00:59] <jmkasunich> (sez the compile farm)
[02:01:04] <daveland> I did the hard drive install and loded the sources using apt-get ... but I think they were on the disk already since I did a custom install
[02:02:03] <daveland> I'll look over EMC2 as I don't really want to get left behind when emc1 is dead
[02:02:26] <jmkasunich> if you need help writing a HAL driver for your hardware, just ask
[02:02:44] <jmkasunich> (we're finishing the one for the Pico Systems boards as we speak)
[02:02:52] <daveland> ok.. Thanks. I still have a lot of hardware debugging to do.
[02:02:57] <cradek> daveland: I set up emc2 on my stepper machine last night. It works great.
[02:03:21] <jmkasunich> cradek is generous... there were a few hiccups along the way ;-)
[02:03:32] <jepler> cradek: you should put that on the AXIS blog; the lat word on emc2 was that neither of us runs it, with the implication that support is bad for it.
[02:03:40] <jepler> s/lat/last/
[02:03:58] <daveland> I have a ycm mill that I am retrofitting. servos and encoders.
[02:04:04] <jepler> now I'd better go tidy up the kitchen ...
[02:04:32] <cradek> jepler: I'm on it
[02:05:02] <daveland> I really don't want the 300lb table jumping around with bugs....
[02:06:29] <daveland> anyone used emc2 with dc servos and an stg card or the like
[02:08:54] <rayh-emc2> check out the mazak stuff on the wiki
[02:09:22] <daveland> will do. thanks ray
[02:12:29] <jmkasunich> daveland: stg driver for emc2 is pretty new, don't know if anyones used it on a real machine yet
[02:15:21] <CIA-5> 03swpadnos * 10emc2/src/hal/drivers/hal_ppmc.c: Added checks for near-zero scale to encoder read routine. Changed "near zero" to a define EPSILON.
[02:16:02] <daveland> Ok, Well I have custome hardware, but I was wondering if anyone got EMC2 working with Real Velocity controled servo amps
[02:17:23] <jmkasunich> ha, I thought your encoder code was too short compared to my stepgen code
[02:17:43] <jmkasunich> daveland: yes, definitely
[02:17:55] <jmkasunich> we used a motenc card to run roland's Mazak
[02:18:49] <daveland> ok then it must be somewhat stable for me to try my stuff out on.
[02:22:11] <SWPadnos_> heh
[02:22:35] <SWPadnos_> I changed your 1e-20's to EPSILONs, I hope you don't mind
[02:22:41] <jmkasunich> not at all
[02:22:56] <daveland> well emc2 make is running now.... we will se how it goes
[02:23:15] <SWPadnos_> actually, that may want to be a HAL-global parameter of some sort
[02:23:29] <jmkasunich> toss it in hal.h?
[02:23:48] <jmkasunich> nah, leave it where it is for now
[02:23:48] <SWPadnos_> maybe - I'm thinking it may want to be settable - it is related to step resolution and the like
[02:23:57] <jmkasunich> not true
[02:24:08] <jmkasunich> well, a little true ;-)
[02:24:13] <SWPadnos_> it can be related, and may want to be settable
[02:24:37] <jmkasunich> but epsilon should be so much smaller than a step....
[02:24:49] <SWPadnos_> true
[02:24:56] <jmkasunich> that a few orders of magnitude more or less don't matter
[02:25:12] <SWPadnos_> actually, 1e-20 is pretty small - that should probably be closer to 1e-12
[02:25:37] <jmkasunich> yeah, I was just thinking that floats as opposed to doubles only have 2^24 range
[02:25:37] <SWPadnos_> one or two orders of magnitude over a 32-bit number
[02:26:17] <SWPadnos_> sonce at some point, everything turns into a 10-16 bit number anyway
[02:26:26] <SWPadnos_> since
[02:27:45] <SWPadnos_> the shutdown / cleanup thing has to be figured out sometime
[02:29:34] <jepler> bah. you should be doing everything as 32.32-bit fixed-point numbers. floating-point is for NaNs.
[02:29:53] <SWPadnos_> nanananana! pthbpthbbbpthtb
[02:30:06] <jmkasunich> heh
[02:30:23] <jmkasunich> the shutdown thing...
[02:30:40] <jmkasunich> we chould just write out zeros to the entire bus
[02:30:43] <SWPadnos_> it's funny - I bet that a lot of people don't realize that you still only get ~4 billion possible numbers from a float
[02:30:53] <jmkasunich> only take a couple hundred uS
[02:30:56] <cradek> well I said "EMC2 works great" on the ever-popular AXIS website so you guys are really on the spot now
[02:31:05] <jmkasunich> uh-oh
[02:31:08] <SWPadnos_> oh shite
[02:32:02] <jmkasunich> I think I'll implement the brute force shutdown
[02:32:07] <cradek> soon our thousands of readers will flock to EMC2
[02:32:18] <SWPadnos_> each driver should do its own thing
[02:32:19] <jmkasunich> for ( n = 0 ; n < 256 ; n++ ) write zero
[02:32:21] <jepler> you should also crow that your election to the EMC board of dictators is a mandate to make AXIS the official gui of emc2.
[02:32:28] <jepler> cradek: ^^^
[02:32:46] <jmkasunich> SWP: I'm talking strictly about the ppmc driver
[02:32:58] <rayh-emc2> I don't think most machine users would agree with that.
[02:33:01] <jmkasunich> I don't want the shutdown code to have to figure out what is in each slot
[02:33:03] <cradek> jepler: just wait until I get cvs access .... oh, forget it
[02:33:32] <SWPadnos_> well - maybe register_sd_funct is in order
[02:33:34] <jmkasunich> ray: what comment were you commenting on?
[02:34:12] <rayh-emc2> AXIS the official gui of emc2.
[02:34:15] <cradek> jepler and ray: let's stop any gui pissing contest before it starts please
[02:34:24] <jmkasunich> yes, please
[02:34:30] <SWPadnos_> yeah - me three
[02:34:34] <jmkasunich> I think jepler's comment was in jest
[02:34:38] <SWPadnos_> (though EMCAS is better)
[02:34:41] <SWPadnos_> EMACS
[02:35:12] <jmkasunich> re shutdown: on power up, all SSRs are off, and stepgens are outputing zero freq, PWMs are at zero, and DACs are at zero
[02:35:20] <jmkasunich> during driver load, that is re-inforced
[02:35:30] <jmkasunich> at shutdown, I believe all should be returned to that state
[02:35:41] <jepler> yes, it was a joke
[02:35:45] <cradek> that sounds entirely reasonable to me
[02:35:50] <jepler> heck, who can't snicker at the word "mandate"?
[02:36:06] <SWPadnos_> that makes sense for the PPMC, but only because the SSR8 being off disables everything else
[02:36:25] <jmkasunich> I'm only talking about the ppmc right now
[02:36:31] <SWPadnos_> a parport can't be so easily shut down - that's why I said each driver has to do its own thing
[02:36:35] <SWPadnos_> yes
[02:37:01] <SWPadnos_> the ppmc can just shut off SSR8, but setting everything to 0 shouldn['t be detrimental either
[02:37:35] <daveland> Hey guys I'm sold !!! EMC2 compiled and ran no problems!!! Great job!! now on to the HAL documents!!
[02:37:40] <jmkasunich> remember, the shutdown code doesn't even know what is in each slot without parsing thru the bus struct
[02:37:59] <jmkasunich> so I'm gonna brute force it
[02:38:03] <jepler> daveland: good to hear
[02:38:17] <SWPadnos_> for now, that's good
[02:38:40] <daveland> I gota go now... Too much progress for one night!!! Perhaps I'll stop back in a few days tnx again!!!
[02:38:45] <SWPadnos_> have fun
[02:38:51] <rayh-emc2> see you dave
[02:40:33] <SWPadnos_> heh - if only axis showed the material being cut, looking up from the bottom would be useful ;)
[02:41:05] <cradek> did you get the snapshot with the new navigation?
[02:41:15] <SWPadnos_> yup - just got it and built it
[02:41:19] <cradek> I think it's much better
[02:41:30] <cradek> the old navigation was bad
[02:41:37] <CIA-5> 03jmkasunich * 10emc2/src/hal/drivers/hal_ppmc.c: added code to shut everything off when the driver is unloaded
[02:42:01] <jmkasunich> dammit
[02:42:07] <SWPadnos_> the only thing I find odd (which hasn't changed), is that the mouse wheel seems to operate backwards
[02:42:23] <jmkasunich> I should know better than to commit without a compile check
[02:42:25] <SWPadnos_> I expect an upward scroll to zoom in, but it zooms out
[02:42:29] <SWPadnos_> heh
[02:42:30] <jepler> SWPadnos_: yeah we were just wondering today whether we could fix that without confusing everyone
[02:42:34] <jepler> SWPadnos_: (the mouse wheel)
[02:42:37] <SWPadnos_> yes
[02:42:44] <cradek> I'll fix it
[02:42:47] <cradek> I complain about it too
[02:43:46] <CIA-5> 03jmkasunich * 10emc2/src/hal/drivers/hal_ppmc.c: dammit, should know better than to commit without compiling first
[02:43:47] <SWPadnos_> hmmm - the perspective "pop" is still there.
[02:43:58] <jepler> how can you tell if g-code is offset-independent? I think AXIS could notice that the loaded file doesn't change just because offsets change, which would mean it didn't need to reload when you offset an axis
[02:44:09] <jepler> but I'm not sure how to check whether this is true of a particular file
[02:44:11] <jmkasunich> heh, revision numbers are free, might as well use them
[02:44:37] <cradek> jepler: that way lies madness?
[02:45:35] <jepler> cradek: I'd like to hear back from Chatchai again to know if the reload time is tolerable for him now...
[02:45:53] <cradek> the scroll wheel is fixed
[02:46:00] <rayh-emc2> insmod: error inserting '/home/rayh/emcdevelop/emc2/rtlib/hal_ppmc.ko': -1 File exists
[02:46:00] <rayh-emc2> HAL:6: ERROR: insmod failed, returned 1
[02:46:02] <jepler> cradek: for everyone else, I think it is only a minor annoyance, and I'm pretty sure he was hitting the Tk "delete" problem..
[02:46:04] <cradek> jepler: me too
[02:46:08] <SWPadnos_> hmmm - that commit assumes that the ppmc driver owns everything on the epp bus
[02:46:17] <jmkasunich> ray: means the driver is already loaded
[02:46:33] <jmkasunich> try sudo bin/halcmd unloadrt hal_ppmc (or unloadrt all)
[02:47:09] <rayh-emc2> I'm working from swp's hal file.
[02:47:35] <jmkasunich> does he load it twice? (maybe once in the io config and once in the motion one?)
[02:47:38] <SWPadnos_> did you update the ppmc_io file as well - that needs the loadrt hal_ppmc commented out
[02:48:06] <SWPadnos_> it should be sane in CVS, but if the file was open during the cvs update, it may not have changed
[02:50:13] <jmkasunich> SWP: do you mind if I edit your comment placement
[02:50:25] <jmkasunich> asm style comments at the end of the line need a very wide window
[02:50:26] <SWPadnos_> nope - have at it
[02:50:35] <jmkasunich> I try to keep lines under 80 cols
[02:50:42] <SWPadnos_> (don't like aligned comments, eh? :) )
[02:50:51] <jmkasunich> usually put comments before the C line
[02:50:55] <jmkasunich> in asm I do
[02:50:58] <jmkasunich> asm lines are shorter
[02:51:08] <SWPadnos_> mov r0,#123
[02:51:13] <SWPadnos_> yesh - that;s a bit shorter
[02:51:17] <jmkasunich> natural columns there
[02:51:34] <jmkasunich> or we could use 1 space indents ;-)
[02:51:36] <rayh-emc2> wow -4000 on all axis displays
[02:52:15] <SWPadnos_> hm - what's your input_scale?
[02:53:19] <SWPadnos_> you know - in this case, if the input_scale is < 1, it's probably invalid
[02:55:18] <rayh-emc2> INPUT_SCALE = 4000 0
[02:55:35] <SWPadnos_> did you recompile the ppmc driver?
[03:00:33] <SWPadnos_> I should have committed the change to the driver at the same time as the change to the .hal file, but there was a several minute gap in there
[03:02:01] <rayh-emc2> Yes i did. What we seem to have is an EstopWrite that will not change.
[03:03:26] <rayh-emc2> I'll cvs up again.
[03:03:32] <SWPadnos_> odd - it works here
[03:03:48] <SWPadnos_> hold off a sec- let me make sure that CVS is up to date
[03:04:55] <rayh-emc2> now I've got -0.0003 for each axis display.
[03:05:12] <SWPadnos_> ok - that sounds better - one count off, at 0.00025 per count
[03:05:18] <SWPadnos_> (rounds up to .0003)
[03:05:44] <SWPadnos_> are you using the stepper -> encoder loopback on the board?
[03:05:50] <SWPadnos_> (via dipswitch)
[03:05:53] <rayh-emc2> I do see the gui trying to issue the emc_estop off message and the nml working on it.
[03:05:58] <rayh-emc2> no change in state.
[03:06:15] <SWPadnos_> do you have input 15 grounded?
[03:06:17] <rayh-emc2> Not gotten that far yet.
[03:06:29] <SWPadnos_> you need to - the board won't work without it
[03:06:30] <rayh-emc2> Yes both 14 and 15 are grounded.
[03:06:33] <SWPadnos_> ok
[03:06:39] <rayh-emc2> 14 says true but 15 says false.
[03:06:39] <SWPadnos_> so the green light is on
[03:06:40] <jmkasunich> green light is on
[03:06:44] <jmkasunich> ?
[03:06:53] <rayh-emc2> yep I got the green
[03:07:01] <jmkasunich> commanding out 7 on?
[03:07:06] <jmkasunich> SSR8 led on?
[03:07:17] <SWPadnos_> what's connected to ppmc.0.dout.07.out?
[03:07:43] <rayh-emc2> not yet. I had presumed that swp had connected that. EstopWrite
[03:07:57] <SWPadnos_> it is connected
[03:08:07] <jepler> goodnight everyone
[03:08:12] <jmkasunich> night
[03:08:15] <rayh-emc2> from ppmc to iocontrol yes.
[03:08:16] <SWPadnos_> but to iocontrol.0.user-enable-out
[03:08:39] <SWPadnos_> night jepler
[03:09:34] <SWPadnos_> atr you loading all three hal files from emc.ini? (core_stepper, ppmc_motion, ppmc_io)
[03:09:52] <SWPadnos_> core_servo, I mean
[03:11:22] <rayh-emc2> Yes
[03:11:44] <SWPadnos_> ok - out of curiosity, which GUI are you using?
[03:12:02] <rayh-emc2> The system is alive. I'll break the estop connections and loopback.
[03:12:34] <SWPadnos_> hold on a sec - you're running with some changes Alex made in the last day or two - I'm not
[03:12:36] <jmkasunich> It's ALIVE!!!!
[03:13:23] <jmkasunich> quick Igor, get the electrodes...
[03:13:37] <SWPadnos_> BZZZZZTTTT
[03:13:39] <rayh-emc2> zap -- that did it.
[03:13:48] <SWPadnos_> oog
[03:14:17] <rayh-emc2> I spent a full moon evening at frankenstein's castle.
[03:14:32] <SWPadnos_> I *don't* want to see the photos ;)
[03:14:45] <rayh-emc2> I looked right at home.
[03:15:03] <rayh-emc2> Let me test the estop stuff with step_cl
[03:15:40] <rayh-emc2> Yep it works there.
[03:16:38] <SWPadnos_> Alex made some changes to the way that emcTrajDisable and emcTrajHalt work, then some others, then reverted some
[03:16:45] <SWPadnos_> this was yesterday
[03:17:15] <rayh-emc2> Right I saw that. That is why I tested with step_cl cause I know that it used to work there.
[03:17:16] <SWPadnos_> It probably makes a difference - I was only updating the configs and drivers directories (on purpose)
[03:17:58] <SWPadnos_> that's step_cl.ini / hal / clp?
[03:18:24] <rayh-emc2> # create a signal for the estop loopback
[03:18:25] <rayh-emc2> linkpp iocontrol.0.user-enable-out iocontrol.0.emc-enable-in
[03:18:40] <rayh-emc2> is what we are doing for estop in standard_pinout
[03:19:23] <jmkasunich> SWP: I have a question about the encoders
[03:19:23] <SWPadnos_> OK - and that's connected to ppmc.0.din.15.in in ppmc_io.hal
[03:19:25] <SWPadnos_> ok
[03:19:27] <rayh-emc2> That is the same as the first row in step_cl.clp
[03:19:29] <jmkasunich> ENCCTRL is 03
[03:19:42] <SWPadnos_> yeah - that's the misplaced register I mentioned last night
[03:19:45] <jmkasunich> but jon's webpage says the USC has the encoder control reg at 12
[03:19:50] <jmkasunich> ok
[03:19:58] <jmkasunich> piss-poor docs
[03:20:13] <SWPadnos_> You have the *real* docs - that's why I asked you :)
[03:20:17] <jmkasunich> that is good news tho, it means the older PPMC encoder board has the same map as the USC
[03:20:25] <SWPadnos_> yeah - they're the same
[03:20:44] <SWPadnos_> except for the pulse width / pulse rate differneces
[03:20:58] <jmkasunich> I'm not talking about USC vs UPC
[03:21:06] <jmkasunich> I mean the ones that go in the cardcage
[03:21:12] <jmkasunich> that card has encoders only
[03:21:14] <SWPadnos_> ah
[03:21:26] <jmkasunich> it seems all three are the saem
[03:21:27] <jmkasunich> same
[03:21:45] <SWPadnos_> actually - other than the two control registers (which can be done "manually"), the entire USC can be read and written in a single address sweep of 32 bytes
[03:21:50] <jmkasunich> so I'm gonna rename your code to encoder instead of UxC encoder, and invoke it for all three
[03:21:58] <SWPadnos_> ok by me
[03:22:08] <SWPadnos_> you may want to feed it a base name then
[03:22:19] <jmkasunich> I'm also changing it to use the master/slave latching
[03:22:27] <SWPadnos_> actually, we may want to do that anyway - USC / PPMC / etc
[03:22:30] <jmkasunich> only the first slot with encoders will generate a latch
[03:22:37] <jmkasunich> nah
[03:22:59] <jmkasunich> ppmc.<busnum>.<function>.<instancenum>.<description>
[03:23:11] <jmkasunich> function being encoder, stepgen, din, dout, or pwm
[03:23:20] <jmkasunich> no need to talk about what board implemnts it
[03:23:25] <SWPadnos_> ok - works for me
[03:23:42] <jmkasunich> that should have been:
[03:23:47] <jmkasunich> ppmc.<busnum>.<function>.<instancenum>.<pin-name>
[03:23:56] <SWPadnos_> I did have a question for you - about another component I'm about to write
[03:24:01] <jmkasunich> shoot
[03:24:18] <SWPadnos_> OK - I was about to implement the spindle controls for the USC
[03:24:45] <SWPadnos_> I wanted to export it as a u8, and have an external component scale a float if necessary
[03:24:52] <jmkasunich> the P8 dac?
[03:25:05] <SWPadnos_> so you see my problem - there isn't any float + scale = u8 block ;)
[03:25:08] <SWPadnos_> yes - P8
[03:25:19] <jmkasunich> I'd rather see that a float
[03:25:32] <SWPadnos_> sure, unless you want to use it as 8 extra DOUTs
[03:25:33] <jmkasunich> either in volts, or with a scale number
[03:25:39] <jmkasunich> ah, I see
[03:26:00] <SWPadnos_> so I'm thinking abour writing something like blocks, but "conversions" or the like
[03:26:12] <jmkasunich> so it wouldn't be ppmc.0.dac.01, it would be ppmc.0.auxout.01
[03:26:43] <SWPadnos_> probably - I was thinking of calling it spindle, but the signal(s) that connect to it would be different
[03:26:57] <jmkasunich> in the driver call it aux
[03:27:02] <SWPadnos_> if you want to use it as auxout, you need to know what you're doing
[03:27:07] <jmkasunich> if it might be a dac, or might be 8 outs, etc
[03:27:14] <SWPadnos_> the simple case is to use it as spindle
[03:27:23] <jmkasunich> no, thats the complicated case
[03:27:38] <SWPadnos_> either way, the more important thing is "conversions" (or converters, as I have it now)
[03:27:39] <jmkasunich> involves float to u8 conversion and all that
[03:27:48] <jmkasunich> yes, lets focus on that
[03:27:58] <jmkasunich> I think converter components are a good idea
[03:28:08] <SWPadnos_> also, some of the functions in blocks would be more appropriate in a conversion / scaling component
[03:28:15] <jmkasunich> convf2u8, convf2u16, etc
[03:28:27] <SWPadnos_> yep - bitstou8, etc
[03:28:36] <jmkasunich> yep
[03:28:42] <jmkasunich> lotta permutations
[03:29:08] <SWPadnos_> I have the option of adding it to blocks, but I think it's better in a separate component - blocks is pretty crowded already
[03:29:15] <jmkasunich> agreed
[03:29:58] <jmkasunich> that module would be a natural for some more efficient export code
[03:29:59] <SWPadnos_> I can also move some things (like the limiter, comparator) out of blocks, if you think it's a better grouping
[03:30:10] <SWPadnos_> heh - yes it would
[03:30:12] <jmkasunich> I like those in there
[03:30:27] <jmkasunich> might eventually split blocks into analog and digital blocks
[03:30:32] <jmkasunich> and, or, etc, would be digital
[03:30:38] <SWPadnos_> yeah -they're already there anyway, so changing moving them now doesn't really buy anything
[03:30:39] <jmkasunich> limit, sum, etc analog
[03:30:47] <SWPadnos_> yes - there should be a "logic" component
[03:30:50] <jmkasunich> but mux, comp, and others have both
[03:31:17] <SWPadnos_> and there's where you need the "anytype" pin
[03:31:25] <jmkasunich> ?
[03:31:51] <SWPadnos_> something that can take a connection from anything, and then "polymorphs" into a component that only accepts more pins of the same type
[03:32:01] <SWPadnos_> (for the specified inputs)
[03:32:21] <jmkasunich> to me, analog = float, digital = bit, and the integral types are bastards
[03:32:21] <SWPadnos_> so you can have a "mux3" that can mux bits, bytes, floats, etc
[03:32:42] <SWPadnos_> but only one type at a time - no automatic conversions
[03:33:11] <jmkasunich> I was seriously considering dumping all all the integral types and just having one, 32 bit signed
[03:33:41] <SWPadnos_> you may be able to do that, but there are three ways of converting between types
[03:33:44] <jmkasunich> an anytype pin would be messy
[03:34:07] <SWPadnos_> I don't think it's so bad
[03:34:22] <jmkasunich> when to you change the associated code? it could be disconnected and reconnected at any time
[03:34:30] <SWPadnos_> you can have a separate input that you connect for setting the type
[03:34:37] <jmkasunich> retch
[03:34:41] <SWPadnos_> all HAL types take 32 bits, regardless of what they are
[03:34:58] <SWPadnos_> or at least, they can
[03:35:02] <jmkasunich> is that a suggestion or a statement?
[03:35:07] <jmkasunich> bits are only 8
[03:35:21] <rayh-emc2> the following lines give the loopback and allow emc to come out of estop.
[03:35:25] <rayh-emc2> linkps iocontrol.0.user-enable-out EstopWrite
[03:35:26] <rayh-emc2> linksp EstopWrite iocontrol.0.emc-enable-in
[03:35:26] <rayh-emc2> linksp EstopWrite <= ppmc.0.dout.07.out
[03:35:31] <SWPadnos_> the anytype would be the same as the largest allowed type
[03:35:43] <rayh-emc2> they do pull pin 07
[03:35:54] <rayh-emc2> but the board does not come out of estop.
[03:36:04] <rayh-emc2> and pin 15 still shows false.
[03:36:23] <jmkasunich> and the board passes the pico diagonistics program?
[03:36:34] <jmkasunich> dio_cont I think it is, that scrolls red lights
[03:37:13] <jmkasunich> SWP: lets resume this anytype thing later
[03:37:14] <SWPadnos_> rayh-emc2: here's wehat I have - only one real changefrom what you just posted:
[03:37:16] <SWPadnos_> linksp EstopSense <= ppmc.0.din.15.in
[03:37:17] <SWPadnos_> linksp EstopSense => iocontrol.0.emc-enable-in
[03:37:17] <rayh-emc2> I'm not able to make either board run that part of the diagnostics.
[03:37:19] <SWPadnos_> linksp EstopWrite <= ppmc.0.dout.07.out
[03:37:20] <SWPadnos_> linksp EstopWrite => iocontrol.0.user-enable-out
[03:37:22] <SWPadnos_> ok
[03:37:27] <SWPadnos_> it's diocontinuous
[03:37:42] <jmkasunich> if the board won;t run Jon's diagnositics, you are pissing up a tree trying to get it to run emc
[03:37:43] <rayh-emc2> does your board come out of estop?
[03:37:49] <SWPadnos_> yes
[03:38:15] <rayh-emc2> These are both brand new from jon.
[03:38:34] <jmkasunich> I don't know why they don't work, just that they dont
[03:38:43] <jmkasunich> his diag is totally independent of our code
[03:38:51] <rayh-emc2> I'm just guessing here but the diags were compiled for 2.4
[03:38:54] <rayh-emc2> not 2.6
[03:38:58] <jmkasunich> so it neither one works, it aint the code
[03:39:01] <SWPadnos_> they work fine on 2.6
[03:39:10] <SWPadnos_> I ran them on a fresh BDI 4.3 install
[03:39:14] <SWPadnos_> 4.30
[03:39:17] <jmkasunich> I don't recall if I downloaded the binary, or compiled here
[03:39:23] <jmkasunich> but the diag works here
[03:39:37] <rayh-emc2> I didn't find a source file for these.
[03:39:47] <SWPadnos_> hm - actually, I had downloaded this a long time ago
[03:39:50] <jmkasunich> I think he sent it to me separately
[03:39:57] <SWPadnos_> there is no source on his website
[03:40:06] <SWPadnos_> I'll download again and se eif it works
[03:40:11] <rayh-emc2> k I'll bail and work on it tomorrow
[03:40:21] <rayh-emc2> thanks for all the help guys.
[03:40:43] <jmkasunich> if I can find the source jon mailed me, I'll send to you guys
[03:40:57] <jmkasunich> heck, I should be able to send the binary
[03:41:15] <jmkasunich> SWP: you are on 4.30, same as ray?
[03:41:21] <jmkasunich> can you send him the binary?
[03:41:27] <SWPadnos_> yes
[03:41:37] <jmkasunich> sometimes he makes me nuts
[03:41:38] <SWPadnos_> we can check that later
[03:41:59] <jmkasunich> don't try to run the whole thing until you know the pieces work
[03:42:14] <SWPadnos_> well - that is ideal
[03:42:43] <jmkasunich> you can try the whole thing if you want, but as soon as you find problems, then troubleshoot by breaking it up
[03:43:03] <jmkasunich> if dout.07 is on and the led isnt, then either the driver or the board is busted, forget about emc and the hal file
[03:43:17] <jmkasunich> use jon's diag to see whether it is the driver or the board
[03:43:23] <jmkasunich> seems obvious to me
[03:43:35] <SWPadnos_> yeah -though I;m now seeing an odd problem here as well
[03:43:52] <jmkasunich> ?
[03:43:59] <SWPadnos_> I loaded up 3d_chips, and tried to run it
[03:44:21] <SWPadnos_> I see a zillion emcTaskPlanCommand(blah) calls
[03:44:31] <SWPadnos_> up to line 1005, where it stops, and does nothing
[03:44:43] <jmkasunich> don't ask me about that, I don't do Task
[03:44:55] <SWPadnos_> I've flipped the switches so the encoders should count step pulses
[03:45:04] <SWPadnos_> and I see no motion
[03:45:23] <jmkasunich> does it jog?
[03:45:25] <SWPadnos_> but the SSR8 LED is on, green light lit, and brake on
[03:45:42] <SWPadnos_> one sec
[03:46:00] <jmkasunich> again with the running before walking.... you guys, I swear ;-)
[03:46:30] <SWPadnos_> heh
[03:47:01] <SWPadnos_> no - it doesn't jog
[03:47:03] <SWPadnos_> ;P
[03:47:17] <jmkasunich> ok, halmeter on axis.0.enable
[03:47:23] <jmkasunich> see if its enabling
[03:47:36] <jmkasunich> then put it on axis.0.position-cmd (or whatever thats called)
[03:47:42] <jmkasunich> see if the command changes
[03:47:49] <jmkasunich> are you getting following errors?
[03:47:55] <jmkasunich> if so, cmd is changing, feedback not
[03:48:04] <jmkasunich> if not, either both are changing, or neither
[03:48:32] <jmkasunich> meter tells you which case you have
[03:48:35] <SWPadnos_> yes - Xenable goes true when I turn the machine on
[03:49:04] <SWPadnos_> and yes - I got joint following errors, and I could see that the position wasn't changing
[03:49:19] <jmkasunich> fb pos wasn't changing, I assume cmd was
[03:49:22] <SWPadnos_> maybe you can't change the encoder mode while the unit is on
[03:49:31] <jmkasunich> Xenabme goes to the PID enable input?
[03:49:38] <jmkasunich> Xenable
[03:49:43] <jmkasunich> jeez, I can't type
[03:50:18] <SWPadnos_> one sec - pulling up a halcmd shell ;)
[03:50:45] <SWPadnos_> yes
[03:50:57] <jmkasunich> sudo bin/halcmd loadrt scope_rt
[03:51:01] <jmkasunich> bin/halscope &
[03:51:13] <jmkasunich> (bring out the big guns)
[03:51:46] <jmkasunich> there is a param axis.0.something that goes true when there is a following error
[03:51:50] <SWPadnos_> ok - got it. I suppose I could get rid of the base_period
[03:51:53] <jmkasunich> put a scope probe on that for trigger
[03:52:09] <jmkasunich> run scope on the servo thread
[03:52:21] <SWPadnos_> that's what I did
[03:52:25] <jmkasunich> ok
[03:52:46] <jmkasunich> now put probes on position cmd and feedback from encoder and output to stepgen
[03:52:58] <SWPadnos_> axis.0.error, or axis.0.f-err?
[03:53:06] <jmkasunich> ferrored maybe?
[03:53:17] <jmkasunich> error is the analog error
[03:53:31] <jmkasunich> hmm... those dialogs should display type
[03:53:36] <jmkasunich> you are looking for a bit
[03:53:37] <SWPadnos_> error is the bit, f-error is the float
[03:53:46] <jmkasunich> ok
[03:54:11] <jmkasunich> i'm rusty on this, should start an emc myself and follow along
[03:54:22] <SWPadnos_> it's ok - I get what you're saying
[03:54:25] <jmkasunich> except I'm in the middle of editing ppmc.c
[03:54:28] <SWPadnos_> heh
[03:58:39] <jmkasunich> are your hal files committed?
[03:58:45] <SWPadnos_> yes
[03:58:55] <jmkasunich> ok, I'm gonna try it here
[03:59:01] <SWPadnos_> ok
[03:59:09] <jmkasunich> is there an ini too, or do I edit my default one?
[04:00:05] <SWPadnos_> I didn't commit an ini
[04:00:39] <jmkasunich> ok, I'll copy emc.ini to ppmctest.ini and edit
[04:00:46] <jmkasunich> just need to add the two hal files, right?
[04:00:58] <SWPadnos_> load core_servo.hal, ppmc_motion.hal, and ppmc_io.hal
[04:03:21] <SWPadnos_> so - apparently the ferror limit is 0.01 (10m in halscope)
[04:03:50] <jmkasunich> you see it tripping?
[04:03:55] <SWPadnos_> the xpos-cmd ramps up smoothly, but both Xoutput and feedback remain at 0
[04:04:01] <SWPadnos_> I see the trigger
[04:04:13] <SWPadnos_> and it's just as the ferror gets to 1 div at 10m/div
[04:04:29] <jmkasunich> are you using the loop gains from core_servo.hal?
[04:04:36] <SWPadnos_> yes - defaults
[04:04:43] <jmkasunich> because they are way too low for anything real
[04:04:52] <jmkasunich> all zero except for P, which is 0.01
[04:05:13] <SWPadnos_> this is using looped stepgens, so P should be at least 1, I guess
[04:05:31] <jmkasunich> make FF1 = 1.0
[04:06:04] <jmkasunich> that means an input position ramp of 1 inch/sec will command an output velocity of 1 inch/sec
[04:06:24] <jmkasunich> which barring errors, roundoff, etc, is exactly what you want
[04:06:35] <SWPadnos_> yep - only it didn't work ;)
[04:06:38] <jmkasunich> scope the PID output
[04:07:17] <jmkasunich> or disconnect the stepgen from the PID loop and force a velocity command, see if A) you get pulses with a scope, B) the encoders count
[04:07:37] <SWPadnos_> goes to a constant at the satart of the move
[04:07:40] <SWPadnos_> start
[04:07:57] <jmkasunich> what value?
[04:08:08] <SWPadnos_> around .015
[04:08:23] <jmkasunich> your jog rate is the default 1 ipm
[04:08:24] <SWPadnos_> can you read actual values from halscope?
[04:08:28] <SWPadnos_> ok
[04:08:30] <jmkasunich> = 0.0167 inches/sec
[04:08:32] <SWPadnos_> ok
[04:08:43] <jmkasunich> yeah, halscope reads values
[04:08:53] <jmkasunich> jeez, what good would it be?
[04:09:10] <SWPadnos_> no - do I get cursors like a nice digital scope?
[04:09:20] <jmkasunich> no cursors yet, that is rev 2 ;-)
[04:09:26] <SWPadnos_> see :P
[04:09:49] <SWPadnos_> maybe I should revive my oscilloscope analysis code from way back ;)
[04:09:52] <jmkasunich> but you can change scale after acquiring, so make it about 1.5 divs, and see what a div is
[04:10:15] <SWPadnos_> yeah - that's how I estimated around .015
[04:10:35] <SWPadnos_> but you're right - if I look at the subdiv dots, it's closer to a little below .017
[04:11:14] <SWPadnos_> I guess different color traces for the different channels is planned for rev2 as well?
[04:11:19] <jmkasunich> this is the output of pid
[04:11:21] <jmkasunich> yeah
[04:11:27] <jmkasunich> the active channel is green
[04:11:32] <SWPadnos_> yes -it's the PID output
[04:11:38] <jmkasunich> click on chan button to change it
[04:11:53] <SWPadnos_> yep - I see that (I experiment from time to time ;) )
[04:12:07] <jmkasunich> ok
[04:12:16] <jmkasunich> sorry, don't mean to insult your intelligence
[04:12:22] <SWPadnos_> no problem
[04:12:38] <Jymmmm> Can I ask a question?
[04:12:43] <SWPadnos_> I have a sense of humor to match
[04:12:46] <SWPadnos_> no!
[04:12:54] <SWPadnos_> um - I mean - sure :)
[04:13:22] <Jymmmm> Is everyone just working on "whatever" in respect to emc development?
[04:13:34] <Jymmmm> or whatever they feel like?
[04:13:39] <SWPadnos_> sort of
[04:14:01] <SWPadnos_> some peple work on "whatever" someone pays them for
[04:14:03] <SWPadnos_> people
[04:14:14] <SWPadnos_> (though I'm not one of them)
[04:14:47] <Jymmmm> ok
[04:15:03] <Jymmmm> Jymmmm is now known as Jymmm
[04:15:13] <Jymmm> sounds a lil counter productive.
[04:15:24] <SWPadnos_> well - there's work, and there's play.
[04:15:30] <SWPadnos_> emc is play for a lot of people
[04:15:42] <SWPadnos_> and playtime doesn't have to be productive
[04:15:45] <Jymmm> ok, then the purpose of a board?
[04:15:53] <SWPadnos_> to guide the players ;)
[04:16:09] <Jymmm> who aren't all playing the same game?
[04:16:12] <SWPadnos_> there are a few of us who just like to work on it, and want to see it progress
[04:16:45] <SWPadnos_> but it's hard to do anything when you don't know what will be accepted, and there are no rules or guidelines for what should be done
[04:16:49] <jmkasunich> SWP: I see ppmc.0.stepgen.00.vel-scale = 1
[04:17:04] <jmkasunich> seems a bit low
[04:17:14] <SWPadnos_> so a few rules, goals, guidelines, etc are the responsibility of the board (in my view)
[04:17:22] <jmkasunich> agreed
[04:17:39] <jmkasunich> more emphasis on guidlines than rules, because everyone is a volunteer
[04:17:40] <SWPadnos_> hm - that should be set from [ASIS_N]INPUT_SCALE
[04:17:50] <SWPadnos_> yes - rules and directions
[04:17:52] <Jymmm> Well, I beeter shut up now. don't want to start anything.
[04:18:06] <jmkasunich> ppmc.0.encoder.00.scale = 4000, so that worked
[04:18:09] <SWPadnos_> it's just a question so far...
[04:18:19] <Jymmm> just wanted confirmation on the anarche.
[04:18:36] <SWPadnos_> sure - the board of dictators will guide the anarchy
[04:18:51] <SWPadnos_> unless people want to fork off
[04:19:07] <jmkasunich> ok, changed the vel-scale to 4000 manually and jogs work
[04:19:13] <SWPadnos_> they can fork themselves if they want
[04:19:37] <jmkasunich> pah - output scale sucks
[04:19:46] <jmkasunich> but I suppose it is the right thing to use
[04:19:55] <jmkasunich> output scale in the default ini was 1.0 ;-)
[04:20:04] <SWPadnos_> ah - that's not helpful
[04:20:18] <SWPadnos_> that should be equal to input scale by default, I'd imagine
[04:20:31] <jmkasunich> if I was doing it, I'd write the HAL file to use input scale for both
[04:20:40] <jmkasunich> but for some folks that would be wrong...
[04:20:44] <SWPadnos_> hmmm - someone suggested that last night
[04:20:45] <jmkasunich> you can never win
[04:21:12] <SWPadnos_> one thing to note about that
[04:21:54] <SWPadnos_> when we talked about it last night, you suggested that people may want to use the encoder inputs for something other than position feedback (on stepper systems)
[04:22:03] <jmkasunich> yes
[04:22:12] <SWPadnos_> they can't, unless the axis isn't being used
[04:22:17] <jmkasunich> right
[04:22:29] <jmkasunich> I was thinking of the fourth axis mostly
[04:22:35] <jmkasunich> or if they have more than one board
[04:22:39] <SWPadnos_> though you may be able to use one axis as a spindle out, and still use the input
[04:22:46] <jmkasunich> right
[04:22:53] <jmkasunich> you might even use it for a spindle encoder
[04:22:55] <SWPadnos_> since you only care about velocity (or the most part)
[04:22:58] <SWPadnos_> for
[04:23:18] <jmkasunich> for the mazak, we used a dac to send an analog speed ref to the spindle drive
[04:23:28] <SWPadnos_> it's a bummer - you can't see how many steps were generated unless you loopback with the dipswitches
[04:23:34] <jmkasunich> and an encoder channel to measure spindle position
[04:23:38] <SWPadnos_> which prevents you from using the encoder input
[04:23:44] <SWPadnos_> yep
[04:23:53] <jmkasunich> ignored the encoder except when doing spindle orient for toolchange
[04:23:54] <SWPadnos_> with the zillion-count encoder-with-index
[04:24:14] <SWPadnos_> which I got working today - index pulses are functional
[04:24:27] <jmkasunich> emc is a prick!
[04:24:35] <jmkasunich> I hate it that it writes the ini file
[04:24:37] <SWPadnos_> heh
[04:24:44] <SWPadnos_> hah
[04:24:44] <jmkasunich> I edited, then exited EMC to restart
[04:24:52] <SWPadnos_> if only it were XML
[04:24:56] <SWPadnos_> * SWPadnos_ ducks
[04:24:57] <petev> yep
[04:25:27] <jmkasunich> yeah, then I couldn;t edit it without going insane, so this would never happen
[04:26:11] <SWPadnos_> no - you'd have some advanced editor that would notice the changes on disk, and have an archived copy in a registry somewhere (unknown to you), so it could auto-restore whenever you think the file is screwed up.
[04:26:12] <jmkasunich> ok, changed OUTPUT_SCALE to 4000 and pid.<all>.FF1 to 1, and I can jog now
[04:26:27] <jmkasunich> fsck advanced editors
[04:26:40] <jmkasunich> <dinosaur mode>
[04:26:53] <petev> jmk: did you ever use nroff?
[04:26:59] <jmkasunich> actually kate did notice the change
[04:27:05] <jmkasunich> but I had to restore it myself
[04:27:07] <jmkasunich> nope
[04:27:20] <petev> well not that much of a dinosaur then
[04:27:38] <jmkasunich> that is dinosaurus-unixus
[04:27:46] <SWPadnos_> you may want to try kdevelop - it's bigger, but has some nice features for just that kind of situation
[04:27:59] <jmkasunich> I am dinosaurus-z-80us
[04:28:07] <jmkasunich> cpm even
[04:28:21] <SWPadnos_> when there's a change on disk, it changes the tab icon, and you can diff to disk version easily
[04:28:21] <petev> yeah, I did multi-processor cpm, it was ugly
[04:28:44] <jmkasunich> anyway, SWP and I can both get out of estop
[04:28:47] <jmkasunich> ray can't
[04:28:49] <SWPadnos_> I did my first robotics project on a PDP-11
[04:28:54] <jmkasunich> he has a hw or config problem
[04:28:55] <SWPadnos_> that was fun
[04:29:16] <petev> yeah, I remember toggling in the octal boot coade
[04:29:29] <SWPadnos_> shouldn't the PID values be in emc.ini?
[04:29:30] <jmkasunich> SWP: did you wire up SSR3 (dout 2) to do something?
[04:29:30] <petev> but that machine code was nice and orthagonal
[04:29:39] <SWPadnos_> I see a pretty LED
[04:29:45] <jmkasunich> me too
[04:30:08] <jmkasunich> oh, you wired them all
[04:30:12] <SWPadnos_> yep
[04:30:15] <jmkasunich> spindle brake
[04:30:23] <SWPadnos_> I see 8 LEDS, and 2 of them are pretty
[04:30:30] <SWPadnos_> right
[04:30:52] <jmkasunich> ohh, now only 1 is pretty
[04:30:53] <SWPadnos_> the settings mirror the univstep.ini on Jon's site
[04:30:57] <jmkasunich> (brake off button works)
[04:31:10] <SWPadnos_> yep, and so do spindle speed + and -
[04:31:14] <SWPadnos_> and fwd/rev
[04:31:19] <jmkasunich> speed up and speed down buttons make pretty
[04:31:23] <SWPadnos_> haven't tried mist / flood
[04:31:43] <SWPadnos_> if only this !@$%^&#% board could take standard opto-22 modules
[04:31:56] <petev> yeah, I tol jon about that
[04:31:58] <jmkasunich> they work
[04:32:06] <petev> they don't fit right
[04:32:07] <SWPadnos_> not with the fuse holders they don't
[04:32:21] <jmkasunich> I jammed the modules in, no fuses in the holders, marginal module contact
[04:32:52] <SWPadnos_> and I have a box of 20 modules here
[04:32:55] <jmkasunich> I'll probably unsolder the fuse sockets, jumper, and fuse externally (or not at all, live dangerousely)
[04:33:04] <SWPadnos_> it depends on which part of a socket the fuse holders are made of ;)
[04:33:11] <SWPadnos_> and how well they're trimmed
[04:33:14] <jmkasunich> spell dangerously too
[04:33:29] <SWPadnos_> if u cud spel, ud b dangrus
[04:33:32] <jmkasunich> most of mine don't even come close to fitting
[04:33:56] <jmkasunich> 6 Grayhill modules, 2 Gordos
[04:34:05] <SWPadnos_> the LEDs are also perilously close
[04:34:12] <jmkasunich> yep
[04:34:21] <jmkasunich> and I hate that stupid heatsink on the regulator
[04:34:29] <jmkasunich> just waiting to get busted off
[04:34:33] <petev> yeah, no board locks
[04:34:36] <petev> breaks off easy
[04:34:49] <jmkasunich> stupid place for it period, locks or not
[04:34:52] <SWPadnos_> I've got modules from some unknown manufacturer - 12 AC and 8 DC (OAC5 and ODC5)
[04:35:14] <SWPadnos_> I also replaced those damned IDC terminal blocks
[04:35:29] <jmkasunich> with something that has screws?
[04:35:34] <SWPadnos_> got real removable screw terminals now
[04:35:36] <petev> yeah, the 2 peice phoenix are much nicer
[04:35:45] <SWPadnos_> yep - just like on his Gecko Servo Interface
[04:35:46] <petev> I told jon all this stuff over a year ago
[04:35:56] <petev> interesting how everyone has the same opinion
[04:36:03] <SWPadnos_> I mentioned it to him at Fest - the price of the connectors is prohibitive
[04:36:03] <jmkasunich> I haven't measured the pin center spacing, do you recall what it is?
[04:36:12] <petev> no
[04:36:15] <SWPadnos_> 3.81mm
[04:36:30] <jmkasunich> whats that in real units? .156 inches?
[04:36:33] <SWPadnos_> the Phoenix Contact or OnShore connectors from DigiKey
[04:36:38] <SWPadnos_> .150
[04:36:42] <jmkasunich> cool
[04:36:56] <SWPadnos_> no - wait - you may be right
[04:37:00] <jmkasunich> I might just have to raid the phoenix drawer at work...
[04:37:02] <SWPadnos_> EDSTL series
[04:37:28] <jmkasunich> I think most of our pheonix are larger spacing
[04:37:48] <jmkasunich> these would be marginal at best at 120V AC I would think
[04:38:23] <jmkasunich> hmm, gonna need more than just FF1 to get good performance
[04:38:31] <jmkasunich> (expected as much)
[04:38:39] <SWPadnos_> ok - it is 0.150
[04:38:45] <jmkasunich> 60IPM jog got a following error
[04:38:57] <jmkasunich> after about 1 inch
[04:39:03] <CIA-5> 03paul_c * 10emc2-auto/wiki/ (13 files in 10 dirs): "Auto update wiki from a cron job. Tue Nov 29 05:30:02 GMT 2005 "
[04:39:20] <SWPadnos_> one thing to note - there are two types of terminal block - one with the key on the side of the wire entry, and one with the key on the opposite side
[04:39:37] <jmkasunich> key? these don't have screws?
[04:39:53] <jmkasunich> oh, I think I understand
[04:40:05] <jmkasunich> maybe? :-/
[04:40:27] <SWPadnos_> there's a ridge on one side of the plug, so you can't plug it in backwards
[04:40:31] <jmkasunich> right
[04:40:48] <jmkasunich> doesn't matter which one you have, unless you already soldered the PC board part on
[04:40:55] <SWPadnos_> the ones I got have the screw on top, and I want the wires to point off the board
[04:40:57] <SWPadnos_> right
[04:40:58] <jmkasunich> (or does it?)
[04:41:03] <SWPadnos_> just get the same kind :)
[04:41:18] <SWPadnos_> no - they work, they're rotationally symmetric to each other
[04:41:24] <jmkasunich> oh, you got some of both?
[04:41:34] <SWPadnos_> no - just a reminder ;)
[04:41:39] <jmkasunich> thanks
[04:42:01] <jmkasunich> hmmm, well past midnight again
[04:42:13] <SWPadnos_> so - you set FF1 to 1, and P to ?
[04:42:26] <jmkasunich> didn't try tuning it yet
[04:43:08] <SWPadnos_> OK - I'll play a little bit, but the change to the default FF1 should probably be in cvs
[04:43:28] <SWPadnos_> and the deafult INPUT_SCALE = OUTPUT_SCALE
[04:44:17] <jmkasunich> I put the FF1 in the hal file
[04:44:28] <jmkasunich> there should probably be a servo ini file, that has the gains
[04:44:35] <SWPadnos_> the core_servo, or ppmc_motion?
[04:44:41] <jmkasunich> I don't want gains in a stepper ini file, why confuse people
[04:44:50] <SWPadnos_> they're in core_servo
[04:45:00] <jmkasunich> I did in in ppmc-motion
[04:45:09] <jmkasunich> core_servo sets them to zero
[04:45:18] <SWPadnos_> and P to 0.01
[04:45:32] <jmkasunich> using FF1 = 1 is specific to ppmc and similar loopback arrangements
[04:45:46] <SWPadnos_> hm - you can turn the brake on while the spindle is on
[04:45:51] <jmkasunich> what should really happen is that the values should be in the ini, and core_servo should pull them and set the params
[04:46:04] <jmkasunich> I dunno why that is a separate button
[04:46:06] <SWPadnos_> yeah - I thought they were supposed to be there
[04:46:19] <jmkasunich> I don't want them in there for a stepper machine
[04:46:26] <SWPadnos_> well - you may need to release the brake for manual toolchange
[04:46:28] <jmkasunich> we need more than one set of sample inis
[04:46:32] <jmkasunich> true
[04:46:54] <jmkasunich> any brake/spindle logic should probably be done in CL anyway
[04:46:57] <SWPadnos_> yes - and the config drectories Ray mentioned are a great way to do that
[04:47:03] <SWPadnos_> yes - it's machine specific
[04:47:31] <jmkasunich> should be a board thing - solicit input about directory layout, then come up with and post a set of guidelines
[04:47:44] <SWPadnos_> yep
[04:48:08] <SWPadnos_> also naming conventions to use for pins/params, etc
[04:48:13] <CIA-5> 03jmkasunich * 10emc2/ (configs/ppmc_motion.hal src/hal/drivers/hal_ppmc.c):
[04:48:13] <CIA-5> Added encoder support for the original PPMC encoder board (can't test). Also
[04:48:13] <CIA-5> modified encoders to use a single latch pulse for all boards (if there are more
[04:48:13] <CIA-5> than one). Needs tested by someone who can put more than one board on an EPP
[04:48:13] <CIA-5> bus.
[04:48:20] <SWPadnos_> and for components in general
[04:48:33] <jmkasunich> damn... I didn't mean to commit my change to ppmc.hal, just ppmc.c
[04:48:47] <SWPadnos_> oh well
[04:49:04] <SWPadnos_> I got used to doing separate updates in each directory
[04:49:16] <jmkasunich> me too, I just forgot this time
[04:49:50] <jmkasunich> should I leave it, or fix it.... it has "setp pid.<all>.FF1 1"
[04:50:14] <SWPadnos_> that's fine - it's only the PPMC that is affected
[04:50:20] <jmkasunich> tempted to leave it until we address PID gains properly
[04:50:48] <jmkasunich> hah - it wasn't a mistake, I meant to do that ;-)
[04:50:55] <SWPadnos_> of course
[04:51:08] <SWPadnos_> ok - so jogging still works, but not auto mode
[04:51:22] <jmkasunich> ppmc.c is up to something like version 17 now ;-)
[04:51:37] <jmkasunich> gotta get the tuning right first
[04:51:44] <SWPadnos_> yeah -I've been trying to commit often, so it looks more important than the others
[04:51:45] <jmkasunich> (you getting following errors?)
[04:52:00] <SWPadnos_> no - it just doesn't run
[04:52:16] <jmkasunich> estop light comes on?
[04:52:23] <SWPadnos_> does taskplanexec\ute up until line 1005, and then nothing
[04:52:30] <SWPadnos_> yep - not in estop
[04:52:36] <jmkasunich> damnfino
[04:53:03] <SWPadnos_> meneither
[04:53:11] <jmkasunich> tomorroww
[04:53:17] <SWPadnos_> okbyme
[04:53:20] <SWPadnos_> sorry - OK by me
[04:55:55] <jmkasunich> goodnight
[04:56:04] <SWPadnos_> night
[06:58:45] <ValarQ> alex_joni: morning
[08:26:53] <K`zan> Night folks
[08:27:06] <alex_joni> morning captain
[08:27:16] <alex_joni> morning rayh
[08:34:57] <rayh> Hi alex.
[08:36:18] <alex_joni> congrats on your reelection :)
[08:36:33] <alex_joni> seems you are very suitable for president (having the most votes :D)
[08:36:34] <rayh> congrats on your election
[08:37:12] <alex_joni> I'll drop an email to the list soon ;)
[14:53:56] <SWPadnos__> SWPadnos__ is now known as SWPadnos
[14:55:55] <skunkworks_wrk> anyone awake? How do I change the ip address in linux. I want to go dhcp -> static ip. The bdi install lets you change it but how do I do it after the install? Is there a gui interface for that? thanks.
[14:56:15] <SWPadnos> darned good question
[14:56:16] <Jacky^af1> Jacky^af1 is now known as Jacky^
[14:56:19] <Jymmm> Good Morning Planet Earth!
[14:56:21] <Jacky^> hello
[14:56:23] <SWPadnos> hold on a sec
[14:56:28] <Jacky^> good morning Jymmm
[14:56:38] <SWPadnos> Damn - I thought I was on Saturn!
[14:56:44] <jepler> skunkworks_wrk: the file /etc/network/interfaces controls that stuff. I'm not sure if there's a GUI
[14:57:04] <skunkworks_wrk> ah - thanks. I will take a look
[14:57:17] <jepler> "man 5 interfaces" documents the format
[14:57:20] <Jacky^> skunkworks_wrk: use some editor like vim
[14:57:41] <SWPadnos_> even easier - use the cKDE Control Center
[14:57:45] <Jacky^> http://documents.made-it.com/Debian_Internet_Server/Debian_Internet_Server-5.html
[14:58:13] <Jacky^> may you want to set the gateway too
[14:58:23] <SWPadnos_> Control Center -> Internet & Network -> Network Settings
[14:58:37] <SWPadnos_> click Administrator mode, enter the root password
[14:58:42] <Jacky^> adding a line like gateway 192.168.1.1
[14:58:53] <SWPadnos_> click on the interface you want to configure (probably eth0)
[14:59:08] <SWPadnos_> click the Configure Interface button
[14:59:29] <SWPadnos_> then enter all the informatio Jacky^ mentioned in the appropriate boxes ;)
[15:00:48] <skunkworks_wrk> how do I get to admistrator mode? what do I "click on"?
[15:01:22] <SWPadnos_> there's an "Administrator Mode" button at the bottom of the Netwrok Settings page
[15:02:53] <skunkworks_wrk> when I go into the control center there is not a "network settings" under internet & network
[15:03:10] <SWPadnos_> this is BDI 4.30?
[15:03:19] <skunkworks_wrk> bdi 4.3
[15:04:05] <skunkworks_wrk> I must be doing something stupid
[15:04:16] <SWPadnos_> ok - and when you click on "Internet & Network", what happens?
[15:04:53] <SWPadnos_> Note that I ran kcontrol from a terminal, since I'm not logged in locally - you may be running a different program, or looking at a differnet menu
[15:05:37] <skunkworks_wrk> I get "local network browsing", "preference", "proxy", and "web browser"
[15:05:42] <Jymmm> Ya know, it's a whole lot easier to walk someone thru via command line than it is GUI
[15:06:14] <SWPadnos_> especially when I run kcontrol from the correct terminal - oops :)
[15:06:23] <Jacky^> skunkworks_wrk: id spent a few minuts to learn Vim editor, its very simple
[15:06:31] <Jacky^> open a console and become root
[15:06:32] <SWPadnos_> I was running it on the "local" com[uter, not the "remote" emc machine
[15:06:41] <Jacky^> apt-get update
[15:06:46] <SWPadnos_> nano -w is also quite workable
[15:06:46] <Jymmm> install mc mcedit - EXTREMELY easy to use
[15:06:47] <Jacky^> apt-get install Vim
[15:07:03] <Jacky^> vi /etc/network/unterfaces
[15:07:08] <Jacky^> interfaces*
[15:07:14] <Jymmm> vi isn't easy to learn
[15:07:26] <Jacky^> press i to start insert text
[15:07:30] <Jymmm> mcedit there is no learning
[15:07:45] <Jacky^> you can move using arrows
[15:07:55] <Jacky^> and backspace to delete
[15:07:58] <Jacky^> very simple
[15:08:17] <Jacky^> at the end, esc :wq to save and exit
[15:08:18] <Jymmm> Jacky^: He doesn't know nix, much less shell, and you want him to learn Vi ?!
[15:08:31] <Jymmm> vi is a bitch to learn!
[15:08:32] <Jacky^> then /etc/init.d/networking restart
[15:08:35] <Jacky^> thats all
[15:08:50] <Jacky^> Jymmm: nah.. its simple and useful
[15:08:58] <Jymmm> Jacky^ BULLSHIT!
[15:09:01] <Jacky^> :)
[15:09:29] <SWPadnos_> nano is trivial to use, except for the fact that it uses some non-standard keystrokes
[15:09:35] <SWPadnos_> it's also installed by default
[15:09:46] <Jymmm> mcedit is easy to use becasue it mimicks the same as notepad in M$ world
[15:09:48] <SWPadnos_> as is mcedit
[15:10:10] <Jymmm> or MS Edit I mean
[15:11:17] <SWPadnos_> yeah - anyway, back to skunkworks_wrk's problem
[15:11:19] <Jacky^> skunkworks_wrk: vi filename to start edit, i to start insert text, esc :wq to save and exit, 3 commands to use, its hard ?
[15:11:46] <Jacky^> try
[15:12:14] <SWPadnos_> the idea that you have to enter a command to start adding text is ridiculous
[15:12:22] <Jymmm> exactly
[15:12:39] <Jacky^> I like vi, because is the common editor you can find also in a minimal system
[15:13:05] <SWPadnos_> how about kate - lets you pick files with a dialog box and stuff
[15:13:05] <Jymmm> Jacky^ That may be true, but he's not a SysAdmin
[15:13:08] <Jacky^> for advanced use i like emacs
[15:13:25] <Jymmm> Jacky^ dont make me hurt you!
[15:13:28] <Jacky^> Jymmm: no need to be sysadmin for that ;)
[15:13:30] <skunkworks_wrk> give me a few (I tried to load kcontrol from root termial and it didn't work either) I will try and see what kind of trouble I will get into ;)
[15:13:42] <Jacky^> skunkworks_wrk: is a couragios man :P
[15:13:57] <Jymmm> Jacky^ and you're a sadistic one.
[15:14:00] <Jacky^> hehe
[15:14:05] <SWPadnos_> yeah - sorry about that - I was using the kcontrol from KDE 3.4.3, not 3.3.2 like the BDI
[15:15:30] <SWPadnos_> note that there's no documentation in /etc/network/interfaces - it just lists interfaces and when to bring them up
[15:16:54] <skunkworks_wrk> right - I just looked in there.
[15:17:39] <cradek> man interfaces
[15:17:48] <cradek> iface eth0 inet static
[15:17:52] <cradek> address x.x.x.x
[15:17:55] <cradek> netmask x.x.x.x
[15:18:05] <Jacky^> Jymmm: you cannot look at Linux as windows .. are two different worlds
[15:18:19] <SWPadnos_> oh sure, pull out the man-ual
[15:18:28] <skunkworks_wrk> what about dns and gateway - thanks cradek
[15:18:30] <Jacky^> just learn to use an editor if you want to take complete control
[15:18:58] <Jacky^> skunkworks_wrk: dns are in another file
[15:19:05] <Jacky^> /etc/resolv.conf
[15:19:13] <skunkworks_wrk> and gateway?
[15:19:15] <Jacky^> try to cat /etc/resolv.conf
[15:19:29] <Jacky^> the gatewy is in /etc/network/interfaces
[15:19:37] <Jacky^> look here: http://documents.made-it.com/Debian_Internet_Server/Debian_Internet_Server-5.html
[15:19:51] <Jacky^> add the gateway line after netmask
[15:20:07] <Jacky^> gateway your.gat.e.way
[15:20:23] <Jacky^> its a simple text file
[15:54:54] <skunkworks_wrk> how do you delete a line in vi?
[15:55:22] <Jacky^> skunkworks_wrk: to delete a line cu can press 2 time d
[15:55:24] <Jacky^> dd
[15:55:52] <Jacky^> or use i to 'insert' then backspace to delete
[15:56:07] <SWPadnos_> skunkworks_wrk: just use kate - from the menu (or from a terminal)
[15:56:34] <SWPadnos_> It's a lot easier to use, and supports cut/paste, hilighting, etc (there's even a g-code hilighting mode)
[15:56:43] <Jymmm> Or.... if you were using mcedit.... hit the DEL key (what an amazing concept)
[15:56:51] <SWPadnos_> or backspace, even
[15:57:06] <skunkworks_wrk> kat won't alow me to save
[15:57:11] <cradek> hey guys, take this to #editors please
[15:57:28] <SWPadnos_> maybe #editor-wars would be better
[15:57:30] <Jymmm> cradek you first
[15:57:35] <SWPadnos_> or #editor-zealotry
[15:57:48] <Jacky^> :)
[15:57:49] <cradek> Jymmm: I'm not involved
[15:58:07] <cradek> skunkworks_wrk: are you running your editor as root? You need to be root to save those system config files
[15:58:20] <Jymmm> cradek: http://MailOrderBrides.ru/
[15:58:40] <Jacky^> skunkworks_wrk: if you really cant get it working tell me your params, i will write the files for you then upload to my website
[15:59:03] <Jacky^> so you can just overwrite the old
[15:59:39] <Jacky^> if so, query me
[15:59:54] <cradek> I tried sudo kate /etc/network/interfaces but it just crashed
[15:59:58] <cradek> and now kate won't run
[16:01:10] <cradek> kate: ERROR: Communication problem with kate, it probably crashed.
[16:01:16] <Jacky^> I think openoffice should be used too, but its dangerours if it change the file format when save
[16:01:18] <Jymmm> ROTF
[16:01:29] <Jacky^> or kedit maybe..
[16:01:51] <cradek> ah, that does work
[16:01:56] <cradek> sudo kedit /etc/network/interfaces
[16:01:56] <jepler> cradek: yeah, kde software + su(do) seems to always work out badly. It writes lots of files in ~, and then they end up owned by root...
[16:02:08] <cradek> * cradek is not a kde user
[16:03:03] <cradek> jepler: you're right, it porked itself up
[16:03:18] <SWPadnos_> it's an X problem - you can't connect to the X server as any user other than the login user (unless you use xhost)
[16:03:21] <cradek> I don't recommend sudo kanything
[16:03:28] <Jacky^> use host +
[16:03:32] <cradek> no, it's a kde problem
[16:03:46] <SWPadnos_> no - general X issue, it happens with gnome as well
[16:03:47] <Jacky^> $ xhost +
[16:03:47] <Jacky^> access control disabled, clients can connect from any host
[16:03:57] <Jacky^> become root
[16:04:09] <SWPadnos_> that's only advisable behind a nice tight firewall
[16:04:12] <Jacky^> after edit xhost -
[16:04:13] <cradek> SWPadnos_: no, you don't understand. Root crapped on emc's kde configuration in emc's home directory, and now emc can't run kde apps
[16:04:25] <SWPadnos_> ah - that can be a problem ;)
[16:04:41] <cradek> SWPadnos_: it's a problem of the kde writers not understanding unix
[16:04:57] <SWPadnos_> heh - that could be as well - thy're trying to mimic Windows, after all
[16:05:06] <cradek> kedit - KDialog
[16:05:09] <cradek> Will not save configuration.
[16:05:18] <cradek> Configuration file /home/emc/.kde/...../keditrc not writable
[16:05:23] <cradek> Please contact your system administrator.
[16:05:26] <cradek> [OK]
[16:05:38] <cradek> (after I ran sudo kedit)
[16:06:00] <skunkworks_wrk> Well I added the address netmask and gateway to the interfaces file and it isn't working - yet Boy vi reminds me of the old dos line editer
[16:06:31] <SWPadnos_> vi == edlin
[16:06:34] <cradek> did you figure out how to restart networking so the changes take effect?
[16:06:36] <SWPadnos_> == crap
[16:06:40] <skunkworks_wrk> edlin - that was it
[16:06:44] <jepler> * jepler chews his tongue
[16:06:45] <Jacky^> skunkworks_wrk: are you using an ethernet modem ?
[16:06:48] <SWPadnos_> heh
[16:06:49] <cradek> SWPadnos_: fwiw, 'sudo vi' always works
[16:06:52] <skunkworks_wrk> I rebooted - doesn't that work?
[16:06:57] <cradek> yeah, that'll do it
[16:07:04] <cradek> run ifconfig eth0
[16:07:10] <SWPadnos_> as does sudo nano, or sudo joe, or sudo pico, ...
[16:07:17] <Jacky^> you no need to rebbot, just restart the net with /etc/init.d/networking restart
[16:07:37] <cradek> does ifconfig eth0 show your new IP address?
[16:07:58] <SWPadnos_> would he be able to answer if it did?
[16:08:11] <jepler> cradek: (depending how it's configured, vim may write ~/.viminfo on exit)
[16:08:51] <Jacky^> skunkworks_wrk: you need to do all as ROOT
[16:08:58] <Jacky^> it must work
[16:09:22] <skunkworks_wrk> that is what I did - as root. edited the interfaces file and saved it.
[16:09:28] <Jacky^> to check the gateway use route -n
[16:09:43] <Jacky^> well.. youre at good point then
[16:09:57] <SWPadnos_> did you then run '/etc/init.d/networking restart' ?
[16:09:59] <Jacky^> what about ifconfig eth0 ?
[16:11:19] <skunkworks_wrk> ifconfig doesn't show the ip adrress
[16:11:32] <skunkworks_wrk> no I just rebooted
[16:11:35] <Jacky^> mmhh you missed something
[16:11:40] <skunkworks_wrk> I figured
[16:11:49] <cradek> skunkworks_wrk: it shows the old address still?
[16:12:12] <SWPadnos_> can you paste your interfaces file here?
[16:12:22] <Jacky^> skunkworks_wrk: are you able to paste your lines here: http://www.rafb.net/paste/
[16:12:35] <Jacky^> cat /etc/network/interfaces
[16:12:57] <Jacky^> select all lines then use the center button of mouse to paste in the box
[16:13:14] <Jacky^> paste the url at the end
[16:13:39] <cradek> I can't find a gui network configurator on my bdi
[16:13:47] <cradek> I can't believe there isn't one
[16:13:52] <SWPadnos_> nope - that was on my Ubuntu box with KDE 3.4.3
[16:14:09] <SWPadnos_> it's quite nice actually, but not worth the pain of a BDI upgrade
[16:15:54] <Jacky^> im happy with an old p133 and linux coyote to share my dsl
[16:16:19] <Jacky^> all in a floppy, all in memory.. its cool :)
[16:17:49] <Jacky^> a complete distro as Debian, could be better, but i dont need printer,webserver, etc.. so its enough
[16:17:56] <skunkworks_wrk> http://www.rafb.net/paste/results/aWwjmE11.html
[16:17:56] <Jacky^> for me
[16:18:20] <cradek> skunkworks_wrk: the problem may be the capital A
[16:18:34] <Jacky^> skunkworks_wrk: seems ok
[16:18:37] <skunkworks_wrk> Crap - didn't see that
[16:18:42] <Jacky^> yeah
[16:18:44] <cradek> skunkworks_wrk: just a guess
[16:18:49] <Jacky^> :)
[16:19:04] <cradek> * cradek is not a kde OR debian user
[16:19:26] <Jacky^> if you cat /etc/resolv.conf you should see your dns servers too
[16:19:48] <cradek> but fix the static part first - dhcp overwrites resolv.conf
[16:20:13] <Jacky^> unm, right
[16:21:30] <skunkworks_wrk> vi has a weird habit of capitalising letters
[16:21:39] <cradek> you may be hitting ~
[16:21:39] <Jacky^> skunkworks_wrk: you should alway take care of capital letters in linux
[16:21:46] <cradek> ~ changes the case of a letter
[16:21:57] <Jacky^> I prefer do not use space too, in the file name
[16:22:03] <skunkworks_wrk> hey - I can ping it now
[16:22:10] <cradek> yay
[16:22:12] <Jacky^> I always prefer underscore
[16:22:37] <Jacky^> my_file_name
[16:23:44] <skunkworks_wrk> woo hoo - I can surf - thanks everyone. I wanted to try to download the latest axis and maybe even the updated interpreter.
[16:23:53] <Jacky^> ;-)
[16:24:08] <cradek> skunkworks_wrk: are you using emc2?
[16:24:11] <skunkworks_wrk> yes
[16:24:23] <cradek> skunkworks_wrk: I just built emc2+latest axis and it works great
[16:24:26] <skunkworks_wrk> playing with it - I would say
[16:33:50] <SWPadnos_> cradek: question for you about Axis (which may actually be a HAL / emc task question)
[16:34:20] <SWPadnos_> in testing the new ppmc driver and default .hal files, I tried to run the 3d_chips file
[16:34:58] <SWPadnos_> I would see a zillion emcTaskPlan messages go by - up to line 1005 (every time), but there would be no motion and no following errors
[16:35:25] <cradek> you are seeing the interpreter read ahead in the file
[16:35:27] <cradek> that's normal
[16:35:32] <cradek> no motion is not normal...
[16:35:45] <SWPadnos_> I wonder if I haven't connected some motion-enable pin somewhere
[16:35:47] <cradek> something is wrong with the ppmc driver or hal config, I guess
[16:36:07] <cradek> yeah, maybe something like that
[16:36:14] <cradek> or, maybe it's working but you're not getting encoder feedback
[16:36:24] <cradek> but you would get an immediate following error then
[16:36:41] <SWPadnos_> nope - I looped back the step generators to the encoder inputs on the board, and I saw no motion
[16:36:51] <SWPadnos_> that was another failure mode though - in jogging
[16:36:56] <cradek> sorry, I don't know how to help
[16:37:14] <SWPadnos_> ok - it's probably something to do with the motion enable pins in the iocontroller or motion
[16:37:26] <cradek> I agree that sounds likely
[16:38:37] <SWPadnos_> the other thing I noticed was tool table and part file editing - I think it would be really convenient to have buttons in Axis to edit those files (by spawning an external editor)
[16:39:05] <cradek> I know what the tool table is
[16:39:07] <cradek> what is the part file?
[16:39:08] <SWPadnos_> separate reload buttons would be fine - all the stuff we discussed earlier wrt detecting changes can be ignored
[16:39:21] <SWPadnos_> the file loaded with file -> open
[16:39:37] <cradek> oh, I see what you mean
[16:40:08] <SWPadnos_> is there a config file for axis (to save options like showing part extents and the like)?
[16:40:31] <cradek> SWPadnos_: nope
[16:40:44] <SWPadnos_> heh - where's the feature request tracker ;)
[16:41:17] <cradek> I'll add saving prefs to the list - seems reasonable
[16:41:25] <SWPadnos_> ok - thanks
[16:41:26] <cradek> some things come from the emc ini
[16:41:41] <SWPadnos_> maybe I'll find that python book of mine and do some light reading
[16:41:42] <cradek> units, abs/rel, commanded/actual etc
[16:41:57] <SWPadnos_> sure - also startup G-codes (hint hint)
[16:41:57] <cradek> but I don't think "show extents" belongs in the emc ini
[16:42:00] <SWPadnos_> nope
[16:42:11] <SWPadnos_> it's display related - could be in the DISPLAY section though
[16:42:41] <SWPadnos_> or even an AXIS section - no reason you can't create one
[16:42:44] <cradek> true
[16:42:51] <cradek> I have mixed feelings about that though
[16:43:09] <SWPadnos_> yep - how do you transfer settings separately
[16:43:14] <cradek> I think user should be able to set them in the gui and save them there (or have them magically saved)
[16:43:16] <SWPadnos_> or set ddefaults
[16:43:39] <SWPadnos_> though you may want separate configs for different ini files
[16:43:45] <cradek> but that probably means writing ~/.axisrc
[16:43:47] <cradek> bleah
[16:43:51] <SWPadnos_> so specifying the config file in the ini might make sense
[16:44:19] <cradek> until we have more (and more complex) prefs, I don't think this is a big issue
[16:44:35] <SWPadnos_> nope, but I was thinking the external editor should be a pref ;)
[16:45:44] <cradek> yes, that would need to be
[16:45:59] <SWPadnos_> any thoughts on including Axis in the emc2 tree?
[16:46:15] <cradek> still up in the air
[16:46:16] <SWPadnos_> the SF feature / bug trackers could be useful
[16:46:26] <SWPadnos_> ok
[16:46:34] <cradek> it is not necessary to use sf's cvs in order to use sf's bugtracker
[16:46:41] <SWPadnos_> ah
[16:46:58] <SWPadnos_> true - we can always add axis requests to the emc trackers
[16:47:03] <cradek> I think a sf bugtracker category would be fine today
[16:47:10] <cradek> but I don't have the ability to add a category
[16:47:31] <SWPadnos_> I'm sure that any of the admins would do that for you :)
[16:47:44] <SWPadnos_> (bnut don't ask Ray - he may delete the repository ;) )
[16:48:26] <cradek> I'll ask alex to do it later if I remember
[16:48:32] <cradek> I'm guessing he should be around soon
[16:48:34] <SWPadnos_> cool - thanks
[17:22:57] <Jymmm> Screw the machine, I want the cabinet! lol ---> http://cgi.ebay.com/Moore-Jig-Borer-Model-1-1-2-with-bench-and-tooling_W0QQitemZ7567098788QQcategoryZ92083QQrdZ1QQcmdZViewItem
[17:25:24] <SWPadnos_> damn - I'll say
[17:25:48] <SWPadnos_> and the bricks ;)
[17:26:09] <Jymmm> bricks?
[17:26:20] <SWPadnos_> the blocks under the wood under the machine
[17:26:54] <Jymmm> ah. I just like the cabinet is all - you don't see that kind of stuff anymore, just like roll top desks and such
[17:27:39] <Jymmm> Ok, I must be missing something here, $11 for a stick of wood and a slot? http://cgi.ebay.com/CARLISLE-SLOT-CAR-CHASSIS-BUILDING-JIG-A-MUST-HAVE_W0QQitemZ6016746986QQcategoryZ2617QQrdZ1QQcmdZViewItem
[17:28:20] <SWPadnos_> yeah - but it's got a couple of pins in it or something
[17:28:28] <SWPadnos_> tat's gott abe worth something
[17:28:34] <Jymmm> 0.01
[17:28:49] <SWPadnos_> and the very precise slot down the middle
[17:28:57] <skunkworks_emc2> thanks again guys - Up and running on my linux machine.
[17:29:05] <SWPadnos_> that would easily take 17 seconds to make on a table saw
[17:29:09] <SWPadnos_> cool
[17:29:51] <Jymmm> and it has 3 bids, plus $10 shipping
[17:30:24] <SWPadnos_> heh - there may be some silly regulation thing going on - you know, exactly 3.421278 inches from front to rear wheels
[17:31:43] <Jymmm> eh, maybe.
[17:33:03] <Jymmm> anyone know of any CHEAP (and plentiful) 110VAC motors that do around 18 RPM or so? No need for toque.
[17:33:36] <SWPadnos_> 18rpm is very slow - would a gearmotor do?
[17:34:08] <Jymmm> sure
[17:35:05] <SWPadnos_> have you searched ebay for gearmotors?
[17:35:30] <Jymmm> SWPadnos: No, due to the plentiful necessaity
[17:35:47] <SWPadnos_> ah - so you need a source for production
[17:35:48] <Jymmm> * Jymmm not that familure with 110VAC motors
[17:36:26] <Jymmm> SWPadnos: yeah, or even something I could rip apart... say can openers or whatnot
[17:36:52] <Jymmm> though I've never cracked open a can opener before
[17:37:03] <SWPadnos_> how about 20 RPM? or would you prefer to go lower instead of higher?
[17:37:24] <Jymmm> something in that general speed
[17:37:32] <SWPadnos_> http://www.surpluscenter.com/sort.asp?UID=2005112912273943&catname=electric&keyword=GIAD
[17:37:49] <SWPadnos_> the 20RPM for $13.99, or 25 RPM for $19.99
[17:38:26] <SWPadnos_> or this guy http://www.surpluscenter.com/item.asp?UID=2005112912273943&item=5-1089&catname=electric
[17:39:11] <Jymmm> or forgot... needs contonous duty.
[17:39:32] <Jymmm> but rotissery/mixer gives me ideas
[17:39:56] <Jymmm> Guess I should hit the $0.99 store for ideas.
[17:40:22] <SWPadnos_> the rotisserie would be a good idea, but a mixer or any other consumer appliance wouldn't be
[17:41:50] <Jymmm> It's ironic.... it be cheaper to rip apart a brand new battery charger for the xfmr than it would be to buy the xfmr itself.
[17:42:12] <Jymmm> I guess I'm goin for the same thign here.
[17:42:39] <SWPadnos_> unless you count the cost of the time
[17:43:11] <Jymmm> what? to remove 4 screws and cut some wires? It take longer to pull it out of the box =)
[17:43:35] <SWPadnos_> you still have to pull it out of the box ;)
[17:43:42] <SWPadnos_> then there's the shell disposal cost ;)
[17:43:45] <Jymmm> who says? =)
[17:43:59] <Jymmm> and I get a free enclosure to boot
[17:44:14] <SWPadnos_> glass half full kind of guy, huh
[17:44:55] <Jymmm> usually no, just was in the market for some xfmr, and the cost of of the car chargers at home depto were much cheaper.
[17:47:17] <SWPadnos_> hm - those are pretty low power though
[17:47:27] <Jymmm> 30a
[17:47:32] <SWPadnos_> well - not necessarily I guess
[17:47:52] <Jymmm> yeah, the shipping weight was the killer mostly
[17:48:12] <SWPadnos_> 30A * 12V = 360W - not too big
[17:52:31] <SWPadnos_> hi rayh
[17:52:40] <rayh> Hi Steven
[17:53:04] <rayh> My univstep is alive.
[17:53:15] <SWPadnos_> cool -I just noticed your email
[17:53:47] <rayh> Can you believe a bit of a charge pump that is supposed to work during handshake.
[17:53:50] <SWPadnos_> I was having some trouble excecuting g-code files - there is probably an error in the hal files regarding iocontrol-enable and / or motion.enable pins
[17:54:13] <SWPadnos_> ?
[17:54:31] <rayh> Might be. It was working a while back but...
[17:54:38] <SWPadnos_> did you have a non-pico (or non-epp) device attached to the port?
[17:55:13] <rayh> no. with the athalon the handshake happens fast enough that
[17:55:31] <rayh> the cmos charge never gets to where it allows it to come out of estop.
[17:55:39] <SWPadnos_> weird
[17:55:52] <rayh> It holds ppmc.0.dout-15 false.
[17:56:03] <SWPadnos_> din.15
[17:56:11] <rayh> Jon built it in deliberately.
[17:56:16] <rayh> right I was guessing.
[17:56:27] <SWPadnos_> that's supposed to be false any time that dout.7 is off
[17:56:34] <rayh> 05 bit -W TRUE ppmc.0.din.15.in ==> EstopSense
[17:56:34] <rayh>
[17:56:59] <SWPadnos_> that's why Jon zires input 15 to input 14 - so you can read the estop state even when the card is disabled
[17:57:02] <SWPadnos_> wires
[17:57:04] <rayh> he said even high capacitance in the cable can cause it to fail.
[17:57:42] <SWPadnos_> the inputs all work even with the card disabled, it's just the outputs / step generators that don't
[17:57:45] <rayh> Break the connection to pin 13 on the parport and that speeds the
[17:57:48] <SWPadnos_> except for estop
[17:57:50] <rayh> charge up of the pump
[17:57:53] <SWPadnos_> ok
[17:58:50] <rayh> Now on to CL and a demo.
[17:58:54] <SWPadnos_> ok - that's the "select" pin - defined as usable by the specific application
[17:59:04] <SWPadnos_> for whatever
[18:00:09] <rayh> Okay.
[18:00:44] <rayh> and his whatever was this pump during handshake.
[18:01:19] <SWPadnos_> there are some annoying "features" on these cards
[18:04:04] <rayh> Right. I think that each emc hardware maker and code writer tries to get around "issues"
[18:04:14] <SWPadnos_> yep
[18:04:19] <SWPadnos_> I know I did ;)
[18:04:28] <rayh> by building in overkill rather than solving the real problem where it lives.
[18:05:29] <rayh> Well I've got to run to town and pick up a few things.
[18:05:36] <rayh> Thanks again for all the good work.
[18:05:41] <SWPadnos_> sure - see you later
[18:24:41] <crib> nabend
[18:30:49] <skunkworks_wrk> Another stupid question. Is there a way to have emc2 start up with the axis posision that it was shut down with?
[18:31:18] <SWPadnos_> funny you should mention that - there were recent discussions on that very topic.
[18:31:27] <SWPadnos_> I believe the answer is no, however
[18:31:42] <cradek> that's right, I think the answer is no
[18:31:43] <skunkworks_wrk> funny - guess I need to get my home switches working. ;)
[18:31:49] <cradek> it does preserve offsets though
[18:31:57] <cradek> skunkworks_wrk: just jog to 0,0,0 before exiting emc
[18:32:03] <SWPadnos_> I had thought that the axis positions were written to the parameter file at startup/shutdown, but they're not
[18:32:10] <cradek> skunkworks_wrk: I do that all the time (I also home "by eye")
[18:32:55] <SWPadnos_> well - read at startup - but you get the idea ;)
[18:33:32] <skunkworks_wrk> sometimes 0,0,0 is outside the machine envelope - (granted there are ways around that also)
[18:33:35] <cradek> no, just the offsets
[18:33:50] <cradek> you can jog to 0,0,0 in your relative coord system then
[18:34:09] <jepler> ...patience...
[18:34:10] <jepler> ...patience...
[18:34:13] <jepler> oops
[18:34:16] <cradek> ?
[18:34:26] <cradek> no, wait, that won't work, you need to go to absolute 0,0,0
[18:34:34] <jepler> message printed by building the BOOST C++ library
[18:34:44] <SWPadnos_> heh ;)
[18:35:28] <jepler> and it was printed twice
[18:35:55] <SWPadnos_> in a row, or after an appropriately long pause?
[18:36:59] <cradek> skunkworks_wrk: I can't see any reason to have absolute 0,0,0 where you can't jog to it
[18:37:24] <cradek> skunkworks_wrk: the abs machine coords are arbitrary - you can set 0 to be the center of travel for instance
[18:37:41] <SWPadnos_> if you're working on a part that's larger than your work envelope, it could be useful
[18:37:47] <SWPadnos_> though you'd have other issues
[18:37:54] <cradek> that's what part offsets are for
[18:37:58] <cradek> relative coordinates
[18:38:00] <skunkworks_wrk> sorry - I am still in the turbocnc state of mind. g92 would reset the master coardiance system - not being able to go back to "master"
[18:38:22] <cradek> oh, never used turbocnc
[18:38:30] <skunkworks_wrk> So yes - I could go back to the original 0,0,0
[18:38:41] <SWPadnos_> it's Tom Hubin's favorite (and the reason he posts stuf on CCED about emc not being usable)
[18:39:04] <cradek> SWPadnos_: huh?
[18:39:24] <SWPadnos_> are you subscribed to CAD_CAM_EDM_DRO?
[18:39:29] <SWPadnos_> yahoo group
[18:39:32] <cradek> no
[18:39:41] <SWPadnos_> ah - then you wouldn't have seen
[18:49:55] <Jymmm> anyone know apx pricing on 24" x 24" x 0.375" 6061 ?
[18:50:17] <Jymmm> or even .250"
[18:50:33] <Jymmm> $20? $40? $80 ?
[18:51:16] <SWPadnos_> boiullion price is around $1.50/pound, I think, and you get ~9 cubic inches per pound
[18:53:46] <SWPadnos_> $193.25 for 24x24x3/8 sheet at MSC
[18:54:09] <alex_joni> evening all
[18:54:18] <Jymmm> Hmmmm ouch. is that mostly due to size or specs?
[18:54:23] <SWPadnos_> hi Alex
[18:54:30] <SWPadnos_> how's the cold?
[18:54:36] <Jymmm> hi alex_joni
[18:54:59] <SWPadnos_> that's for plates, so they're probably more precisely made
[18:55:07] <Jymmm> ah, ok
[18:55:12] <SWPadnos_> the cost for .25 sheet (24x24) is $114.85
[18:55:13] <alex_joni> SWPadnos_: very bad :(
[18:55:18] <SWPadnos_> bummer
[18:55:47] <SWPadnos_> $130.79 for the equivalent plate
[18:55:53] <SWPadnos_> so not too much difference
[18:55:57] <alex_joni> SWPadnos_: fever & all
[18:56:03] <Jymmm> okey dockey, thanks.
[18:56:24] <SWPadnos_> there are better places to get metals though
[18:56:48] <Jymmm> Yeash, just needed a rought idea is all.
[19:02:06] <SWPadnos_> there's a lot of stuff in boost
[19:12:46] <Jymmm> boost?
[19:17:02] <jepler> Jymmm: this terrible, complicated C++ library
[19:17:12] <alex_joni> hi jeff
[19:17:22] <Jymmm> jepler ah, ok.
[19:17:49] <jepler> Jymmm: imagine something like the C++ STL but written by 100 people who each feel they need to prove they're as clever as Bjarne Stroustrup.
[19:18:07] <Jymmm> jepler: Oh, you mean microsoft developers?
[19:18:49] <skunkworks_emc2> I am here http://axis.unpy.net/index.cgi/installing for emc2 - I says to unpack axis in tthe axis directory - where is the axis directory at? Where should it be? in the emc2 directory?
[19:19:18] <cradek> no, you untar it wherever you want
[19:19:29] <cradek> that creates the axis directory, and you enter it to build and install
[19:19:33] <jepler> alex_joni: hi
[19:19:42] <alex_joni> how are you guys?
[19:19:44] <cradek> alex_joni: hi! didn't see you there
[19:19:55] <alex_joni> I'm small..in a corner
[19:20:13] <cradek> alex_joni: would you make an axis bug tracker category? or make me an admin so I can do it?
[19:20:25] <alex_joni> on SF?
[19:20:32] <cradek> yes
[19:20:41] <alex_joni> sure, one thing before that :)
[19:20:42] <cradek> I think jeff and I agreed to do that a while back, but then forgot
[19:20:49] <alex_joni> move it in CVS :)
[19:20:55] <alex_joni> kidding.. doing that now
[19:21:07] <cradek> thank you
[19:21:21] <alex_joni> did you talk to jeff about AXIS & SF.CVS?
[19:21:30] <cradek> no
[19:21:33] <cradek> I'm not even ready yet
[19:21:49] <cradek> after this release cycle I think we might want to talk about it.
[19:21:58] <alex_joni> ok
[19:45:32] <skunkworks_wrk> - don't know how I did it but axis is running the penguin. Thanks - that interface looks nice.
[19:45:59] <alex_joni> nice to hear that
[19:46:09] <alex_joni> any particular problems during installing it?
[19:46:37] <skunkworks_wrk> I was using the wiki instruction and the instruction on axis's website.
[19:46:38] <alex_joni> cradek: still around?
[19:50:05] <skunkworks_wrk> God - I don't know exactly what I did but the direction on axis's site didn't work - I had to install python first with the direction on wiki's site. Then the command on wikis site to install axis (python2.3 setup.py install) didn't work - but the command on axises site did. It could be all me though ;)
[19:51:20] <alex_joni> skunkworks_wrk: glad you got it working though
[20:06:10] <cradek> I'm back now
[20:06:24] <cradek> the wiki instructions are sometimes out of date
[20:06:32] <cradek> please update them if they are wrong and you know better!
[20:06:33] <Jymmm> Jymmm is now known as Red70sShow
[20:06:33] <Red70sShow> Red70sShow is now known as Jymmm
[20:07:05] <skunkworks_wrk> I would have to do it a few more times to figure out what I did ;)
[20:07:26] <SWPadnos_> the hard part is done - making sure you have all the necessary software installed in the first place
[20:07:52] <skunkworks_wrk> very nice job - I like it. I was running the penguin with it.
[20:07:58] <SWPadnos_> from now on, it'll be as easy as `env EMCROOT=/path/to/emc python setup.py install`
[20:08:14] <skunkworks_wrk> That is what I figured
[20:08:20] <SWPadnos_> ;)
[20:09:46] <skunkworks_wrk> I think there was a few commands that needed to be run sudo - but like I said - I would have to do it again to figure out what I did.
[20:10:28] <skunkworks_wrk> * not a linux person
[20:10:39] <skunkworks_wrk> yet
[20:10:53] <SWPadnos_> you're working on it - that's what count
[20:10:57] <SWPadnos_> counts
[20:10:59] <alex_joni> skunkworks_wrk: you're getting there
[20:15:23] <alex_joni> hi martin
[20:36:56] <Imperator_> Hi Alex
[20:37:12] <Imperator_> quiet this evening
[20:37:17] <alex_joni> yes
[20:37:28] <skunkworks_wrk> anyone here that worked on the mazak conversion?
[20:38:16] <Imperator_> Alex and I are about 8000km away form that mazak machine :-)
[20:38:47] <alex_joni> only 8000?
[20:38:55] <alex_joni> I think a bit more ;)
[20:39:04] <skunkworks_wrk> ;) - I was wondering if you guys scrapped using the fanuc amps and servos because of the tach issue
[20:39:08] <Imperator_> :-)
[20:39:28] <Imperator_> thats no problem
[20:39:49] <Imperator_> but i read that the machine has no normal amps
[20:40:02] <alex_joni> skunkworks_wrk: you need to open your eyes for rayh or jmkasunich
[20:40:07] <Imperator_> the tachs are conected to the controller and not to the amp
[20:40:21] <alex_joni> or even fenn, or maybe SWPadnos_ (playing dead right now)
[20:40:34] <Imperator_> there is some good documentation on wiki and on the mailing list
[20:40:52] <SWPadnos_> I am dead
[20:41:21] <SWPadnos_> even though I'm only about 500 miles from the Mazak, I had nothing to do with the conversion (other than some discussions on IRC)
[20:41:30] <skunkworks_wrk> Ok - from what I read the fanuc servo amps needed velocity feedback in way of tach signal - while the fanuc servos had only encoders.
[20:42:18] <SWPadnos_> I think the problem was that the controller had to get the feedback, then synthesize something that the driver could use - or something like that
[20:42:39] <SWPadnos_> and the control didn't work, and had no documentation, so they couldn't use those amps
[20:42:51] <Imperator_> maybe frequency to voltage conversation (tacho simulation)
[20:43:16] <SWPadnos_> yeah - something like that, but without documentation or a working unit ;)
[20:43:25] <Imperator_> hm
[20:43:34] <Imperator_> difficult
[20:43:39] <SWPadnos_> makes it a little harder
[20:44:17] <djb_rh_> djb_rh_ is now known as djb
[20:51:40] <skunkworks_wrk> we where looking for some cheap servos and drives for our big mill - there sure is a lot of ge fanuc stuff on ebay
[20:51:59] <SWPadnos_> cheap is a relative term though ;)
[20:52:09] <skunkworks_wrk> I know - I know
[20:52:23] <skunkworks_wrk> I guess we are used to making junk work. ;)
[20:52:32] <alex_joni> SWPadnos_: cheap ;)
[20:52:44] <SWPadnos_> no - just my relatives ;)
[20:53:10] <alex_joni> not you swampy :P, the servos skunkworks_wrk's looking for
[20:53:46] <SWPadnos_> heh - I just know the prices for feanuc motors on ebay, and I wouldn't call most of them cheap
[20:54:20] <SWPadnos_> though I only search for the DC brush motors, not AC or BLDC
[20:59:12] <skunkworks_wrk> we want to replace the hydrolic servos - Now there is some torque ;)
[20:59:46] <SWPadnos_> indeed - hydraulics are pretty amazing (but big and messy)
[21:01:04] <skunkworks_wrk> I'll say - I am trying to think - I think when we where looking before they had 75ft-lbs of stall torque
[21:01:31] <SWPadnos_> that'll be a big servo
[21:04:42] <skunkworks_wrk> We figure we will have to put up with less. Not a big deal.
[21:04:50] <alex_joni> night all
[21:05:00] <SWPadnos_> night Alex
[21:06:18] <ValarQ> alex_joni: g'dnite
[23:10:30] <skunkworks_emc2> Xlib: extension "XFree86-DRI" missing on display ":0.0". I this normal for axis install
[23:10:34] <skunkworks_emc2> is
[23:10:56] <SWPadnos_> good question
[23:14:25] <SWPadnos_> I didn't get that error
[23:14:35] <SWPadnos_> either installing or running axis
[23:15:47] <skunkworks_emc2> I get that error in the terminal window when starting axis
[23:16:12] <skunkworks_emc2> it is right after the emcTaskInit: adding user-defined function ../nc_files/M101
[23:16:39] <SWPadnos_> does axis display, or does it bomb out?
[23:18:02] <SWPadnos_> what video card do you have in that machine?
[23:18:14] <Jymmm> Trident 8900
[23:18:23] <SWPadnos_> Tseng ET4000
[23:18:27] <Jymmm> Hercules
[23:18:37] <SWPadnos_> Cirrus Logic 5419
[23:18:39] <skunkworks> seems to start - first time it bombed out.. I think with axis I can't run as fast a period. I ran it back to .00005 and it came up and seems to work
[23:19:12] <SWPadnos_> axis is a bit more CPU hungry - I think it does more checking for status changes
[23:20:04] <skunkworks> I don't know what video is in the machine - will check
[23:36:19] <skunkworks> yah - something is not right. The cylinder is not a visable
[23:36:30] <skunkworks> The "tool"
[23:37:45] <SWPadnos_> well - DRI is an acceleration feature of X-windows, and you probably don't have it installed correctly
[23:37:58] <skunkworks> hey I had a hercules card a long time ago
[23:38:03] <SWPadnos_> or configured? (sorry - I can't be of much help there)
[23:39:23] <skunkworks> I guess I can go through it again - how can you tell the video card? it doesnt seem to be in "info center"
[23:44:23] <SWPadnos_> actually - try this first:
[23:44:39] <SWPadnos_> grep DRI /var/log/XFree86.0.log
[23:44:55] <SWPadnos_> tell me what that does
[23:46:11] <Jymmm> SWPadnos stuff.
[23:46:43] <skunkworks> no such file or directory - do I have to be in a root terminal?
[23:48:09] <SWPadnos_> you may need to be
[23:48:35] <SWPadnos_> it tells you if X tried to load DRI when it was last started
[23:49:01] <skunkworks> says (II) loading extenion xfree86-dri
[23:49:21] <SWPadnos_> ok - it thinks DRI is loading - that's probably a good sign
[23:49:23] <skunkworks> DRI
[23:50:52] <skunkworks> jees - it won't remember your last exited axis posision but it does remember the g92 offset ;)
[23:52:46] <jepler> skunkworks: that "DRI" error is harmless. It simply means that AXIS will fall back to slower "indirect" OpenGL rendering.
[23:53:12] <skunkworks> it seems to be running other than the taperd cylinder (tool) is not colored. black hole ;)
[23:53:31] <jepler> huh, I'm not familiar with that (mis)behavior
[23:54:41] <skunkworks> going to have to find a better video card? something that supports opengl? the machine at work that I was playing with worked just fine displaying the cutter
[23:56:04] <jepler> no, even if your card doesn't do accelerated OpenGL, it should still work just the same. Modern X servers all have software OpenGL. Though there may be some kind of bug, if the cone is black...
[23:58:10] <skunkworks_emc2> can you change the color some how?
[23:58:48] <skunkworks_emc2> just for sh$ts and Giggles ?
[23:59:53] <jepler> in scripts/axis.py, search for "def make_cone()". The line "glColor3f(.75,.75,.75)" is supposed to set the color to 75% grey. You might also try commenting out the line that says "glEnable(GL_LIGHTING)". After you edit that file, you need to "setup.py install" again.