Back
[00:13:19] <LawrenceG> most people seem to have lost any concept of physics
[00:14:21] <LawrenceG> although a dvd burner laser diode is quite powerful... burns holes in black electrical tape!
[00:15:20] <LawrenceG> friday nite... yahooooo
[00:18:57] <skunkworks> finally
[00:20:11] <skunkworks> LawrenceG: saw that on a video somewhere.
[12:57:58] <fenn> alex you should use a typedef in halui.cc so you dont have to duplicate that big hairy struct
[13:43:35] <jepler> one contains pointers and the other doesn't, if I understand which struct you mean
[13:53:56] <alex_joni> right
[13:54:31] <alex_joni> morning guys
[14:07:09] <jepler> lyx won't let you insert a footnote in a footnote :(
[14:07:59] <alex_joni> heh
[14:08:13] <alex_joni> how about a sidenote?
[14:13:24] <fenn> a depthnote?
[14:14:41] <fenn> why does one struct use pointers and the other doesnt?
[14:14:56] <jepler> fenn: one must because it is a struct of HAL pins
[14:15:10] <jepler> the other doesn't because it's not necessary -- it's the internal copy of the earlier state of each of the pins
[14:16:20] <fenn> why cant you just make two instances of the struct type and point one of them at hal pins?
[14:16:45] <jmkasunich__> what are you gonna point the other one at?
[14:16:57] <jepler> you'll waste as many lines creating all the pointers in the second struct as you do declaring it
[14:17:51] <jmkasunich__> I suppose I shouldn't comment more unless I look at what jeff is doing...
[14:17:55] <jmkasunich__> but what the heck
[14:18:07] <jmkasunich__> what about a struct that contains a single pointer and a single value
[14:18:17] <jmkasunich__> then make a struct of however many of those you need
[14:18:28] <jmkasunich__> that keeps the pin and the location where you store the pin's old value together
[14:32:55] <alex_joni> yeah, but some are bit, some are float, some are params (no internal copy), etc
[14:33:30] <alex_joni> I agree it's not the prettiest thing, but you won't save much either way
[14:55:20] <fenn> i'm having a bit of trouble with vismach order of operations
[14:55:48] <fenn> i want something to rotate around the tool-tip, but it rotates around the starting point instead
[14:58:19] <fenn> http://fenn.dyndns.org/pub/irc/hexapod_rotate.png
[15:00:30] <fenn> and here's da code
http://pastebin.ca/735324
[15:01:43] <fenn> i'm guessing i need to make a Collection somewhere to provide the point of rotation?
[15:04:00] <cradek> to rotate something around a point that's not the origin, you translate it to the origin, rotate it, then translate it back
[15:04:13] <cradek> (beware I haven't looked at the code)
[15:12:14] <alex_joni> hmm.. 39F outside
[15:33:03] <fenn> aha - rotate first, then translate
[15:33:45] <alex_joni> translate to rotation point, rotate, translate back
[15:38:40] <fenn> i was translating an unknown amount first, so i couldn't translate to the origin
[17:17:52] <alex_joni> bbl
[19:42:54] <alex_joni> ever heard of Ethercat?
[19:43:53] <alex_joni> http://en.wikipedia.org/wiki/EtherCAT
[19:44:03] <alex_joni> seems to be pretty widespread lately
[19:47:06] <alex_joni> "Data for and from 100 servo axis can be updated with up to 10 kHz."
[19:48:10] <alex_joni> you might wonder why this is interessting..
[19:52:05] <alex_joni> http://mmmir.de/download/emc2_ethercat.tar.gz <- HAL comp to control 4 inputs & 4 outputs over ethercat
[19:56:26] <jepler> * jepler downloaded it -- seems like 'spin_lock' is not suitable for realtime code
[19:57:15] <alex_joni> hal_mutex_get() ?
[19:58:47] <alex_joni> or does spin_lock something else?
[20:02:49] <jepler> I think it blocks waiting to get the lock
[20:05:07] <alex_joni> right, it should probably skip the execution, until it's available
[21:06:18] <cradek> jepler: stepconf should do -?
[21:16:14] <cradek> did I not get some of the changes? I thought we changed some defaults, like rotary velocity
[21:20:11] <cradek> jepler: I have a problem with amp enable which is hooked to parport pin 1. It doesn't enable even though halmeter says it comes on
[21:21:48] <cradek> strange. when I take out the doublestep stuff, it still doesn't work
[21:21:59] <cradek> rebooting...
[21:29:03] <cradek> hmmm
[21:29:11] <cradek> I can run emc once per reboot
[21:29:17] <cradek> subsequent times, I get nothing on the parport
[21:29:23] <cradek> rebooting...
[21:37:36] <cradek> I can run my old config several times, but the stepconf generated config only once per reboot
[21:38:21] <cradek> after I run the stepconf config, my old config also stops working
[21:38:25] <cradek> rebooting...
[21:41:58] <cradek> aha! removing loadrt probe_parport fixes this problem
[21:42:26] <SWPadnos> isn't that interesting
[21:42:38] <SWPadnos> does probe_parport reserve the IO region or something?
[21:43:35] <cradek> I haven't looked yet, I'm going to continue testing instead
[21:44:14] <SWPadnos> hhe
[21:44:16] <SWPadnos> heh
[21:44:29] <SWPadnos> I'll continue trying to find out why my VHDL code does strange things
[21:46:53] <jepler> cradek: hm, that's odd
[21:47:12] <cradek> I think there are major problems with doublestep
[21:48:10] <cradek> pin 1 gets inverted, pin 14 gets stuck on
[21:48:38] <cradek> if I take out probe_parport and doublestep stuff, my stepconf config does work right
[21:48:45] <cradek> (including the rotary)
[21:54:52] <cradek> yes with doublestep, pin 14 is stuck on
[21:55:26] <cradek> I think pin 1 is working
[21:57:00] <cradek> jepler: if you want to work on this, come on over
[22:06:10] <jepler> cradek: so unmotivated
[22:06:43] <jepler> I'm sure the control port stuff is just an oversight, I'm more curious about the probe_parport stuff..
[22:08:05] <cradek> I meant to test the rotary axis vs. doublestep stuff, but you've since broken it worse so I can't...
[22:08:25] <cradek> but yeah, I agree the probe_parport stuff is very troubling.
[22:20:13] <jepler> can you get me dmesg from the first and second loads of probe_parport?
[22:39:50] <cradek> let me try
[22:40:44] <cradek> can I just halrun, loadrt probe_parport, unloadrt prob_parport, etc?
[22:40:56] <jepler> probably
[22:41:57] <cradek> I do not see anything in dmesg [the first time]
[22:42:22] <cradek> Module Size Used by
[22:42:22] <cradek> probe_parport 3464 0
[22:43:11] <cradek> the first unload, I get:
[22:43:11] <cradek> [ 3772.093577] pnp: Device 00:07 disabled.
[22:43:27] <cradek> second load:
[22:43:27] <cradek> [ 3796.611335] pnp: Device 00:07 activated.
[22:43:56] <cradek> second unload, same 'disabled' message
[22:44:10] <jepler> rtapi_print_msg(RTAPI_MSG_INFO, "parport: PnPBIOS parport detected, io_lo=%lx io_hi=%lx\n",
[22:44:14] <jepler> io_lo, io_hi);
[22:44:26] <cradek> I must not have _INFO
[22:44:36] <cradek> reboot...
[22:44:58] <cradek> I'm at a different screen now
[22:45:50] <cradek> someone remind me how to turn on _INFO?
[22:46:55] <jepler> echo ... > /proc/rtapi/debug ?
[22:47:07] <jmkasunich__> echo 4
[22:48:04] <cradek> first load:
[22:48:05] <cradek> [ 113.127673] HAL: component 'probe_parport' initialized, ID = 03
[22:48:05] <cradek> [ 113.127735] parport: PnPBIOS parport detected, io_lo=378 io_hi=778
[22:48:34] <cradek> second load:
[22:48:37] <cradek> [ 148.516278] HAL: component 'probe_parport' initialized, ID = 03
[22:48:37] <cradek> [ 148.518162] pnp: Device 00:07 activated.
[22:48:37] <cradek> [ 148.518172] parport: PnPBIOS parport detected, io_lo=378 io_hi=778
[23:27:50] <jepler> that sure all looks ok
[23:28:15] <cradek> it seems strange that it says `activated' only the second time
[23:29:29] <jepler> it was activated before the first run, presumably by the BIOS
[23:29:41] <cradek> oh ok
[23:30:23] <jepler> int pnp_activate_dev(struct pnp_dev *dev)
[23:30:28] <jepler> if (dev->active) {
[23:30:28] <jepler> return 0; /* the device is already active */
[23:30:33] <jepler> ...
[23:30:34] <jepler> dev->active = 1;
[23:30:34] <jepler> pnp_info("Device %s activated.", dev->dev.bus_id);
[23:30:34] <jepler> return 1;
[23:30:39] <cradek> ok
[23:31:16] <cradek> so it would make sense that my old config (no probe) would stop working after running the new one (probe)
[23:31:23] <jepler> yes
[23:31:28] <cradek> but, the new one should keep working
[23:31:30] <jepler> yes
[23:31:46] <jepler> I wonder what behavior you see if you remove the call to pnp_unregister_driver in probe_parport.c:rtapi_app_exit
[23:37:42] <cradek> trying...
[23:39:55] <jepler> I can add a checkbox for probe_parport, but I would rather have it be harmless and not burden the user with more questions
[23:45:17] <cradek> taking out the unregister does make it seem to work
[23:47:03] <cradek> with doublestep: pin 1 works, pin 14 is stuck on
[23:47:36] <cradek> but I am getting only the very occasional steps
[23:47:56] <cradek> I'll get the scope - maybe pins 1,14 are both unstable and I can't tell the difference
[23:52:04] <cradek> pin 1 does work
[23:52:18] <cradek> pin 14 is stuck *low*, sorry, I forgot I have an invert there
[23:56:17] <cradek> I *am* getting step pulses but my drives are ignoring them. they are 3.4us long.
[23:59:24] <cradek> there are also step pulses on pin 9, also 3.4us long
