Back
[00:40:25] <jmkasunich> the lyx authors don't believe in sticking with standards
[00:40:43] <alex_joni> hmm.. why?
[00:40:53] <jmkasunich> most programs, you get the version with "prog -v" or "prog -V" or "prog --version"
[00:41:01] <jmkasunich> lyx uses "lyx -version"
[00:41:13] <jmkasunich> note only one "-" for a long option name
[00:43:47] <cradek> * cradek beats the lyx authors with getopt
[02:12:04] <alex_joni> darn.. was about to leave
[02:12:13] <jmkasunich> so leave already!
[02:12:14] <alex_joni> got an email from Eric with his telnet thingie
[02:12:39] <alex_joni> I'll look at it tomorrow.. but I'd like your oppinion if I should add it to CVS or not
[02:12:54] <alex_joni> seems OK to me, bet I can hack it to play nicely
[02:12:59] <jmkasunich> if it works, and doesn't interfere with the rest of emc, why not?
[02:13:30] <alex_joni> my thoughts exactly
[02:13:33] <cradek> agreed
[02:13:44] <alex_joni> ok.. I'm gone now
[02:13:51] <cradek> g'night!
[02:13:58] <jmkasunich> goodnight
[02:14:04] <jmkasunich> or good morning
[02:14:07] <cradek> darn timezones
[02:14:19] <jmkasunich> 5:25 am there I think
[02:14:29] <jmkasunich> * jmkasunich is confused
[02:14:43] <cradek> about what?
[02:14:49] <jmkasunich> I created one pdf by doing File->Export->Pdflatex in LyX
[02:15:18] <jmkasunich> another by doing "lyx-qt --export pdf Master_HAL.lyx" on the cmd line
[02:15:30] <jmkasunich> the first one is 691K, the second one over a meg
[02:15:42] <SWPadnos> does one look better than the other?
[02:15:43] <jmkasunich> they look pretty much the same in a pdf viewer
[02:15:59] <SWPadnos> can you stick them on the web so I can check that with a Windows machine?
[02:16:15] <jmkasunich> ok
[02:16:33] <SWPadnos> one never knows with fonts + X
[02:18:47] <jmkasunich> upload bandwidth isn't setting any records tonight
[02:18:55] <SWPadnos> heh - it rarely does
[02:19:04] <SWPadnos> keeping the A in ADSL ...
[02:19:10] <jmkasunich> http://home.att.net/~jmkasunich/scratch/Master_HAL_cmdline.pdf
[02:20:30] <jmkasunich> http://home.att.net/~jmkasunich/scratch/Master_HAL.pdf
[02:24:22] <SWPadnos> ok - they look pretty similar. I think the non-commandline version is slightly nicer - the kerning is a bit different
[02:24:29] <jmkasunich> ahh, it seems the command line version is the same as you get if you do "File->Export->PDF"
[02:24:36] <SWPadnos> character spacing looks more uniform, and "better" to me
[02:24:43] <jmkasunich> I've always been more pleased with the pdflatex output as well
[02:24:52] <jmkasunich> but I can't seem to get that from the command line
[02:25:13] <jmkasunich> (I want to add it to the makefile)
[02:25:21] <SWPadnos> I only really notice it in the images (looking at stepgen block diagram at 400%)
[02:26:31] <SWPadnos> the character baselines are also a little different, but for that, I like the commnad line version better ;)
[02:27:05] <jmkasunich> the block diagrams are .eps files
[02:27:29] <jmkasunich> I'm not sure if Lyx does much with them, it may just pass em thru and some later stage is responsible for the differences
[02:27:42] <SWPadnos> weird - if I look at the page that says "HAL Introduction & Tutorial", (8 of 98), the character shape for the 'n' in introdction is actually different between the two
[02:28:37] <SWPadnos> they're probably using slightly different foncts by default - that could explain the baseline and kerning differences as well
[02:28:42] <SWPadnos> fonts
[02:29:35] <jmkasunich> but both seem "OK"?
[02:29:53] <jmkasunich> what about the parport drawing?
[02:30:20] <SWPadnos> they both seem OK - lemme check the parport drawing
[02:30:31] <jmkasunich> here, one file displayed that page in landscape (so the drawing itself is upright), the other displayed it in portrait like all the other pages
[02:31:25] <SWPadnos> right - I was just going to say that
[02:31:51] <jmkasunich> do you think the rotation would cause grief to people trying to print it?
[02:32:29] <jmkasunich> its actually nicer for viewing, don't have to tilt your head
[02:32:32] <SWPadnos> I prefer the upright orientation
[02:32:44] <jmkasunich> upright page, or upright image?
[02:33:37] <SWPadnos> well, for viewing, I like the upright image. for printing, I think it would be a nightmare
[02:34:07] <jmkasunich> unfortunately I don't have a pringer
[02:34:09] <jmkasunich> printer even
[02:34:11] <SWPadnos> I guess the page should be correct for printing, since it's easy to fiddle with things onscreen
[02:34:35] <jmkasunich> cradek: you have a printer?
[02:34:59] <SWPadnos> I can print it on Wednesday night :(
[02:35:16] <jmkasunich> I figured you didn't have one in your hotel room
[02:36:01] <SWPadnos> I think I have PrintOn available, but it's crap (orwas when I tried it last)
[02:36:06] <SWPadnos> PrinterOn, that is
[02:38:01] <jmkasunich> it looks like the command line conversion first generated postscript, then used ps2pdf13 to convert to a version 1.3 pdf file
[02:39:46] <SWPadnos> I suspect that the comand line used for the pdflatex version is somewhere in the lyx setup
[02:39:58] <jmkasunich> yeah, I'm spelunking now
[02:40:03] <SWPadnos> heh
[02:40:14] <SWPadnos> I think I'll head out for dinner then ;)
[02:40:28] <SWPadnos> (I have no lyx on this WinBox)
[02:40:48] <SWPadnos> see you later
[02:40:53] <jmkasunich> goodnight
[02:41:01] <jmkasunich> (I hope to be in bed by the time you come back)
[02:41:08] <SWPadnos> me too :)
[02:41:40] <SWPadnos> (I was at the airport at 6"30 AM EST this morning, so it's been a long day)
[02:42:01] <SWPadnos> SWPadnos is now known as SWP_away
[02:45:42] <jmkasunich> hah, found it
[02:46:21] <jmkasunich> File->Export->PDF (pdflatex) can be done from the command line as "lyx-qt --export pdf2 myfile.lyx"
[02:46:47] <jmkasunich> on that note, I'm going to bed
[02:47:23] <jmkasunich> tomorrow we tackle detecting lyx (and any other required programs) from configure, and invoking the above command line from the Makefile
[02:47:27] <cradek> cool
[02:47:35] <cradek> this will sure be nice
[02:49:55] <jmkasunich> html would be nice too
[02:50:27] <jmkasunich> PDFs are very nice - good fonts, good graphics (no pixelization of the block diagrams, etc)
[02:50:38] <jmkasunich> but not very nice to navigate
[02:50:50] <jmkasunich> (although the table of contents does hyperlink to the rest of the document)
[02:51:38] <jmkasunich> and I think cross-references become links too
[02:53:38] <cradek> some of that does seem to work in pdf
[02:53:46] <jmkasunich> thats what I meant
[02:53:53] <jmkasunich> the pdf TOC links to the rest of the doc
[02:53:58] <cradek> ah
[02:54:44] <jmkasunich> ideally html output would be multiple pages, with "prev/up/next" links and such
[02:54:50] <jmkasunich> that would make it even easier to navigate
[02:55:28] <jmkasunich> one massive html file would be worse than the pdf I think
[02:56:02] <cradek> argh!
[02:56:06] <cradek> my qctp rotates
[02:56:07] <jmkasunich> ?
[02:56:26] <jmkasunich> rotates? the bolt holding it down isn't tight enough?
[02:56:41] <cradek> the bottom was all crappy, so I carefully filed it flat, but that didn't fix it
[02:56:55] <cradek> the bolt is pretty darn tight
[02:56:58] <jmkasunich> ideally it would be a little concave
[02:57:12] <jmkasunich> so the force is all on the outer edge where it does the best at resisting rotation
[02:57:57] <jmkasunich> if you really want it locked in, turn it upside down, mill a slot in it the same as the width of your table t-slot, and fit a key
[02:58:08] <cradek> it's not, I can see it's being clamped most in the center
[02:58:28] <jmkasunich> what is the body made of?
[02:58:33] <cradek> hey now that's a good idea
[02:58:36] <jmkasunich> steel? hardened steel? alum?
[02:58:40] <cradek> aluminum
[02:58:45] <cradek> used to be anodized
[02:58:55] <jmkasunich> lol
[02:59:10] <cradek> you should have seen the "workmanship"
[02:59:19] <jmkasunich> is the shape something you could stick in the four-jaw? (base out)
[02:59:20] <cradek> terrible raw flycutter marks under pretty anodizing
[02:59:32] <cradek> yes it's pretty square
[02:59:50] <jmkasunich> you could face it off, recess the center by 0.005" or so
[03:00:36] <jmkasunich> is the actual dovetail that the toolholder engages also aluminum?
[03:00:52] <cradek> all the parts are Al
[03:00:58] <cradek> except maybe the plungers
[03:00:59] <jmkasunich> thats just wrong
[03:01:16] <cradek> $75, made for a sherline
[03:01:35] <jmkasunich> is the sherline table alum or cast iron?
[03:01:40] <cradek> heh
[03:01:47] <cradek> Al
[03:02:18] <cradek> the ways are actually steel
[03:02:35] <cradek> on the lathe - not sure about their mill
[03:02:39] <jmkasunich> I knew there was some ferrous content in there _somewhere_
[03:02:53] <jmkasunich> but not much apparently
[03:02:59] <cradek> just the leadscrews on the mill maybe
[03:03:20] <jmkasunich> I think the mill and lathe use the same way technology
[03:03:38] <jmkasunich> so the ways are alum sliding on steel?
[03:04:04] <cradek> yes with a plastic gib thingy on one side
[03:04:13] <jmkasunich> ;-)
[03:04:21] <jmkasunich> well, back to the qctp
[03:04:28] <cradek> the plastic works surprisingly well
[03:04:31] <jmkasunich> quick version, recess the center in the lathe
[03:04:45] <jmkasunich> fancy version, mill a slot, install keys
[03:05:13] <jmkasunich> the quick version lets you mount the post at an odd angle if the need arises
[03:05:16] <cradek> by milling a slot I lose the ability to rotate it
[03:05:20] <cradek> heh yeah that
[03:05:22] <jmkasunich> the key version ensures repeatibility
[03:05:31] <jmkasunich> the keys can always be removed
[03:05:54] <cradek> true
[03:06:25] <cradek> wonder how square this is - wonder if I can put the top face against the 4-jaw's face and get everything parallel
[03:06:50] <jmkasunich> you have an indicator right? so you can try and test, no risk
[03:07:15] <cradek> my file job turned out surprisingly square
[03:07:31] <jmkasunich> but you probably made it ever so slightly convex
[03:07:40] <jmkasunich> almost impossible not to with a file
[03:07:50] <cradek> possibly so
[03:07:55] <cradek> that would sure make it rotate
[03:08:13] <cradek> not sure I have anything really flat to check it with
[03:09:03] <jmkasunich> good straightedge? even the blade of a square
[03:09:12] <jmkasunich> that only checks a line, not the entire surface
[03:09:12] <cradek> not sure how to make it a tiny bit concave on my manual lathe
[03:09:24] <jmkasunich> you don't need to
[03:09:30] <jmkasunich> face the whole thing off flat
[03:09:42] <cradek> flat I can do
[03:09:48] <jmkasunich> then make a round recess a few thou deep and maybe 60-70% of the diameter
[03:09:59] <jmkasunich> contact will be on the outer flat area
[03:10:23] <cradek> that risks messing up my T slot if I overtighten it
[03:10:48] <jmkasunich> pulling the lips up into the recess?
[03:10:50] <cradek> I guess a few thou would be ok
[03:10:53] <cradek> yeah
[03:10:58] <jmkasunich> how flimsy is that table anyway?
[03:11:14] <jmkasunich> when you use milling clamps, there is usually no support above the t-nut
[03:11:18] <cradek> don't know, I haven't messed it up yet
[03:11:44] <cradek> that's true, and they have leverage
[03:11:58] <cradek> ok I'll go do it
[03:12:27] <jmkasunich> just don't go nuts with the bolt - no tighter than you'd do it when using clamps
[03:12:47] <jmkasunich> how big is the bolt anyway? 1/4-20 or something?
[03:13:19] <jmkasunich> 6-32? ;-)
[03:13:21] <cradek> 10-32
[03:13:25] <cradek> :-P
[03:13:30] <jmkasunich> you're shitting me
[03:13:48] <cradek> nope
[03:13:55] <jmkasunich> oh
[03:13:56] <jmkasunich> my
[03:13:57] <jmkasunich> god
[03:14:03] <cradek> the T slots are only .25 wide
[03:14:30] <cradek> you don't get how small this machine is...
[03:14:31] <jmkasunich> you need a bigifier ray
[03:14:48] <cradek> nah, it's small on purpose
[03:15:23] <cradek> off to the garage, back in a bit
[03:15:34] <jmkasunich> off to bed, back in a longer bit
[03:15:56] <cradek> ok, goodnight, thanks for the advice
[03:41:01] <danfalck> hi chris
[03:41:17] <danfalck> oh sorry, you're off to the garage
[03:41:42] <cradek> back already
[03:41:47] <danfalck> I'm just playing with adding small python scripts into nedit
[03:41:58] <danfalck> in command line execute mode
[03:42:11] <danfalck> I'll probably put ttt in there
[03:42:38] <cradek> what's nedit?
[03:42:45] <danfalck> an editor
[03:43:04] <danfalck> www.nedit.org
[03:43:09] <danfalck> I like it
[03:43:36] <danfalck> been using it for a while now. not as powerful as a lot of editors, but usable for me
[03:44:42] <cradek> sorry I don't follow what you're doing with ttt then...?
[03:44:54] <cradek> yay, jmk's advice solved my problem, like usual
[03:45:15] <danfalck> nothing yet ,but I want to string a lot of the small CAM utilities together
[03:45:29] <cradek> ah, I see
[03:45:36] <danfalck> I like ttt
[03:46:05] <danfalck> I've got a little bolt circle calculator that sends data to the clipboard > nedit
[03:46:45] <danfalck> I have been trying out a lot of the utilities on the CAM page on linuxcnc.org (wiki)
[03:47:06] <cradek> I saw that interesting page, but haven't looked at any of the things mentioned
[03:47:19] <cradek> did you write most of that? it has a lot of programs that are new to me
[03:47:27] <danfalck> I've been trying out Aptos and it actually works
[03:47:30] <danfalck> some of it
[03:48:55] <cradek> hmm, no idea what APT is
[03:49:45] <danfalck> the first CNC programming langauge (from the 1950s)
[03:49:53] <danfalck> I ordered a book on it last night
[03:50:09] <danfalck> I think that it's incredibly powerful, from what I've seen so far
[03:50:26] <danfalck> Machinist's Handbook edition 26 has a chapter on it
[03:50:48] <danfalck> http://aptos.sourceforge.net/
[03:51:28] <danfalck> kind of an interpreter for man readable math and geometry statements that converts them into gcode
[03:52:08] <danfalck> was used to make code for turbines 4/5 axis stuff in 1950s /1960s
[03:52:29] <danfalck> so, I'm getting into it
[03:53:04] <danfalck> http://aptos.sourceforge.net/WhatisApt.html
[03:53:28] <cradek> aha, the executive summary
[03:53:41] <danfalck> kind of a curiosity
[03:54:03] <cradek> Apt shares many similarities to computer programming languages like Fortran.
[03:54:05] <cradek> ouch.
[03:54:09] <danfalck> modern cam systems don't tend to use it, except for in the post processor side
[03:54:21] <danfalck> yea
[03:54:44] <danfalck> the guy that is working on this project converted a bunch of Fortran using f2c
[03:55:04] <cradek> so he found old source somehow?
[03:55:18] <danfalck> someone donated the old apt360 Ibm source to him
[03:55:39] <danfalck> I almost bought a copy of it about 5 years ago, luckily I didn't
[03:55:52] <danfalck> it would have cost me $1200 for the print out and VAX tape
[03:56:07] <danfalck> someone else did this and gave him a copy of the code
[03:56:12] <danfalck> it is public domain
[03:56:20] <danfalck> but the media cost was horrible
[03:56:25] <cradek> heh wow
[03:56:29] <danfalck> not to mention I don't know anyone with a VAX
[03:56:37] <cradek> often 50 years is plenty long enough to lose source code
[03:56:43] <danfalck> I did search a bit, but luckily couldn't find one
[03:57:02] <danfalck> good luck for me not spending the $1200
[03:57:16] <cradek> right
[03:57:40] <danfalck> anyway, I will study it over the coming weeks and keep you updated ; )
[03:58:34] <danfalck> how's your shop going?
[03:58:36] <cradek> ok sounds interesting
[03:58:54] <cradek> I have a nicely workable cnc lathe finally
[03:58:59] <danfalck> good
[03:59:06] <cradek> just testing the new threading cycle
[03:59:10] <danfalck> got some pics?
[03:59:29] <cradek> not yet
[03:59:36] <cradek> I'd like to make another video
[03:59:44] <cradek> it's pretty impressive threading at 1krpm
[04:00:01] <danfalck> I saved the IRC log where you laid out how to set up the lathe
[04:00:32] <danfalck> sometime in the next couple months I would like to do the same thing with a lathe I have
[04:00:58] <danfalck> but, the software kind of has my interest at the moment
[04:01:15] <cradek> that would be great, we could use more people using/testing it
[04:01:37] <danfalck> I have emc2 set up on this box, just not connected to a machine yet
[04:01:53] <danfalck> I use it to test gcode from all the little utilities that I find
[04:02:03] <danfalck> axis is pretty cool
[04:02:16] <danfalck> I like the opengl screen - panning rotating zooming
[04:02:19] <cradek> thanks
[04:02:58] <danfalck> I will probably find a place to stick in a little icon to launch an editor
[04:03:24] <cradek> well, you aren't the first to want that
[04:03:30] <danfalck> it seems like every time I open a program, I have forgotten to remove a %
[04:03:46] <danfalck> I'll just shoehorn nedit into it
[04:04:27] <danfalck> I just want a quick way to launch the editor. It doesn't need to reside inside the application
[04:04:59] <cradek> if you know anyone who needs a bunch of 1/4-20 threaded brass, I can cut him a deal
[04:05:27] <danfalck> you've been doing a lot of threading
[04:05:32] <cradek> yeah I've thought that maybe launching a gui editor wouldn't be so bad, but that can easily be done with gnome too
[04:05:44] <danfalck> yep
[04:06:18] <danfalck> I'll just stick with stringing all the little programs together
[04:06:35] <cradek> do you know axis has filters?
[04:06:39] <danfalck> It's funny how I can forget all the parameters for something, if I don't use it every day
[04:06:45] <danfalck> filters?
[04:06:56] <cradek> you can open (say) an apt program in axis, and in the background it will run the apt-to-gcode converter for you
[04:06:59] <danfalck> I think you mentioned it before, but lay it out
[04:07:15] <cradek> so you can edit the apt and hit reload in axis to transparently redo the conversion and give you the new preview
[04:07:26] <cradek> I've used that for python programs that generate gcode
[04:07:34] <cradek> edit the python, hit reload, see the new output
[04:07:39] <danfalck> ok let me try that
[04:07:50] <cradek> have a look at sim/axis.ini
[04:07:55] <cradek> it shows how to set them up
[04:08:16] <danfalck> ok thanks
[04:09:27] <danfalck> looking now
[04:11:35] <danfalck> didn't find it in sim/axis.ini
[04:11:43] <danfalck> did a search for filter
[04:12:20] <cradek> hmm
[04:12:28] <cradek> maybe yours is too old
[04:13:04] <danfalck> I think I have 1.40a...
[04:13:04] <cradek> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/configs/sim/axis.ini?rev=1.11
[04:13:07] <danfalck> ok
[04:13:55] <danfalck> PROGRAM_EXTENSION = .png,.gif,.jpg Grayscale Depth Image
[04:13:57] <danfalck> ok
[04:14:15] <danfalck> PROGRAM_EXTENSION = .dxf 3D Polygon Model
[04:14:15] <danfalck> PROGRAM_EXTENSION = .py Python Script
[04:14:45] <cradek> right
[04:15:03] <cradek> then a little further down, you specify the program used to filter (convert from the named extension into gcode)
[04:15:16] <danfalck> ok, I need to update my Axis
[04:15:33] <cradek> probably you just need to add that section to your ini
[04:15:42] <danfalck> ok
[04:15:51] <cradek> I'm not sure really, too many versions of stuff around
[04:16:18] <danfalck> how do you check the version of Axis that you are using? axis -v?
[04:17:00] <cradek> help/about
[04:17:18] <cradek> AXIS version 1.4a0 / emc2 pre-2.1 CVS HEAD
[04:17:20] <cradek> mine says this
[04:17:32] <danfalck> PROGRAM_EXTENSION = .dxf 3D Polygon Model
[04:17:32] <danfalck> PROGRAM_EXTENSION = .py Python Script
[04:17:36] <danfalck> whoops
[04:17:55] <danfalck> axis 1.40a0
[04:18:10] <danfalck> emc2 2.0.3
[04:18:22] <danfalck> I'll add that section to the ini by hand
[04:18:45] <cradek> the py one is the most useful since you don't have those other programs
[04:18:50] <danfalck> so to run ttt from axis, you just go to 'file' 'open'
[04:19:07] <danfalck> run ttt or whatever py program
[04:19:11] <cradek> yes
[04:19:21] <cradek> those extensions show up in the file open dialog
[04:20:26] <danfalck> ok I will try it right now. going to add to ini...
[04:22:10] <danfalck> I added the lines:[FILTER]
[04:22:10] <danfalck> PROGRAM_EXTENSION = .png,.gif,.jpg Grayscale Depth Image
[04:22:10] <danfalck> PROGRAM_EXTENSION = .dxf 3D Polygon Model
[04:22:10] <danfalck> PROGRAM_EXTENSION = .py Python Script
[04:22:10] <danfalck> png = image-to-gcode.py
[04:22:11] <danfalck> gif = image-to-gcode.py
[04:22:13] <danfalck> jpg = image-to-gcode.py
[04:22:15] <danfalck> dxf = toolpaths.py
[04:22:17] <danfalck> py = python
[04:22:19] <danfalck> into the ini
[04:22:21] <danfalck> axis.ini that is
[04:22:25] <cradek> right
[04:22:41] <cradek> now make a program test.py containing something like print "M2"
[04:22:52] <cradek> then open test.py in axis
[04:28:48] <danfalck> I got impatient and just downloaded axis.ini from cvs, but broke it for a bit
[04:29:08] <danfalck> fixed it.
[04:29:16] <danfalck> now back to editing ini
[04:37:20] <danfalck> I'm going to reinstall axis to get update
[04:49:44] <danfalck> I reinstalled using synaptic got the same version of axis 1.4a0 but with the old ini again
[04:49:56] <danfalck> I made sure the ini wasn't there before reinstalling
[04:50:06] <danfalck> I should install from source
[12:38:41] <jepler> cradek: to move emc from Lost & Found on kubuntu, put a copy of cnc.menu in /etc/xdg/menus/kde-applications-merged/cnc.menu
[12:39:32] <jepler> fucking brilliant, eh?
[12:40:51] <jepler> from the first moment, I loathe kde: that annoying little "cute" lizard, the "fade in" effect of the massively oversized tooltips for the panel, the use of konqueror instead of the web browser everyone wants...
[12:41:06] <jepler> at least the gnome people haven't insisted on making their own browser
[12:59:08] <steves_logging> steves_logging is now known as steve_stallings
[13:01:13] <steve_stallings> JMK -- regarding Hal docs, the command line version of the PDF displays the printer port diagram in landscape but autorotates to print vertical with no user intervention using Acrobat 6 on Windows
[14:53:47] <jmkasunich> steve_stallings: thanks for testing that
[15:09:54] <steve_stallings> A question... would it be possible to use a single bit "limit" sense to inform EMC to stop motion, and the access other slower (think serial access) bits to determine which axis hit the limit? impact on homing?
[15:10:23] <jmkasunich> homing can disable limits, so thats not the issue
[15:10:47] <jmkasunich> you could route the single limit bit to both motion controller limit inputs, so it would stop
[15:11:00] <jmkasunich> but it decides which limit it hit at that instant
[15:11:15] <jmkasunich> it would be very difficult to defer that
[15:12:21] <jmkasunich> otoh, if both limits are activated at the same time, it seems logical to assume that the one toward which you were traveling is the one that tripped, so maybe we could code it that way, and you wouldn't need the "which switch" info at all
[15:13:10] <rayh> I had a long discussion with a couple of Smithy users about this.
[15:13:29] <steve_stallings> that is fine for homing, but actual cutting would move many axes at the same time and not know which limit was hit
[15:13:36] <rayh> One was pressing home on all axes at once and the first homed them all.
[15:13:51] <jmkasunich> oh, you are merging the axes, not just the high and low
[15:13:51] <rayh> that is what they found as well.
[15:14:19] <jmkasunich> if you want to do simultaneous homes you need to have independently wired home switches
[15:14:25] <steve_stallings> yes, one single "Stop we hit a limit switch" bit for everything
[15:14:26] <jmkasunich> I thought that would be obvious, but...
[15:14:35] <cradek> hitting any limit stops motion today, and the user has to figure out how to jog out of the limit condition, override limits, and then jog
[15:14:58] <jmkasunich> cradek: but we report the axis and direction that we _think_ was hit
[15:15:07] <cradek> that's true
[15:15:15] <jmkasunich> if one input is driving all of them, that report will probably be wrong
[15:15:31] <cradek> I think it reports all of them using many messages (seriously)
[15:15:48] <jmkasunich> it might
[15:16:03] <cradek> so this is just about the report being right, I understand
[15:16:15] <jmkasunich> not just that actually
[15:16:52] <jmkasunich> if you have high and low limits wired separately, and you hit the high, it will allow you to jog away from it without overriding limits (IIRC)
[15:17:01] <cradek> I don't think that's true, but not 100% sure
[15:17:08] <jmkasunich> if they're wired together, then you have to override to get off because it doesn't know which end you're at
[15:17:55] <cradek> can't test it right now...
[15:18:12] <cradek> sounds like a good idea, whether or not it's there already
[15:19:00] <jmkasunich> steve_stallings: exactly what do you have in mind anyway? some kind of polling things for the individual switches?
[15:19:48] <steve_stallings> yes, polled or serialized I/O to expand a parallel port
[15:20:14] <rayh> good plan steve_stallings
[15:20:20] <alex_joni> hello
[15:20:21] <steve_stallings> if we can separate the "stop" from the "why" it would be possible
[15:20:43] <jmkasunich> like a batch of 74xx245's for input and 74xx374's for output?
[15:21:23] <steve_stallings> sorry, I'm a bit more modern, probably a CPLD
[15:21:30] <jmkasunich> lol
[15:21:44] <jmkasunich> but functionally something like that?
[15:21:48] <jmkasunich> port expander?
[15:22:25] <steve_stallings> yes, yes, to allow a simple par port to be more useful
[15:23:02] <rayh> I saw specs on a mach to proprietary board that does a bit of this.
[15:23:17] <jmkasunich> its possible to make a port expander that doesn't significantly increase the delay (suitable for limits and such, but not really for step/dir)
[15:24:00] <jmkasunich> lets think in terms of 74xx for a moment, less confusing... the actual implementation can be otherwise
[15:24:03] <steve_stallings> keep direct access to 8 data bits for step/dir and high priority bits like e-stop and my magic "stop" bit
[15:24:32] <jmkasunich> have a bunch of 245's for input expansion, and a bunch of 374's for output
[15:24:47] <jmkasunich> a pair of 138's, one for input, one for output
[15:25:00] <steve_stallings> talk 75xx195 shift register if you want to mimic my thoughts
[15:25:07] <jmkasunich> the data port goes to the 245 outputs and the 374 inputs
[15:25:18] <jmkasunich> three extra outputs go to the 138 addr lines
[15:25:25] <steve_stallings> 74xx195
[15:25:43] <jmkasunich> you strobe the output 138 to latch an output port, and the input 138 to latch the input port
[15:26:05] <jmkasunich> the hal driver would do all the addressing and strobing, so all input and output ports could be accessed every servo cycle
[15:26:22] <steve_stallings> nope, I don't want to muck with the high speed access to data bits which I would still use as direct step/dir outputs
[15:26:28] <jmkasunich> (the series of address and strobe operations would be a little long to do a the base rate)
[15:26:48] <jmkasunich> ok, so you are going bit serial, not byte serial
[15:27:06] <steve_stallings> right, and I don't expect to run a "frame" in one base rate cycle
[15:27:50] <alex_joni> is this one-wire ?
[15:27:53] <alex_joni> or clk
[15:27:56] <alex_joni> or clk+data ?
[15:28:15] <steve_stallings> clocked, don't want to depend on decoding time
[15:28:34] <jmkasunich> probalby 3-4 wires total, data in, data out, clock, and a direction bit
[15:28:44] <jmkasunich> (assuming you're expanding inputs and outputs)
[15:28:58] <steve_stallings> right
[15:29:17] <jmkasunich> and the driver would be running in the base thread, since you want to do step/dir thru it
[15:29:18] <steve_stallings> except no direction bit, but need sync or reset bit
[15:30:02] <jmkasunich> not to be a smart-ass, but if you have a cpld, why are you still using software step/dir?
[15:30:06] <steve_stallings> driver will need to have base thread access, but will take multiple cycles of base thread to implement low speed I/O bits
[15:30:26] <alex_joni> jmkasunich: I think of another HAL module that connects to the parport driver
[15:30:34] <alex_joni> using some of the free pins
[15:30:41] <steve_stallings> I want to so something relatively simple, small cpld
[15:31:02] <jmkasunich> steve_stallings: ok, I understand - a few hundred gates, not ten thousand
[15:31:27] <steve_stallings> plus I doubt serialized I/O would be fast enough to do something like Jon's system
[15:31:50] <jmkasunich> well it works for jon ;-)
[15:32:06] <jmkasunich> once the step/dir is offboard, then you can do 8 bits at at time
[15:32:13] <jmkasunich> but thats a tangent...
[15:32:25] <jmkasunich> how many bits of I/O do you anticipate?
[15:32:34] <jmkasunich> (slow IO)
[15:32:36] <steve_stallings> I also want to avoid all the issues with getting MB/bios to play nice with epp
[15:33:05] <steve_stallings> at least 8 of each, maybe expandable
[15:33:38] <jmkasunich> since the slowest base thread I know of anybody using is 50uS = 20KHz, you can probably transfer 8 bits each way in 1mS
[15:33:46] <jmkasunich> the limits and such are read in the servo thread
[15:34:00] <jmkasunich> so your "slow" I/O actually isn't
[15:34:34] <steve_stallings> ok, but maybe someone wants 2000 Hz servo rate and 24 bits of I/O
[15:34:59] <jmkasunich> I don't see a clean way to change the motion controller to do what you want
[15:35:09] <steve_stallings> now it takes 6 servo cycles to pick up on a limit switch, is that acceptable
[15:35:20] <alex_joni> what does this have to do with the motion controller?
[15:35:24] <jmkasunich> 3mS...
[15:36:07] <alex_joni> jmkasunich: motion->hal->new_component->parport_driver ..
[15:36:20] <jmkasunich> alex_joni: read back, he wants the motion controller to have a "you hit some limit" input, as well as the 6 (or more) specific limit inputs, and defer reading the specific ones until he has a chance to upate them
[15:36:22] <steve_stallings> yea, and anybody concerned with 2000 Hz servo should be running a faster base rate
[15:36:32] <alex_joni> oh, I see
[15:36:32] <jmkasunich> we're talking about inputs, not outputs
[15:37:01] <alex_joni> you could have an OR2 on all the inputs, and feed the generic through to all
[15:37:11] <jmkasunich> steve_stallings: anybody doing 2KHz servo should have analog servo, or hardware step/dir
[15:37:21] <steve_stallings> 8-)
[15:37:36] <jmkasunich> anyway, we digress again
[15:37:43] <jmkasunich> alex's idea is interesting
[15:37:55] <alex_joni> it will cause 6 messages though
[15:37:56] <jmkasunich> your "you hit something" input would have to be a pulse, not a maintined level
[15:38:23] <jmkasunich> so all six would turn on during the pulse, then when the pulse goes away, only one remains on, the one you hit
[15:39:02] <steve_stallings> easily done in HAL, but it does sound risky
[15:39:14] <jmkasunich> risky how?
[15:39:21] <alex_joni> jmkasunich: great idea
[15:39:32] <jmkasunich> alex_joni: your idea
[15:39:44] <alex_joni> didn't think about the pulse :)
[15:40:07] <jmkasunich> steve_stallings: risky how?
[15:40:25] <steve_stallings> how will EMC2 react if it gets the 6 messages, but there is no limit signal when it looks again a few mS later?
[15:40:49] <alex_joni> it won't mind
[15:40:50] <jmkasunich> i don't know what you mean by "emc2"
[15:40:53] <steve_stallings> or is this the NIST style everything is an event model?
[15:40:58] <jmkasunich> the motion controller doesn't get messages, it sends them
[15:41:00] <alex_joni> it will stay in machine off
[15:42:45] <steve_stallings> another HAL question, it would seem a properly written serial driver could still access the par port through the standard HAL module so that nothing special needs to be done for step/dir
[15:43:01] <jmkasunich> yes
[15:43:20] <jmkasunich> that does mean that you are limited to one transition per base period on each pin
[15:43:53] <steve_stallings> so that halves the data rate...
[15:43:56] <jmkasunich> where a dedicated driver could do more (at the expense of more execution time, outb() to a parport is slow)
[15:44:02] <jmkasunich> not neccessarily
[15:44:10] <jmkasunich> your hardware could clock on both clock edges
[15:44:37] <steve_stallings> not something I like to do
[15:44:52] <steve_stallings> seems more noise sensitive
[15:44:53] <jmkasunich> and delay a half microsecond or so, so you can change the outgoing data and the clock at the same time, and ensure your hardware gets the new data not the old
[15:45:03] <jmkasunich> not true
[15:45:16] <jmkasunich> a false edge is gonna screw you no matter what
[15:45:39] <jmkasunich> a false edge when you clock on both edges just means you are off by two bits instead of one
[15:45:44] <steve_stallings> not willing to try bit spin delays, modern hardware does strange things
[15:45:57] <jmkasunich> huh?
[15:46:25] <jmkasunich> you mean if the driver was dedicated to your board, doing bitspin to make a complete clock pulse in one base period?
[15:46:31] <steve_stallings> yes
[15:46:44] <steve_stallings> or to delay data to clock edge
[15:46:52] <jmkasunich> if I took that approach, I wouldn't do any spinning
[15:47:12] <jmkasunich> if you aren't using the data port, then both clock and serial data will be coming from the control port
[15:47:20] <steve_stallings> yes
[15:47:26] <jmkasunich> so one outb writes both at the same time
[15:47:42] <jmkasunich> put a half-uS delay on the clock in your hardware
[15:47:57] <jmkasunich> that would also deglitch you
[15:48:46] <steve_stallings> old dogs, new tricks, still makes me uneasy....
[15:49:06] <jmkasunich> say a 2-4 bit shift register, clocked at 4-8MHz, when all bits are high, your internal clock goes high, when all bits are low your internal clock goes low, any other combination, internal clock doesn't change
[15:50:02] <steve_stallings> digital filter I know and use in my quadrature decoder stuff...
[15:50:03] <jmkasunich> (or were you planning to not have a clock in your cpld?)
[15:50:33] <jmkasunich> I guess that is a dig filter isn't it... I didn't think of it that way
[15:50:42] <steve_stallings> would be nice to not have a clock needed on the board, but if there was one it could also be used for "charge pump" stuff
[15:51:04] <jmkasunich> now you are making _me_ nervous
[15:51:19] <jmkasunich> I don't like asynchronous designs (edge triggered)
[15:51:22] <jmkasunich> rather have clocked
[15:51:27] <jmkasunich> esp for cplds
[15:51:36] <steve_stallings> what, you don't trust clocked logic for safety charge pump? 8-)
[15:51:48] <jmkasunich> no, just in general
[15:52:21] <jmkasunich> if the "clock" from the PC is literally going to clock flipflops in your cpld, then yes, it would be quite noise sensitive
[15:52:25] <steve_stallings> rayh - you have been silent too long. how do you feel about 2-3 mS response to limit switch?
[15:52:57] <rayh> Hi. Was off writing a reply.
[15:53:07] <jmkasunich> re: response time... just multiple max machine speed time 2-3mS and see if the answer makes you sweat
[15:53:12] <jmkasunich> for most machines I bet it won't
[15:53:22] <jmkasunich> also, consider the time needed to decel to a stop
[15:53:27] <rayh> Homing from something that has a 2-3 ms uncertainty bothers me a bit.
[15:53:31] <jmkasunich> its probably an order of magnitude bigger
[15:53:44] <cradek> % units '(120inch/min) * 3 millisec' inch
[15:53:48] <cradek> * 0.006
[15:54:15] <jmkasunich> we were talking about limits, not homes, but ray raises a valid point
[15:54:25] <jmkasunich> the answer of course is to set "HOME_LATCH_VEL" slow
[15:54:35] <rayh> But that cpld out there could sum all limits to a single home pin at the higher rate
[15:54:57] <rayh> and then use each "limit" separately for tripping.
[15:55:11] <jmkasunich> lots of ways to handle that issue
[15:55:25] <rayh> I set a minimum of .025 between soft limit and hard limits anyways.
[15:55:33] <jmkasunich> if you are doing software step/dir, you should have HOME_LATCH_VEL at less than one step per servo period anyway
[15:55:40] <jmkasunich> even with fast switches
[15:55:41] <rayh> and more than that between hard limits and end of travel.
[15:55:42] <steve_stallings> I sort of like the single fast "home" bit and many slower "limit" bits
[15:56:11] <jmkasunich> single home bit means you can only home one axis at a time
[15:56:18] <rayh> home pin is ignored if the system is not homing anyway.
[15:56:19] <jmkasunich> (which might be fine with you)
[15:56:31] <steve_stallings> that is typical of many machines anyway (single axis homing)
[15:56:59] <rayh> I've had one fuss from a Sherline "power" user that wants to home em all at once.
[15:57:00] <steve_stallings> almost all home Z separately
[15:57:21] <jmkasunich> I thought sherlines didn't even have switches? or did he add them?
[15:57:38] <rayh> This user added limits.
[15:57:52] <jmkasunich> sherline is still using emc1, right?
[15:58:03] <jmkasunich> so the pins are pre-defined, and all homes are on one pin?
[15:58:24] <rayh> yes the factory installs bdi-4.38 these days
[15:58:29] <rayh> Yes.
[15:58:42] <jmkasunich> ok, so that is what it is, no changing it
[15:59:02] <rayh> exactly.
[15:59:17] <rayh> some have switched to EMC2 and added and twiddled but not very many.
[15:59:23] <steve_stallings> I have no desire to support a new product under EMC1, so not relevant to me
[15:59:47] <rayh> EXACTLY!
[16:00:12] <steve_stallings> I also have no problem telling customers that with my product homing will be a serial process
[16:00:22] <jmkasunich> steve_stallings: everybody has their own ideas, but if I were building your widget, I'd make the hardware transfer one bit in and one bit out on every edge of the clock pulse, use synchronous logic in the cpld
[16:01:08] <jmkasunich> I'd be torn about how to do the driver, but for simplicity of config I'd probably combine the parport code and the serialization code
[16:01:09] <steve_stallings> I did plan to do input and output at same time, one bit of each on every clock cycle
[16:01:40] <jmkasunich> instead of using two separate modules, standard parport + serializer
[16:02:13] <jmkasunich> there will never be a reason to swap your data and clock pins around, so why make them hoop up hal pins for those signals
[16:02:23] <steve_stallings> yea, I guess since it is a GPL environment I can just clone the parts of your code that I need
[16:02:37] <jmkasunich> and why tempt them with parport pins that are actually dedicated to your stuff
[16:02:45] <steve_stallings> true...
[16:02:49] <jmkasunich> the revised driver would export the 8 data port pins, and then N expanded pins
[16:03:52] <steve_stallings> so do you guys think any likely customers would want more than 8 bits in, 8 bits out enough to pay for it?
[16:04:11] <jmkasunich> hard to say
[16:04:27] <rayh> Eight of each is a very nice expansion.
[16:04:27] <jmkasunich> software step/dir (4 axis), plus I/O
[16:04:31] <jmkasunich> might be interseting
[16:04:44] <jmkasunich> seperate limits and homes for 4 axis is 12 inputs, no outputs
[16:04:45] <steve_stallings> I usually like 1.5 times as many ins as outs, but doesn't fit serial model well
[16:04:59] <rayh> If we could add spindle pwm in there without killing the serial it would be nice.
[16:05:11] <jmkasunich> well, most of the per-bit cost will be terminal blocks, and any drivers or isolation
[16:05:30] <jmkasunich> three axis plus pwm would fit on the 8 fast outputs
[16:05:35] <steve_stallings> ray - I am keeping spindle, charge pump, eStop etc. in mind as I think this through
[16:06:01] <rayh> You're a good man, Steve.
[16:06:28] <steve_stallings> that remains to be seen 8-)
[16:07:05] <jmkasunich> hmm
[16:07:07] <alex_joni> steve_stallings: btw, thanks for the help while moving linuxcnc.org (not sure I ever got a chance to thank you), keeping the old page online came in handy a few times
[16:07:13] <jmkasunich> the serial clock makes a nice charge pump
[16:07:19] <steve_stallings> if I have a single fast "home" pin, can it do double duty as "probe" also?
[16:07:36] <jmkasunich> yes
[16:07:42] <rayh> Sure.
[16:07:47] <jmkasunich> just route it to both pins on the motion controller
[16:07:56] <steve_stallings> alex - thank YOU for working through the process
[16:08:06] <jmkasunich> home is ignored except when homing, probe is ignored execpt when probing
[16:08:25] <rayh> I love EMC2!
[16:08:37] <steve_stallings> jmk - yep, that was the plan (charge pump)
[16:09:31] <steve_stallings> but maybe not.... EMC should be able to examine inputs even with eStop in effect?
[16:09:33] <alex_joni> rayh: we all do ;)
[16:10:33] <jmkasunich> estop and charge pump don't have to be the same thing
[16:10:33] <steve_stallings> maybe charge pump should be a regular serialized output bit, that would assure that the complete interface was working
[16:10:55] <jmkasunich> the actual relay or whatever would be the OR (in hardware) of one output bit (estop) and the chargepump
[16:12:46] <steve_stallings> I love cpld's almost as much as ray loves EMC2
[16:13:17] <rayh> steve_stallings, You going to have a prototype of this next week?
[16:13:30] <alex_joni> why that late?
[16:13:33] <rayh> I'll send cash!
[16:13:43] <steve_stallings> got to give ray time to build a test machine... 8-)
[16:13:45] <jmkasunich> steve_stallings: speaking of charge pumps (and a minor change of topic) did you ever change the cap on your existing board's charge pump?
[16:13:53] <steve_stallings> yes
[16:13:54] <rayh> I've got one.
[16:14:12] <rayh> Is this going to be an expansion of the parport isolator card?
[16:15:01] <steve_stallings> cost vs. optos and 24 volt tolerance yet to be decided, likewise having more than 8 bits in
[16:15:58] <steve_stallings> plan would be new product, and if opto isolated, then drop the old PMDX-120
[16:16:57] <rayh> Okay.
[16:17:15] <rayh> I was thinking a parport plug through.
[16:18:14] <steve_stallings> nah, that would waste the I/O on the pass through board that was reused for serial stuff
[16:19:00] <rayh> Okay as long as you find or supply downstream cables for xylotex or relatives.
[16:19:18] <rayh> * rayh slaps rayh for using a bad word.
[16:20:03] <steve_stallings> ok, I mis-understood. having a pass thru for step/dir on the new product would make sense
[16:20:24] <steve_stallings> you ok with opto isolate I/O but not step/dir?
[16:22:55] <rayh> Sure if you are.
[16:23:29] <steve_stallings> ok, thanks to all of you for letting me use EMC channel to test product ideas
[16:23:55] <steve_stallings> now back to your regularly scheduled programming.....
[16:24:25] <rayh> sounds like a great product. I can see an order for 40 of em real soon.
[16:24:58] <jmkasunich> steve_stallings: about the pass thru...
[16:25:04] <steve_stallings> ok
[16:25:08] <jmkasunich> what if you have a parport connector on the far end
[16:25:16] <jmkasunich> the 8 data pins pass thru to it
[16:25:31] <jmkasunich> the 4 control and 5 status pins are _some_ of the serial I/O
[16:25:45] <jmkasunich> and the additional serial I/O is available on terminal blocks or another connector
[16:27:18] <steve_stallings> more likely a 26 pin ribbon header that mates with DB-25 compatible pinout, data bits buffered and inhibited if eStop
[16:28:25] <steve_stallings> will consider the I/O from the pass through as possible additions to 8in/8out
[16:29:25] <jmkasunich> that would support daisy chaning the expander between the PC and _any_ product, yours or another, that expects a normal parport
[16:29:32] <steve_stallings> yep
[16:29:54] <jmkasunich> in fact, the driver might well want to name its hal pins accordingly
[16:44:52] <jmkasunich> pmdx-199.0.pin-2-out (for the data port pins)
[16:45:29] <jmkasunich> pmdx-199.0.pin-14-out (or whatever) for the other I/O on the pass thru (maybe with something to indicate that its "aux" IO, slower)
[16:45:56] <jmkasunich> pmdx-199.0.extra-1.out (or something) for the rest of the expanded I/O
[16:46:04] <jmkasunich> whatever makes sense
[16:46:37] <jmkasunich> keeping in mind that loading the driver and doing "halcmd show pin" is the most likely way people will discover its capabilities
[16:50:19] <steve_stallings> sounds reasonable, now all we need is hardware... 8-)
[16:51:46] <steve_stallings> time for me to take advantage of the weather and move more junk. later....
[16:51:56] <jmkasunich> have fun ;-)
[16:52:00] <steve_stallings> steve_stallings is now known as steves_logging
[16:52:06] <alex_joni> bye steve
[17:07:26] <alex_joni> jmkasunich: wanted to ask you something
[17:08:01] <alex_joni> is there any exact reason for having HAL parameters?
[17:08:24] <alex_joni> as opposed to HAL pins doing the same?
[17:08:54] <jmkasunich> hard to say\
[17:09:22] <jmkasunich> parameters were originally intended to be things that you wouldn't want to connect to another module
[17:09:40] <jmkasunich> in the hardware world, pins are connectors, and parameters are trimpots and dip switches
[17:09:44] <alex_joni> yeah, but it seems people keep finding stuff to connect everything to
[17:10:00] <jmkasunich> yep
[17:10:24] <alex_joni> it probably would extend the flexibility quite a bit
[17:10:27] <jmkasunich> someday, when the much delayed hal refactor comes around, I'm going to seriously consider doing away with parameters
[17:10:57] <alex_joni> then maybe have setp set pin, and I think the functionality wouldn't be harmed at all
[17:11:14] <jmkasunich> yeah
[17:11:24] <jmkasunich> the pin lists would get a lot longer
[17:11:41] <alex_joni> have you looked at it recently?
[17:11:48] <jmkasunich> the pin list?
[17:11:52] <alex_joni> especially with halui loaded
[17:11:54] <alex_joni> yeah
[17:11:59] <jmkasunich> pretty long already
[17:12:11] <alex_joni> 100+ pins on halui
[17:15:18] <jmkasunich> 347 pins, 230 params, 83 signals
[17:15:24] <jmkasunich> thats halui/halvcp
[17:16:00] <jmkasunich> 153 of the pins are halui
[17:17:21] <alex_joni> almost half
[17:17:45] <jmkasunich> I wonder if its possible to not export halui.joint and motion.axis pins for joints we're not using?
[17:18:06] <alex_joni> we are using a #define for max_axis
[17:18:11] <alex_joni> which is set to 8 right now
[17:18:17] <alex_joni> how about making it 6 fow now
[17:18:24] <jmkasunich> thats not what I mean
[17:18:27] <alex_joni> I know
[17:18:33] <jmkasunich> the ini file defines the joints
[17:18:43] <alex_joni> but it would still be an improvement
[17:18:53] <alex_joni> I can do it in halui (detect number of axes), and go from there
[17:18:59] <jmkasunich> until somebody needs more, then we get a bug report or a confused user
[17:19:09] <alex_joni> I'll do it now
[17:19:21] <jmkasunich> how do you detect the number?
[17:19:25] <jmkasunich> from the ini file?
[17:19:27] <alex_joni> [TRAJ]
[17:19:32] <alex_joni> AXES = foo
[17:19:33] <alex_joni> iirc
[17:19:44] <alex_joni> and yes, I know it's not 100% right
[17:20:00] <alex_joni> it assumes joints = axes, which the rest of emc2 also does
[17:21:03] <jmkasunich> I think the problem with motion is that the ini file doesn't get read until after motmod is loaded
[17:21:19] <jmkasunich> however, we could pass num_axes as an insmod parameter
[17:21:30] <jmkasunich> default it to 8 so we don't break existing configs
[17:21:54] <alex_joni> I seriously doubt anyone can use more than 6
[17:21:55] <jmkasunich> but the loadrt line would do "num_axes=[TRAJ]AXES"
[17:22:07] <alex_joni> you can't define them in the ini, and motion won't enable them afaik
[17:22:13] <jmkasunich> ok, so we default it to 6
[17:22:22] <alex_joni> I'm ok with 8 too..
[17:22:36] <alex_joni> easiest would be to use the name of the #define
[17:22:48] <alex_joni> and default it to 8
[17:23:04] <alex_joni> are you still working on the lyx stuff?
[17:23:06] <jmkasunich> that would need checked tho, the define is probably used in places where a compile time constant is needed
[17:23:21] <alex_joni> oh, right.. arrays
[17:23:40] <jmkasunich> I was thinking about trying to detect lyx in ./configure, and generate the pdfs in Makefile
[17:23:51] <alex_joni> ok, holler if you need help
[17:23:58] <jmkasunich> help!
[17:24:03] <alex_joni> :D
[17:24:09] <alex_joni> anything specific?
[17:24:12] <jmkasunich> actually I haven't gotten started yet (you distracted me)
[17:24:17] <alex_joni> .)
[17:24:22] <jmkasunich> but the configure stuff is gonna be fun
[17:24:28] <alex_joni> hang on, finishing the halui change, and I'll look at configure
[17:24:35] <jmkasunich> I did figure out how to make lyx generate the pdfs from the cmd line
[17:38:08] <alex_joni> jmkasunich: it will take a while.. I broke halui :(
[17:40:27] <jmkasunich> no rush
[17:41:51] <alex_joni> I don't quite get this :(
[17:42:40] <jmkasunich> whats happening?
[17:43:12] <alex_joni> if I move the iniLoad() call earlier, halui stops working (nothing happens when the HAL pins get triggered)
[18:18:10] <jmkasunich> * jmkasunich smacks the lyx developers
[18:18:30] <rayh> what's happening?
[18:18:35] <jmkasunich> lyx-qt -version sends its output to stderr, not stdout
[18:18:47] <jmkasunich> and makes about 10 lines of output
[18:18:57] <jmkasunich> so I can't pipe it thru grep to filter it down
[18:19:09] <rayh> darn.
[18:19:16] <alex_joni> 2>1 ?
[18:19:19] <alex_joni> or similar ?
[18:19:30] <alex_joni> then pipe it through grep ?
[18:19:33] <jepler> 2>&1
[18:19:48] <jmkasunich> duh
[18:20:10] <jmkasunich> I tried that, but I mistyped it as 2>$1
[18:20:14] <jepler> oops!
[18:21:33] <jmkasunich> can I assume the existance of awk during ./configure?
[18:21:45] <jepler> yeah awk is ancient as unix
[18:22:07] <jepler> but it's not hard to accidentally use gawk features
[18:22:07] <jmkasunich> I want to pull the version out of "LyX 1.3.6 of Sat, Jul 16, 2005
[18:22:07] <jmkasunich> "
[18:22:41] <jmkasunich> /^Lyx/ { print $2 } isn't gawk I hope
[18:22:56] <jepler> no, should be fine
[18:23:52] <jepler> though the hardcore shell nerd would do it without awk:
[18:23:53] <jepler> $ set -- `lyx --version 2>&1 | grep ^LyX`; echo $2
[18:23:53] <jepler> 1.3.6
[18:24:19] <jmkasunich> neat
[18:24:45] <jmkasunich> you can invoke "lyx" from the cmd line?
[18:24:54] <jmkasunich> on my box I have to invoke "lyx-qt"
[18:25:04] <jepler> lrwxrwxrwx 1 jepler jepler 15 2006-05-06 08:28 bin/lyx -> /usr/bin/lyx-qt
[18:25:11] <jepler> looks like I made that symlink for myself
[18:25:22] <jmkasunich> ok
[18:27:32] <jmkasunich> hmm, I like the set version
[18:27:51] <jmkasunich> but I want to do LYX_VER=`that command`
[18:27:56] <jmkasunich> which means nesting ``
[18:28:13] <jepler> $(...) and `...` are the same, except the former can nest .. but I'm not 100% sure of the portability.
[18:28:41] <jepler> maybe you just want: set -- `lyx ...`; LYX_VER=$2
[18:28:56] <jmkasunich> duh
[18:32:50] <jepler> alex_joni: you were saying something about multiple GUIs and improper use of the command channel. Is there some bug in AXIS I should fix?
[18:33:08] <jepler> alex_joni: I didn't follow the discussion then and now it's gone from my scrollback
[18:35:43] <alex_joni> jepler: no
[18:35:57] <alex_joni> nothing wrong with AXIS
[18:36:38] <jepler> you said something about all the GUIs identifying as 'xemc'. Is there any advantage to changing that?
[18:36:44] <alex_joni> no
[18:36:56] <alex_joni> not really
[18:37:57] <alex_joni> the only advantage would be if they would use different command channels
[18:38:00] <alex_joni> which isn't the case
[18:38:27] <jmkasunich> is there any reason _not_ to have them correctly identify themselves?
[18:38:42] <alex_joni> jmkasunich: only changing the nml file
[18:39:04] <alex_joni> and causing potential config problems
[18:39:10] <jmkasunich> thats a good reason
[18:39:13] <jmkasunich> forget I said anything
[18:39:56] <alex_joni> * alex_joni hates pointers
[18:40:05] <jepler> speaking of the nml file, is 'tool' used?
[18:40:05] <jepler> P tool toolCmd LOCAL localhost RW 0 1.0 0 3
[18:40:12] <alex_joni> yes
[18:40:14] <jepler> ok
[18:40:20] <alex_joni> task sends stuff to iocontrol through there
[18:40:40] <alex_joni> jepler: I kinda cleaned up unused stuff last time I touched emc.nml (when installing emcsvr by default)
[18:40:45] <jepler> ok
[18:40:50] <jepler> it did look short and sweet
[18:40:57] <alex_joni> thank you :D
[18:41:52] <alex_joni> if I have a function that takes a (hal_bit_t *foo) parameter..
[18:42:06] <alex_joni> can I call it like this foo(&hal_bit_var) ?
[18:42:26] <alex_joni> I'm getting: emc/usr_intf/halui.cc:1870: error: invalid conversion from .volatile unsigned char. to .volatile hal_bit_t*.
[18:43:12] <jmkasunich> the first is a char, the second is pointer to char
[18:44:00] <alex_joni> which one is a char?
[18:44:02] <jmkasunich> what function are you calling?
[18:44:12] <alex_joni> foo (hal_bit_t *pin)
[18:44:17] <jmkasunich> (my line 1870 and yours arent the same)
[18:44:20] <alex_joni> that's the prototype
[18:44:26] <alex_joni> no, I'm modifying it now
[18:44:42] <jmkasunich> foo is not one of the HAL API functions?
[18:44:49] <alex_joni> static int check_bit_changed(hal_bit_t *halpin, hal_bit_t *oldpin) {
[18:44:49] <alex_joni> hal_bit_t bit;
[18:45:18] <alex_joni> ...
[18:45:22] <jmkasunich> a pin is not a pointer to a bit
[18:46:09] <alex_joni> I need only the value
[18:46:19] <alex_joni> the one found in the shm
[18:46:22] <jmkasunich> you are trying to resolve that multiple-read thing?
[18:46:26] <alex_joni> right
[18:46:38] <alex_joni> and simplify it meanwhile
[18:46:52] <jmkasunich> you have a big struct called halui_data
[18:46:57] <jmkasunich> its members are pointers to pins
[18:46:58] <alex_joni> right
[18:47:06] <alex_joni> hal_bit_t * foo
[18:47:10] <alex_joni> are the members
[18:47:22] <alex_joni> some, some are hal_float_t *, etc
[18:47:31] <jmkasunich> right
[18:47:36] <alex_joni> I care for bit now
[18:47:49] <alex_joni> I also have an struct with the old data (not pointers)
[18:48:09] <alex_joni> so I wanted to pass the address of that &foo, so it can be modified in the function
[18:48:40] <alex_joni> let me pastebin the relevant stuff
[18:48:45] <jmkasunich> ok
[18:49:17] <alex_joni> http://pastebin.ca/119225
[18:49:34] <alex_joni> ok, you can stop looking
[18:49:39] <alex_joni> found my stupid typo
[18:50:20] <jmkasunich> need **halpin I think
[18:50:29] <alex_joni> no.. don't need to call it with *()
[18:50:37] <alex_joni> I only need the value in there
[18:51:01] <jmkasunich> oh, right... because you are only reading the halpin, not modifying it
[20:36:09] <jmkasunich> jepler: you around?
[20:37:54] <jepler> jmkasunich: hi
[20:37:59] <jmkasunich> hi
[20:38:14] <jmkasunich> I'm looking at the makefile to add document build
[20:38:21] <jmkasunich> and I'm going boggle boggle boggle
[20:38:26] <jepler> hah
[20:38:52] <alex_joni> boggle ?
[20:39:00] <jmkasunich> my mind is boggled
[20:39:41] <alex_joni> * alex_joni says halui is finished for now..
[20:39:45] <jepler> well, the simplest thing to do is write a rule that builds the documentation any time it is requested:
[20:39:49] <jepler> .phony: docs
[20:39:49] <jmkasunich> yay
[20:39:51] <jepler> docs:
[20:39:53] <jepler> (or maybe that's ".PHONY"; I forget)
[20:39:56] <jepler> commands
[20:40:07] <alex_joni> let the rest be feature requests
[20:40:55] <jmkasunich> jepler: any particular place I should insert this stuff? or just at the bottom?
[20:41:28] <jmkasunich> things I need to do:
[20:41:35] <jmkasunich> add the document files to the clean target
[20:41:37] <jepler> jmkasunich: maybe in a Submakefile?
[20:42:11] <jmkasunich> conditionally invoke the docs build (based on config results, I have a var called BUILD_DOCS that will be either yes or no
[20:42:47] <jmkasunich> line 51 lists dirs that have submakefiles
[20:42:55] <jepler> ifeq ($(BUILD_DOCS),yes) ... endif
[20:42:58] <jmkasunich> can I add ../docs/src to that list?
[20:43:08] <jepler> yes it should be OK to have a directory starting with ".." in there
[20:43:51] <jmkasunich> ok, thats done, and the actual making rules will now go in the submakefile
[20:44:01] <jmkasunich> can I stick the clean rule in the submake too?
[20:44:38] <jepler> yes, I think you can
[20:45:17] <jmkasunich> ifneq ($(MAKECMDGOALS),clean)
[20:45:17] <jmkasunich> SUBMAKEFILES := $(patsubst %,%/Submakefile,$(SUBDIRS))
[20:45:17] <jmkasunich> -include $(SUBMAKEFILES)
[20:45:17] <jmkasunich> endif
[20:45:34] <jmkasunich> does that mean the submakefiles are just included inline with the main Makefile?
[20:45:56] <jepler> yes
[20:46:25] <jmkasunich> so all paths in the Submakefile need to be relative to the dir where the main makefile is, _not_ where the submakefile is?
[20:49:57] <jepler> yes
[20:50:13] <jmkasunich> eww
[20:50:54] <jepler> I know
[20:51:29] <jepler> that's part of the price to pay for having a non-recursive build
[20:51:40] <jmkasunich> could I do something like:
[20:51:48] <jmkasunich> DOCSRC=../docs/src
[20:52:03] <jmkasunich> then $DOCSRC/MasterHAL.lyx
[20:52:04] <jmkasunich> etc
[20:52:06] <jepler> sure
[20:52:27] <jmkasunich> doesn't really reduce the typing that much, but it will be easier to change later if needed
[20:52:39] <jmkasunich> each doc is gonna have a crapload of dependencies
[20:52:47] <jmkasunich> all the images in the doc, for starters
[20:53:01] <jepler> you may also be able to use $(addprefix) .. see rs274ngc/Submakefile
[20:53:20] <jepler> this adds the given prefix (first argument) to all the words in the second argument
[20:53:22] <jmkasunich> oh, to add a prefix to all files in a long list
[20:53:32] <jmkasunich> sounds very usefull
[20:55:51] <jmkasunich> ifneq ($(MAKECMDGOALS),clean)
[20:56:05] <jmkasunich> implies that you don't invoke submakefiles for make clean
[20:56:08] <jmkasunich> any reason why?
[20:57:18] <jepler> no, I'm not sure why
[20:57:34] <jmkasunich> I made a submakefile like this:
[20:57:39] <jmkasunich> clean:
[20:57:39] <jmkasunich> echo "called docs/src/ clean"
[20:57:39] <jmkasunich> docs:
[20:57:39] <jmkasunich> echo "called docs/src/ docs"
[20:57:51] <jmkasunich> make docs does the expected
[20:57:52] <jepler> I know why the .d files aren't included but those reasons don't apply to Submakefiles
[20:58:04] <jepler> does the CVS history say anything useful
[20:58:05] <jepler> ?
[20:58:36] <jmkasunich> john@ke-main-ubuntu:~/emcdev/emc2head/src$ make docs
[20:58:36] <jmkasunich> Makefile:278: warning: overriding commands for target `clean'
[20:58:36] <jmkasunich> ../docs/src/Submakefile:2: warning: ignoring old commands for target `clean'
[20:58:36] <jmkasunich> echo "called docs/src/ docs"
[20:58:36] <jmkasunich> called docs/src/ docs
[20:58:42] <jmkasunich> checking history now
[20:58:49] <jepler> cradek committed that with '
[20:58:49] <jepler> cradek committed that with 'make clean doesn't need to generate depends
[20:58:55] <jepler> ' as the log message
[20:59:43] <jmkasunich> oh, so I should pester him
[20:59:54] <jepler> it looks like the 'ifneq' around the include $(DEPS)' does the same thing, but better
[21:00:07] <jepler> so try removing the one around the SUBMAKEFILES and see if it is OK
[21:00:08] <jmkasunich> line 104 you mean?
[21:00:25] <jepler> yes
[21:00:56] <jepler> in particular, 'make clean; make clean' shouldn't generate any dependency files
[21:01:23] <jepler> seems to work fine
[21:01:27] <jmkasunich> yeah
[21:01:43] <jmkasunich> it seems I can't have a clean target in the submakefile though
[21:01:58] <jmkasunich> (I'm afraid my brain hasn't moved beyond recursive make)
[21:02:25] <jmkasunich> thats what this message is about:
[21:02:47] <jmkasunich> Makefile:278: warning: overriding commands for target `clean'
[21:02:47] <jmkasunich> ../docs/src/Submakefile:2: warning: ignoring old commands for target `clean'
[21:04:19] <jmkasunich> the main clean rule does -rm -f $(TARGETS)
[21:04:48] <jmkasunich> TARGETS seems to be the headers and the .po files only?
[21:04:52] <jmkasunich> what about the binaries?
[21:05:36] <jmkasunich> ok, it does include the binaries
[21:05:51] <jmkasunich> but I'll be damned if I can figure out when they get added to the list
[21:06:51] <alex_joni> jmkasunich: in each Submakefile I guess
[21:06:59] <alex_joni> TARGETS += ../bin/emcsh
[21:07:01] <alex_joni> ...
[21:07:09] <alex_joni> TARGETS += ../lib/libnml.so
[21:07:13] <alex_joni> and so on
[21:07:18] <jmkasunich> yeah, I was just starting to come to that conclusion
[21:07:25] <jepler> jmkasunich: ah, write your commands under 'docclean' and then make 'clean' depend on 'docclean'
[21:07:38] <jmkasunich> ok
[21:07:52] <jmkasunich> and add the names of the pdfs to TARGETS in the submakefile
[21:07:58] <jmkasunich> s/and/or/
[21:08:33] <jepler> yes. adding to TARGETS also has the effect of trying to make them by default too
[21:08:44] <jmkasunich> probably don't want to be adding .pdf files to TARGETS though, don't know where else TARGETS is used
[21:09:09] <alex_joni> maybe replicate a DOCSTARGETS
[21:09:14] <alex_joni> and add them there
[21:09:26] <alex_joni> but for 2 files it seems overkill
[21:09:39] <alex_joni> and you can't know how many files the html version will generated anyways
[21:09:57] <jmkasunich> I think I like the docclean idea better
[21:10:10] <jmkasunich> keep all docs specific commands and lists of files and such in the submakefile
[21:10:22] <jmkasunich> decouple it as much as possible from the main makefile
[21:10:39] <alex_joni> right
[21:14:45] <jmkasunich> so what exactly is the default target anyway?
[21:14:51] <jmkasunich> I'm used to it being "all"
[21:15:14] <jepler> When 'make' isn't given a target, it chooses the first one in the file
[21:15:17] <jepler> I called it 'default'
[21:15:18] <jepler> default: configs userspace modules
[21:15:31] <jepler> it could just as well be called 'all'
[21:15:31] <jmkasunich> duh
[21:15:47] <jmkasunich> I'm just having trouble navigating that file
[21:15:56] <jepler> userspace depend on $(TARGETS)
[21:15:57] <jepler> userspace: $(TARGETS)
[21:15:58] <jmkasunich> I knew about the first target rule, just didn't spot it
[21:16:21] <jmkasunich> I'm tempted to just add "docs" to the default rule
[21:16:30] <jmkasunich> and not muck with TARGETS at all
[21:16:51] <jepler> that would mean that each 'make' will rebuild the documentation
[21:16:59] <jepler> if it takes more than a few seconds, it's not desirable...
[21:17:07] <jmkasunich> it does
[21:17:34] <jmkasunich> the rules for each individual document will have dependencies, and they shouldn;t rebuild unless the dep's change
[21:18:00] <jepler> that's the best, but I was afraid of the trouble to hand-generate them, and the fragility of manually generating them (the dependencies)
[21:18:02] <jmkasunich> HAL_Handbook.pdf: HAL_Handbook.lyx some-image.png another-image.eps
[21:18:11] <jepler> er, the trouble to automatically generate them
[21:18:46] <jepler> but if you have taken care of that, then it's fine to put 'default: docs' or TARGETS += HAL_Handbook.pdf
[21:18:46] <jmkasunich> there is no way (that I know) to automatically generate deps for lyx files
[21:18:55] <alex_joni> grep & sed
[21:19:08] <alex_joni> but like jeff said.. a pain
[21:19:12] <jmkasunich> grep the lyx file(s) for include?
[21:19:38] <alex_joni> yeah, and for image
[21:19:52] <jepler> bbl
[21:20:08] <alex_joni> \begin_inset Graphics
[21:20:09] <alex_joni> filename ../../images/axis.png
[21:20:41] <alex_joni> actually "\include"
[21:26:33] <jmkasunich> whats the difference between "include" and "input"
[21:26:43] <jmkasunich> \begin_inset Include \include{install/installing_emc2.lyx}
[21:26:43] <jmkasunich> \begin_inset Include \input{hal/intro.lyx}
[21:28:39] <jmkasunich> ok, I finally figured out what Jeff was saying
[21:29:00] <jmkasunich> instead of trying to come up with dependencies that will remake the docs when and only when needed
[21:29:14] <jmkasunich> have the docs target unconditionally make the docs, and only invoke it when needed
[21:29:22] <jmkasunich> (like when building packages to release)
[21:30:27] <alex_joni> right
[21:30:44] <alex_joni> and I have nfc what the difference is (between include and input)
[21:30:49] <alex_joni> couldn't figure it out
[21:36:34] <jmkasunich> should the user handbook be called "User_Handbook.pdf", or "Users_Handbook.pdf" ?
[21:37:34] <jmkasunich> oh, I guess we already call it EMC2_User_Manual.pdf
[21:54:59] <jmkasunich> so, should the hal book be HAL_Manual.pdf or HAL_User_Manual.pdf
[21:55:07] <jmkasunich> I had the former, but the latter is probably better
[21:55:32] <alex_joni> It's HAL_DOcumentation.pdf now
[21:56:16] <jmkasunich> oh
[21:56:34] <jmkasunich> I thought it was HAL_Introduction.pdf
[21:56:40] <jmkasunich> damn thing has more names than my cat
[21:57:38] <jmkasunich> I strongly prefer HAL_User_Manual I think
[21:57:49] <alex_joni> it was Intro, but was renamed a while ago
[21:57:54] <rayh> Sounds good to me.
[21:58:02] <jmkasunich> but if thats going to mean that an outdated version called HAL_Documentation.pdf remains on a users system when they upgrade, that sucks
[21:59:01] <jmkasunich> hmm, I have 2.0.3 installed, and there is no hal documentation in /usr/share/docs/emc2
[21:59:06] <jmkasunich> just the user manual
[22:02:33] <alex_joni> right
[22:02:41] <alex_joni> the HAL_Documentation is only on the website
[22:02:45] <alex_joni> www.linuxcnc.org
[22:02:58] <jmkasunich> ok
[22:03:18] <jmkasunich> I'm calling it HAL_User_Manual then, and we should eventually put that on the website
[22:07:23] <alex_joni> ok
[22:07:37] <jmkasunich> doing a final test before commit
[22:07:55] <jmkasunich> then hopefully somebody else can test, make sure I cvs added all the required files
[22:17:24] <jmkasunich> alex_joni: can you update and verify that make doc works?
[22:19:58] <alex_joni> jmkasunich: update yes, verify no.. I shut my box down .(
[22:20:05] <alex_joni> first thing tomorrow
[22:20:09] <jmkasunich> ok
[22:20:44] <alex_joni> I'll drop you an email if it doesn't work
[22:20:53] <jmkasunich> I think I'm gonna start to backport the manual stuff to the v2.0 branch
[22:21:16] <jmkasunich> so when 2.0.4 is released it will have the manuals
[22:21:22] <jmkasunich> two more things tho:
[22:22:09] <jmkasunich> 1) somebody (probably cradek) needs to change the package building scripts or whatever to invoke "make docs" and to install the docs wherever they should be (/usr/share/docs/emc2 I think)
[22:22:42] <jmkasunich> 2) paul says he's gonna be making a new bdi with a new emc2 package, I wonder if we should bet him to use 2.0.3 instead of a random checkout from head
[22:22:59] <jmkasunich> s/bet/beg
[22:24:34] <jmkasunich> wow, configure.in has been touched 18 times since the 2.0 branch
[22:25:38] <jmkasunich> Makefile 48 times
[22:25:46] <jmkasunich> backporting isn't gonna be fun
[22:26:48] <jmkasunich> bbl
[22:42:19] <alex_joni> jmkasunich: by reading the stuff I can see one problem
[22:42:35] <alex_joni> you assume lyx-qt, other distros have lyx, others ...
[22:57:28] <danfalck> cradek, with yours and jeff's help, I have the latest version of Axis running
[22:57:47] <danfalck> tried ou the *.py open filter and it works for me
[22:58:24] <danfalck> my little python prog sent axis some code (which I will reformat to make it actually work)
[22:59:05] <danfalck> cradek, my question now is how to use the *.dxf filter and the bitmap filters
[23:00:19] <alex_joni> danfalck: what software do you use to convert from dxf to ngc?
[23:01:06] <danfalck> alex_joni, there are some small utilities that we have listed in the linuxcnc wiki that I have been playing with a bit
[23:01:09] <danfalck> codeg
[23:01:30] <danfalck> but I'm really just interested in how things interact with axis
[23:01:44] <danfalck> I can run python programs that generate gcode
[23:01:45] <danfalck> with it
[23:01:59] <alex_joni> just like that you should be able to run any program
[23:02:18] <danfalck> I didn't know if jeff and chris where doing some trick to convert dxf to gcode right through axis
[23:02:36] <alex_joni> not that I know of
[23:17:53] <alex_joni> jmkasunich: I assume you meant 'make docs' not 'make doc', I'm going to fix that
[23:20:53] <alex_joni> jmkasunich: the pdf built nicely, so I'd say it's ok (this was on a fresh dapper with fresh lyx)
[23:31:41] <jmkasunich> back
[23:31:47] <jmkasunich> thanks for testing that alex_joni