Back
[00:01:06] <MASEngr> It's just taking forever to load the joystick. This is exceedingly weird.
[00:01:42] <skunkworks> again - I have nothing for you.
[00:01:48] <skunkworks> jmk
[00:01:53] <SWPadnos> someone else (or maybe it was you) mentioned this
[00:02:14] <SWPadnos> that it's fine on 6.06 or 7.10, but it takes a long time to be noticed on 8.04
[00:02:56] <MASEngr> Ah, that's interesting.
[00:03:09] <SWPadnos> there are emails about it - ('m searching nw
[00:03:11] <SWPadnos> now
[00:03:19] <jmkasunich_> MASEngr: slow down a bit - you are thrashing
[00:03:24] <skunkworks> oh - I vaugly remember something about that
[00:03:39] <jmkasunich_> joypad is a user space component, why do you have a thread for it?
[00:04:01] <MASEngr> Okay, jmk. It's been a long few days, and I keep getting asked "is it working yet?".
[00:04:17] <jmkasunich_> I can understand
[00:04:22] <skunkworks> jmkasunich_:
http://pastebin.com/d6f89fbab
[00:04:31] <jmkasunich_> but you have to understand that we are not standing over your shoulder
[00:04:47] <jmkasunich_> I get the distinct impression that you try 10 things, then report one or two bits of info back to us
[00:04:52] <MASEngr> That's true, and you're being very nice about helping.
[00:04:54] <jmkasunich_> we can't help you when you do that
[00:05:11] <MASEngr> I saw in core_servo.hal that there's a line:
[00:05:18] <MASEngr> # Slow thread for joypad
[00:05:18] <MASEngr> loadrt threads name1=joy-thread fp1=0 period1=10000000
[00:05:43] <jmkasunich_> I have no idea what that is doing, or if it is even remotely connected to what you need to do
[00:06:00] <MASEngr> I thought that the slow detection might be related to the slow period shown, and tried to reduce the period time. I don't think the two are connected.
[00:06:08] <jmkasunich_> they aren't
[00:06:39] <jmkasunich_> my approach to _any_ HAL problem is to step thru it manually and understand what is happening
[00:06:50] <jmkasunich_> so, make sure EMC itself is not running
[00:06:57] <jmkasunich_> make sure HAL and realtime is not loaded
[00:07:28] <jmkasunich_> then start an interactive halcmd session with "halrun -I"
[00:07:48] <jmkasunich_> that _should_ get you a halcmd prompt, with nothing at all loaded
[00:08:35] <MASEngr> All right, how can I make sure that it's not running?
[00:09:00] <SWPadnos> halrin -U
[00:09:02] <SWPadnos> halrun -U
[00:09:07] <jmkasunich_> yeah, that
[00:09:44] <jmkasunich_> when you are looking at a halrun prompt, type "show" and hit return
[00:10:00] <jmkasunich_> it should give you empty lists
[00:10:27] <MASEngr> Confirmed empty.
[00:10:44] <MASEngr> http://pastebin.com/d4c6308b5
[00:10:52] <jmkasunich_> ok - what is the command that you have in your file to load the joypad driver?
[00:11:06] <jmkasunich_> you added a -W, right?
[00:11:19] <MASEngr> loadusr -W hal_joystick -d /dev/input/js0 -p joypad
[00:11:28] <MASEngr> Where the -W is new and not confirmed to work yet.
[00:11:48] <jmkasunich_> ok, type the command at the halcmd prompt, _without_ the -W
[00:12:53] <jmkasunich_> what did that command do?
[00:13:44] <jmkasunich_> hello?
[00:13:44] <MASEngr> returned to a blank line. Show results at pastebin:
[00:13:45] <MASEngr> http://pastebin.com/d769c0fe2
[00:14:00] <jmkasunich_> ok, two issues here
[00:14:14] <jmkasunich_> #1: -W will never work with hal_joystick
[00:14:29] <jmkasunich_> #2: hal joystick seems to have some issue
[00:14:35] <jmkasunich_> lets talk about #1 first
[00:14:43] <jmkasunich_> line 4 of the pastebin
[00:14:58] <jmkasunich_> the name of the component you just loaded is "hal_joystick-12051"
[00:15:39] <jmkasunich_> because HAL doesn't allow two comps with the same name, and because I thought somebody might want to load hal_joystick twice, I made it append the PID to get a unique name
[00:15:58] <jmkasunich_> loadusr -W will wait for a comp called "hal_joystick" to become ready
[00:16:11] <jmkasunich_> which will never happen, because there is no such component
[00:16:20] <jmkasunich_> do you understand problem #1?
[00:16:34] <MASEngr> Yes, that's perfectly clear.
[00:16:37] <jmkasunich_> ok
[00:16:45] <SWPadnos> http://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg01104.html
[00:16:56] <MASEngr> Without knowing the PID in advance, which you can't, you can't match the name, so it waits forever.
[00:17:06] <jmkasunich_> right
[00:17:09] <SWPadnos> precisely
[00:17:23] <jmkasunich_> I admit that hal_joystick is poorly designed - and I'm the guilty party
[00:17:37] <jmkasunich_> I wrote it in a rush about 2 years ago
[00:17:59] <jmkasunich_> jepler wrote hal_input which is much better behaved later - is there any reason you aren't using it instead?
[00:18:27] <jmkasunich_> SWPadnos: what does that message you linked to have to do with anything?
[00:18:41] <MASEngr> I "inherited" this machine when I started working here, so I have no idea why some of the things are the way they are.
[00:18:53] <jmkasunich_> it was already running EMC?
[00:19:20] <MASEngr> Yes, on different hardware. Long story.
[00:19:34] <jmkasunich_> ok, neither of us has time for long stories
[00:20:23] <skunkworks> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?A_New_Approach_For_Using_Joypads_With_EMC2
[00:21:02] <jmkasunich_> heh - note the very first item in the bulleted list
[00:21:12] <jmkasunich_> that race condition is exactly problem #1 that I mentioned
[00:22:10] <jmkasunich_> I've never used hal_input, and its manpage is rather complex
[00:22:25] <SWPadnos> I saw some mention of the joystick taking a long time to respond, thought it could be related
[00:22:31] <jmkasunich_> you can fillow the wiki page instructions that skunkworks gave you and see if that works
[00:22:37] <MASEngr> Right, because if you delay for X time, you don't know exactly when the joypad will be ready. If you're lucky, it'll work 99% of the time.
[00:22:55] <skunkworks> * skunkworks was actually waiting to get scolded ;)
[00:22:57] <jmkasunich_> right - when the problem first showed up, we used a delay hack
[00:23:16] <MASEngr> And on slower hardware, the problem can hide for a very long time.
[00:23:16] <jmkasunich_> then Jeff came up with the "ready" flag, and the -W option for loadusr
[00:23:40] <MASEngr> Which, as we've proven, can't work on a joystick because of the PID append.
[00:23:56] <jmkasunich_> and because it never sets the ready bit (I think)
[00:24:03] <SWPadnos> hal_input doesn't have that problem though
[00:24:08] <jmkasunich_> right
[00:24:16] <jmkasunich_> hal_input is the preferred way to go
[00:24:20] <SWPadnos> and it works with joysticks, as long as they're recognized by the Linux input layer
[00:24:28] <jmkasunich_> unfortunately, hal_input has a 10 page long manpage
[00:24:36] <SWPadnos> heh
[00:24:55] <MASEngr> So all I have to do is reconfigure the file so that it will use hal_input instead of hal_joystick, and in theory, it'll work.
[00:25:11] <SWPadnos> in its simplest form, you just run hal_input "word", where word is some part of the text description of the input device
[00:25:13] <SWPadnos> not quite
[00:25:25] <MASEngr> DOn't worry, I'm not naive enough to think that a simple text swap will work. ;)
[00:25:32] <SWPadnos> read all of `man hal_input`
[00:25:41] <jmkasunich_> MASEngr: don't start by "reconfiguring the file"
[00:25:49] <jmkasunich_> start by using halcmd
[00:26:11] <jmkasunich_> if you cannot create a loadusr -W command in halusr that works, putting it in a file is just a waste of time and typing
[00:26:35] <jmkasunich_> note that you _cannot_ load things twice - after every attempt (good or bad) do "unloadusr all"
[00:26:43] <jmkasunich_> that should get you a clean slate
[00:26:56] <jmkasunich_> also, life will be simpler if you ignore the -W for now
[00:27:13] <jmkasunich_> loadusr hal_input <some-incantation-that-identifies-the-joypad>
[00:27:40] <jmkasunich_> once that works, and "show" shows you the pins, you can add -Wn <the-comp-name-as-shown-by-show>
[00:28:26] <jmkasunich_> this kind of interactive approach beats the hell out of editing a config, trying to run it, and then trying to understand a bazillion lines of spew
[00:28:37] <MASEngr> Yes, yes it does.
[00:28:40] <jmkasunich_> if you run one halcmd command at a time, you will know exactly which one doesn't work
[00:29:06] <MASEngr> Okay then, I'll get started on those man pages.
[00:29:25] <jmkasunich_> I just found my joystick - gonna see if I can figure out the hal_input command line
[00:29:44] <MASEngr> Okay then.
[00:31:19] <MASEngr> Thanks for the help; hopefully we can get this figured out.
[00:31:28] <jmkasunich_> ok, this doesn't seem too bad actually
[00:31:36] <jmkasunich_> open a fresh shell
[00:31:50] <jmkasunich_> and do "less /proc/bus/input/devices"
[00:32:06] <jmkasunich_> on my box, with my joystick plugged in, one part of the output reads:
[00:32:13] <jmkasunich_> I: Bus=0003 Vendor=046d Product=c214 Version=0205
[00:32:13] <jmkasunich_> N: Name="Logitech Logitech Attack 3"
[00:32:13] <jmkasunich_> P: Phys=usb-0000:00:1d.3-1/input0
[00:32:13] <jmkasunich_> S: Sysfs=/class/input/input4
[00:32:13] <jmkasunich_> H: Handlers=event3 js0
[00:32:14] <jmkasunich_> B: EV=b
[00:32:16] <jmkasunich_> B: KEY=7ff 0 0 0 0 0 0 0 0 0
[00:32:18] <jmkasunich_> B: ABS=7
[00:34:27] <MASEngr> I: Bus=0003 Vendor=046d Product=c216 Version=0110
[00:34:27] <MASEngr> N: Name="Logitech Logitech Dual Action"
[00:34:27] <MASEngr> P: Phys=usb-0000:00:0b.0-4/input0
[00:34:27] <MASEngr> S: Sysfs=/devices/pci0000:00/0000:00:0b.0/usb1/1-4/1-4:1.0/input/input2
[00:34:27] <MASEngr> U: Uniq=
[00:34:27] <MASEngr> H: Handlers=event2 js0
[00:34:29] <MASEngr> B: EV=1b
[00:34:31] <MASEngr> B: KEY=fff 0 0 0 0 0 0 0 0 0
[00:34:33] <MASEngr> B: ABS=30027
[00:34:35] <MASEngr> B: MSC=10
[00:34:39] <MASEngr> Excuse me; afk for 2 minutes.
[00:34:42] <SWPadnos> use the word "Dual" then
[00:34:56] <SWPadnos> or something else that's unlikely to be in another device description
[00:37:15] <MASEngr> I'm back. Thank you.
[00:37:51] <MASEngr> Sorry, SWP, I don't follow you.
[00:40:24] <jmkasunich_> MASEngr: the loadusr line will have to tell hal_input what device to access
[00:40:47] <jmkasunich_> the idea is to use something that matches the data you pasted above
[00:40:59] <MASEngr> so an example would be loadusr hal_input -KA "Logitech Dual" for my joypad?
[00:41:03] <jmkasunich_> swp was suggesting matching part of the device name
[00:41:19] <jmkasunich_> more bulletproof would probably be to match the vendor and product ID
[00:41:48] <MASEngr> There aren't a lot of joysticks plugged into the milling machine. :D
[00:42:41] <jmkasunich_> yeah, but it would suck if it you use "Dual" and it matched say a "Dual button mouse"
[00:43:20] <MASEngr> Touche.
[00:44:23] <jmkasunich_> it looks like you'll have to set up a udev rule
[00:44:44] <MASEngr> Odd, I got this error:
[00:44:52] <MASEngr> LookupError: No input device matching '"Vendor=046d Product=c216"' was found
[00:44:57] <jmkasunich_> yeah
[00:45:04] <jmkasunich_> I got the same thing a few mins ago
[00:45:13] <jmkasunich_> I think its a permissions thing, hence the udev rule
[00:45:22] <jmkasunich_> give me a few minutes here to try some stuff
[00:46:21] <SWPadnos> hold on, I'll upload a file for you
[00:48:43] <MASEngr> Okay, holding on.
[00:49:56] <SWPadnos> go here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?A_New_Approach_For_Using_Joypads_With_EMC2
[00:50:05] <SWPadnos> and download the file under the section on plugdev
[00:50:19] <SWPadnos> put it in the /etc/udev/rules.d/ directory
[00:50:44] <SWPadnos> you'll need to do that as root, so download somewhere then sudo copy from a terminal or something
[00:52:53] <SWPadnos> if you reload the page now, you'll see some more instructions
[00:54:00] <MASEngr> Okay, I'll take a look.
[00:54:34] <SWPadnos> I have the same joypad, and I loaded it with the command "loadusr hal_input Dual"
[00:55:24] <dgarr> I had some udev problems with joystick when i upgraded to hardy, my solution described here:
[00:55:30] <dgarr> http://pastebin.com/mad2b68e
[00:55:58] <SWPadnos> you can add -W to that if you like: "loadusr -W hal_input Dual"
[00:56:19] <MASEngr> Hang on, it didn't download. Permission issue, I think.
[00:56:25] <SWPadnos> hmmm
[00:56:38] <SWPadnos> did you try to download it directly to etc/udev/rules.d?
[00:56:47] <MASEngr> Yes.
[00:56:52] <jmkasunich_> it is a one line file
[00:57:00] <SWPadnos> bad MASEngr - read the instructions! :)
[00:57:26] <SWPadnos> though I didn't explicitly say to download it elsewhere :)
[00:57:51] <SWPadnos> yep - only one line - should be easy
[00:57:53] <MASEngr> *hangs head in shame*
[00:57:58] <SWPadnos> heh
[00:57:59] <jmkasunich_> you could so "sudo echo 'SUBSYSTEM=="input", mode="0660", group="plugdev"' >/etc/udev/rules.d/50-input-permissions.rules"
[00:58:08] <jmkasunich_> s/so/do
[00:59:16] <SWPadnos> dgarr, thanks - did you write the wiki page also? it seems to be the same solution (though yours is more complete, with the event rule also)
[00:59:27] <SWPadnos> he could so! :)
[01:00:01] <MASEngr> All right, a quick sudo nano wrote the rule.
[01:00:36] <jmkasunich_> ok, unplug the joypad, wait a few secs, plug it in, wait a few secs
[01:00:53] <jmkasunich_> then "halrun -I" and "loadusr hal_input Dual"
[01:01:07] <SWPadnos> with -W even
[01:01:13] <SWPadnos> (for later use in a hal file)
[01:01:20] <jmkasunich_> baby steps SWPadnos
[01:01:24] <SWPadnos> heh
[01:01:44] <jmkasunich_> if it works without -W, then "unloadusr all" and "loadusr -W hal_input Dual"
[01:02:01] <SWPadnos> I tried it with -W here (same joyupad even)
[01:02:05] <SWPadnos> u-
[01:02:15] <MASEngr> Let me show you:
[01:02:16] <MASEngr> http://pastebin.com/d68db91e3
[01:02:27] <jmkasunich_> woo-hoo
[01:02:36] <MASEngr> Yes, jubilation.
[01:02:52] <jmkasunich_> now of course you'll have to change names in your hal file, but I think this should get you over the hump
[01:03:03] <SWPadnos> MASEngr, close your eyes for a sec
[01:03:04] <jmkasunich_> good learning experience for me too - never used hal_input before
[01:03:18] <MASEngr> I got the same results with the -W flag
[01:03:27] <SWPadnos> jmkasunich_, do you know if halui isn't usable for "velocity-mode" jogging, such as with an analog input from a joypad?
[01:03:30] <MASEngr> eyes closed. Typing with them closed.
[01:03:34] <SWPadnos> thanks :)
[01:03:44] <jmkasunich_> SWPadnos: no clue at all, I've done nothing yet with halui
[01:03:48] <SWPadnos> I noticed these hal files are using synthesized encoders
[01:03:50] <SWPadnos> ok
[01:03:59] <SWPadnos> MASEngr, you can open your eyes now
[01:05:54] <dgarr> i didn't write a wiki page, sent it to a few developers if i recall, udev does some things different (better) in hardy i think
[01:05:58] <MASEngr> Okay.
[01:06:08] <MASEngr> Hey, I can touch-type. I didn't know that.
[01:06:35] <SWPadnos> that page I linked (from skunkworks pointing it out to me) has an interesting "gamma curve" component for setting accel
[01:06:40] <SWPadnos> like audio taper and stuff
[01:06:48] <MASEngr> I think I'll pass for now.
[01:07:00] <MASEngr> If I can get it to work, that's good enough for me.
[01:07:02] <SWPadnos> yep
[01:07:58] <MASEngr> So I would assume that in the joypad.hal file, I would have to change the line to load the joypad with hal_input, then modify all the pin assignments accordingly.
[01:08:07] <SWPadnos> yep
[01:08:39] <SWPadnos> look at what's what with the bare halcmd though - load up some halmeters or halscope and twiddle the various buttons and knobs
[01:09:03] <SWPadnos> if I remember correctly, there's something weird about the way the hat switches or axes are named
[01:09:07] <MASEngr> For example, the old line net velX joypad.axis.0 => sim-encoder.0.speed would get changed to net velX input.0.abs-x-position => sim-encoder.0.speed
[01:09:17] <MASEngr> Ah, I see.
[01:09:38] <SWPadnos> yes, something like that
[01:09:54] <SWPadnos> I loaded a zillion halmeters to look at everything
[01:10:10] <SWPadnos> loadusr halmeter -s pin input.0.abs-x-position
[01:10:16] <SWPadnos> up-arrow is your friend :)
[01:10:20] <MASEngr> I was just about to ask, thanks.
[01:11:42] <MASEngr> Well, that was a more complicated answer than last time.
[01:12:00] <MASEngr> Last time I couldn't find joypad.0.axis, the stupid thing was unplugged.
[01:12:16] <SWPadnos> heh
[01:18:29] <MASEngr> Hmm, is there a difference between joypad.axis.0 and axis.0, or is it just shorthand?
[01:19:23] <SWPadnos> there is no shorthand
[01:19:43] <SWPadnos> except when doing halcmd show
[01:20:03] <SWPadnos> you can show pin joy, and it'll show joypad* and joystick*, for example
[01:20:28] <SWPadnos> are you looking at a whole EMC2 HAL?
[01:22:46] <MASEngr> Yes, I'm looking at joypad.hal
[01:23:06] <SWPadnos> axis.* are from the motion controller
[01:23:58] <MASEngr> That's what I thought - if it was joypad based, it would say joypad in there.
[01:24:33] <SWPadnos> that's generally true
[01:25:11] <MASEngr> Well, it works.
[01:25:24] <SWPadnos> yay
[01:25:35] <MASEngr> The pins are probably wrong for the CNC guys, but I can fix that up tomorrow.
[01:25:53] <MASEngr> I'll paint the joypad with some kind of indicators.
[01:25:58] <SWPadnos> like moving left moves the quill up or something like that? :)
[01:26:28] <MASEngr> Well, EMC2 boots. That's a big chunk o' progress.
[01:26:50] <skunkworks> Great - was it dave that left the country?
[01:27:03] <SWPadnos> Adam maybe?
[01:27:08] <skunkworks> adam - that is it/
[01:27:08] <MASEngr> Adam left the country for Bermuda.
[01:27:09] <SWPadnos> to jamaica or something
[01:27:12] <SWPadnos> ah
[01:27:17] <MASEngr> Haven't seen nor heard from him since.
[01:27:26] <SWPadnos> can you blame him? :)
[01:27:28] <MASEngr> And yes, the joypad actually controls the mill.
[01:27:45] <MASEngr> Hey, I'd be too busy diving to check in.
[01:28:28] <SWPadnos> egggzactly
[01:29:11] <MASEngr> "Hmm, I wonder what the guys in Victoria are doing?" <-- unlikely to be thought.
[01:29:59] <MASEngr> So, while I have everyone's attention, do I have to reset anything if the max jitter drops dramatically?
[01:30:11] <SWPadnos> hmmm
[01:30:19] <MASEngr> Say, from 850k to 8k?
[01:30:28] <SWPadnos> I'd be suspicious about that, if I hadn't done anything to make that happen
[01:30:51] <MASEngr> I replaced the HDD, mobo, RAM, and CPU.
[01:30:59] <MASEngr> So a few changes, yes. ;)
[01:31:09] <SWPadnos> oh, I thought you were talking since this afternoon or something :)
[01:31:34] <SWPadnos> you have either the USC or Mesa hardware, rigth?
[01:31:34] <MASEngr> I didn't run stepconf; I have a m5i20 and didn't see it listed.
[01:31:47] <SWPadnos> ok, I don't think you have anything to worry about then
[01:32:04] <SWPadnos> though the simulated encoders for jogging may want to be a little faster than the 1ms servo period
[01:32:12] <SWPadnos> that's what that joypad_thread was for
[01:32:25] <SWPadnos> or whatever it was called
[01:33:00] <MASEngr> I think I'll leave well enough alone for now. If I don't have to reset something, then I'll just leave it.
[01:33:14] <MASEngr> If the only problem is a lag when using the joypad, that's good enough.
[01:33:16] <SWPadnos> I think you'll get a base thread anyway - you could change that to the 50 us or so that you need for the encoder
[01:33:57] <SWPadnos> change BASE_PERIOD in the ini to 50000 or 100000 (or whatever you need for the joypad)
[01:34:32] <SWPadnos> the hal_input driver will still run only ~10 times/second, but the synthesized encoders will maintain velocity nicely
[01:34:54] <MASEngr> BASE_PERIOD is already 50000
[01:34:55] <SWPadnos> actually, you can probably get away with longer - play with the times yourself, don't listen to me :)
[01:35:17] <MASEngr> SERVO_PERIOD is 1000000
[01:35:19] <SWPadnos> ok, then leave it - you can stick the synthesized encoders in that thread instead of creating a new one
[01:35:37] <SWPadnos> but whatever works for is correct
[01:35:40] <SWPadnos> for you
[01:36:22] <MASEngr> Meh, good enough.
[01:36:48] <MASEngr> What about for automatic milling? Should I / must I change anything?
[01:37:00] <SWPadnos> you mean running G-code?
[01:37:04] <SWPadnos> probalby not
[01:37:06] <MASEngr> Yes.
[01:37:25] <SWPadnos> the settings are sane - the old motherboard was not
[01:38:01] <MASEngr> Excellent. THe new one isn't sane either, but at least it's fast.
[01:38:15] <MASEngr> Proprietary Compaq garbage.
[01:38:38] <SWPadnos> if it has max latency around 8000 (with you doing "hard things"), then it's pretty sane :)
[01:39:48] <MASEngr> I had a lot of stuff going on, yes, and it was tested nicely.
[01:40:33] <MASEngr> All right, I think that's everything. Thank you very much; I couldn't have done it without #emc.
[01:40:49] <SWPadnos> you're welcome - enjoy
[01:55:50] <stustev> hello world
[01:56:28] <stustev> I have a question or two for the 'AXIS' gurus.
[01:57:05] <skunkworks> stuart!
[01:57:15] <stustev> good evening!
[01:57:36] <stustev> what's happening this evening?
[01:58:56] <skunkworks> some heavy discussions on hal_input vs hal_joystick. other than that.
[01:59:15] <stustev> The preview display shows the AB axis motion backwards from my machine motion.
[01:59:34] <stustev> How can I reverse the displayed motion?
[01:59:38] <SWPadnos> fix your machine ;)
[01:59:49] <stustev> my machine runs just fine thank you
[02:00:08] <stustev> :)
[02:00:15] <SWPadnos> hmmm - lemme mess with sim_9axis for a sec
[02:00:41] <stustev> I will post my other questions while you look
[02:00:57] <stustev> The cinci is running and looking GOOD
[02:01:51] <skunkworks> we need some more videos.
[02:02:09] <stustev> will do - shortly
[02:02:25] <stustev> I hope to cut metal tomorrow
[02:02:46] <stustev> that reminds me I need to email the man with the movie camera - bbl
[02:05:59] <SWPadnos> heh
[02:06:20] <SWPadnos> I don't have any idea how to change that, and I'm not sure if what I'm seeing with the sim/axis_9axis config makes sense
[02:06:31] <SWPadnos> so I'm no help, sorry
[02:07:23] <stustev> thanks for looking
[02:08:40] <SWPadnos> it looks like B is counterclockwise around the Y axis for positive movements
[02:09:13] <SWPadnos> A doesn't seem to do anything (it may not be implemented, though I'd expect that was the first one done)
[02:09:38] <SWPadnos> and C goes - uh - I'd have to look again
[02:09:48] <stustev> bbl - my wife just informed we that we are going to the Y. If I survive I will be back in about 1 1/2 hours
[02:10:29] <stustev> I will revisit the machine configs.
[02:10:41] <SWPadnos> heh
[02:10:50] <dmess> + on rotary axis is always CCW
[02:10:58] <SWPadnos> see you. remember - there should be a hot tub in the locker room
[02:11:37] <dmess> mine will be behind the l/r in the cold
[02:11:48] <stustev> the movement of geometry is counterclockwise for positive movement when viewed in the negative direction (from the positive)
[02:12:00] <stustev> A cutter will move opposite.
[02:12:14] <SWPadnos> the motion is defined as tool motion
[02:12:28] <SWPadnos> so + should be tool motion CCW around the axis
[02:12:36] <dmess> not really it will usually aproach from the +
[02:12:46] <SWPadnos> ifthe machine moves the work, then it will move opposite (like a knee mill table/saddle)
[02:13:38] <dmess> YOU ARE ALWAYS DRIVING THE TOOL sit on the cutter...
[02:13:58] <dmess> and ride around..
[02:14:09] <SWPadnos> yes, I'm aware of that - in fact I think I said that :)
[02:14:41] <dmess> sorry befor i came into to room
[02:15:16] <SWPadnos> <SWPadnos> the motion is defined as tool motion
[02:15:25] <dmess> si
[02:15:28] <SWPadnos> 8 lines up :)
[02:16:35] <dmess> brain faRT
[02:16:49] <SWPadnos> pheww - open a window or something
[02:17:10] <dmess> its the barley
[02:17:16] <dmess> in me
[02:23:19] <owad> Does anybody use Inkscape with the gcode script? I'm finding it a bit flakey, when working with vectorized text.
[02:24:06] <MASEngr> quit
[02:39:48] <dmess> Owad.... chk out #cam Dan has some sweet text to gcode stuff
[02:45:24] <owad> thanks, dmess
[03:16:20] <stustev> SWPadnos: are you still here?
[03:16:33] <SWPadnos> yep
[03:17:05] <stustev> got my physical exertion in - walked a mile
[03:17:22] <SWPadnos> heh
[03:17:32] <SWPadnos> from the parking lot to the building and back ;)
[03:17:40] <stustev> yeh
[03:17:46] <stustev> 3 times
[03:19:06] <stustev> When a machine rotary axis moves the tool the + motion should be clockwise rotation when viewed in the negative direction (from the positive)
[03:19:46] <stustev> Then it will agree with the relative motion of tool to geometry when the machine move the part instead of the tool.
[03:20:09] <SWPadnos> so if I'm at the top of the world (Z+) looking down on the table (toward Z-), you're saying that positive C rotation should be clockwise?
[03:20:24] <SWPadnos> rotation of the tool, that is
[03:20:29] <stustev> yes
[03:20:43] <SWPadnos> hmmm. I may disagree with you (even though I don't know squat)
[03:20:53] <stustev> look at graph paper
[03:20:56] <SWPadnos> that's backwards from a mathematical standpoint
[03:21:20] <stustev> no it agrees with mathematical standpoint - see two lines up
[03:21:41] <SWPadnos> it agrees with a compass, not with sines and cosines
[03:21:51] <stustev> and sines and cosines
[03:22:02] <SWPadnos> mathematically, +x (east) is 0 degrees, +y (north) is 90
[03:22:22] <SWPadnos> that's counterclockwise
[03:22:36] <stustev> the sine of 45 degrees is a positive and the cosine of 45 degrees is a positive - that is moving geometry not the tool
[03:22:54] <SWPadnos> G-code always describes the tool, doesn't it?
[03:23:17] <SWPadnos> orientation and/or position, it's the tool, not the work
[03:23:19] <stustev> the program moves the tool yes but that should also agree with geometry movement
[03:23:35] <SWPadnos> I may not understand what you mean by "geometry movement"
[03:23:38] <stustev> orientation to the work (geometry)
[03:24:17] <stustev> at the very base of motion you are moving the tool around the part
[03:24:43] <stustev> the program moves the tool - yes - but the point of the motion is to move the tool around the part
[03:25:17] <stustev> when you rotate the part in the coordinate system you follow the sine - cosine. The tool moves around the part.
[03:25:46] <SWPadnos> but ABC are tool orientation, not part orientation ...
[03:26:27] <stustev> ABC rotation are the tool rotation around the geometry of the part
[03:27:19] <stustev> if you keep the relative tool and part rotation in agreement the tool must rotate opposite the part
[03:27:58] <SWPadnos> hmmm. I'm having a hard time visualizing what you're saying
[03:28:03] <stustev> for example a four axis mill
[03:28:10] <SWPadnos> it may have to do with only getting a few hours sleep last night :)
[03:28:14] <stustev> two four axis mills
[03:28:21] <stustev> one with a rotary table
[03:28:31] <stustev> one that rotates the tool
[03:28:43] <SWPadnos> sure - pivoting the head vs. using a trunion are two different things
[03:29:06] <SWPadnos> they require opposite motion to accomplish the same move in G-code
[03:29:35] <stustev> yes - that is correct - but the g code should agree
[03:29:42] <SWPadnos> (like gantry router vs. knee mill motion)
[03:30:03] <stustev> yes - the relative motion should agree
[03:30:05] <SWPadnos> this machine has a pivoting head, right?
[03:30:10] <stustev> yes
[03:31:53] <stustev> it is possible to configure the machine for motion in either direction. you just then match your post to how the machine moves.
[03:32:16] <SWPadnos> so fix the machine ;)
[03:32:24] <stustev> my post will handle either direction - I must specify which direction is positive when setting up the post
[03:32:53] <stustev> NO! I want it MY way:)
[03:33:03] <SWPadnos> I think the tool visualization in axis is misleading, but correct
[03:33:05] <SWPadnos> heh :_)
[03:33:06] <SWPadnos> :)
[03:33:20] <stustev> I don't agree
[03:33:22] <SWPadnos> it keeps the tool tip at the same spot
[03:33:34] <stustev> I think that is correct and very nice
[03:33:40] <stustev> the rotation is backward
[03:33:58] <SWPadnos> I pivoted B by 45 degrees, while viewing from the positive Z axis (clicked the upright Z view)
[03:34:27] <SWPadnos> the tool appeared to tilt to the left, but it's the top of the tool that moves - the tip stays stationary
[03:34:39] <SWPadnos> so it's the tip pivoting right
[03:35:06] <SWPadnos> when I do G0C90, the top points down (counterclockwise motion), with the tip pointing upward, toward positive Y
[03:35:30] <stustev> what are you looking at - vismach?
[03:35:31] <SWPadnos> that's mathematically correct - the tip is pointing at 90 degrees in the XY plane, as C==90 should
[03:35:41] <SWPadnos> no, looking at the AXIS preview screen
[03:38:03] <stustev> the tool axis should be aligned with the y axis and the tip pointing in the y positive direction when it is in a + 90 degree position
[03:38:15] <SWPadnos> yep, that's exactly what I see
[03:38:35] <SWPadnos> remember - it's the ass end of the tool that pivots in axis, the tip remains stationary
[03:38:47] <SWPadnos> that's why I said I think it's misleading but accurate
[03:39:49] <stustev> what is your A or B position?
[03:40:13] <SWPadnos> a seems to have no effect, and it's 0
[03:40:26] <SWPadnos> I can't see C rotation with B=0, so I set it to 45 or 90
[03:40:48] <stustev> or -45 or -90
[03:41:12] <SWPadnos> sure, either would let me see some motion
[03:41:16] <stustev> are you using the axis_9axis?
[03:41:30] <SWPadnos> yes
[03:41:46] <stustev> but the apparent C motion would be opposite - yes?
[03:41:46] <SWPadnos> when B is negative, C is effectively reversed
[03:41:49] <SWPadnos> yep
[03:42:09] <SWPadnos> do you want C to always act as though B is positive?
[03:42:23] <stustev> I just started that - I will play with it some
[03:42:28] <stustev> no
[03:42:51] <stustev> my only point is I want the relative motion to always agree
[03:43:14] <stustev> no matter whether the rotary axis is a table or a head
[03:43:31] <SWPadnos> I think they do now but I'm not positive - it's easy to get confused
[03:43:58] <SWPadnos> AXIS doesn't care what your kinematics do with the commands, it shows what the G-code asks for (and the kinematics tells it has happened)
[03:44:15] <stustev> I want to play with this some - the motion I have been talking about is the AB motion. The cinci doesn't agree with the screen
[03:44:29] <stustev> no control cares
[03:44:32] <SWPadnos> ok - I don't see A motion at all for some reason
[03:44:50] <stustev> they can all be set up however the integrator wants
[03:45:09] <SWPadnos> I think I remember some effort toward making the work move for A, likea rotary table (so you'd see a gear instead of a lot of repetitions of a line to cut one :) )
[03:45:11] <SWPadnos> yep
[03:45:45] <SWPadnos> I'm using TRUNK by the way, not 2.2.6, for this testing - it may be different from 2.2.6
[03:46:11] <stustev> I use TRUNK also
[03:46:31] <SWPadnos> I'm updating my 2.2.x checkout - I'll see if it's different in a sec
[03:46:41] <SWPadnos> unless there's no 9axis in that one ;)
[03:50:40] <stustev> I think both the B and C are backwards in 9axis - it follows that A would agree with B and C - I assume A is backward also
[03:50:40] <SWPadnos> yep - 2.2.7~cvs only moves A
[03:51:29] <SWPadnos> does A move for you?
[03:51:38] <stustev> this becomes moot if there is a way to reverse the motion in the preview - I will check
[03:51:52] <stustev> no
[03:51:59] <SWPadnos> ok, phew (me either)
[03:52:38] <stustev> it moves as expected on the cinci - just opposite what I want
[03:53:48] <stustev> if A is moving a table it may be correct
[03:54:42] <SWPadnos> the preview shows the tool motion, regardless of how it's implemented on the machine
[03:54:55] <SWPadnos> it's either correct or it's not, it shouldn't be machine dependent
[03:55:22] <stustev> the tool motion is backward to what it should be
[03:55:26] <SWPadnos> vismach may care, but axis doesn't
[03:56:09] <SWPadnos> I can't see how the tool orientation is handled in AXIS - I see a get_tool function and some other stuff, but I don't know how it fits together
[03:56:16] <stustev> this tool motion will not agree with a table or a head
[03:56:39] <stustev> somebody will know
[03:56:49] <SWPadnos> I know somebody who probably knows ;)
[03:57:10] <stustev> me too - he is conspicuously absent this evening
[03:57:23] <SWPadnos> it's late for him
[03:57:35] <SWPadnos> and me, considering how little I slept last night
[03:57:38] <stustev> I will hit him up tomorrow morning
[03:58:02] <stustev> time for me to take a shower and go to bed - see you later
[03:58:41] <SWPadnos> see you
[04:03:51] <JymmmEMC> SWPadnos: So, is the joystick plug-n-pray now?
[04:04:04] <SWPadnos> seems to work, you just need that udev rule file
[04:04:17] <SWPadnos> at least for 7.10 sim ;)
[04:04:20] <JymmmEMC> SWPadnos: dynamic jog speed?
[04:04:31] <SWPadnos> dunno, haven't actually jogged with it
[04:04:34] <JymmmEMC> ah
[04:04:38] <SWPadnos> but I think that's how the HAL file is set up
[04:05:01] <SWPadnos> uses step generators to synthesize quadrature, with the rate coming from the joystick position and buttons
[04:05:22] <SWPadnos> there's also a component that will allow you to adjust the velocity curve, similar to a gamma curve component
[04:05:37] <JymmmEMC> from config file or the joystick itself?
[04:05:59] <SWPadnos> a separate HAL component
[04:06:07] <SWPadnos> it's on that wiki page I linked
[04:06:19] <SWPadnos> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?A_New_Approach_For_Using_Joypads_With_EMC2
[04:07:32] <JymmmEMC> Hmmm, a slow/fast jog toggle from one of the button on the joystick itself would be nice.
[04:08:11] <SWPadnos> that's simple to do with a mux
[04:08:45] <JymmmEMC> Is a "RUN" button still requried to be held down to jog (as a safety device)?
[04:09:01] <JymmmEMC> s/device/interlock/
[04:09:45] <JymmmEMC> Like if the joystick is knocked off the table =)
[04:10:03] <SWPadnos> not from the GUI, but you can configure HAL (pendant) jogging that way
[04:10:11] <JymmmEMC> ah
[04:10:17] <SWPadnos> so if a bird lands on the X key, you could be in trouble
[04:10:24] <SWPadnos> err - right arrow, that is
[04:10:25] <JymmmEMC> yep
[04:12:56] <JymmmEMC> oh crap... I forgot I was going to research something when I got home... sigh
[04:33:14] <JymmmEMC> I'll be damn... I found my new love
[04:33:37] <JymmmEMC> (sorry, it's a M$ thing)
[04:34:00] <JymmmEMC> wouldn't apply to 99.999$ of you
[04:34:04] <JymmmEMC> %
[04:36:29] <JymmmEMC> SWPadnos: you play with M$ at all anymore?
[04:36:46] <SWPadnos> I'm on a Windows machine most of the time - engineering apps you know
[04:36:50] <SWPadnos> like right now
[06:48:23] <alex_joni> SWPadnos: just for reference, it's way easier to do halui velocity based jogging
[06:48:33] <alex_joni> the hal file should only be a couple lines long
[06:49:40] <alex_joni> SWPadnos:
http://wiki.linuxcnc.org/uploads/joypad_v3.hal
[06:49:50] <alex_joni> (the commented out commands.. )
[07:25:16] <pjm> good morning
[07:26:15] <alex_joni> hi
[09:08:05] <micges> hi alex_joni
[09:09:26] <micges> do you remember thread about g64 pn mode and issue that emc did not optimising first vector ?
[09:57:39] <alex_joni> no.. sorry
[09:57:47] <alex_joni> can't say that I do
[10:48:04] <anonimasu> hello
[12:14:02] <skunkworks_> cradek: did it move?
[12:15:16] <stustev1> good morning
[12:15:34] <skunkworks_> good morning.
[12:15:46] <stustev1> again it you sam
[12:16:08] <stustev1> how are you this morning?
[12:16:15] <skunkworks_> I live here.. Have a cot and everything. ;
[12:16:17] <skunkworks_> ;)
[12:16:27] <skunkworks_> awake and glad it is friday.
[12:16:27] <stustev1> are you at work?
[12:16:30] <skunkworks_> yes
[12:16:39] <stustev1> what do you do for work?
[12:16:56] <skunkworks_> Mostly IT stuff
[12:17:09] <skunkworks_> but sort of a jack of all trades master of none
[12:17:28] <archivist_ub> best way to be
[12:17:39] <stustev1> I am not an IT guy but I resemble the jack of all trades - master of none
[12:17:59] <stustev1> The older I get the less I know about more and more
[12:18:00] <skunkworks_> hey - I am working on a 150v 20a <if I am lucky pwm h-bridge. I think cradek thought you might be interested in it.
[12:18:18] <stustev1> yes I am
[12:18:38] <skunkworks_> http://www.electronicsam.com/images/KandT/servostart/newschem5.png
[12:19:03] <skunkworks_> and
http://www.electronicsam.com/images/KandT/servostart/boardfinal4.PNG
[12:19:15] <stustev1> pretty soon I will know absolutely nothing about absolutely everything
[12:20:58] <stustev1> nice - hope it works
[12:21:17] <stustev1> have you made much progress on your mill?
[12:22:13] <skunkworks_> none
[12:22:14] <skunkworks_> :)
[12:23:58] <stustev1> time gets away so fast
[12:24:33] <skunkworks_> exactly. I have been working mostly on the house/garage. Hard to make it to the shop.
[12:25:31] <skunkworks_> * skunkworks_ is sore from moving retaining wall blocks and stones.
[12:27:25] <cradek> hi all
[12:27:36] <cradek> it moves! X is working nicely
[12:27:53] <jepler> cradek: cool
[12:27:55] <jepler> been up all night?
[12:28:13] <archivist_ub> another happy emc'er
[12:28:16] <cradek> nope, I got to bed around midnight
[12:28:50] <cradek> I'm going to have to figure out the mesa watchdog. it is an I/O pin for some reason
[12:29:20] <cradek> a comment in the mesa sample configuration shows it hooked up to a motion.watchdog output that doesn't exist
[12:29:55] <skunkworks_> cradek: what fe did you get it down to?
[12:30:04] <cradek> about .001 at rapid
[12:30:15] <cradek> a little under
[12:30:21] <skunkworks_> and how is the resolver->encoder board working?
[12:30:35] <cradek> 200ipm on 4 inches of travel looks pretty fast
[12:30:40] <skunkworks_> heh
[12:30:55] <cradek> it works fine, no surprises. I have not tried index yet though.
[12:31:08] <skunkworks_> very nice
[12:31:42] <cradek> it turns out ground wires are important. I had .2v of noise I was trying to 'tune out'. as you might guess, this didn't work very well
[12:31:56] <cradek> once I got a brain, it tuned right up
[12:32:46] <skunkworks_> yecky ;)
[12:33:07] <cradek> have you made the first amp yet?
[12:33:47] <cradek> K-lined, bizarre
[12:34:23] <skunkworks_> no - It rained last night. But just ran out of time.
[12:35:25] <skunkworks_> I can almost taste it though..
[12:35:29] <skunkworks_> ;)
[12:35:34] <cradek> hope it works!
[12:36:07] <skunkworks_> and if it doesn't I hope it is on video. ;)
[12:36:09] <cradek> I should go to work... bbl.
[12:36:12] <cradek> haha
[12:53:55] <stustev1> cradek: jepler: how would I reverse the direction of rotation of the ABC axes in the AXIS display?
[12:55:51] <archivist_ub> axis dispay of A bugs me as well
[12:56:10] <archivist_ub> my work rotates not the tool
[13:02:49] <cradek> stustev1: pretty sure that would take a change in axis.py
[13:03:30] <stustev1> I agree - where should I look?
[13:04:31] <cradek> look for glCallList(cone_program) and then up a bit for glRotatef calls
[13:04:36] <cradek> those are angle and vector
[13:04:39] <cradek> brb
[13:04:44] <stustev1> ok
[13:17:14] <stustev1> I only found two glRotatef calls - one for 1 0 0 and one for 0 1 0. Is there one for 0 0 1?
[13:18:04] <stustev1> cancel that - further investigation reveals more glRotatef calls :)
[13:23:03] <anonimasu> :)
[13:23:12] <anonimasu> I have a workholding issue..
[13:23:15] <anonimasu> -_-
[13:23:25] <anonimasu> cutting a gearbox cover for a motor
[13:23:56] <anonimasu> the motor + gearbox is 36x11.9mm big :)
[13:24:34] <archivist_ub> heh big stuff
[13:24:41] <anonimasu> yeah
[13:24:50] <anonimasu> it's just in plastic though..
[13:24:57] <anonimasu> with a press fit :)
[13:25:48] <anonimasu> http://www.lawicel-shop.se/shop/assets/prod_images/pPOL-0994m.jpg
[13:26:33] <archivist_ub> you didnt have to scale the image down
[13:26:45] <anonimasu> uh.. it's not mine
[13:27:02] <anonimasu> that's probably the real size of it :)
[13:27:05] <anonimasu> atleast on my screen :)
[13:27:06] <archivist_ub> I was joking
[13:27:14] <anonimasu> 298:1 gearing
[13:27:57] <anonimasu> 90oz-inch of torque :)
[13:28:25] <archivist_ub> we have some nice small motors
[13:30:55] <archivist_ub> holding a small bit of plastic to make a cover could be "interesting"
[13:31:33] <anonimasu> hehe
[13:31:33] <anonimasu> yep
[13:31:36] <archivist_ub> working from solid?
[13:31:40] <anonimasu> yes
[13:31:48] <anonimasu> I think I'll just make the mount cover the gearbox
[13:32:12] <archivist_ub> I would work end on, and part off
[13:33:15] <archivist_ub> hmm noisy here some idiot using a jigsaw on sheet metal
[13:36:41] <anonimasu> crap. I dont have the tooling to do this.
[13:36:56] <archivist_ub> I tend to think in terms of using the best machine for the job, end mill out the inner space
[13:37:17] <anonimasu> oh.. I dont have any sub 1mm endmills..
[13:37:21] <anonimasu> 3 is the smallest
[13:37:34] <anonimasu> and the corner radii will make it not fit.
[13:37:42] <archivist_ub> glue sheet together then
[13:37:53] <anonimasu> I need 10 mounts :)
[13:38:10] <anonimasu> I'll cut the corners oversize..
[13:39:46] <archivist_ub> hmm plastic, broach the corners
[13:40:28] <anonimasu> I'd rather mill them in one setup :p
[13:40:40] <anonimasu> they dont have to be super tight..
[13:40:53] <anonimasu> well, airtight.
[13:40:56] <archivist_ub> we have manufactured keys with a press operation here
[13:41:54] <anonimasu> :)
[13:42:01] <anonimasu> it's a blind hole too..
[13:42:27] <archivist_ub> so were clock keys
[13:42:39] <anonimasu> you are better then I am...
[13:42:40] <anonimasu> :P
[13:43:04] <archivist_ub> get it wrong and you burst the item :)
[13:44:18] <anonimasu> ^_^
[13:44:21] <cradek> stustev1: if you reverse the cone rotation I think it will be goofy because the 5-axis preview won't match it anymore
[13:46:06] <stustev1> I need to reverse the cone and preview to match my machine.
[13:48:29] <cradek> is axis backward from the normal setup?
[13:49:25] <stustev1> yes - I believe it is - although normal is the operative word here
[13:50:09] <stustev1> I found two 'authoritative' NC programming books last night. They partially agreed on the direction of rotations.
[13:50:29] <cradek> looks like the two important calls are at line 971 in my trunk checkout
[13:50:45] <cradek> that's just for the cone
[13:50:50] <stustev1> One had the B axis and the A axis not in agreement (on the same machine).
[13:51:05] <stustev1> I think I found those for the cone.
[13:51:07] <cradek> hmm
[13:51:59] <stustev1> I think the best fix for everyone's machines would be to allow the integrator to choose
[13:52:12] <Lerman> stustev1: I saw your feature request.
[13:52:34] <Lerman> I suspect that user defined g/mcodes will make something like that reasonably easy.
[13:52:40] <stustev1> Lerman: does it make sense to you
[13:52:49] <cradek> stustev1: some lathes want the X axis point up too. there is a lot about the preview that could be more configurable
[13:53:08] <cradek> to point up
[13:53:13] <anonimasu> * anonimasu nods
[13:53:22] <Lerman> I could parse the words -- but I'm not sure why two point instead of one or N.
[13:54:15] <stustev1> N would be the best but I have never used more than two.
[13:54:33] <Lerman> My initial reaction was that who is the yahoo who is asking for crazy features. Then I realized that he was one of our yahoos. :-)
[13:54:59] <stustev1> If you need more than two points you are in way over your head
[13:55:29] <stustev1> you may as well back out and start over
[13:56:32] <Lerman> Refresh my memory... Is this at a coded pause, or is it at a GUI pause (or estop)?
[13:56:50] <stustev1> cradek: I haven't seen much about preview that I would 'fix'. It works well.
[13:57:34] <Lerman> Synchronous stuff (to the interpreter) is much easier to handle (at least from where I sit).
[13:57:41] <stustev1> Lerman: ideally this would take place at any arbitrary point. Hit feed hold when you see the cutter start to break down.
[13:58:39] <stustev1> manually move the cutter to a position to clear the work
[13:58:58] <Lerman> The issue I have is that the interpret may be many lines ahead. So either this is not done in the interp or the interp has to "back up".
[13:59:19] <stustev1> hit the button - this becomes the first return point after you change the cutter
[13:59:36] <stustev1> move the machine to a point where you can change the cutter or inserts
[13:59:50] <stustev1> reset the tool length if necessary
[14:00:42] <stustev1> hit cycle start and the machine moves to the return point and then moves the the location where it was last cutting and resumes cutting in the program
[14:02:45] <cradek> this sounds like an extra thing to keep in mind for the run-from-line rewrite
[14:03:28] <Lerman> "move the machine" means jog?
[14:03:30] <cradek> it's hardest if you're in the middle of an arc
[14:03:33] <stustev1> yes - it is something not often used but when it is it can be VERY nice - saves a bunch of time and effort
[14:03:46] <stustev1> yes - jog
[14:05:17] <cradek> if you did not have this, you would have to place the tool outside the work and pick a point in the program that gives you safe entry, and you would recut at least some of the program
[14:05:58] <cradek> or I suppose you could put the tool in the work, like at the beginning of the move where you had trouble, and restart at that move, but that's a bit scary
[14:06:37] <Lerman> What does feedhold do? I assume it stops instantly.
[14:06:51] <cradek> it decels and stops asap (realtime)
[14:08:22] <stustev1> cradek: the pick a safe entry point is good - it just gives another opportunity for human error.
[14:08:37] <Lerman> stu -- I assume you have a controller that supports that. Which one?
[14:09:09] <stustev1> fanuc
[14:10:29] <Lerman> I could imagine needing more that two points. Using a keyway cutter on the inside of a pocket. Move away from the wall, then vertically out of the pocket, finally to a point where the tool can be changed.
[14:10:56] <stustev1> cradek: reversing the preview - is that a difficult, involved thing?
[14:11:02] <Lerman> The keyway cutter was cutting a groove on the inseide of the wall.
[14:11:09] <anonimasu> that sounds really advanced
[14:11:35] <stustev1> Lerman: that is a very good example of use of the feature
[14:13:25] <Lerman> Diagonal jog is not supported. So even if you need to move from the center of the part to a corner to get to the tool, you would need to have two points juust for that.
[14:13:52] <stustev1> anonimasu: EMC2 is at the point that a feature it doesn't have will be advanced :)
[14:14:46] <Lerman> Conceptually, it is very simple.
[14:14:50] <anonimasu> hehe
[14:15:07] <stustev1> Lerman: a diagonal jog using two or more stopping points would not require each stopping point to be recorded for playback
[14:15:12] <cradek> stustev1: I looked briefly and didn't figure out where to do that... there is a separate position logger ... somewhere
[14:15:27] <Lerman> Ah. You are correct.
[14:16:44] <cradek> I would be scared of this feature, and I would restart the program where the keyway cutter is loaded...
[14:16:56] <stustev1> cradek: I can run with it the way it is - the screen just looks different than the machine motion
[14:17:03] <cradek> that's probably just me though. I am never in a hurry.
[14:17:30] <stustev1> once you have started in that fashion and it works your confidence level it a lot higher
[14:17:43] <stustev1> s/it/is
[14:18:13] <Lerman> Don't think of it as a keyway. Think of it as the finish pass of a mold for a complex three dimensional cam.
[14:20:05] <stustev1> or the middle of a program that runs for 120 hours kellering a contour that is 200 inches long
[14:20:51] <stustev1> finding a safe start point is sometimes a little tricky
[14:21:24] <cradek> stustev1: check out src/emc/usr_intf/axis/extensions/emcmodule.cc around line 1434
[14:21:38] <stustev1> checking
[14:22:13] <stustev1> i can see by the suffix this will be interesting. - .cc?
[14:22:55] <cradek> I think in here is the position logger that stores up the points that make up the display
[14:23:18] <cradek> I don't know if it is also responsible for the preview or if that's somewhere else
[14:24:47] <stustev1> doesn't look so bad - is see rotate z and y - I will look for rotate x
[14:25:10] <stustev1> I like the way the preview shows the tool length and diameter now - very nice
[14:25:13] <cradek> I bet there isn't one because this is for BC machines only
[14:26:07] <stustev1> my cinci is AB - the AB axis motions look good just reversed
[14:26:59] <anonimasu> what does kelering mean?
[14:27:05] <cradek> hmm
[14:27:20] <cradek> that puzzles me because I thought this was only BC so far
[14:27:53] <stustev1> kellering is also called lacing sometimes
[14:28:17] <stustev1> kellering is also called waterfalling
[14:28:50] <anonimasu> I dont know what that is either :/
[14:29:20] <stustev1> many cuts (either unidirectional or bidirectional) close together to machine a contour with a ball mill or a bull mill
[14:31:00] <stustev1> If you want to cut a corner radius on the top edges of a block with a ball mill instead of a corner round cutter you would need to make a lot of passes close together to contour the corner radius on the block.
[14:31:39] <anonimasu> ah yeah
[14:31:43] <stustev1> in the programming world it is called 'scrub'.
[14:31:55] <anonimasu> hm.. isnt that what masercam calls flow contouring?
[14:32:08] <stustev1> probably
[14:33:45] <stustev1> cradek: I thought so too. I was surprised when the AB motion looked as good it did in preview. I like it.
[14:34:22] <stustev1> I had a long discussion last night with SWPadnos about rotation direction.
[14:35:16] <stustev1> his comment was - fix your machine - :)
[14:36:41] <Lerman> It would probably be just fine in the southern hemisphere. :-)
[14:37:14] <stustev1> I hadn't thought of that - Brazil would be nice? RIO?
[14:37:40] <cradek> stustev1: well emc already does it consistently one way - I would sure make my machine match it, but I don't have any other machines (or cam software) it should also match
[14:37:40] <stustev1> bbl - working on the cinci
[14:38:11] <stustev1> cradek: and a LOT of programs - years of programs
[14:38:20] <cradek> yeah that too
[14:38:30] <stustev1> having fun now
[14:41:01] <Lerman> I consider stustev part of our adult supervision. :-) He's a strong link to the real world.
[14:52:06] <skunkworks_> funny :)
[14:57:01] <anonimasu> ^_^
[15:32:54] <fenn_> fenn_ is now known as fenn
[15:40:41] <jepler> cradek: how much load did you end up with on the 5V rail to get a good +-12V out of that PC power supply?
[15:42:06] <alex_joni> * alex_joni usually plugs in an old hdd
[15:43:22] <Lerman> I have 20 300 watt ten ohm resistors that I connect in parallel.
[15:43:41] <BigJohnT> * BigJohnT usually grabs a power supply off the shelf
[15:44:13] <alex_joni> 300W ?
[15:44:14] <cradek> jepler: I ended up with 5 ohm / 1 amp
[15:44:29] <cradek> not sure if it's right. I still seem to be getting only +-11.5
[15:44:48] <Lerman> Roughly $50 for the whole set on Ebay.
[15:46:29] <alex_joni> how big are those?
[15:47:12] <Lerman> They measure about two inches on a side and are 1/2 inch thick. They must be heatsinked.
[15:48:18] <alex_joni> nice
[15:48:36] <alex_joni> I have some 10W .1 ohm around ;) those are way smaller
[15:50:11] <Lerman> http://www.ebgusa.com/PDF/EBGCAT19.PDF
[15:50:56] <skunkworks_> I have some .015ohm...
http://www.ohmite.com/catalog/pdf/10_series.pdf
[15:50:57] <skunkworks_> ;)
[15:52:07] <alex_joni> oops.. I meant to type .01 ohm
[15:52:24] <alex_joni> for measuring current in an servo amp
[15:52:28] <Lerman> I bought them because I wanted to load test the line power at our summer place. I should look into connecting some of them as dump resistors on my servo controllers.
[15:52:44] <alex_joni> bbl
[15:55:03] <cradek> Lerman:
http://timeguy.com/cradek-files/emc/halscope-menu.png
[15:55:44] <Lerman> So does that mean the answer to my original question (who is the halscope guru) is cradek?
[15:55:50] <cradek> certainly not
[15:56:14] <Lerman> Nice. Does it work? or is it just a pretty picture at this time?
[15:56:26] <cradek> I only slogged through the gtk crap enough to add the menu - nothing is hooked up
[15:58:03] <Lerman> I think we might want an option to save the configuration file in the data file. That way a single file could be saved to reproduce a display. Maybe that should just be the default. The configuration file is a lot smaller than the data file.
[15:59:35] <cradek> the configuration often isn't going to work for someone else. imagine mine with a bunch of m5i20 pins hooked up, when I send it to you running sim/axis
[15:59:59] <cradek> viewing saved data is really a separate activity
[16:00:08] <Lerman> Well, it won't "work", but it should be usable as a viewer.
[16:00:16] <cradek> ideally it wouldn't even require a running emc
[16:00:32] <Lerman> Correct. It should NOT require emc.
[16:00:35] <cradek> it would skip all the hookups to hal.
[16:00:56] <Lerman> Exactly.
[16:01:32] <Lerman> It would still use the configuration info for the signal names, the gains, the time scale, etc.
[16:02:37] <Lerman> Opening a config file would connect. Opening a data file would just view. Perhaps something in the run mode panel could say that it was view only.
[16:03:29] <Lerman> Oops. Time to disappear for the weekend. I'll see you next week.
[16:03:39] <jepler> see you Lerman
[16:03:41] <cradek> ok, bye
[16:19:52] <micges> cradek: I was digging into emc yesterday and some things are not clear to me
[16:20:29] <cradek> I've had that feeling too
[16:21:09] <micges> heh
[16:22:12] <micges> in task directory , emccanon.cc what is it do ?
[16:23:08] <jepler> when gcode is interpreted, the "output" is a sequence of calls to the "canonical machining functions", such as STRAIGHT_FEED
[16:23:38] <micges> they are in interp_list I suppose
[16:23:58] <jepler> emccanon.cc takes those function calls and does the appropriate action, which yes is often putting something on the interp_list
[16:24:23] <jepler> another part of task takes those items from the interp_list in sequence and does something, like direct the I/O controller to change tools, or to direct the motion controller to move to a new location
[16:26:09] <micges> ok, and what path of command like c.spindle(0) is ?
[16:26:29] <micges> I saw that they not go to interp or so
[16:27:33] <jepler> no, that is transmitted to task through nml.
[16:28:54] <jepler> it is an EMC_SPINDLE_OFF message
[16:29:09] <micges> so task is in kernel module ?
[16:29:26] <jepler> no, task is the userspace executable "milltask"
[16:30:35] <jepler> an EMC_SPINDLE_OFF message will ultimately send a command to the realtime motion controller -- that's in the function emcSpindleOff()
[16:32:38] <micges> wrr, code is clear enough but connection between parts are not obvious
[16:36:42] <jepler> well -- I don't know what to say about that. I didn't have all this specific knowledge in my head when I started explaining it to you just now. Instead, I have general ideas (like 'gui sends NML message to task' and 'task sends messages to motion controller'), and a text editor that helps me go to places that a symbol is defined or used to actually find the steps of this specific case.
[16:37:55] <micges> ok
[16:38:20] <micges> then a couple specific questions
[16:38:54] <micges> in emcSpindleOff() there is usrmotWriteEmcmotCommand()
[16:41:25] <micges> copying command to shared memory and then what ?
[16:42:20] <jepler> and then waiting until it is received by the realtime motion controller
[16:42:30] <jepler> or do you want to talk about what happens in the motion controller?
[16:43:37] <micges> I would like to have general idea of data flow in emc
[16:43:51] <micges> where is realtime mot contrl ?
[16:44:11] <jepler> primarily in src/emc/motion and src/emc/kinematics
[16:45:18] <micges> next step is recive by emcmotCommandhandler ?
[16:45:55] <jepler> yes I think that's right
[16:46:21] <jepler> for the case of EMCMOT_SPINDLE_OFF you can see that it just sets the value of some items in emcmotStatus
[16:47:17] <jepler> later in output_to_hal, those are copied into the hal output pins of motion
[16:48:28] <micges> and that it ?
[16:49:25] <jepler> next that hal value is read and acted on by whatever the integrator connects to the hal pin
[16:49:46] <owad> How long does emc take to compile? It's been going at it for over 12 hours now...
[16:49:58] <micges> python -> emcmodule.cc -> nml -> emccanon -> realtime motion control -> update emc status -> output to hal ?
[16:50:04] <jepler> owad: that's very wrong.
[16:50:20] <cradek> owad: a couple minutes
[16:51:42] <archivist_ub> must be on a 486 with no/little ram and swapping
[16:51:53] <owad> stuff like: Depending limit2.9
[16:51:54] <owad> ../bin/comp --document -o ../docs/man/man9/limit2.9 hal/components/limit2.comp
[16:51:58] <jepler> micges: no, emccanon is not part of the picture when sending a "spindle on" message from emc. emccanon would be involved if you are running gcode that has an M3 or M5 command.
[16:51:59] <owad> keeps scrolling by, as if it's doing like it should
[16:52:30] <cradek> owad: are the time and date on your computer set right?
[16:52:30] <owad> I have it running in a virtual machine, on a 2.2 GHz MacBook w/4 GB RAM
[16:52:35] <owad> no
[16:53:02] <cradek> I recommend setting the time and date and getting a clean checkout
[16:53:16] <owad> ok
[16:53:16] <owad> thanks
[16:54:17] <micges> ok then what part of source interprets gcode ad pass calls to canon ?
[16:55:02] <jepler> micges: the stuff in emc/rs274 interprets gcode and makes canon calls. that's when emccanon.cc gets involved.
[16:57:26] <micges> jepler: thank you very much , that clear me enough
[16:57:50] <jepler> oh good, that means it's time for my lunch break
[16:58:16] <micges> :)
[17:01:12] <owad> fixing the clock did it. thanks
[17:01:57] <archivist_ub> cradek, is this the same as yours?
http://cgi.ebay.co.uk/HARDINGE-GN6-SERIES-CNC-LATHE-CHNC-CHUCKING-MACHINE_W0QQitemZ230281682763QQcmdZViewItem?hash=item230281682763&_trkparms=72%3A12|39%3A1|66%3A2|65%3A12|240%3A1318&_trksid=p3286.c0.m14
[17:58:13] <cradek> archivist_ub: it looks like the same basic lathe with a newer control. this one is CHNC (computerized) and mine is HNC (numeric control)
[17:59:07] <archivist_ub> ok , I cant afford it anyway!
[17:59:28] <cradek> if you want to retrofit, you can find a HNC for *much* cheaper
[17:59:39] <SWPadnos> where was yours?
[17:59:42] <archivist_ub> havnt seen one yet
[18:00:05] <cradek> denver CO
[18:00:46] <SWPadnos> hmmm. that's quite a ways
[18:00:50] <SWPadnos> even for you ;)
[18:00:54] <cradek> yep it was a looooong drive
[18:01:29] <cradek> two whole days and then some of driving
[18:01:47] <archivist_ub> but should I stick with gear cutting, heard of one of these for £100
http://www.nmteng.co.uk/gearmach/11178.jpg
[18:02:02] <cradek> but that's nothing compared to getting one from somewhere in the rust belt, where everything can be found
[18:02:28] <cradek> archivist_ub: nice!
[18:03:32] <archivist_ub> plus a few bits from here
[18:32:49] <pjm> btw can i pick the brain of an emc guru? I've added a meter via pyvcp to axis that I want to tie spindle RPM to. I've got the sensor mounted and get a clean signal (4 ppr) which is fed into the parport, can i get some pointers about how i calculate the RPM and display it?
[18:33:46] <alex_joni> pjm: you set up a counter
[18:33:59] <jepler> "encoder" has a nice velocity estimate output. It can work from quadrature encoders or from a single channel (in which case it can't tell direction).
[18:34:00] <alex_joni> which counts the pulses, then you need to scale the signal to get RPM
[18:34:35] <pjm> ahh ok got ya, so where do I get the reference timing from to use to calc the rpm?
[18:34:50] <alex_joni> you know you have 4 pulses/turn
[18:35:03] <alex_joni> so you count the pulses / second (which encoder already does)
[18:35:09] <pjm> right
[18:35:12] <alex_joni> than divide that by 4 to get turns / second
[18:35:22] <alex_joni> then multiply that by 60 to get turns/minute
[18:35:24] <pjm> ok cool, i will do some more rtfm'ing
[18:35:39] <pjm> but cool, thanks for the pointers, it gives me something to work on!
[18:36:01] <jepler> you can find something similar to what you need in configs/nist-lathe/nist-lathe.hal and configs/sim/lathe.hal
[18:36:19] <pjm> ok great i will have a look at that - thanks ;-)
[18:36:37] <jepler> both of those use a low-pass filter on the speed value, but as long as your pulses are equally spaced I don't think that will be necessary.
[18:37:13] <jepler> (you probably want to use encoder in counter mode, not counter; only encoder has the high quality velocity estimate mode)
[18:37:21] <pjm> yeah i looked at the pulse train and it looks reasonable
[18:37:53] <pjm> but ok i will check out those hal's and have a play
[18:38:46] <anonimasu> :)
[18:45:01] <jepler> if you don't want to use feed per revolution mode then you can set the encoder scale to 4*60 so the output is rpm instead of rps
[18:45:38] <alex_joni> jepler: I think you mean 60/4 = 15
[18:47:12] <jepler> ummmm now I'm not sure what I mean :-P
[18:47:22] <jepler> I bet that 4 and 60 will figure in it though
[18:47:30] <pjmemc> ok i will test it with a 1K squarewave up the input first until I have the numbers correct
[18:56:28] <alex_joni> pjmemc: that's 15kRPM
[18:56:42] <alex_joni> you have such a fast spindle?
[18:58:09] <pjmemc> no it'll just be for testing
[18:58:16] <pjmemc> i'll set the scale to 1
[18:58:30] <alex_joni> ok then :)
[18:58:30] <pjmemc> to make sure it reports 1k rpm
[18:58:44] <pjmemc> just so i get me head round it first !
[18:59:10] <alex_joni> pjmemc: great plan
[18:59:41] <pjmemc> i want to learn it rather than just copy off google ;-)
[18:59:48] <alex_joni> even better plan
[18:59:59] <pjmemc> as i have great plans for my cnc
[19:00:32] <jepler> now you have me wishing for spindle speed feedback too
[19:01:00] <pjmemc> hah well once i have it working i'll paste my hal somewhere for critique
[19:01:28] <pjmemc> i thought it might be nice to monitor the spindle speed so i can see the effect of a cut on it
[19:01:33] <jepler> wiki.linuxcnc.org is always a good place to put durable stuff about emc
[19:01:55] <pjmemc> and then once the spindle is controlled via pwm output i can get an idea of loading by comparing commanded to actual
[19:02:10] <pjmemc> and automatically adjust feed rates etc to keep the load constant
[19:02:21] <jepler> yep that is sure a possibility
[19:02:49] <pjmemc> i have to add a pwm input to my mini-mill head too, the dc side floats at 1/2 mains volts so that should be fun
[19:02:51] <alex_joni> adaptive feed rate is the buzz word
[19:02:59] <pjmemc> hehh
[19:03:11] <pjmemc> well the Haas minimill does it and i'm sure EMC can too
[19:03:17] <pjmemc> except better
[19:03:22] <jepler> yeah -- when you turn on adaptive feed with M52P1 you can feed a value from 0.0 to 1.0 to the hal pin motion.adaptive-feed to control the speed as a fraction of the commanded F-number
[19:03:32] <alex_joni> it does, not sure if better.. but it does it well
[19:03:41] <jepler> well I have no idea how that compares to haas
[19:04:09] <pjmemc> i was giving me dad a demo of my cnc, he consults to a company that has a tonne of haas machining centres
[19:04:22] <pjmemc> and none of them give a 3d view of the g-code
[19:04:44] <pjmemc> but the haas machines do have a lot of monitoring of loads etc on the axis's and spindle motor etc
[19:05:02] <pjmemc> so i thought it would be nice to have an even more verbose display of what the machine is up to
[19:05:17] <alex_joni> cnc machine controller fight-off
[19:05:24] <anonimasu> :p
[19:05:46] <pjmemc> hehh well the latest haas mini-mill they bought seems to be based on a PC for the controller
[19:05:50] <micges> what means load ?
[19:06:06] <pjmemc> effort to turn motors per axis
[19:06:06] <micges> for non-english speaker
[19:06:17] <alex_joni> micges: effort to cut
[19:06:17] <pjmemc> so cutting air is no load
[19:06:28] <anonimasu> dont haas have several control boards for closed loop?
[19:06:32] <anonimasu> (I think)
[19:06:34] <jepler> "The external mechanical resistance against which a machine acts."
[19:06:38] <alex_joni> if you go faster with the same spindle speed, you get higher load
[19:06:53] <micges> ok :)
[19:07:05] <alex_joni> (nothing related to plasma or laser)
[19:07:19] <pjmemc> anonimasu, i'm not sure re the closed loop, but from talking to the haas engineer a lot of the positioning stuff is handed off to intelligent controllers
[19:07:40] <pjmemc> i must take some foto's of the electronics etc, they dont mind be opening the cabinets and u can do so whilst the machines are running
[19:08:23] <anonimasu> pjmemc: that would be where the stuff happens :P
[19:08:26] <pjmemc> but i'm trying to twist the haas engineers arm to 'find' me a mpg pendant, he has a garage full of stuff that he's hoarded
[19:08:49] <micges> alex_joni: I have 3 table mill under emc too ;)
[19:09:07] <alex_joni> micges: ok then :)
[19:10:38] <alex_joni> * alex_joni heads to bed
[19:10:41] <alex_joni> good night all
[19:10:45] <micges> gn alex
[19:18:30] <micges> it took me about 8 hours to program bypass of inconsistents run-from-line(arc) function, but it works and now waiting for fix(improvement)
[19:19:36] <micges> SWPadnos: remeber about mail to emc-users about new approach to run-from-line behaviour ?
[19:19:48] <SWPadnos> yes, haven't done it yet :)
[19:24:38] <stustev1> cradek: you are correct - the A axis preview does not tilt the tool - i was looking at it from the perspective and thought it did.
[19:24:51] <SWPadnos> heh
[19:24:56] <stustev1> hi!
[19:24:59] <SWPadnos> middle-drag sure tilts the tool ;)
[19:25:01] <SWPadnos> hi
[19:25:08] <SWPadnos> and the path
[19:41:55] <tomp> I need to replace a Fanuc motor rated in Nm with a motor supplied by Panasonic rated in W. argh! how to translate Newtonmeters to watts??? on is force and other is work!
[19:44:17] <tomp> hmmm Nm/s does xl8 to W
[19:44:38] <SWPadnos> heh
[19:44:48] <SWPadnos> Watt-seconds is work, I think
[19:47:05] <tomp> urf! i got a 1:1 relation ( i dont believe 1234W = 1234Nm/s :(
[19:47:13] <SWPadnos> heh
[19:47:24] <SWPadnos> hmmm - it could be actually
[19:47:59] <SWPadnos> watts are kg*m^2/s^3
[19:48:19] <SWPadnos> newtons are kg*m/s^2
[19:48:34] <SWPadnos> N-m is therefore kg*m^2/s^2
[19:48:41] <SWPadnos> so Nm/s == W
[19:50:47] <tomp> wow, thanks ( it >was< hard to believe, but i believe it now )
[19:50:59] <SWPadnos> heh - smart calculators to the rescue :)
[19:51:15] <SWPadnos> I love the units catalog in my HP 28-series calculators
[19:51:44] <tomp> hp calculators, the slip-stick killer from the 70's
[19:51:58] <SWPadnos> well, mine are from the '80s-'90s
[19:52:07] <SWPadnos> slipsticks were already dead ;)
[19:53:43] <skunkworks_> 'save the slide rule foundation'
[19:53:49] <tomp> ah, i see my error, one was force, other was energy ( not work )
[19:54:10] <tomp> thx thx thx thx, back to work
[19:54:18] <SWPadnos> heh - see you
[21:06:18] <mozmck> do I want to disable apic in the bios or just acpi?
[21:41:43] <seebo> I'm new to IRC and EMC2. I'm hoping somone can help me hooking an Arduino up to EMC
[21:43:46] <seebo> based on the article at
http://axis.unpythonic.net/01198594294 I've been buiding a jog pendant using Arduino
[21:44:28] <seebo> I've got hold of an i2c based LCD so I can display current machine position on the pendant
[21:44:59] <seebo> Everything works, but the problem is it shows machine position, not relative position
[21:45:29] <seebo> So cna nayone suggest how to pick either relative position or current offset out of Axis?
[21:46:02] <alSMT> chose it from the gui
[21:46:36] <seebo> Yes, I can see it on the axis screen, but how to access this value via halui etc?
[21:47:56] <alSMT> not sure myself
[21:50:39] <seebo> I'm using the axis.0.joint-pos-cmd pin to read X position, but this is machine pos whatever the GUI setting
[21:51:35] <seebo> the EMC status window shows machine position and offset - where's it get the offset from?
[21:52:54] <alSMT> offset.var table
[22:02:15] <tomp> "asperities: Microscopic peaks found on all surfaces. Contact between asperities causes friction" huh! down with asperities!
[22:03:39] <skunkworks> seebo: I think you need to read this
http://www.cnczone.com/forums/showthread.php?t=60199
[22:03:55] <skunkworks> (if I am understanding what you are asking)
[22:05:35] <dmess> hi all...
[22:05:38] <mozmck> hi. is it advantageous to realtime performance to disable APIC in the BIOS?
[22:06:09] <seebo> skunkworks: looks promising -
[22:10:01] <tomp> mozmck: yes, an advantage, please read
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting#APM_and_ACPI_bios_settings
[22:16:50] <tomp> on cnczone, someone asked for big dro in axis. does the big dro here work?
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?PyVCP ( not running rt right now )
[22:17:07] <tomp> does this technique work?
http://linuxcnc.org/docs/devel/html/gui_axis.html#r1_11_2
[22:17:20] <seebo> skunkworks: right on the money, thanks!
[22:17:34] <seebo> I'm running EMC 2.2.6: I guess the fix mentioned by Ray Henry isn't there yet?
[22:17:46] <mozmck> tomp, I know about ACPI, but I was asking about APIC! I disabled it and then figured out it is an Advanced Programmable Interrupt Controller, not the power save stuff.
[22:18:08] <mozmck> so I don't know if it hurts or helps to disable it.
[22:20:42] <tomp> mozmck: ah, sorry, if it's a bios setting, and it bothers rtai, then it ought to be on that page OR at the RTAI sites
[22:21:37] <mozmck> ok, thanks!. I'll try the RTAI site. I didn't find anything on the emc site.
[22:22:17] <skunkworks> seebo: I don't see it in the 2.2.6 release notes.
[22:22:31] <skunkworks> you may have to compile from source.
[22:23:57] <tomp> mozmck: google rtai apic, there a lot of talk about it
[22:25:57] <seebo> skunkworks: I feared so! To borrow a quote from Raymond Chen, now I have two problems...
[22:27:14] <seebo> I'll try contacting Ray Henry first
[22:30:21] <mozmck> There's some information here:
http://www.captain.at/rtai-manual.php?rtai=5
[22:31:36] <mozmck> looks like it can help to leave APIC enabled, but maybe only if RTAI is compiled for it. It says that if RTAI is not compiled with APIC support it will give an error.
[22:32:17] <mozmck> that makes me think that the RTAI with emc2 is not compiled with APIC support, since I don't get an error. Is this true?
[22:36:27] <tomp> i think the beginning of one of captain's comments is... apic is not automaticlly turned on by newer kernels (please check i am running off memory ;)
[22:37:46] <tomp> still, if no one here ever had to fiddle with APIC, you're entirely free to make a report of the benefits on the wiki ;)
[22:38:02] <mozmck> hmmm, I'll have to dig in further when I have more time (hah!)
[23:55:34] <dmwaters> {global notice} Good day folks, we are having some general major routing problems, We apologize for the inconvenience, and thank you for using freenode!
[23:59:27] <mozmck> what's with everyone leaving and re-entering?
[23:59:27] <archivist_ub> netsplit
[23:59:28] <mozmck> does freenode kick everone every so often?
[23:59:28] <mozmck> netsplit?
[23:59:30] <archivist_ub> no its a server interconnection problem
