Back
[00:27:52] <jepler> http://linuxcnc.org/docs/devel/html/hal/drivers/ http://emergent.unpy.net/index.cgi-files/sandbox/l2h/drivers.html
[00:28:09] <jepler> ^^ I'm working on a new piece of software to convert the docs from lyx to html; comments?
[00:31:13] <SWPadnos> much (much much) nicer!
[00:31:25] <jepler> I've only tried it on the one small document so far..
[00:31:37] <SWPadnos> are the shaded regions from CSS, or is that in the HTML?
[00:32:01] <SWPadnos> the darker blueish-slightly-purple background makes text a little hard to read
[00:32:05] <jepler> it uses CSS; there's a <style> in the html document
[00:32:08] <SWPadnos> ok
[00:32:17] <jepler> I am not in love with those colors, but I wanted some color on headings and such
[00:32:38] <SWPadnos> yep. they do stand out, which is quite useful when writing the code
[00:33:02] <SWPadnos> also I note that the parport pin diagram actually appears in the new page, which is also nice
[00:33:13] <jepler> yeah that's one of the things I think is important :-P
[00:33:24] <jepler> I changed it to a new shade of blue
[00:33:35] <SWPadnos> much easier to rea
[00:33:39] <SWPadnos> d
[00:33:51] <SWPadnos> interesting - the pluto diagram shows up in the old version
[00:33:59] <jepler> yeah I don't actually know what "breaks" some of the image files
[00:34:20] <SWPadnos> but it's a different size
[00:34:31] <SWPadnos> the new one is smaller, and a little blurry from the scaling
[00:38:29] <jepler> hm
[00:41:38] <jepler> for some reason, I can run "convert -density 96 pluto-pinout.eps ../out/pluto-pinout.png" from the commandline but the same thing fails when run from my program .. no error message, just an exit value of 127
[00:42:02] <jepler> oh duh
[00:42:08] <jepler> os.spawnvp(os.P_WAIT, 'convert',
[00:42:08] <jepler> ['convert', '-density', 96, srcfile, destfile])
[00:42:21] <jepler> that's twice today Python has disappointed me (by hiding the error that '96' was not a stirng)
[00:44:24] <jepler> OK, re-rendered the images at 96dpi
[00:45:10] <jepler> they're still different sizes and it's still not particularly legible :(
[00:46:21] <jepler> * jepler bumps to 100dpi
[00:47:42] <SWPadnos> it looks much better now
[00:48:17] <jepler> it went over 1024-wide though :(
[00:48:25] <SWPadnos> it did?
[00:48:30] <jepler> there have got to still be a few people with 1024-wide screens, though I don't know any of them
[00:48:52] <SWPadnos> it's 631x336, according to Mozilla
[00:49:03] <jepler> huh?
[00:49:10] <SWPadnos> http://emergent.unpy.net/index.cgi-files/sandbox/l2h/pluto-pinout.png
[00:49:12] <jepler> 1063x811
[00:49:28] <jepler> I thought we were talking about parport pinout being illegible
[00:49:35] <SWPadnos> oh, nope :)
[00:49:39] <SWPadnos> pluto
[00:50:13] <SWPadnos> you should be able to tell convert to make it a certain pixel size
[00:50:22] <SWPadnos> err - certain resolution
[00:50:34] <SWPadnos> um - you know, you can tell it how many pixels to make the output image
[00:50:45] <jepler> yes but I doubt all images should "nearly fill a 1024x768 screen"
[00:51:02] <SWPadnos> no, but I think you can limit it to a certain size as well
[00:51:17] <SWPadnos> so you do 96DPI or something, but limit to the smaller of 96DPI or 1000 pixels wide
[00:51:53] <SWPadnos> it's been a while since I messed around with imagemagick though, so I can't tell you the options to do that
[00:54:37] <jepler> yeah, I figured it out finally
[00:54:49] <jepler> ['convert', '-density', '100', '-resize', '1000x9999>', srcfile, destfile]
[01:02:49] <jepler> I should probably find the courage to try some other portions of the emc docs next
[01:04:15] <SWPadnos> heh
[01:05:05] <jepler> huh, I didn't know about this (apparently deprecated?) scripting extension for html:
http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.7.1.1
[01:05:58] <jepler> I wonder if any browsers implement it, and whether stuff like webmail and facebook correctly strip it
[01:08:41] <jepler> doesn't seem that firefox does
[01:22:12] <jepler> I think -density .. -resize .. gives worse results .. as though it first produces the full-sized image from the vector source, then resizes the bitmap image
[01:24:52] <jepler> oh well
[01:27:13] <jepler> I also need to figure out what to do about cross-document links..
[02:50:02] <cradek> good evening
[02:53:01] <cradek> jepler: that looks very promising
[03:22:53] <fenn> how is hal_parport_block_diagram.dxf converted to .png? is that vec2web?
[03:23:27] <fenn> there are a lot of font styles you can specify in qcad but it doesnt render them any different in qcad
[03:23:29] <jepler> fenn: by manually running qcad, I think -- see docs/src/README
[03:23:51] <jepler> though the .eps files there may or may not be generated from a win9x cad package running on an old system of jmk's
[03:24:06] <fenn> ok i thought it was automatic since there isnt anything in cvs
[03:25:20] <jepler> dxf->eps or ps is manual; eps or ps -> png is part of the latex2html step in docs/src/Submakefile
[03:25:40] <jepler> COOOOOL -- I just got cross-document links to work
[03:25:55] <jepler> <A><xsl:attribute name="href">
[03:25:56] <jepler> <xsl:value-of select="document('xref.xml')//label[@anchor=current()/@target]/@src"/>#<xsl:value-of select="@target"/></xsl:attribute>[->]</A>
[03:26:09] <cradek> oh holy crap
[03:26:12] <jepler> xsl is a hard language to love but I am sure pleased with the results I've been able to get
[03:26:56] <jepler> "look around in xref.html for a <label> whose anchor= matches the desired one, and substitute in its src=, followed by #, followed by ... and stuff that all into the href= of the <A>"
[03:27:29] <cradek> yes if you say so
[03:29:05] <fenn> that seems like a very basic thing to need
[03:30:39] <jepler> I've now converted all of the hal/ directory of docs with my new software:
http://unpy.net/emc2-docs-hal (try any .html or .xml file; they should look the same)
[03:31:02] <jepler> the software:
http://git.unpy.net/view?p=l2h.git;a=shortlog;h=xml
[03:32:12] <jepler> hm the links in the html files are to the xml files...
[03:32:40] <cradek> jepler: I find myself getting lost (losing track of the heirarchy) since only font size gives those cues
[03:33:03] <cradek> maybe put the numbers in the headers like latex does?
[03:33:07] <jepler> hm something goes wrong in comp.html
[03:33:46] <cradek> oh, yes it sure does
[03:33:46] <jepler> http://unpy.net/emc2-docs-hal/comp.xml
[03:34:46] <cradek> <deeper>...
[03:36:20] <tomp> i want something like hal_input.py for the labjack, but it is iput and output, also analog(float) and digital, and counters and timers. Do I extend KRAL to allow these pin/param types?
[03:37:07] <jepler> tomp: analog inputs are already supported -- should be in the category of "A" in this case
[03:37:34] <jepler> I'm not sure about analog outputs; they don't seem to be supported by the linux input layer (only LEDs like keyboard status LEDs, seem to be)
[03:38:10] <tomp> did you invent the linux_event scheme?
[03:39:19] <jepler> I wrote linux_event.py but modeled it on other software which uses /dev/input on linux
[03:39:23] <fenn> while on this topic, is it possible to grab mouse events with hal_input?
[03:39:48] <jepler> fenn: yes, you can use a mouse with hal_input; you have a choice of sharing it with the X server, or using it exclusively by putting "+" at the start of the device specifier.
[03:40:04] <fenn> how do i share it? i get permission denied when i try to use event1
[03:40:24] <jepler> see section PERMISSIONS AND UDEV of the manpage
[03:40:37] <jepler> (by default on ubuntu the console user doesn't get the necessary permission on input devices)
[03:41:22] <tomp> analog outputs are analog onlyafter the device coverts a binary number into the analog voltage, so ther name is missleading, it's really writing a 'word' to a 'port', my bad
[03:41:26] <fenn> so changing the file permissions would not work?
[03:42:43] <fenn> crw-rw-r-- 1 root root 13, 65 2007-09-21 16:07 event1
[03:44:02] <fenn> halcmd: loadusr hal_input -R 1
[03:44:09] <fenn> OSError: [Errno 13] Permission denied: '/dev/input/event1'
[03:45:17] <jepler> are you in group 'root'? It opens the device with O_RDWR.
[03:46:16] <fenn> hm i never thought of adding write access
[03:46:49] <fenn> that was much easier than figuring out how to use udev :)
[03:48:05] <fenn> this is sweet
[03:48:33] <tomp> got a format example of the device specifier ( eg: /dev/usb/labjacku3_0 ) with the loadusr hal_input command?
[03:50:58] <jepler> only if the Linux device is called /dev/input can it be used with hal_input
[03:51:14] <jepler> if it's under /dev/usb it's some other kind of device which requires a different program
[04:00:26] <jepler> sounds like some versions of linux tried to treat the device like a HID device (the type hal_input is useful for) but this was undesirable, leading to weird workarounds..
http://www.labjack.com/forums/index.php?showtopic=1370
[04:02:27] <jepler> (HID supports analog inputs and outputs, but linux's /dev/input seems to have poor or no abilities to work with analog outputs)
[04:04:31] <tomp> hmm, xemets joypad >is< in /dev/input i'm working this the wrong way trying to find a simple solution ( hal_input, python... ) looks like time for a real 'c' driver
[04:05:02] <tomp> thanks
[04:07:03] <fenn> you might have an easier time hacking on their python driver
[04:07:21] <fenn> its definitely more discoverable with the help() function
[04:11:01] <tomp> thier? labjack's
[04:12:08] <fenn> yeah the labjackpython.zip
[04:12:23] <fenn> i'm sure it does something :)
[04:13:03] <tomp> i managed to get data out of it using labjackpython, i can set up the queries and get the data and set the data ok ( a bit z-80 ish )
[04:13:21] <fenn> it is a microntroller after all
[04:13:27] <tomp> and am working on the communications to hal
[04:14:15] <tomp> I xemet used hal_joystick, which is in /dev/input , but thats not a pre-requisite, (he doesnt use hal_input ), maybe thats a starting point
[05:13:50] <jepler> you can tell I'm excited about this l2h project because I've stayed up past midnight working on it :-P
[05:14:51] <jepler> * jepler pushes the latest copy to his webiste once more
[05:17:48] <jepler> if I fix any more bugs this program will go over 1000 lines though :(
[13:25:05] <jepler> 4 warnings, 0 errors were found!
[13:25:13] <jepler> make: *** [../out/bug3.tidy.html] Error 1
[13:25:23] <jepler> hmm looks like 'tidy' has an interesting definition of exit values
[16:06:49] <tomp> hal_joystick.c gets a nice struct when the joystick handle (jsfd) is read.
[16:06:54] <tomp> The struct sez what kind of event, author and value.
[16:07:05] <tomp> Hal_joystick then inspects the struct for a known type , evaluates and places stuff on pins.
[16:07:09] <tomp> How does the struct get filled in?
[16:07:10] <tomp> Does the device constantly create new data ready for retrieval?
[16:09:14] <SWPadnos> when something happens, the device filld in a struct and makes it available for reading
[16:09:22] <SWPadnos> so when hal_joystick gets it, it's filled in
[16:10:26] <tomp> right, the device knows about events, and makes a short report to notify a change. later a query can be made about the specifics
[16:11:20] <tomp> so a device that does not generate such a struct is 'another story'
[16:11:44] <SWPadnos> yes, probaly a story in a different language
[16:12:00] <tomp> forth? :)
[16:12:10] <SWPadnos> Sanskrit
[16:12:13] <tomp> c should so
[16:12:25] <tomp> thx
[16:12:53] <tomp> its not necc to have teh event struct, just some way to tell there's news
[16:13:16] <SWPadnos> I bet both are necessary
[16:13:53] <SWPadnos> you need to know how to tell there's new (that's the select call), and you also have to know how to interpret the news (that's the "language=sanskrit" part)
[16:13:58] <SWPadnos> s/new/news/
[16:18:42] <tomp> yes, detect change then if true, evaluate is great,
[16:18:47] <tomp> i meant an event struct tied the driver to linux event types which are wrapped in keyboard/mouse/rumblepad thinking, not machine/laboratory i/o thinking.
[16:19:46] <SWPadnos> I bet when you read from the labjack, the data is in some predetermined format (a filled-in struct)
[16:20:17] <tomp> you read data A with this cnmd, data B with that command, timer Z withthe other command....
[16:20:29] <tomp> like z-80 peripherals
[16:20:45] <SWPadnos> ok. have you looked into the python or C source to see how they do it?
[16:21:08] <tomp> used it, read a bit of thier code yes
[16:21:50] <SWPadnos> unless they're sending a command to the unit to get the data before returning it to the calling program, their library is likely looking at full packets and only returning one item
[16:21:58] <SWPadnos> "it's easier to use" that way
[16:25:49] <tomp> yes a unique (very) cmd to get an individual data... not a full set of data and send this one back to caller. maybe what you say is true at some lower level, i'll look. thx
[16:30:58] <SWPadnos> well, it looks like that may not help
[16:31:26] <SWPadnos> I'm just scanning through the python library, nad 99% of the functions are Windows only - they'll raise exceptions on Linux
[16:33:59] <tomp> right, the linux functs are fewer but more robust
[16:34:42] <SWPadnos> so far, ervery function except open is Windows only
[16:34:53] <tomp> i think you're right about the whole shebang being available tho, if you'd like to look at def Read(Handle, Stream, numBytes):
[16:35:40] <tomp> :) i used a folding editor to remove the windows cruft , almost folded the file away :)
[16:36:38] <tomp> line 1515 is Linux Read
[16:38:24] <tomp> and if the lower level ( non python approach ) is used, then bulkread and bulkwrite hint that the whole data is available ( file labjackusb.c lines 108, 134 resp )
[16:38:52] <SWPadnos> there you go :)
[16:39:43] <SWPadnos> it does look as though you need to do some initialization of the device itself, but I'd hope you could tell it to just keep scanning all channels
[16:40:06] <tomp> right, me --> rtfm ;)
[16:40:10] <SWPadnos> heh
[16:40:24] <SWPadnos> me -> head out for breakfst :)
[16:40:34] <SWPadnos> fast too
[16:40:37] <tomp> thanks, have a waffle on me
[16:41:19] <SWPadnos> thanks
[17:01:59] <jepler> any last comments before I make the new converter the default for emc 2.2 and beyond?
http://unpy.net/emc2-docs-new/
[17:11:36] <tomp> just one, nice work
[17:13:19] <jepler> tomp: thanks
[17:38:28] <DanielFalck> jepler: looks great
[17:45:48] <jepler> hm, multiple index entries with the same text don't work
[17:50:06] <jepler> and there are more problems with Formula
[19:41:05] <cradek> jepler: it looks great to me, thanks for adding the numbers
[19:43:11] <cradek> jepler: in
http://unpy.net/emc2-docs-new/gcode_tool_compensation.html there are some spurious (I think) "inner_position 0"
[19:46:01] <jepler> cradek:
[19:46:06] <jepler> hmm I'll look
[19:46:19] <jepler> I wonder what that's about
[19:46:34] <jepler> there's also something funky with the 'Caption' in that file..
[19:49:51] <cradek> it's very nice to see those images again
[20:06:40] <jepler> cradek: fixed 'inner_position' and 'caption' in Tool Compensation
[20:08:33] <jepler> and yes, having the images work is one of the biggest bonuses
[20:08:42] <jepler> it's too bad this will break all the old documentation links though
[20:14:50] <alex_joni> jepler: wouldn't pages with links help there out?
[20:36:06] <alex_joni> good night all
