Back
[01:23:24] <fenn_> fenn_ is now known as fenn
[12:17:27] <fenn_> fenn_ is now known as fenn
[12:33:10] <skunkworks_> So should I add the next read function? keeping the old one? It ran all night with just pci8255.0.0.read
[12:33:27] <fenn> yes
[12:34:28] <skunkworks_> :)
[12:34:42] <skunkworks_> morning - isn't it a bit early for you? or have you been up all night?
[12:37:20] <fenn> i dont even know
[12:37:31] <fenn> dont forget to write a man page
[12:38:42] <fenn> some comments would be nice
[12:41:44] <skunkworks_> sure. I think I may be getting it down.
[12:45:09] <alex_joni> hi samco
[12:45:43] <skunkworks_> morning alex
[12:56:36] <skunkwork1> addf pci8255.0.0.read servo-thread 1
[12:56:36] <skunkwork1> addf pci8255.0.1.read servo-thread 1
[13:05:41] <alex_joni> skunkworks: still running?
[13:06:09] <alex_joni> skunkwork1: keep adding them until it starts misbehaving :)
[13:08:23] <skunkworks_> still running so far.
[13:09:06] <skunkworks_> so - is running read-all doing the exact same thing as running all 3 read threads?
[13:22:59] <alex_joni> I think I saw 4 read threads in there
[13:23:33] <alex_joni> hmm.. no, only 3
[13:23:35] <alex_joni> http://www.pastebin.ca/963631
[13:23:43] <alex_joni> skunkwork1: basicly yes
[13:24:39] <skunkworks_> Heh - It locked up..
[13:24:47] <alex_joni> with 2? or 3?
[13:24:50] <skunkworks_> 2
[13:25:06] <alex_joni> ok, next try 0.0 and 0.2
[13:25:20] <skunkworks_> or should I just try .1?
[13:32:25] <alex_joni> skunkworks: that too
[13:34:58] <skunkwork1> addf pci8255.0.1.read servo-thread 1
[13:35:22] <skunkworks_> we will try that for a while
[14:03:45] <skunkworks_> cradek: your website is down.
[14:04:08] <skunkworks_> here anyway/
[14:04:26] <cradek> huh, seems ok from here
[14:06:02] <skunkworks_> cradek: what is the ip address?
[14:06:23] <cradek> 76.79.20.190
[14:06:43] <skunkworks_> got it - it just started resolving. Maybe it was a dns issue on this end.\
[14:07:48] <alex_joni> fine from here too
[14:08:35] <alex_joni> cradek: what's the result to that code snip?
http://timeguy.com/cradek/01201480454
[14:10:39] <cradek> like the title says, irritation
[14:11:49] <alex_joni> oh, come on.. don't make me compile/run it
[14:13:42] <skunkworks_> .00000000000000000000000000000000000000000000000000000000000001?
[14:13:52] <jepler> skunkworks_: you're an optimist
[14:13:55] <alex_joni> bbl.. gotta run
[14:14:16] <jepler> skunkworks_: sorry, other stuff caught my attention this weekend (ooh, a shiny thing!) and I never looked at the pci_8255 driver
[14:14:49] <skunkworks_> jepler: no problem. I had fun making it lock up the computer. :)
[14:15:05] <skunkworks_> Did you notice that it did lock up with 0x0ff?
[14:15:12] <skunkworks_> just took a bit longer.
[14:15:33] <jepler> skunkworks_: I don't like that :(
[14:15:38] <jepler> it should lock up immediately, or not at all
[14:15:44] <jepler> that's how I prefer my software
[14:15:49] <skunkworks_> * skunkworks_ wonders what the shiny thing is..
[14:15:51] <skunkworks_> Heh
[14:16:21] <skunkworks_> It did lock up this morning with 2 read threads running.. 0,1 now running 1 and it is still running.
[14:16:36] <jepler> the shiny (but extremely buggy) thing is:
http://emergent.unpy.net/index.cgi-files/sandbox/demo_comp.png
[14:16:37] <skunkworks_> ran all night with the 0 thread
[14:17:10] <skunkworks_> Wow - I was expecting something outside of emc - very cool
[14:21:19] <fenn> cutter comp for concave corners?
[14:39:05] <jepler> fenn: it's a 2D path offsetting algorithm outside of emc .. it just happens that my test program emits gcode
[14:39:39] <cradek> jepler: I think you've written pocketing... That's really great news
[14:40:02] <cradek> how do you do the loop removal? that seems like the hard part to me
[14:40:03] <jepler> cradek: well, it doesn't handle islands or paths that break apart (yet)
[14:40:30] <jepler> (and there are also some bugs in the arc-line and arc-arc intersection code which happen to be avoided by the paths and offsets shown)
[14:41:44] <jepler> cradek: detecting loops is easy -- you just go through the items in the final path pairwise (O(N^2)) and find intersections. If you find one, then you've found a loop. Use the intersection algorithm to trim the intersecting primitives to each other, and throw away the intervening items
[14:42:18] <cradek> for paths that break apart, you just have to keep both pieces
[14:42:31] <cradek> then, discard leftover loops that go "the wrong way"
[14:43:04] <cradek> and that's easy to detect - same algorithm as finding the front side of a polygon
[14:43:41] <jepler> that leaves the problem of islands (an area inside a pocket to avoid milling)
[14:43:56] <cradek> oh, right
[14:44:05] <cradek> hmmm
[14:44:28] <cradek> I don't know how to do that part.
[14:46:30] <jepler> I put the code online too --
http://git.unpy.net/view/comp.git
[14:48:32] <fenn> i thought you hated C++?
[14:50:01] <jepler> fenn: It's not my favorite language, but if I do eventually want this to go in the emc gcode interpreter that's the language I should use
[14:50:24] <jepler> (and you'll notice it's terrible style for a C++ program, lots of functions that should be methods and so on)
[14:50:41] <fenn> oh, i didnt even consider that it would be part of emc
[14:51:02] <jepler> dpm
[14:51:30] <fenn> well, at worst it could be useful for making cutter comp not suck
[14:52:28] <jepler> cradek is pushing me in a different direction by mentioning pocketing
[14:53:13] <cradek> oops
[14:54:02] <fenn> it looks like your arc is underspecified? no cw/ccw
[14:54:24] <jepler> if th1 > th0, the arc is ccw. otherwise, it's cw.
[14:58:46] <cradek> jepler: if we move ccomp out of interp, it seems like we really could use your code (even with loop removal) at the canon level. I think you'd only have to save up seq nums and set them when sending to the interp list.
[14:59:16] <cradek> it would be amazing to have the loop removal.
[14:59:40] <jepler> it would be nice
[14:59:41] <cradek> I don't quite know how lathes would work though.
[15:00:20] <jepler> you mean detecting gouging by the non-cutting part of the tool?
[15:01:16] <cradek> I don't know how advanced we could get. at the very least we'd have to deal with the crazy origin points (and everything being in the wrong plane)
[15:02:05] <jepler> (at least) three things before trying to move it into emc. 1: fix the intersection bugs (hopefully all the bugs are in the intersection, not the rest of the algorithm). 2: detect if a "cut off part" is positive, rather than negative (region "fell apart") 3: carrying additional information (e.g., moves in Z) through the process
[15:02:31] <jepler> "region fell apart" would essentially be the only path forbidden by this algorithm
[15:03:05] <cradek> moves in Z and differing feed rates are the big ones
[15:03:22] <cradek> oh yuck, inverse time
[15:03:27] <jepler> yeah I'd just forbid that
[15:03:30] <cradek> the segment length changes
[15:03:54] <cradek> forbid which?
[15:04:01] <jepler> inverse time
[15:04:17] <cradek> ouch
[15:04:38] <cradek> do you mean all feed rate changes, or just IT?
[15:05:27] <cradek> we could just assume the offset is small and don't worry about how IT is affected. It would be bad to forbid it, less bad for it to be not quite right
[15:05:35] <jepler> I was thinking to forbid IT and allow feed changes, but maybe IT isn't more of a problem than feed changes
[15:05:46] <cradek> brb
[15:08:53] <fenn> jepler: dunno if you've read this yet, but it has a decent overview of strategies for path planning:
http://fennetic.net/pub/irc/held1991_voronoi_pocketing.pdf
[15:09:06] <jepler> chmod +r pls
[15:09:37] <fenn> ok
[15:10:27] <jepler> I don't understand why the GLU tesselator doesn't have the "equal to one" winding rule.
[15:10:45] <jepler> it seems like that's the winding rule you want for this kind of application
[15:12:27] <jepler> (though the other problem with trying to use the glu tesselator for this is the arcs, which you'd have to approximate with lines and then reconstitute into arcs when you're done)
[15:15:00] <cradek> jepler: IT isn't harder as long as you think the nominal path is close enough to the right length
[15:16:12] <jepler> in a convex corner, your original line becomes a line and an arc. what is the feed for the arc?
[15:16:20] <jepler> (if the input line was in IT)
[15:17:18] <cradek> I was picturing that you'd (wrongly) assume the length of the new arc + line is the same as the old line. This gives a (non-inverse) feed that you would use for both
[15:19:41] <cradek> it's not really clear to me what IT means with comp since the path changes length.
[15:20:01] <jepler> cradek: hm, I was thinking something different -- you'd look at the feed rate the original line would have taken, then use that as the feed-per-minute number for both the line and the arc
[15:20:19] <cradek> I think we are saying the same thing
[15:20:42] <cradek> you let the time slip, keep the (implicitly specified) feed
[15:21:21] <jepler> oh, ok
[15:21:23] <cradek> that is NOT how it currently works. it keeps the time (which is what's explicitly specified) and changes the implicitly specified feed
[15:21:38] <fenn> what if there's an angular move involved?
[15:21:50] <cradek> I'd be ready to argue either way is right, as long as I was being contrary :-)
[15:22:07] <jepler> moves in ZABCUVW during comp hurt my head
[15:26:03] <jepler> I *think* that you complete any ZABCUVW move during the "original segment" and never have any ZABCUVW movement during arcs that are added to convex corners.
[15:26:09] <jepler> cradek: what does the present code do?
[15:26:52] <cradek> no 'extra' motion occurs during the auxiliary arcs
[15:27:31] <cradek> sorry, yes that's what you said
[15:30:18] <fenn> seems like the rotary motion should be done during the added arc if there is a rotary-only move between two linear moves (meeting at a corner)
[15:31:43] <cradek> yes that's another possibility
[15:32:09] <cradek> but, nobody would ever see it... the Z moves are the important ones.
[15:34:03] <cradek> load up tests/ccomp/mill-zchanges/test.ngc and you can plainly see how it currently works
[15:34:57] <cradek> err tests/ccomp/mill-g90g91g92/test.ngc is the one I meant
[15:54:07] <skunkworks_> Could it be something to do with the actual changing of the bits? I have the first pin on the first header able to run from +5 to grn. It seems to run until I start toggling the bit. Atleast the last few times.
[16:03:21] <fenn> cradek: nobody would ever see it? imagine you're cutting out a a mould pattern with draft, like an ice cube tray, you want to rotate around the rounded corner smoothly
[17:29:29] <skunkworks_> jepler: Ok - it seems to be an issue with how many times the pin has been switched...
[17:30:13] <skunkworks_> I can get it to lock up even with the 0.0 read running if I hammer pin 0 a few dozen times.
[17:30:59] <skunkworks_> (with just the pci8255.0.0.read function running)
[17:31:10] <skunkworks_> so - could be why it seemed more random..
[17:37:16] <skunkworks_> Steve!
[17:37:24] <SWPLinux> yeah, don't mention it
[17:37:31] <SWPLinux> err - hi
[17:37:42] <SWPLinux> * SWPLinux is not having a good day
[17:37:55] <skunkworks_> aww.
[17:38:00] <skunkworks_> anything we can do?
[17:38:11] <SWPLinux> send a charter jet to San Francisco?
[17:38:22] <SWPLinux> that would work for me
[17:38:28] <skunkworks_> * skunkworks_ just got a powervault 124t
[17:38:35] <SWPLinux> that's not the same thing :)
[17:38:37] <skunkworks_> sorry - the jet is in the shop
[17:38:44] <SWPLinux> damn
[17:38:51] <skunkworks_> (rubber band broke)
[17:38:53] <SWPLinux> maybe Stuart can build me knw real quick
[17:38:57] <SWPLinux> one
[17:39:52] <SWPLinux> I porbably haven
[17:40:01] <SWPLinux> gah
[17:40:17] <SWPLinux> I probably haven
[17:40:17] <SWPLinux> 't
[17:40:42] <SWPLinux> mentioned this since I was last in San Jose, but you really really want to check in more than 45 minutes before the flight is supposed to leave
[17:40:59] <SWPLinux> and due to the totally screwed up traffic flow, this means that you must arrive the night before
[17:41:24] <SWPLinux> I think that's the trick - don't bother trying to stay in a hotel the last night, just go to the airport and sleep in a chair
[17:41:27] <skunkworks_> yikes
[17:42:02] <SWPLinux> and don't depend on frequent flyer status to help you - it just gets them to say "sir" after they laugh and tell you you're screwed
[17:45:36] <alex_joni> skunkworks_: that's a real good pointer
[17:47:03] <alex_joni> hmm, I think I spot something
[17:48:50] <alex_joni> hi SWPLinux
[17:48:57] <SWPLinux> h
[17:48:59] <SWPLinux> hi
[17:49:12] <alex_joni> got stuck?
[17:50:13] <SWPLinux> yep, yet again
[17:51:27] <alex_joni> ouch.. how long?
[17:51:52] <SWPLinux> who knows? there are delays at Chicago, and I haven't even left for there yet
[17:52:22] <alex_joni> * alex_joni prods skunkworks_
[17:56:36] <skunkworks_> Hi
[17:57:34] <jepler> skunkworks_: you mean it only happens when you are driving the pin to GND externally?
[17:57:54] <jepler> I wonder if the direction register is being set up wrong, so you're grounding an output pin that is trying to drive a load
[17:58:40] <jepler> use a series resistor (e.g., 1K ohm) to gnd and see what voltage you measure at the pin -- if it's still close to 5V then it could be that
[17:59:08] <SWPLinux> pluto problem?
[17:59:09] <jepler> (or whatever other test you can devise to see whether the pin is being driven)
[17:59:14] <jepler> SWPLinux: no, the pci 8255 board from futurlec
[17:59:21] <SWPLinux> oh, hmm
[18:00:01] <alex_joni> jepler: where do you set the directions?
[18:00:27] <jepler> alex_joni: 129 WRITE((dir&3) | ((dir & 0xc) << 1) | 0x80, ioaddr, 3);
[18:00:55] <jepler> offset 3 from the base register of an 8255 is the direction/mode register
[18:02:42] <jepler> page "4-235" (pdf page 5) gives the meaning of the bits.
http://www.diamondsystems.com/files/binaries/har82c55.pdf
[18:02:44] <skunkworks_> jepler.. I am actually changing directions of the pin thru my volt meter..
[18:02:54] <skunkworks_> so - very high inpedence.
[18:03:19] <alex_joni> shoult the (hal_bit)ci_not(i) = (int)!t, be ok?
[18:04:19] <jepler> skunkworks_: I don't understand what you mean "changing directions".
[18:04:33] <alex_joni> polarities I bet..
[18:04:43] <SWPLinux> state
[18:04:47] <SWPLinux> is it in volts mode or amps mode?
[18:04:48] <skunkworks_> going from +5 to ground
[18:04:53] <skunkworks_> volt
[18:04:54] <skunkworks_> ;)
[18:04:57] <SWPLinux> heh
[18:04:59] <SWPLinux> had to ask
[18:05:12] <skunkworks_> I do know a bit of electronics. :)
[18:05:28] <alex_joni> u sure?
[18:05:32] <jepler> describe what you're doing to me as though i'm a 3-year old
[18:05:52] <SWPLinux> one engineer I've worked with from time to time always sai "when debugging, forget what you think you know and put on your stupid hat"
[18:05:55] <SWPLinux> said
[18:06:07] <alex_joni> * alex_joni puts on the wizard hat
[18:06:16] <skunkworks_> I have pin on hooked to the + lead of my volt meter.. The other lead is connected to either the ground pin of a hard drive plug or the +5v pin.
[18:06:30] <jepler> what setting is the meter on?
[18:06:33] <skunkworks_> volts
[18:06:40] <skunkworks_> dc
[18:06:52] <alex_joni> autorange ?
[18:06:56] <skunkworks_> yes.
[18:07:14] <alex_joni> and that pin is configured as input?
[18:07:19] <skunkworks_> I am using the voltmeter as a large ressiter.
[18:07:29] <alex_joni> I mean the hal driver exported pin, it toggles?
[18:07:33] <skunkworks_> yes
[18:07:37] <skunkworks_> I am using halmeter
[18:08:51] <skunkworks_> halmeter switches between false and true as I move the lead from ground to +5v
[18:09:01] <skunkworks_> * skunkworks_ hopes he is making sense.
[18:09:32] <jepler> alex_joni: "!t" will be 0 or 1, it should be fine to assign that to a hal_bit_t
[18:10:19] <jepler> skunkworks_: yes, if your mental model of a multimeter in VDC mode as a large-value resistor is accurate
[18:10:44] <SWPLinux> the equivalent resistance to the load should be around 10 megohm
[18:11:55] <alex_joni> 1..10megohm, depending on the meter
[18:12:59] <SWPLinux> usually scopes are around 1M, meters are in the 10M range, but it does vary
[18:13:15] <skunkworks_> yes.
[18:13:52] <alex_joni> jepler: then how about c(i) = t; ?
[18:14:15] <alex_joni> I know this should be fixed by the compiler..
[18:14:50] <alex_joni> or should the != 0 return 0/1 ?
[18:16:35] <jepler> alex_joni: a TRUE bit is any nonzero value. hal_bit_t happens to be 8 bits like a char, and t is 128 or smaller.
[18:16:41] <jepler> alex_joni: this is the same as hal_parport does: 525 *(port->status_in[b]) = indata & mask;
[18:17:41] <alex_joni> jepler: ok, sorry for asking.. it was a longshot
[18:18:08] <alex_joni> skunkworks_: I didn't ask this before.. do you see anything in dmesg ?
[18:18:17] <SWPLinux> skunkworks_: how long does it take for the HAL pin to change?
[18:18:18] <alex_joni> or in syslog or /var/log/messages?
[18:18:40] <skunkworks_> I will look
[18:18:59] <SWPLinux> actually, it doesn't really matter - the input capacitance is ~10-20 pf, so even with a 10M resistor, the time constant is 10 usec
[18:19:11] <skunkworks_> I am running it in a servo thread
[18:19:32] <skunkworks_> * skunkworks_ doesn't know how fast he could run the 8255 card
[18:19:57] <SWPLinux> take a look at the read*.tmax numbers
[18:20:38] <SWPLinux> it should be <1usec or so, depending
[18:21:13] <skunkworks_> 8895 parport.0.read.tmax
[18:21:28] <SWPLinux> that's parport, not PCI8255
[18:21:40] <skunkworks_> oops my mistake
[18:21:45] <SWPLinux> show *tmax
[18:21:45] <SWPLinux> :)
[18:23:59] <cradek> what gpl program was it whose author was on emc-users saying it could be useful as a hal gui editor frontend?
[18:24:14] <skunkworks_> 1824 pci8255.read-all.tmax
[18:24:22] <SWPLinux> what CPU speed?
[18:24:39] <skunkworks_> hmm - That might have been the 2.4ghz
[18:24:52] <SWPLinux> I'm pretty sure tmax is in clock cycles
[18:25:07] <cradek> geda
[18:25:13] <SWPLinux> in either case, it would be <2 us, so base thread is OK for that function
[18:25:34] <SWPLinux> cradek: was that it? I couldn't remember
[18:27:23] <cradek> http://article.gmane.org/gmane.linux.distributions.emc.user/5597
[18:28:19] <alex_joni> it was geda I think
[18:28:30] <alex_joni> I even started looking at geda sources.. but it was a pita
[18:28:33] <alex_joni> (at first glance)
[18:28:51] <SWPLinux> well, I think I'll go find out what's going on. bbl maybe
[18:53:14] <alex_joni> whee.. it _compiles_
[19:01:34] <CIA-23> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/canterp/canterp.cc: add a couple of hacks (and further fixes) to make it compile/run. grep for FIXME-AJ for remaining issues
[19:01:35] <CIA-23> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/motion/ (command.c motion.h): add a couple of hacks (and further fixes) to make it compile/run. grep for FIXME-AJ for remaining issues
[19:01:35] <CIA-23> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/emcglb.c: add a couple of hacks (and further fixes) to make it compile/run. grep for FIXME-AJ for remaining issues
[19:01:38] <CIA-23> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/task/taskintf.cc: add a couple of hacks (and further fixes) to make it compile/run. grep for FIXME-AJ for remaining issues
[19:01:41] <CIA-23> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: add a couple of hacks (and further fixes) to make it compile/run. grep for FIXME-AJ for remaining issues
[19:01:44] <CIA-23> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: add a couple of hacks (and further fixes) to make it compile/run. grep for FIXME-AJ for remaining issues
[19:19:15] <alex_joni> jmkasunich_: I think the joints_axes is now in an advanced state of fixing the joint/axis namings throughout canon/task/GUIs
[19:19:34] <alex_joni> that doesn't mean the issues are fixed, that is up next..
[19:19:43] <alex_joni> and I haven't touched anything jogging related
[21:01:43] <alex_joni> cradek: it would be nice if you could take a look at the joints_axes branch sometimes
[21:02:05] <alex_joni> (at least jmkasunich_ mentioned you wanted to work on teleop jogging, and other nontriv fixes)
[21:02:28] <cradek> I've tried, but I'm fixated on cutter comp, but am happily watching your commits go by
[21:02:47] <alex_joni> ok, this doesn't have to be today.. can wait for a while
[21:07:41] <alex_joni> good night all
[21:07:53] <micges> good night alex
[23:29:20] <jmkasunich_> Hi Y'all
[23:34:08] <skunkworks> Hi john
[23:36:53] <skunkworks> I am going to test some more - but it seems to be how many true/false/true transisions. (why it would sometimes take a bit for it to lock up)
[23:48:38] <jmkasunich_> when you weren't giving it transitions, was the input always low? or always high?
[23:48:50] <jmkasunich_> it might not be the transitions as much as the state
