Back
[01:07:55] <cradek> /usr/realtime-2.6.20.14-magma/include/rtai_lxrt.h:645: warning: ISO C90 forbids mixed declarations and code
[01:08:02] <cradek> strange - I don't remember seeing this before
[01:09:28] <SWPadnos> is C99 not being used?
[01:13:36] <cradek> seems so, it's just a warning
[01:14:14] <SWPadnos> I recently recompiled that kernel (the one in /experimental), and it performs much much worse than the one you compiled
[01:14:22] <cradek> ha
[01:14:31] <SWPadnos> I'm reasonably sure the only change I made was to add a couple of SATA chipsets and overall SATA support
[01:14:32] <cradek> fascinating
[01:14:42] <cradek> mine doesn't have sata? bizarre
[01:14:47] <SWPadnos> yeah, I thought so
[01:15:10] <SWPadnos> I'm not positive I used your config though, it may be jepler's
[01:15:13] <SWPadnos> for x64
[01:15:31] <cradek> # CONFIG_BLK_DEV_IDE_SATA is not set
[01:15:35] <cradek> well lookie at that
[01:15:41] <SWPadnos> well there you go
[01:15:42] <cradek> "works for me"
[01:15:44] <SWPadnos> heh
[01:15:47] <SWPadnos> old kool
[01:15:49] <SWPadnos> skool
[01:15:52] <cradek> scsi actually
[01:16:05] <SWPadnos> old expensive skool
[01:16:23] <cradek> old server class stuff, I have a small collection of it
[01:16:25] <SWPadnos> but still better on the server
[01:16:57] <SWPadnos> I do too, if you're interested in ~15 4G disks and a few (up to U160 even) that are 9, 18, or 36G
[01:17:35] <cradek> I was making do with 4 and 9 gig disks, until jmk gave me a stack of 18s
[01:17:40] <SWPadnos> heh
[01:17:49] <cradek> 9 is still plenty for me, 4 is slightly tight now
[01:17:51] <SWPadnos> but are they Ultra SCSI? that's the question
[01:18:12] <SWPadnos> I think I have 4 36G drives, in a hot-swap RAID cage
[01:18:22] <cradek> /dev/sda1 8356868 5454584 2477768 69% /
[01:18:33] <cradek> actually this machine has two nines (came in it) and only one is even formatted
[01:18:34] <SWPadnos> and du -h says? ;)
[01:18:40] <cradek> 9G
[01:19:10] <SWPadnos> or df -h. I like that "-human readable output" :)
[01:19:28] <cradek> as long as I keep all my porn together, only one machine needs a big disk
[01:19:36] <SWPadnos> true enough
[01:19:44] <cradek> errr, documents
[01:19:49] <SWPadnos> so many people forget that you only need one copy
[01:19:54] <cradek> (kernel source trees)
[01:20:06] <SWPadnos> of course, that's what I assumed you meant
[01:20:25] <cradek> wow, I can just pick L297 in stepconf instead of trying to look up the timings and stuff
[01:20:33] <SWPadnos> heh
[01:23:06] <cradek> hm jepler said a while back that step outputs should be inverted for L297. I wonder if he intended for stepconf to 'know' that
[01:23:30] <SWPadnos> duh - could be
[01:23:58] <jepler> no, it doesn't automatically set the inverts
[01:24:08] <jepler> there's an XXX comment in the source about it though
[01:25:03] <cradek> hi
[01:27:12] <cradek> it happily accepts microstepping=0, but says 0.0Hz max pulse rate
[01:27:34] <SWPadnos> it seems that 1 would be a better minimum for that field
[01:28:07] <cradek> yargh
[01:28:25] <cradek> when I pushed the jog button in "X axis test" the spindle came on full speed
[01:28:33] <cradek> scared the living crap out of me
[01:28:50] <jepler> really
[01:29:01] <cradek> and it doesn't jog...
[01:29:19] <jepler> check your pinout?
[01:29:33] <cradek> 5 bit IN FALSE parport.0.pin-02-out <== dir
[01:29:33] <cradek> 5 bit IN FALSE parport.0.pin-03-out <== step
[01:29:46] <cradek> amps are enabled...
[01:30:05] <jepler> anything odd-looking in halcmd show?
[01:30:13] <jepler> I forget what it connects with signals and what it just 'setp's
[01:30:23] <cradek> 5 bit IN FALSE parport.0.pin-14-out
[01:30:33] <jepler> but it specifically does some sets of amp-enable and estop-out, iirc
[01:30:35] <cradek> this is spindle-fwd not
[01:30:46] <cradek> (I did turn on the "not" checkbox)
[01:30:51] <jepler> ahm, hmm
[01:31:11] <jepler> so probably all the 'invert's should be set when testing, not just those for the pins that are thought to be "relevant"?
[01:31:33] <cradek> I guess so
[01:31:52] <cradek> I'm not sure why the spindle doesn't come on normally... that pin must be high
[01:33:28] <cradek> I hit "run" and it stuck down. I get a few tiny steps now and then
[01:34:13] <jepler> run is a toggle .. but it should be moving by the distance you specified .. assuming you set your scale right
[01:34:53] <jepler> you click run again to stop running and return to the center position
[01:35:00] <cradek> oh I couldn't tell it was a toggle
[01:35:21] <cradek> my scale was off by a factor of 2 (I forgot half stepping) but that doesn't fix it of course
[01:35:45] <jepler> 2 is dir and 3 is step?
[01:36:13] <cradek> yes I cheated and looked at my old hal file
[01:36:25] <jepler> try not inverting step if you had checked it in the pinout page?
[01:36:54] <cradek> that fixes it
[01:37:05] <jepler> OK I guess my understanding of the L297 must be wrong then
[01:37:49] <cradek> the jog and "run" move at different velocities
[01:38:22] <jepler> which is faster?
[01:38:53] <cradek> run is much faster
[01:39:05] <jepler> any sense of which is the requested speed?
[01:39:14] <jepler> (if either one is :-P)
[01:39:24] <cradek> I think run is
[01:39:41] <cradek> because if I set vel to 1.0 on the test screen, jog still jogs but run stalls
[01:39:51] <cradek> (my max vel is actually more like .6)
[01:41:06] <jepler> * jepler hmms
[01:41:24] <jepler> position_cmd = position_fb - maxvel * fperiod;
[01:41:30] <jepler> here's "jog" in that dialog: ^^
[01:41:33] <jepler> (running in realtime of course)
[01:41:47] <jepler> I expected that to accelerate to maxvel but maybe it doesn't for some reason
[01:42:09] <SWPadnos> what's the stepgen accel set to?
[01:42:19] <jepler> whatever is entered on that dialog
[01:42:22] <SWPadnos> ah
[01:43:12] <SWPadnos> in theory, you should be able to set position_cmd to the target position, and stepgen should obey the accel/vel limits you've set
[01:43:27] <SWPadnos> oh - jog, right
[01:43:59] <cradek> the live test is extremely cool
[01:45:23] <cradek> hmm these questions are hard for the rotary
[01:46:20] <jepler> what questions should I ask instead?
[01:46:34] <cradek> I'm not sure yet
[01:46:36] <jepler> OK
[01:46:38] <jepler> me either
[01:46:40] <cradek> I know my scale is 80, I don't know where that comes from
[01:47:15] <cradek> it might be nice if the calculated scale would be shown in the info area at the bottom
[01:47:16] <SWPadnos> I think only the gear ratio question(s) need to change
[01:47:33] <cradek> it says leadscrew pitch (rev/degree)
[01:47:54] <SWPadnos> yeah - that should probably be "turns/rev" or similar
[01:47:56] <cradek> I think that answer is always going to be < 1
[01:47:58] <SWPadnos> or degrees/rev
[01:48:39] <SWPadnos> and there are one or two common ones also - 90 turns/rev or maybe 60
[01:48:44] <cradek> I think it's 0.2 for this one
[01:48:54] <SWPadnos> (actually, both of mine are 4 degrees per turn of the handle)
[01:49:25] <cradek> I think this one is 5
[01:49:28] <cradek> my big table is 4
[01:49:35] <cradek> I have a third one ... somewhere
[01:49:38] <cradek> (sherline)
[01:50:09] <SWPadnos> interesting. both my 4" cheezo eBay chinese one and my nice Troyke 12" quality eBay one are 90 turns/rev
[01:52:47] <cradek> hm, can't find the other one
[01:53:24] <cradek> jepler: maybe the reciprocal degrees/rev is what you want here
[01:53:56] <jepler> what about the pulley question for rotary?
[01:54:07] <jepler> I think I can easily do degree/rev for the 'leadscrew' question
[01:54:13] <SWPadnos> you still need that, though I suspect direct drive is more common on a rotary
[01:54:17] <cradek> I have not seen a rotary table with pulleys, but it seems possible
[01:54:32] <SWPadnos> you can still have a ratio between the motor and the crank
[01:54:50] <SWPadnos> there's an extra one between the crank and the table, which is analogous to TPI on a leadscrew
[01:55:00] <cradek> SWPadnos: 360 degrees per second vel default seems pretty high, what do you think?
[01:55:06] <SWPadnos> heh
[01:55:15] <SWPadnos> only if it's a lathe ;)
[01:55:37] <cradek> +- 0.5 degrees is not enough test area by default
[01:56:11] <jepler> by the way I love that you're giving me this feedback
[01:56:24] <SWPadnos> * SWPadnos hopes that wasn't sarcasm :)
[01:56:39] <cradek> great, I am glad you see it as constructive and not bitching
[01:56:47] <SWPadnos> err - that's what I meant
[01:56:56] <SWPadnos> * SWPadnos nominates chris for chairperson again
[01:57:04] <cradek> I am not getting good motion even though I think (?) the numbers are right
[01:57:14] <cradek> is there any way to see the calculated scale?
[01:57:20] <SWPadnos> UTSL
[01:57:36] <cradek> (the top four numbers multiplied together?)
[01:57:50] <jepler> cradek: If I don't add that (display computed SCALE) tonight bug me again
[01:58:00] <cradek> sure
[01:58:08] <jepler> what do you think are good default travels for axis test? 1in, 25mm, ??deg?
[01:58:40] <SWPadnos> I'd say (of fthe cuff) +/- 10 degrees or so
[01:58:55] <cradek> +-.5 in +-10mm and +-30deg?
[01:59:13] <SWPadnos> or that
[01:59:27] <cradek> a rotary is never going to hurt anything
[01:59:43] <SWPadnos> that's true, though it's the reversals you want to test
[01:59:49] <cradek> oh travel for rotary -4..+4 is not enough
[02:00:01] <cradek> true, +-10 is better
[02:00:04] <SWPadnos> well, and top vel as well, so longer is fine too
[02:00:07] <jepler> cruise and accel are both important
[02:00:09] <cradek> err +-10 deg
[02:00:22] <cradek> something like that, just more than .5
[02:00:24] <SWPadnos> I just think a 60 degree excursion is probably too long
[02:00:31] <cradek> I agree now
[02:00:34] <SWPadnos> +/- 15 or 20 then
[02:01:13] <jepler> let me point out that the user is free to select the appropriate amount
[02:01:43] <SWPadnos> sure. 10 or 15 (or 20) should be ok as a default
[02:04:07] <cradek> stepconf.hal:5: Can't find module 'probe_parport' in /home/chris/emc2.trunk/rtlib
[02:04:42] <cradek> after fixing that...
[02:04:42] <cradek> INIFILE: ERR_CONVERSION, section=TRAJ, tag=ANGULAR_UNITS, num=1, lineNo=41
[02:04:42] <cradek> emc/task/emctaskmain.cc 2606: can't initialize motion
[02:05:36] <cradek> I have two [TRAJ]ANGULAR_UNITS, one is =degrees and one is =degree
[02:05:53] <jepler> hum which is right?
[02:05:59] <cradek> degree
[02:06:17] <jepler> what was the problem with probe_parport?
[02:06:26] <cradek> I just commented it
[02:06:52] <cradek> it's not built??
[02:06:58] <jepler> * jepler looks puzzled
[02:07:13] <cradek> not here anyway
[02:07:18] <jepler> ifneq "$(filter 2.6.%, $(kernelvers))" ""
[02:07:26] <cradek> ohhhhh
[02:07:32] <jepler> Makefile.inc:kernelvers = 2.6.15-magma
[02:07:39] <jepler> what are you running on, something exotic?
[02:07:59] <cradek> kernelvers =
[02:08:07] <cradek> Linux emc 2.6.20.14-magma #1 SMP Fri Jun 22 22:04:24 CDT 2007 i686 GNU/Linux
[02:09:27] <jepler> let's forget about that for the moment...
[02:09:35] <cradek> right
[02:09:43] <cradek> ok with those two fixes emc runs, but I have no motion ... checking
[02:10:28] <cradek> nothing is writing to the sig amplifier-enable
[02:10:44] <jepler> ah, my machine doesn't actually have an amplifier-enable
[02:11:32] <cradek> also I have no spindle control (and the widgets are not there in AXIS)
[02:11:50] <cradek> nothing is writing to the sig spindle-cw
[02:12:14] <jepler> OK I'll look at both these things right after this commit
[02:12:58] <cradek> ok I'll keep typing, read later
[02:13:04] <cradek> something is wrong with the A axis test: even though it has the right scale (verified in the ini afterward) the jogging and run button do not give correct motion, it's all stuttery
[02:17:06] <cradek> I'm not getting correct A motion in emc either
[02:18:47] <jepler> OK did I botch the scale calculation or something?
[02:18:55] <cradek> no the scale is right
[02:19:00] <cradek> I haven't found the problem yet
[02:19:21] <jepler> try setting stepgen velocity limit
[02:19:25] <cradek> AXIS velocity display seems right...
[02:19:29] <jepler> hm except that was set for the jog test
[02:19:48] <cradek> 7 float RW 0 stepgen.3.maxvel
[02:20:02] <cradek> oh they all say that
[02:20:22] <SWPadnos> maxvel should be able to be set to 0
[02:20:32] <SWPadnos> instead of dealing with some arbitrary overhead
[02:20:34] <jepler> yes stepconf explicitly doesn't set stepgen maxvels
[02:20:54] <SWPadnos> so, hiw can I run stepconf?
[02:20:55] <SWPadnos> how
[02:21:03] <cradek> SWPadnos: "stepconf"
[02:21:13] <SWPadnos> well, that doesn't seem to do it for me :)
[02:21:17] <cradek> . emc-environment
[02:21:50] <SWPadnos> already had been done
[02:21:58] <SWPadnos> let me try in a different shell
[02:22:20] <SWPadnos> hmmm
[02:22:39] <SWPadnos> ok - that worked. the emc-environment should tell you that it only needs to be run once, but it shouldn't exit
[02:22:47] <jepler> cradek: by the way you can regenerate the ini/hal from the .stepconf with: stepconf -r my-mill.stepconf
[02:23:56] <jepler> hm it doesn't exactly do the right thing because it doesn't rewrite the .stepconf with the new md5s
[02:24:04] <jepler> emc/task/emctaskmain.cc 2606: can't initialize motion
[02:24:07] <jepler> now what?
[02:24:14] <jepler> (that's the only error)
[02:27:09] <dmwaters> {global notice} Hi all, looks like this last split was do to a glitch in the eu hub's network. If there are any more problems, i may need to do some emergency rehubbing.
[02:27:11] <cradek> http://timeguy.com/cradek-files/emc/stepgenconf.txt
[02:27:30] <cradek> I don't see anything substantial different
[02:29:02] <cradek> pin-09-out-reset (astep) is 1...
[02:29:03] <jepler> what about the [AXIS_3] stanzas?
[02:29:18] <jepler> should it be? did you select it in the GUI?
[02:29:34] <cradek> I didn't see anywhere to select doublestep
[02:29:39] <cradek> it must be the default
[02:29:48] <jepler> it's the only option
[02:30:00] <cradek> I don't understand the question then
[02:30:08] <jepler> oh sorry
[02:30:10] <jepler> I read -out-invert
[02:30:23] <cradek> oh ok
[02:30:31] <cradek> it's not inverted, it matches X,Y,Z
[02:30:43] <SWPadnos> are those u32s printed in hex or decimal?
[02:30:49] <jepler> hex
[02:30:54] <jepler> I think
[02:30:56] <SWPadnos> that's a friggin huge steplen then
[02:31:01] <cradek> yes hex
[02:31:19] <cradek> they are all that big
[02:31:20] <SWPadnos> and dirhold and dirsetup
[02:31:33] <SWPadnos> what's the BASE_PERIOD?
[02:31:37] <jepler> that's probably 1 period
[02:31:44] <cradek> base is 100000
[02:32:02] <jepler> urmmmm
[02:32:08] <SWPadnos> slightly under BASE
[02:32:51] <jepler> it's rounded up to multiples of period by stepgen
[02:32:52] <SWPadnos> 72 under - is that a significant number?
[02:32:58] <SWPadnos> ok
[02:32:59] <jepler> so it's one actual period
[02:33:06] <SWPadnos> ok
[02:33:25] <jepler> stepconf tries to make the period as big as possible
[02:33:31] <jepler> to a limit 100000ns
[02:33:49] <SWPadnos> but steplen shouldn't be high with doublestep - it should be as low as possible
[02:33:56] <SWPadnos> since it's a busy-wait
[02:34:11] <SWPadnos> then again, I didn't see the rewet-time param
[02:34:14] <SWPadnos> reset
[02:34:21] <jepler> reset-time is small, steplen is "one period"
[02:34:38] <jepler> so that at max speed step (the hal signal) is true every period but the parport signal is asserted only a short time
[02:34:47] <jepler> cradek: change PERIOD in the generated inifile?
[02:34:50] <SWPadnos> steplen should be able to be 1
[02:34:56] <SWPadnos> and stepspace 0
[02:35:06] <jepler> print >>file, "setp stepgen.%d.steplen 1" % num
[02:35:06] <jepler> print >>file, "setp stepgen.%d.stepspace 0" % num
[02:35:06] <jepler> print >>file, "setp stepgen.%d.dirhold %d" % (num, self.dirhold + lat)
[02:35:10] <jepler> print >>file, "setp stepgen.%d.dirsetup %d" % (num, self.dirsetup + lat)
[02:35:13] <jepler> that's exactly what's written
[02:35:20] <jepler> but stepgen rounds that up to "one period" when it runs
[02:35:24] <SWPadnos> ah - nevermind. you're saying that stepgen makes it one period - got it
[02:35:40] <SWPadnos> (sorry - 100-hour work weeks are catching up to me)
[02:35:41] <cradek> setting period to 30000 (what it is in my old config) makes no difference in A motion
[02:35:44] <jepler> hah
[02:35:52] <jepler> time for me to call it quits for the night
[02:35:57] <jepler> cradek: thanks for all the testing
[02:36:10] <SWPadnos> see you later then. stepconf looks nice, good job
[02:36:21] <cradek> yes I think it's going to be really great for users
[02:36:22] <jepler> hope we can get A figured out soon
[02:37:03] <cradek> wonder if it's a doublestep thing
[02:37:12] <cradek> (not sure how it could be)
[02:37:25] <SWPadnos> do you have the same type of driver on all axes?
[02:37:29] <cradek> yes
[02:37:32] <SWPadnos> ok
[02:38:05] <cradek> I should probably get out the scope, it must be very apparent
[02:38:28] <cradek> the rotary axis sounds like it has a bunch of gravel in it and it jerks around randomly
[02:38:58] <SWPadnos> hmmm
[02:39:40] <SWPadnos> you could try a siggen (sinewave) -> stepgen (doublestep) HAL setup and see if it does the same thing
[02:41:45] <cradek> actually I'm feeling pretty finshed for the night too
[02:41:51] <cradek> fished?
[02:43:25] <SWPadnos> fish-shed
[07:41:24] <alex_joni> jepler: any idea about this?
http://5128.rapidforum.com/topic=115670985798
[07:43:01] <alex_joni> jepler: I put it on pastebin, in case you can't read that forum
http://pastebin.ca/704285
[12:20:29] <jepler> alex_joni: no, no ideas.
[12:33:21] <alex_joni> should I tell him to send you the pgm?
[12:41:16] <alex_joni> heh, another guy suggested the following:
[12:41:28] <alex_joni> env REVERSE_VIDEO=x VARIABLE_SIZE=X stippler 'Pfad der.pgmDatei'/Rebekka2.pgm 3000
[12:41:47] <alex_joni> 'Pfad der.pgmDatei' = path/to/file
[12:58:03] <jepler> looks like it probably will segfault rather than giving a useful error message if the named image doesn't exist
[12:59:21] <jepler> there are probably a lot of things that will make it segfault, though
[13:03:03] <alex_joni> bbl
[13:11:40] <jepler> verified that it segfaults if the file doesn't exist
[13:12:33] <jepler> with an image that is too large, it also segfaults but a bit later -- after printing more lines of output
[13:44:00] <cradek> I should have tried my old ini file with the new hal file
[13:44:17] <cradek> and/or the other way around
[13:46:36] <jepler> they won't quite be compatible, the first thing comes to mind is that stepconf uses [AXIS_n]SCALE instead of INPUT_SCALE but there's bound to be more
[13:46:49] <cradek> oh, right
[13:47:04] <cradek> it's puzzling why A in particular is broken
[13:47:29] <jepler> indeed
[13:49:32] <jepler> did you ever put up the [AXIS_3] stanza ? I only remember seeing the 'show param' for the axis.3 stepgen
[13:49:37] <jepler> er, stepgen.3 I mean
[13:49:47] <cradek> let me see if the machine is on
[13:50:29] <cradek> http://timeguy.com/cradek-files/emc/stepconf.tar.gz
[13:50:55] <cradek> the config is slightly edited, but you said you can regenerate it from the .stepconf somehow
[13:51:57] <cradek> in AXIS_3 I increased the limits and the ferror
[13:52:15] <cradek> it was .01 degrees which is less than a step, I thought that might be the problem
[14:01:04] <jepler> that wouldn't affect the stepconf axis test though
[14:01:34] <cradek> true
[14:01:54] <cradek> did I make it clear that the motion from emc is bad too?
[14:02:44] <jepler> yes
[14:21:23] <jepler> 577 /* assemble output byte for data port from 8 source variables */
[14:22:34] <jepler> hi SWPadnos
[14:22:44] <SWPadnos> hi
[14:22:50] <cradek> I don't see anything obvious wrong...
[14:23:46] <SWPadnos> oh, I can come back later then ;)
[14:24:12] <jepler> signed vs unsigned problem?
[14:24:46] <jepler> I notice outdata and mask are ints; I made reset_mask and reset_val locals 'unsigned char'
[14:25:41] <jepler> or the reverse
[14:25:46] <jepler> I'm not sure what I'm saying
[14:30:25] <skunkworks> doublefreq problems?
[14:32:17] <skunkworks> It was working fine for me I think... I actually cut the donut on some plywood at around 100ipm :)
[14:33:26] <skunkworks> good times
[14:33:59] <jepler> skunkworks: cradek had trouble with a step signal on pin 9, which happens to be the "last" pin of the data port...
[14:34:10] <skunkworks> ah - ok
[14:34:25] <skunkworks> I was not using pin 9 I am sure. only 2,3,4,5,6,7
[14:34:42] <jepler> cradek: you could also try decreasing BASE_PERIOD until the max step rate is less than one per two periods .. if that clears up the A-axis problem then it points at doublestep..
[14:34:50] <jepler> cutting it in half should do
[14:35:28] <cradek> when I decreased base period to 30000 the motion got somewhat better
[14:35:50] <cradek> it's got to be a doublestep high bit problem
[14:37:56] <jepler> bu....
[14:37:57] <jepler> t
[14:38:51] <jepler> the written base_period is 100000, but the max step rate of A is 50deg/sec * 80 SCALE = 4000Hz
[14:39:07] <jepler> seems like you're guaranteed spaces between steps anyway, since the max step rate is less than one per two base_period
[14:40:41] <cradek> oh, hm
[14:40:50] <cradek> maybe the dir bit is going crazy then
[14:40:57] <cradek> (need to scope it obviously)
[14:44:23] <SWPadnos> does it act differently depending on the direction of rotation?
[14:44:44] <cradek> I don't think so
[14:45:04] <SWPadnos> that would lead me to believe that direction changes aren't an issue
[14:45:23] <SWPadnos> I'd assume that the dir pins would have a preference for high or low if there were a problem
[14:54:51] <SWPadnos> man. you know you're losing it when you can't remember if argc or argv is first
[14:55:07] <cradek> soon you'll be a java programmer
[14:55:16] <jepler> c comes before v
[14:55:27] <SWPadnos> I guess that's a natural progression. I'm a java drinker now
[14:55:54] <SWPadnos> jepler, so it does :)
[15:00:00] <skunkworks> and for a little break from all this seriousness
http://youtube.com/watch?v=wA69vjmI1s8
[15:02:11] <jepler> but .. I have no sense of humor
[15:03:59] <skunkworks> heh - thats funny. see - there you go.
[15:09:42] <skunkworks> http://www.cnczone.com/forums/showthread.php?t=43872
[15:10:12] <skunkworks> a bit over my head. (which doesn't take too much)
[15:13:03] <SWPadnos> hmmm. interesting point
[15:13:38] <SWPadnos> oh, and funny Star Wars videos :)
[15:13:58] <skunkworks> I like the cantina one.
[15:14:03] <SWPadnos> yeah
[15:14:18] <SWPadnos> and the "oops I dropped the lightsaber" one
[15:14:25] <skunkworks> heh - yah
[15:15:31] <skunkworks> although I have the 'cantina' music in my head now.
[15:15:36] <SWPadnos> heh
[15:15:42] <SWPadnos> at leat it's a good tune
[15:15:45] <SWPadnos> least
[15:16:19] <skunkworks> it annoys the coworkers.
[15:16:33] <SWPadnos> well, I don't think there's an answer for the jogging question
[15:16:56] <cradek> yeah, all of hal is in joint space
[15:16:58] <SWPadnos> in HAL, it's all joints
[15:17:20] <cradek> hmm, maybe halui does jogging
[15:17:34] <SWPadnos> motion could switch between the two, but I'm not sure I like the idea
[15:17:58] <SWPadnos> halui wouldn't work well with jogwheels
[15:18:04] <SWPadnos> (which is why it's in motion now)
[15:18:08] <cradek> right
[15:18:10] <cradek> but he says joypad
[15:18:13] <SWPadnos> sure
[15:18:20] <cradek> it does work with that I think
[15:18:28] <cradek> yes halui does teleop (or at least some of the code is there)
[15:24:04] <fenn> isnt teleop a different nml command than JOG..*?
[15:27:22] <skunkworks> what does teleop stand for?
[15:27:50] <SWPadnos> it should be "remote operation" :)
[15:28:18] <SWPadnos> as I recall, it's the opposite of what you'd think though
[15:29:26] <skunkworks> telephone operation? (remote)
[15:29:48] <SWPadnos> "tele phone" means "distant sound" :)
[15:30:10] <SWPadnos> "tele op(eration)" would be distant operation
[15:30:22] <skunkworks> ah - ok
[15:30:37] <SWPadnos> tele scope - distant vision ... :)
[15:30:48] <SWPadnos> television too ;)
[15:31:04] <SWPadnos> err - scope would be more like sight, so that's more like distant sight I guess
[15:31:46] <SWPadnos> but to answer your question, I don't remember what teleop stands for, I only remember that it seemed to be backwards to me :)
[15:31:58] <fenn> hrm i think puma kinematics is bad
[15:32:15] <fenn> teleop is just jogging with kinematics on
[15:32:21] <fenn> imagine you're moving a hexapod crane around
[15:32:54] <SWPadnos> so it's world coordinate jogging
[15:33:14] <SWPadnos> ok, then it may make sense - it is remote operation of the machine (in world space)
[15:33:21] <fenn> i'm not sure about the exact meaning of world/machine coords, but i thought machine coordinates was also cartesian space
[15:33:37] <SWPadnos> err - damfino
[15:33:49] <skunkworks> could there be pins from 'motion' or whatever for hal to do this?
[15:34:02] <SWPadnos> I remember talking with Fred about it, and thinking it was backwards. that could be from lack of caffeine or something else though
[15:34:06] <fenn> the difference is for example you can rotate the machine in world coordinates if it's on wheels (kind pointless in emc tho)
[15:35:35] <fenn> oh, i'm wrong. nevermind
[15:43:32] <fenn> axis doesnt display world coordinates when you switch to world mode
[15:43:52] <cradek> yes it does
[15:45:08] <cradek> (unless it broke recently)
[15:46:33] <fenn> File "/pub/emc/emc2/bin/axis", line 3112, in jog_off_actual
[15:46:33] <fenn> c.teleop_vector(*jogging)
[15:46:34] <fenn> TypeError: function takes at most 6 arguments (9 given
[15:47:15] <SWPadnos> I was just noticing that teleop hasn't been updated for 9 axes
[15:47:36] <fenn> teleop doesnt make sense with 9 axes really
[15:48:14] <fenn> the function should only ever receive XYZABC
[15:49:57] <fenn> come on you stubborn robot
[15:50:36] <skunkworks> are you talking to cradek? ;)
[15:53:57] <fenn> jogging in teleop mode on the puma seems to move more than one axis at once, but it goes in non-straight lines
[15:54:24] <fenn> and then it shoots off to infinity and the joints read "nan"
[15:57:58] <fenn> mdi has the same problems but it errors 'move would exceed limits' instead of going to infinity
[16:00:30] <jepler> I think the puma visualization never quite matched the kinematics
[16:00:37] <jepler> I'm not entirely sure however
[16:08:52] <fenn> right the parameters are just off
[16:09:39] <fenn> i thought the visualization got the parameters from the hal file, silly me :)
[16:13:27] <fenn> still, the "nan" stuff is an emc error
[16:13:36] <jepler> or maybe a kinematics bug
[16:13:52] <fenn> is kinematics not considered "emc" anymore?
[19:09:35] <fenn> setp halui.mode.* doesnt seem to do anything?
[19:13:50] <fenn> no, it does something, its just confused
[19:14:41] <SWPadnos> what do you expect it to do?
[19:15:04] <SWPadnos> (or is there more that you didn't type here?)
[19:15:31] <fenn> i expect it to change the mode :) and show halui.mode.is-* for whatever the current mode is
[19:15:46] <SWPadnos> ok, you typed setp ...
[19:16:30] <fenn> setp halui.mode.mdi 1
[19:16:39] <fenn> ugh lemme restart emc
[19:16:41] <SWPadnos> heh
[19:19:40] <fenn> it messes up when halui.mode.mdi is TRUE and you click 'manual' in axis, but that's to be expected
[19:20:44] <SWPadnos> I think those halui inputs are supposed to be momentary
[19:20:49] <fenn> yes
[19:23:34] <fenn> i cant figure out what mode i'm supposed to be in to enable teleop mode
[19:24:32] <cradek> emc starts in joint mode. you home the joints then switch to teleop
[19:24:49] <fenn> joint mode?
[19:24:55] <fenn> is that a traj mode or a task mode?
[19:25:38] <cradek> too many kinds of modes
[19:25:48] <fenn> i keep getting "cant do that (EMC_TRAJ_SET_MODE) in mdi mode" or auto or manual
[19:25:51] <cradek> when you start emc do you see joint numbers 0,1,2 instead of x,y,z?
[19:26:08] <fenn> well, i'm using puma.ini
[19:26:32] <fenn> yes it shows 0 1 2 3 4 5
[19:27:06] <cradek> ok home them all, then switch to world mode (view menu, or $)
[19:27:50] <fenn> suppose i should explain what i'm doing
[19:28:03] <fenn> trying to add a teleop-mode pin to halui
[19:28:25] <fenn> so i copied all the code for halui.mode.mdi and halui.mode.is-mdi
[19:29:56] <cradek> I suggest turning on 'task issue' debug to see what messages are needed in what order
[19:30:29] <fenn> i have debug set to 7FFFFF..
[19:30:44] <alex_joni> you need to be in manual mode
[19:31:08] <alex_joni> fenn: if you want teleop jogging, you need manual mode (for jogging)
[19:31:20] <alex_joni> then you need to switch from joint to world
[19:31:33] <fenn> right, that's what i thought
[19:31:40] <alex_joni> but that is _not_ a change in task
[19:32:03] <alex_joni> you send a different jog message
[19:32:10] <alex_joni> but I thought I did that for halui
[19:32:42] <fenn> there is a bunch of teleop stuff in halui but it's not connected to any hal pins
[19:32:56] <alex_joni> ok, manual, mdi or auto are task modes
[19:33:04] <alex_joni> teleop is a traj mode
[19:33:16] <fenn> yep
[19:33:20] <fenn> i'm sending EMC_TRAJ_MODE_TELEOP
[19:33:41] <fenn> maybe i should be sending EMC_TRAJ_SET_TELEOP_ENABLE
[19:33:55] <alex_joni> EMC_TRAJ_SET_TELEOP_ENABLE
[19:33:58] <alex_joni> yup
[19:34:10] <alex_joni> but it will only work after homing all joints
[19:34:49] <alex_joni> the EMC_TRAJ_SET_TELEOP_ENABLE has a field called enable
[19:35:00] <alex_joni> you set that to 1 to set teleop
[19:35:05] <alex_joni> or to 0 to set free mode
[19:35:44] <alex_joni> halui should really use shcom.cc
[19:36:00] <alex_joni> int sendSetTeleopEnable(int enable)
[19:36:28] <fenn> yeah halui has a lot of duplicated code
[19:36:47] <alex_joni> well, at the time I wrote it so did emcsh.cc
[19:36:51] <alex_joni> and emclcd.cc
[19:37:38] <fenn> what's emclcd?
[19:38:11] <alex_joni> some thingie to display stuff on a LCD
[19:38:26] <alex_joni> * This program implements a limited user interface on an LCD
[19:38:26] <alex_joni> * display and keypad, such as the MX4 series made by Matrix Orbital.
[19:38:26] <alex_joni> *
http://www.matrixorbital.com
[19:38:30] <cradek> I think it's supposed to be a full emc ui
[19:39:08] <alex_joni> I think a HAL interface to LCDproc would be more usefull :)
[19:39:53] <alex_joni> I think emclcd.cc uses LCDproc
[19:48:13] <fenn> yay it worked
[19:48:48] <alex_joni> what are you trying to do?
[19:48:58] <alex_joni> jogging oligopods from halui?
[19:49:46] <fenn> trying to make this right
http://www.cnczone.com/forums/showthread.php?t=43872
[19:50:48] <cradek> fenn: why did you tell him to use emcsh? it's in the gui
[19:51:21] <fenn> because the gui wasnt working for me
[19:51:42] <fenn> i should just be able to select "world coordinates" and then jog around right?
[19:52:08] <cradek> after homing the joints, yes
[19:52:30] <alex_joni> and it should work from all the connected GUIs
[19:52:38] <alex_joni> aka halui, axis, tkemc, etc
[19:52:46] <alex_joni> I think I tried with 4 once
[19:53:28] <alex_joni> heh, tripod :D
[19:53:32] <fenn> but how do you set 'world coordinates' from halui?
[19:53:49] <alex_joni> you set it from the other gui
[19:53:59] <alex_joni> I bet he doesn't run only halui
[19:54:36] <alex_joni> fenn: if you look at the sendJog command in halui, you'll see it uses emcstatus->traj.mode == EMC_TELEOP_MODE
[19:54:38] <cradek> he does not even MENTION halui
[19:54:40] <alex_joni> or something like that
[19:54:53] <alex_joni> "installed the joypad jog HAL elements"
[19:55:02] <fenn> alex_joni: then it's always in teleop mode?
[19:55:07] <rayh> I'm having a bit of confusion with running a custom config from an installed system.
[19:55:17] <skunkworks> Hi ray.
[19:55:18] <alex_joni> fenn: once you switch, you switch the machine
[19:55:27] <fenn> sorry that was an == not =
[19:55:34] <rayh> It does not seem to find the location of my gcode directory.
[19:55:39] <rayh> Hi skunkworks
[19:55:42] <fenn> alex_joni: there's currently no way to set teleop mode from halui
[19:55:47] <alex_joni> fenn: right
[19:55:59] <cradek> rayh: what is "it"? that's mostly a gui function I think
[19:56:01] <alex_joni> rayh: what's the PROGRAM_PREFIX = in the ini?
[19:56:31] <alex_joni> fenn: but I bet he uses the GUI to load programs and home
[19:56:45] <alex_joni> and just jogging with the joypad from halui (if even that)
[19:56:56] <rayh> doesn't matter it always uses /usr/share/emc/...
[19:57:04] <cradek> it?
[19:57:14] <cradek> what gui?
[19:57:16] <alex_joni> fenn: so he can use the GUI to switch modes, then use the joypad to jog in world view
[19:57:18] <rayh> My own
[19:57:26] <alex_joni> rayh: emc2?
[19:57:38] <rayh> Yes the current installed release
[19:57:55] <cradek> the gui has to read that value from the ini file and do the right thing with it
[19:58:17] <cradek> usually that just means opening a file dialog with that as the initial path
[19:58:22] <rayh> It looks to me like the "emc" script is setting only the default installed
[19:58:38] <alex_joni> rayh: it's not a matter of the "emc" script
[19:58:52] <alex_joni> the GUI needs to parse the ini, and read the "PROGRAM_PREFIX"
[19:58:54] <rayh> so why is it in there at all?
[19:58:55] <cradek> the emc script does not read that value from the ini
[19:59:11] <alex_joni> rayh: can you look at xemc.cc ?
[19:59:28] <alex_joni> if (NULL != (inistring = inifile.Find("PROGRAM_PREFIX", "DISPLAY"))) {
[19:59:28] <alex_joni> if (1 != sscanf(inistring, "%s", programPrefix)) {
[19:59:28] <alex_joni> programPrefix[0] = 0;
[19:59:28] <alex_joni> }
[19:59:28] <alex_joni> }
[19:59:38] <rayh> but the script does set a global variable named EMC@_SACRIPTDIR
[19:59:48] <alex_joni> SCRIPTDIR is something else
[19:59:55] <rayh> EMC2 sorry
[19:59:55] <alex_joni> that's for tcl scripts
[20:00:19] <rayh> so that's why the tcl scripts do not work properly
[20:00:24] <SWPadnos> heh
[20:00:28] <SWPadnos> hi :)
[20:01:14] <alex_joni> rayh: I'm a bit lost..
[20:01:39] <rayh> So am I
[20:01:49] <cradek> when I run my installed sim/tkemc, scripts/set coordinates and scripts/halshow work fine
[20:01:51] <alex_joni> are you saying you changed EMC2_SCRIPT_DIR to point to you g-code folder, and now tcl scripts don't work properly?
[20:02:52] <rayh> No I'm saying that a during EMC startup a variable named -- let me find it.
[20:03:57] <rayh> EMC2_NCFILES_DIR=/usr/share/emc/ncfiles
[20:04:18] <rayh> and it never reads the real ini for a desired directory.
[20:04:20] <cradek> hm, I don't think anything uses that, they all do what alex pasted
[20:04:31] <alex_joni> rayh: what version is this?
[20:04:34] <cradek> the user can't edit that file, so it's the wrong place for a user preference type thing
[20:04:41] <rayh> current released.
[20:05:20] <alex_joni> 2.1.7 ?
[20:05:34] <rayh> I don't want to edit that file. I want it to read the ini for the proper location of chosen directory
[20:05:44] <cradek> your gui has to read the ini
[20:05:45] <rayh> Yes alex
[20:05:51] <alex_joni> there is also 2.0.5 which is the current release for the 2.0 branch
[20:06:07] <alex_joni> rayh: ok, just making sure
[20:06:18] <rayh> I thought we had abandoned the 2.0
[20:06:29] <alex_joni> as chris said, the GUI needs to read the ini for PROGRAM_PREFIX, and use that
[20:06:49] <alex_joni> rayh: we would still release a version with bugfixes if anyone would notify us of any
[20:07:02] <cradek> alex_joni: (maybe)
[20:07:23] <alex_joni> yeah, but given that we didn't hear anything for about a year.. I doubt it will happen
[20:07:37] <alex_joni> * alex_joni still waits for feedback for emc-1.2.0-rc1
[20:08:16] <cradek> according to
http://www.linuxcnc.org/component/option,com_poll/task,results/id,1/lang,en/ some people are still using emc 2.0
[20:08:27] <rayh> Then why do we have code in EMC that is useless?
[20:08:50] <cradek> rayh: please feel free to remove that line if nothing is using it
[20:08:55] <alex_joni> that's a trick question :P
[20:09:19] <alex_joni> in my current view of emc2 about 5-10% could be removed, because it's unused
[20:09:31] <rayh> In the script named emc that we execute every time we startup
[20:09:49] <alex_joni> but that doesn't mean I'm actually correct, and no-one uses that 10%
[20:09:51] <rayh> I'm not trying to deal in the whole code base only the executable script.
[20:10:04] <rayh> and damn if I
[20:10:14] <rayh> m not being misunderstood here.
[20:11:05] <rayh> I suppose what we ought to do is rename that script to something like emc_startup
[20:11:48] <alex_joni> it was called emc.run 2 years ago
[20:13:44] <rayh> Okay I see that we change the nature of the "emc" script during compile.
[20:14:23] <alex_joni> yes, for run-in-place it's quite different that for installed systems
[20:16:10] <rayh> And during that process we set some defaults that don't get checked back to the values they carry in the ini.
[20:16:20] <alex_joni> you can't do that
[20:16:40] <alex_joni> because at the time the script gets modified, the ini the user will use might have not be written yet
[20:17:24] <rayh> Ah but there is a section in the "emc" script that reads the ini and sets a number of values during startup.
[20:17:41] <alex_joni> rayh: the EMC2_NCFILES_DIR is probably my bad
[20:17:59] <alex_joni> I remember about 1-2 years ago I tried to fix this, but probably I messed it up
[20:18:32] <alex_joni> this = issue that there are different default paths for run-in-place and installed system
[20:19:06] <alex_joni> but I think I lost track of this, because most GUIs (tkemc, mini, xemc, axis, not sure about the rest) scan the ini themselves
[20:19:08] <rayh> No problem.
[20:19:29] <alex_joni> tkemc: set programDirectory [emc_ini "PROGRAM_PREFIX" "DISPLAY"]
[20:19:38] <rayh> Except that I was trying to use something that was not kept up.
[20:19:54] <alex_joni> right..
[20:20:12] <alex_joni> would it be easier for you to read that env than read the ini?
[20:20:24] <alex_joni> * alex_joni could update EMC2_NCFILES_DIR based on the ini
[20:21:30] <rayh> The mini interface gets it wrong in RIP
[20:22:16] <alex_joni> sim/mini.ini ?
[20:22:54] <alex_joni> mini.tcl: set programDirectory [emc_ini PROGRAM_PREFIX DISPLAY]
[20:23:14] <SWPadnos> quotes are missing
[20:23:15] <rayh> yes sim
[20:23:33] <alex_joni> SWPadnos: good catch, might be the reason why it's not doing the right thing
[20:23:54] <SWPadnos> could be
[20:24:21] <rayh> Are quotation marks required for that?
[20:24:22] <alex_joni> although it does the same for MAX_VELOCITY
[20:24:35] <alex_joni> rayh: you're a better tcl expert than me :)
[20:24:43] <SWPadnos> I don't know if they're required - I just noticed the difference in the two pasted lines
[20:25:10] <alex_joni> I'd say 50% of the calls to emc_ini are with quotes, the other half without
[20:25:51] <SWPadnos> so roughly half are nearly guaranteed to be almost correct
[20:26:56] <rayh> I've never heard of the need for quotation marks in the emc_ini call.
[20:27:15] <rayh> But let me try it and see if that fixes the issue.
[20:27:44] <SWPadnos> it seems unlikely that's the problem if half are with and half are without quotes
[20:27:58] <SWPadnos> but hey - it's not hard to check it
[20:29:19] <jepler> tcl's parsing rules should treat the two the same, since the quoted words don't contain any whitespace
[20:29:35] <alex_joni> what's the print command in tcl?
[20:29:41] <jepler> puts
[20:29:43] <SWPadnos> print
[20:29:48] <rayh> Nah it still opens configs/sim
[20:30:03] <jepler> puts example; puts "three word example"; puts "the value of x is $x"
[20:30:23] <alex_joni> rayh: I can confirm
[20:30:27] <jepler> puts {$4 a gallon for gas?!?!}
[20:30:33] <SWPadnos> heh
[20:30:46] <rayh> and the same for milk and a pack of cigs!
[20:31:37] <alex_joni> well, it reads the right thing from the ini
[20:32:10] <alex_joni> * alex_joni has a hunch
[20:32:20] <alex_joni> there used to be a double / at the end of the config dir.. right?
[20:35:27] <SWPadnos> look at line 2386 in mini.tcl - it adds "-parent ." to the params for tk_getOpenFile
[20:35:33] <SWPadnos> what does that do?
[20:36:35] <SWPadnos> ah - parent window, not parent dir. nevermind :)
[20:37:01] <alex_joni> 2386?
[20:37:10] <SWPadnos> oops 2836
[20:37:42] <rayh> I'm seeing that /home/rayh/emc/emc2-head/configs/sim is the working directory
[20:37:52] <alex_joni> yeah, that's expected
[20:38:00] <alex_joni> and in the ini we have "../../nc_files"
[20:38:04] <rayh> so ../../ncfiles should lead it to the correct place.
[20:38:11] <alex_joni> which should be /home/rayh/emc/emc2-head/nc_files
[20:38:21] <alex_joni> I tried an abs. path, and no difference
[20:38:25] <SWPadnos> ah - hold on a moment
[20:38:36] <SWPadnos> I'm not sure what order these run in (I'm using grep :) )
[20:38:45] <SWPadnos> line 1724 uses initialdir
[20:38:46] <alex_joni> 172x should run
[20:38:53] <SWPadnos> but it's first set on line 2486
[20:38:57] <alex_joni> nope
[20:39:08] <alex_joni> it's set on 169
[20:39:26] <alex_joni> set programDirectory ...
[20:39:27] <SWPadnos> not in my copy
[20:39:29] <rayh> ah tkemc does the same on a rip.
[20:39:47] <SWPadnos> I did `grep -in initialdir *` in the tcl dir
[20:40:16] <SWPadnos> does `. scripts/emc-environment` help ?
[20:40:38] <alex_joni> SWPadnos: what's 2486 ?
[20:41:03] <SWPadnos> 2486: set initialDir $programDirectory
[20:41:13] <alex_joni> huh? what version do you have?
[20:41:29] <alex_joni> ah, sorry
[20:41:36] <SWPadnos> oops - latest CVS
[20:41:37] <SWPadnos> not 2.1.7
[20:41:46] <alex_joni> yeah, but it doesn't use $initialDir in the tkOpenDialog
[20:41:52] <alex_joni> it uses $programDirectory
[20:42:05] <alex_joni> -initialfoo is a param for tkOpenDialog
[20:42:15] <SWPadnos> so it doesn't
[20:42:31] <alex_joni> notice it's -initialdir $programDirectory
[20:42:43] <alex_joni> not $initialDir
[20:42:58] <SWPadnos> yep. I noticed the variable on 1724, but it appears to be unused other than there
[20:42:59] <alex_joni> (that's what you get when running grep -i)
[20:43:04] <SWPadnos> heh
[20:43:03] <rayh> ah but programDirectory is only ../../ncfiles
[20:43:23] <alex_joni> rayh: sure, but that works from the current dir
[20:43:24] <SWPadnos> yep - they're all (for the most part) set to that
[20:43:51] <alex_joni> as I said, I tried an abs. dir (/home/juve/emc2.TRUNK/nc_files) and it still behaves the same way
[20:44:14] <SWPadnos> there are a few that are set to /usr/share/enc/ncfiles/ though
[20:44:17] <SWPadnos> emc
[20:44:47] <alex_joni> oh, my bad
[20:44:50] <alex_joni> I had a typo
[20:44:57] <alex_joni> if I use an abs. path it works right
[20:45:10] <alex_joni> so the ../../nc_files/ is the problem
[20:45:54] <alex_joni> weird.. now it works here
[20:46:01] <skunkworks> so - that is supposed to go up 2 directorys then down to nc_files?
[20:46:07] <alex_joni> yup
[20:46:44] <alex_joni> ahh :D
[20:46:49] <alex_joni> the problem is in the ini file
[20:48:22] <SWPadnos> how so?
[20:48:30] <alex_joni> ncfiles vs. nc_files
[20:48:36] <alex_joni> I just commited a change :)
[20:48:40] <SWPadnos> oh, interesting
[20:49:10] <SWPadnos> yep. lots of ncfiles instead of nc_files :)
[20:49:13] <alex_joni> all the ini's use ncfiles
[20:49:54] <alex_joni> rayh: good catch
[20:50:14] <rayh> I didn't think I caught anything other than confusion
[20:50:54] <SWPadnos> luckily it was contagious
[20:51:14] <alex_joni> all bugs are a source of confusion
[20:53:42] <rayh> Once you see it, it's dead simple.
[20:54:07] <skunkworks> funny - I actually saw that a while back. at some point the ncfiles directory changed to nc_files or vice versa. I just powered thru it.
[20:54:29] <skunkworks> I remember thinking - huh - thats odd
[20:54:45] <skunkworks> :)
[20:54:53] <rayh> damn that error is in a lot of configs
[20:56:06] <SWPadnos> all of them, unless they have the error of the fully qualified installed path instead ;)
[20:58:39] <alex_joni> * alex_joni commits a change
[20:59:10] <skunkworks> lot of help I am. ;p
[20:59:20] <rayh> Looks like 38 of em.
[20:59:32] <alex_joni> commit coming up
[20:59:42] <alex_joni> the issue is because of released packages I bet
[21:00:00] <alex_joni> all those need to be change to /usr/.../ncfiles before a package is released
[21:00:18] <SWPadnos> ncfiles or nc_files? :)
[21:00:37] <alex_joni> ncfiles for the /usr/foo
[21:00:45] <alex_joni> and ../../nc_files for the rip
[21:01:39] <rayh> so that's how we did it.
[21:02:03] <rayh> perhaps we should make nc_files in user.share/emc
[21:02:06] <SWPadnos> I'd just rename ncfiles for RIP :)
[21:02:17] <SWPadnos> but only if we were using subversion or git
[21:02:49] <alex_joni> rayh: still only helps marginally
[21:03:05] <alex_joni> there's still the change from ../../ to /usr/share/emc2/
[21:03:36] <alex_joni> I think this is exactly what I tried to acheive with EMC2_NCFILES_DIR (set by the runscript)
[21:04:30] <rayh> ah okay.
[21:05:45] <rayh> Are these commits going to break the installed version?
[21:06:28] <alex_joni> the installed version needs to have all those changed
[21:06:39] <alex_joni> but that should be done before the package is built
[21:10:07] <alex_joni> the thing is.. we can't have both values inside the ini's in the CVS
[21:10:41] <alex_joni> we could have the default path put in by the configure script, but that still leaves the issue of ncfiles vs. nc_files
[21:23:21] <skunkworks> http://www.cnczone.com/forums/showthread.php?t=43872
[21:24:28] <alex_joni> bah
[21:24:33] <alex_joni> you made me open halui.cc
[21:25:43] <fenn> me?
[21:26:39] <alex_joni> nah, the link skunkworks pasted
[21:27:36] <alex_joni> can one of you ask the guy in here?
[21:27:43] <alex_joni> can one of you ask the guy to come in here?
[21:28:04] <alex_joni> * alex_joni wonders what the exact interface he is using for jogging
[21:28:16] <alex_joni> might not be halui at all
[21:28:19] <SWPadnos> I'm sure it's the axis.n.jog-input
[21:28:23] <SWPadnos> (or whatever)
[21:28:32] <SWPadnos> the problem is that those only work on joints, not for teleop
[21:28:58] <fenn> hmm yep
[21:29:00] <fenn> didnt even see those
[21:29:02] <alex_joni> halui jog.x.analog should work on both
[21:29:13] <alex_joni> linked to the joystick/joypad
[21:29:29] <alex_joni> that's how I did my jogging
[21:33:53] <rayh> IMO. Here we have a case of HAL and EMC being out of sync.
[21:35:20] <alex_joni> here, where?
[21:35:21] <SWPadnos> well, sort of but not really I think
[21:35:31] <SWPadnos> HAL is strictly meant to mess around with hardware
[21:35:55] <SWPadnos> joints are hardware, teleop / world coordinates are a higher level of abstraction
[21:35:57] <rayh> Sure and there is no way to get some of these things back through EMC
[21:36:11] <fenn> rayh: what things?
[21:36:20] <rayh> joystick
[21:36:32] <fenn> joystick is a piece of hardware so it should go through hal
[21:36:34] <SWPadnos> I guess it depends on where kins goes
[21:36:49] <alex_joni> wth are you guys talking about?
[21:37:03] <SWPadnos> jogging in joint vs. world mode, I think
[21:37:04] <rayh> I've got no problem with joystick pins and params in there.
[21:37:20] <rayh> But there is no way to get those back into EMC
[21:37:33] <fenn> rayh: what's wrong with halui?
[21:37:58] <rayh> What you have here is joystick ->axis position
[21:38:15] <alex_joni> rayh: right
[21:38:16] <rayh> Which is way different from keyboard ->emc
[21:38:24] <alex_joni> err.. not really
[21:38:32] <alex_joni> it doesn't go to the emc axis position
[21:38:42] <alex_joni> it goes to halui (which is a user interface)
[21:38:49] <alex_joni> joystick -> halui -> emc
[21:38:53] <fenn> it should go to halui (but not in this case)
[21:39:21] <alex_joni> if it would go to halui, then the joystick would mean both things (jogging in joint and in world space)
[21:39:34] <rayh> Yep
[21:39:52] <SWPadnos> the "problem" is that there are two places to connect "jogging controls"
[21:39:57] <fenn> he's got a pic up
[21:39:59] <SWPadnos> and they don't always act the same
[21:40:29] <rayh> two places at least