Back
[02:04:12] <JT-Hardinge_> JT-Hardinge_ is now known as JT-Hardinge
[13:29:15] <skunkworks> logger_dev: bookmark
[13:29:15] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-11-08.txt
[13:30:22] <skunkworks> cradek: I think that we should have a slight time delay after the up switch is hit.
[13:30:38] <skunkworks> but I have not scoped it yet
[14:05:58] <cradek> yeah, either that or two switches for 'fully up' and 'fully down'
[14:06:16] <cradek> one switch isn't enough, if it takes seconds to move
[14:09:49] <skunkworks> hmm - really? I have a up switch hooked into the unlocked pin.
[14:10:48] <skunkworks> I wasn;t really worried about the fully down - as I figured it would be down by the time I would be rapiding back to cut something.
[14:35:34] <cradek> yeah what I meant was you need hysteresis before giving it to is-unlocked
[14:39:06] <skunkworks> everything is falling togather.
[14:39:44] <skunkworks> I still don't know what was happening to the home to index.
[14:39:57] <skunkworks> odd
[14:43:49] <skunkworks> didn't get to cutting though.
[14:48:14] <cradek> yeah that kind of worries me - sure looked odd.
[14:49:04] <skunkworks> cradek: when you get a chance - you should slow your search velocity and see if you see it on your rotory.
[14:49:49] <cradek> ok
[14:51:22] <skunkworks> when are you guys leaving for the fest?
[14:51:45] <cradek> thursday late afternoon probably
[14:52:00] <qq-> psha, greetings
[14:52:18] <cradek> hi dgarr
[14:52:36] <cradek> are you at all close to wichita?
[14:52:58] <dgarr> nope
[14:53:10] <cradek> darn.
[14:54:03] <psha> qq-: hey
[14:54:12] <psha> i've written filter for your cam :)
[14:56:12] <qq-> psha,
http://paste.debian.net/99300/ , cool
[14:57:06] <psha> install libv4l-dev from my repo
[14:57:12] <psha> update cu-plugins
[14:57:18] <psha> and make convert_v4l.so
[15:10:17] <qq-> psha, how ? > update cu-plugins
[15:12:08] <psha> git clone git://psha.org.ru/psha/cu-plugins
[15:17:22] <qq-> psha, bad news, libv4l-dev removed my qv4l2 v4l-utils, and now qv4l2_0.8.1-2 wont show any image
[15:20:27] <psha> bad...
[15:20:42] <psha> try convert_v4l plugin
[15:20:49] <psha> maybe it's working
[15:21:59] <qq-> cd cu-plugins/ ; make convert_v4l.so 'make: *** [convert_v4l.o] Error 1
[15:22:13] <qq-> so ? or
[15:22:30] <psha> make convert_v4l.o
[15:22:31] <psha> :)
[15:23:16] <qq-> same ..
[15:23:44] <psha> what's error?
[15:23:56] <psha> try to comment pkg-config --cflags opencv line
[15:24:22] <qq-> http://paste.debian.net/99303/
[15:25:25] <psha> libcamunits6-dev
[15:25:46] <psha> wait
[15:25:49] <qq-> hm, missed camunits too
[15:25:52] <psha> i'll build package with it
[15:26:00] <psha> squeeze?
[15:26:06] <qq-> yes
[15:26:34] <psha> http://psha.org.ru/p/convert_v4l.so
[15:26:49] <psha> it depends only on camunits and v4lconvert lib
[15:26:59] <psha> which are equal on our systems
[15:27:44] <qq-> o package 'opencv' found < so now install libcv-dev
[15:27:56] <qq-> no*
[15:28:08] <psha> not needed
[15:28:14] <psha> it's for opencv plugins
[15:28:23] <psha> convert depends only on libv4l-0
[15:28:25] <qq-> okey
[15:29:21] <qq-> so i copy convert_v4l.so to /usr/lib ?
[15:29:29] <psha> somewhere in /tmp :)
[15:29:37] <qq-> okey
[15:29:38] <psha> camview -p /tmp
[15:29:45] <psha> it's look there for plugins
[15:30:49] <qq-> make convert_v4l.o | make: `convert_v4l.o' is up to date
[15:31:10] <qq-> so now was build on my system
[15:31:29] <psha> so run camview -p.
[15:31:36] <psha> and send my .so file to trash
[15:33:07] <qq-> ok, camview not changed ... no display
[15:33:29] <psha> add your input device
[15:33:40] <psha> then select convert v4l plugin
[15:33:43] <psha> and then opengl renderer
[15:34:44] <qq-> can't see 'convert v4l plugin' ..
[15:34:58] <psha> it's 'convert unknown ....
[15:35:14] <psha> "Convert from unknown v4l formats
[15:35:26] <psha> in section 'convert'
[15:35:32] <qq-> not here
[15:35:52] <qq-> here is old camview
[15:36:01] <psha> not important
[15:36:15] <psha> camview -p 'path-to-dir-where-convert_v4l.so lives'
[15:39:47] <psha> check output of camview
[15:39:55] <psha> it prints what it's loading and why
[15:40:51] <qq-> okey now i have convert from unkn...
[15:41:14] <qq-> but my camera is off
[15:43:31] <qq-> http://paste.debian.net/99305/
[15:44:23] <qq-> ok, camera is on
[15:46:20] <qq-> but camview say it is off ...
[15:48:07] <qq-> and camview segfault on saving my camera output.log
[15:48:38] <psha> ** (camview:8695): WARNING **: /home/ee/cu-plugins/convert_v4l.o: only ET_DYN and ET_EXEC can be loaded
[15:48:52] <psha> oops
[15:54:25] <qq-> * qq- back in ~20 min
[16:05:44] <psha> qq-: so let's solve segfault now
[16:08:43] <psha> bbl
[16:21:59] <mshaver> Where can I find the source for the kernel used in the Lucid CD? It doesn't seem to be in git.linuxcnc.org/infrastructure (Hardy is there).
[16:24:57] <skunkworks> I don't know if this is it..
http://www.linuxcnc.org/mozmck/
[16:25:25] <skunkworks> or
http://www.linuxcnc.org/lucid/
[16:25:39] <cradek> mshaver: it's in apt, like normal:
http://linuxcnc.org/emc2/dists/lucid/base/
[16:25:50] <cradek> you should already have an apt source that finds it
[16:26:47] <mshaver> Thanks! I need to remake a module - usbtouchscreen
[16:27:11] <cradek> you should be able to build a kernel module with just the linux-headers package installed
[16:27:25] <cradek> sure hope you don't have to build the whole dang thing
[16:27:33] <mshaver> me too
[16:27:46] <mshaver> the headers package has the module sources?
[16:28:07] <cradek> oh I misunderstood - I thought you were building a new kernel module, not one that was part of the kernel
[16:30:16] <mshaver> No - I have an egalax touchscreen that doesn't get devices created for it in /proc/bus/input/devices
[16:30:42] <cradek> oh - you probably just need a udev entry, not a rebuild
[16:31:00] <mshaver> I think I need to modify usbtouchscreen.c
[16:31:45] <qq-> psha, back
[16:31:52] <cradek> add a new USB_DEVICE(....)?
[16:32:09] <cradek> what are your numbers?
[16:33:22] <mshaver> Do you mean the Vendor & Product IDs? I don't get any devices created in /dev/input
[16:33:30] <cradek> check lsusb
[16:34:01] <mshaver> it shows up in lsusb, but nothing get created in /dev/input
[16:34:13] <cradek> I understand :-)
[16:34:27] <mshaver> I wish I did :)
[16:35:19] <cradek> what does it show up as in lsusb?
[16:35:49] <mshaver> Bus 001 Device 005: ID 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen
[16:36:18] <cradek> alias: usb:v0EEFp0001d*dc*dsc*dp*ic*isc*ip*
[16:36:37] <cradek> my usbtouchscreen (ubuntu 10.04 2.6.32-25-generic) has that one
[16:37:00] <cradek> yours doesn't? (I don't have a linuxcnc-kernel machine here)
[16:37:34] <cradek> (I got that from modinfo usbtouchscreen)
[16:37:43] <mshaver> I don't know - I haven't installed the kernel sources yet
[16:37:53] <mshaver> hold on, let me check
[16:40:23] <mshaver> yes, mine does
[16:40:35] <cradek> interesting
[16:40:42] <cradek> does dmesg say anything useful when you plug the device in?
[16:41:14] <SWPadnos> "lsusb -vvvv -s 001:005" might also show some useful info
[16:41:34] <SWPadnos> (unless it's been unplugged/replugged, in which case the second number is likely to have changed)
[16:41:49] <cradek> did you see
http://ubuntuforums.org/showthread.php?t=1541396
[16:42:09] <mshaver> I was thinking this was the problem:
http://ubuntuforums.org/showpost.php?p=6625125&postcount=16
[16:42:21] <mshaver> looking at your link...
[16:43:03] <cradek> oh you want to *remove* it from usbtouchscreen? you could just blacklist the module.
[16:44:07] <mshaver> Actually, I want usbtouchscreen to stop ignoring it because it thinks it's usbhid compatible
[16:44:10] <cradek> the internet doesn't agree on whether it's supposed to be a usb-hid device or a usbtouchscreen device
[16:44:51] <cradek> gotcha
[16:45:09] <mshaver> I get: "generic_usb probe failed with error -32" when I plug it in - and no /dev/input devices created
[16:45:33] <cradek> ok - maybe you are right - they are both ignoring it.
[16:47:22] <mshaver> actually I think I'd rather have it be handled by usbhid (as a generic human interface device), but I can't find any reference on how that should work
[16:48:02] <cradek> I wonder which method it actually supports
[16:49:18] <mshaver> One guy (in that post I referenced) says he got it to work with usbtouchscreen - I'd settle for that!
[16:49:52] <mshaver> Is usbtouchsreen compiled as a moudule for -122, or is it (gulp) built in?
[16:50:17] <cradek> maybe you can force usb-hid to recognize it by setting quirk 0x10
[16:50:27] <cradek> or 0x80?
[16:51:01] <cradek> if you got something from modinfo, it's a module
[16:51:01] <mshaver> And how would I do that (said Matt who knows nothing of quirks, save his own)?
[16:51:23] <cradek> http://ubuntuforums.org/showpost.php?p=9745870&postcount=3
[16:51:31] <mshaver> reading...
[16:51:45] <cradek> list of quirks you can play with, here:
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/include/linux/hid.h#L303
[16:52:43] <cradek> this person is also playing with an 0eef:0001 device
[16:54:59] <mshaver> OK, this is solid stuff I should try! I'll poke at this for a bit and get back to you in 15-30 mins!
[16:55:13] <cradek> 60-90-240 :-/
[16:55:38] <cradek> good luck :-)
[16:56:10] <mshaver> actually, I'm about 360-420 into this touchscreen thing so far...
[17:06:36] <cradek> is that the inexpensive little screen marketed for car use?
[17:07:05] <mshaver> yep
[17:07:26] <cradek> ah - I have one of those too
[17:07:50] <mshaver> tried it yet?
[17:08:03] <cradek> a couple years ago?
[17:08:12] <cradek> it was hard to get to work - same as yours
[17:08:17] <cradek> I did finally get it to work
[17:08:25] <mshaver> it probably worked with hardy or Dapper
[17:09:03] <cradek> the touchscreen worked for about 5 minutes and then began to always think it was being touched in a certain place. :-/
[17:09:38] <cradek> I sometimes still use it as a tiny portable screen - I don't try to use the touch part anymore.
[17:10:19] <mshaver> upper left corner? that's another reported problem...
[17:10:34] <cradek> I don't recall - I think it was in the middle somewhere
[17:10:46] <cradek> if I touched it, the pointer would move from there to my finger, and then when I let go, it would move back
[17:11:11] <cradek> pretty sure it was a hardware problem.
[17:11:14] <SWPadnos> that's advanced. multi-touch with only one finger
[17:11:19] <cradek> bleh
[17:11:44] <cradek> my elographics SAW screen is great, but it doesn't tolerate wet coolant fingerprints
[17:12:01] <cradek> I don't know which is the best technology for machine tools...
[17:12:13] <mshaver> great! glad to hear of you luck with reliability...
[17:12:16] <cradek> I have a microtouch on the lathe - I think it is capacitive?
[17:12:33] <cradek> mshaver: sorry, I don't write the news, I only report it.
[17:13:03] <mshaver> this is another type of controller - no coolant - but not a cleanroom environment either
[17:14:04] <cradek> I'd be interested to hear your results, especially if you try many of these in production
[17:14:16] <cradek> the price point is appealing.
[17:14:18] <mshaver> ok, going to go try quirks - back shortly
[17:14:26] <cradek> fingers crossed.
[17:14:43] <mshaver> probably a couple hundred all together - I'll let you know
[17:24:40] <jepler> I looked for a problem with index-only homing and with moving slowly during the search phase. I didn't find anything.
http://emergent.unpy.net/files/sandbox/indexonly-homing-slowly.png
[17:25:07] <jepler> the top trace is pid error and the scale is 200u/div
[17:25:08] <skunkworks> jepler: Thanks - it sure could be something I was doing
[17:26:08] <jepler> skunkworks: perhaps, but I'd like to know what it is
[17:26:13] <jepler> skunkworks: you'll bring that down to wichita, right?
[17:26:22] <skunkworks> heh
[17:37:49] <psha> qq-: back too
[17:42:50] <tom3p> psha why camunits versus opencv?
[17:44:24] <psha> tom3p: opencv has horrible capture
[17:44:51] <psha> you need to create you own control loop for it and integrating it within gtk is painfull
[17:45:20] <psha> camunits has extreamly clean codebase and very flexible
[17:45:32] <tom3p> ah, thanks for the warning
[17:46:10] <psha> with camunits you may place gl widget with glade just like other ordinar widgets
[17:46:46] <psha> and with gladevcp this gives very flexible tool for creating custom control applications
[17:48:41] <psha> tom3p: what's your task? just live view with crosshair?
[17:49:45] <tom3p> oops, i wanted to overlay a part photo and cross hair. over the actual view.
[17:49:57] <tom3p> try to avoid part loading errors
[17:50:17] <psha> crosshair plugin may be found in
http://psha.org.ru/cgit/psha/cu-plugins
[17:50:29] <tom3p> i need to try you gladevcp
[17:50:44] <psha> most of changes are already merged to master
[17:51:10] <psha> next patchset is cleanup only
[19:26:09] <micges> when one will link external stop button with halui.abort on ffast machine, he will getting "EMC_TRAJ_SET_TELEOP_ENABLE can't be executed..." from Axis
[19:26:30] <micges> (see my talk with sebastia1 on #emc)
[19:30:17] <psha> qq-: i've located segfault
[19:32:33] <qq-> psha, good
[19:32:51] <jepler> when interp_state changes from any other state to INTERP_IDLE, axis will send a teleop enable message. update_state (axis.tcl) -> set_mode_from_tab (axis.tcl) -> ensure_mdi (axis.py) -> commands.set_joint_mode()
[19:34:39] <micges> I know
[19:35:59] <micges> but it seems that on faster machine message is sended while machine is still moving or such
[19:40:37] <jepler> immediately before the set_joint_mode message is sent, there's a call to ensure_mode. The intent of ensure_mode is that when it returns True you just switched to the requested mode
[19:41:28] <jepler> so next I'd look into what happens in ensure_mode()
[19:42:00] <jepler> or maybe the problem is that ensure_mdi isn't checking the return value from ensure_mode (False return indicates that the mode wasn't settable because the interpreter wasn't idle)
[19:43:42] <jepler> er, above I wrote ensure_mdi but of course I meant ensure_manual
[19:45:55] <micges> tomorrow I'll add some button to my machine and do some debuging to check it
[19:46:09] <psha> qq-: i'll get camera with format unknown to camunits tomorrow and fix this segfault
[19:46:27] <jepler> configs/halui_halvcp/halui.ini can show the problem
[19:46:29] <psha> micges: that's evening :)
[19:55:07] <jepler> as far as I can tell, task is telling axis that the TASK_SET_MODE command has been completed (wait_complete returns -1 in case of timeout), but it's not really(?)
http://pastebin.ca/1985649
[19:55:23] <jepler> now, I could change ensure_mode to poll and check for the desired mode (as well as make ensure_manual check the result of ensure_mode, as it should..)
[19:58:05] <jepler> .. but I'm really tempted to ask how task can say that the TASK_SET_MODE is complete if the mode is not actually manual yet
[20:02:53] <jepler> polling doesn't fix anything -- even after .5 seconds it's still not actually in auto mode!
http://pastebin.ca/1985660
[20:03:41] <jepler> er, it's still in auto mode
[20:03:46] <jepler> * jepler needs to think before he hits enter
[20:04:25] <micges> something locks mode switching
[20:05:38] <jepler> here's a trace of the case where the abort comes from axis too:
[20:05:40] <jepler> http://pastebin.ca/1985667
[20:05:53] <jepler> I see there's a TASK_PLAN_SYNCH that's not in the debug from halui
[20:20:05] <mshaver> cradek: Getting back to you on the touchscreen issue - No luck with enabling the quirks you suggested. It was a good thought, but usbhid seems uninterested in this touchscreen. I'm going to look at the kernel sources to see if I can rebuild the usbtouchscreen module without the lines that cause it to ignore this particulat Vendor:Product ID pair. Any other thoughts (from anybody) are welcome!
[20:20:51] <mshaver> so it saw <colon>P as :P, very funny...
[20:21:13] <cradek> did it make any difference at all?
[20:21:36] <mshaver> no, nothing created in /dev/inputs no matter what
[20:22:01] <cradek> no difference in dmesg either?
[20:22:11] <mshaver> I wish I understood the usb subsystem better!
[20:22:39] <qq-> psha, thanks
[20:22:43] <mshaver> No, dmesg still reports "usb_generic failed probe with error -32"
[20:22:43] <cradek> yeah I know that feeling
[20:22:56] <cradek> yuck.
[20:23:17] <mshaver> I can't even find out what "error -32" means
[20:23:50] <cradek> wonder why someone specifically blacklisted that device
[20:24:24] <mshaver> it says in the coments that it's excluded because it's handled by usbhid
[20:24:48] <mshaver> #ifdef CONFIG_TOUCHSCREEN_USB_EGALAX
[20:24:48] <mshaver> /* ignore the HID capable devices, handled by usbhid */
[20:24:48] <mshaver> {USB_DEVICE_HID_CLASS(0x0eef, 0x0001), .driver_info = DEVTYPE_IGNORE},
[20:24:51] <cradek> ah
[20:25:08] <mshaver> this is the line I want to comment out & recompile
[20:25:53] <cradek> oh hey - I see usbhid is a module. I wonder if you need to specify the quirks at modprobe time, not on the kernel command line
[20:26:02] <mshaver> once i figure out if it's a module or the whole kernel
[20:26:17] <mshaver> hmm, that's a thought!
[20:26:30] <mshaver> I wonder how you do that?
[20:27:11] <cradek> make /etc/modprobe.d/whatever.conf containing options usbhid quirks=...
[20:28:05] <mshaver> modinfo usbhid says "parm: quirks:Add/modify USB HID quirks by specifying quirks=vendorID:productID:quirks where vendorID, productID, and quirks are all in 0x-prefixed hex (array of charp)"
[20:29:02] <mshaver> does it matter what I call the .conf file?
[20:29:12] <cradek> nope
[20:29:42] <jepler> I think you're supposed to use the .conf extension on the file, but that's the only naming rule I know of
[20:30:04] <cradek> yes
[20:31:00] <mshaver> so it looks at all those files every time a any module is loaded to see if there's some parameter it should apply?
[20:31:32] <mshaver> I'll make a usbhid.conf and see what happens!
[20:39:11] <jepler> mshaver: yes
[21:03:10] <mshaver> I made a usbhid.conf which had, "options usbhid quirks=0x<vendor>:0x<product>:0x<quirks>". I then did 'modprobe -c usbhid' and it showed the quirks I had enabled, both in /etc/default/grub and in my newly created .conf file. Unfortunately, this didn't fix the touchscreen.
[21:08:14] <cradek> no difference in dmesg?
[21:10:09] <mshaver> nope - still "failed probe error -32"
[21:11:00] <cradek> wonder if you need a udev rule too
[21:14:16] <mshaver> is there a guide to writing udev rules? An easy one? :)
[21:16:44] <cradek> guess udev is for managing /dev, not choosing which modules handle which devices
[21:16:59] <cradek> just ignore my shooting in the dark...
[21:17:40] <SWPadnos> man udev?
[21:26:34] <mshaver> cradek: no problem, I've been shooting in random directions all day!
[21:26:42] <SWPadnos> TMI!
[21:27:14] <mshaver> anything that moved, BLAMMO!
[21:27:31] <SWPadnos> heh
[22:42:59] <mshaver> Where can I find a copy of the .config file used to compile the Lucid kernel?
[22:43:08] <cradek> in your /boot directory
[22:43:34] <cradek> (it's in the binary package)
[22:43:44] <cradek> not sure if it's also in the source package somewhere - might be
[22:44:04] <cradek> bbl
[22:44:33] <mshaver> Thanks!
[23:33:32] <alex_joni> cradek: it has to, otherwise you couldn't recompile the package and get the same binary package
[23:33:55] <alex_joni> it's probably in debian/ .. flavours .. somewhere
