fenn_ is now known as fenn
fenn_ is now known as fenn
So should I add the next read function? keeping the old one? It ran all night with just pci8255.0.0.read
morning - isn't it a bit early for you? or have you been up all night?
i dont even know
dont forget to write a man page
some comments would be nice
sure. I think I may be getting it down.
addf pci8255.0.0.read servo-thread 1
addf pci8255.0.1.read servo-thread 1
skunkworks: still running?
skunkwork1: keep adding them until it starts misbehaving :)
still running so far.
so - is running read-all doing the exact same thing as running all 3 read threads?
I think I saw 4 read threads in there
hmm.. no, only 3
[13:23:35] <alex_joni> http://www.pastebin.ca/963631
skunkwork1: basicly yes
Heh - It locked up..
with 2? or 3?
ok, next try 0.0 and 0.2
or should I just try .1?
skunkworks: that too
addf pci8255.0.1.read servo-thread 1
we will try that for a while
cradek: your website is down.
huh, seems ok from here
cradek: what is the ip address?
got it - it just started resolving. Maybe it was a dns issue on this end.\
fine from here too
cradek: what's the result to that code snip? http://timeguy.com/cradek/01201480454
like the title says, irritation
oh, come on.. don't make me compile/run it
skunkworks_: you're an optimist
bbl.. gotta run
skunkworks_: sorry, other stuff caught my attention this weekend (ooh, a shiny thing!) and I never looked at the pci_8255 driver
jepler: no problem. I had fun making it lock up the computer. :)
Did you notice that it did lock up with 0x0ff?
just took a bit longer.
skunkworks_: I don't like that :(
it should lock up immediately, or not at all
that's how I prefer my software
* skunkworks_ wonders what the shiny thing is..
It did lock up this morning with 2 read threads running.. 0,1 now running 1 and it is still running.
the shiny (but extremely buggy) thing is: http://emergent.unpy.net/index.cgi-files/sandbox/demo_comp.png
ran all night with the 0 thread
Wow - I was expecting something outside of emc - very cool
cutter comp for concave corners?
fenn: it's a 2D path offsetting algorithm outside of emc .. it just happens that my test program emits gcode
jepler: I think you've written pocketing... That's really great news
how do you do the loop removal? that seems like the hard part to me
cradek: well, it doesn't handle islands or paths that break apart (yet)
(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)
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
for paths that break apart, you just have to keep both pieces
then, discard leftover loops that go "the wrong way"
and that's easy to detect - same algorithm as finding the front side of a polygon
that leaves the problem of islands (an area inside a pocket to avoid milling)
I don't know how to do that part.
I put the code online too -- http://git.unpy.net/view/comp.git
i thought you hated C++?
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
(and you'll notice it's terrible style for a C++ program, lots of functions that should be methods and so on)
oh, i didnt even consider that it would be part of emc
well, at worst it could be useful for making cutter comp not suck
cradek is pushing me in a different direction by mentioning pocketing
it looks like your arc is underspecified? no cw/ccw
if th1 > th0, the arc is ccw. otherwise, it's cw.
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.
it would be amazing to have the loop removal.
it would be nice
I don't quite know how lathes would work though.
you mean detecting gouging by the non-cutting part of the tool?
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)
(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
"region fell apart" would essentially be the only path forbidden by this algorithm
moves in Z and differing feed rates are the big ones
oh yuck, inverse time
yeah I'd just forbid that
the segment length changes
do you mean all feed rate changes, or just IT?
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
I was thinking to forbid IT and allow feed changes, but maybe IT isn't more of a problem than feed changes
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
chmod +r pls
I don't understand why the GLU tesselator doesn't have the "equal to one" winding rule.
it seems like that's the winding rule you want for this kind of application
(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)
jepler: IT isn't harder as long as you think the nominal path is close enough to the right length
in a convex corner, your original line becomes a line and an arc. what is the feed for the arc?
(if the input line was in IT)
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
it's not really clear to me what IT means with comp since the path changes length.
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
I think we are saying the same thing
you let the time slip, keep the (implicitly specified) feed
that is NOT how it currently works. it keeps the time (which is what's explicitly specified) and changes the implicitly specified feed
what if there's an angular move involved?
I'd be ready to argue either way is right, as long as I was being contrary :-)
moves in ZABCUVW during comp hurt my head
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.
cradek: what does the present code do?
no 'extra' motion occurs during the auxiliary arcs
sorry, yes that's what you said
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)
yes that's another possibility
but, nobody would ever see it... the Z moves are the important ones.
load up tests/ccomp/mill-zchanges/test.ngc and you can plainly see how it currently works
err tests/ccomp/mill-g90g91g92/test.ngc is the one I meant
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.
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
jepler: Ok - it seems to be an issue with how many times the pin has been switched...
I can get it to lock up even with the 0.0 read running if I hammer pin 0 a few dozen times.
(with just the pci8255.0.0.read function running)
so - could be why it seemed more random..
yeah, don't mention it
err - hi
* SWPLinux is not having a good day
anything we can do?
send a charter jet to San Francisco?
that would work for me
* skunkworks_ just got a powervault 124t
that's not the same thing :)
sorry - the jet is in the shop
(rubber band broke)
maybe Stuart can build me knw real quick
I porbably haven
I probably haven
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
and due to the totally screwed up traffic flow, this means that you must arrive the night before
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
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
skunkworks_: that's a real good pointer
hmm, I think I spot something
yep, yet again
ouch.. how long?
who knows? there are delays at Chicago, and I haven't even left for there yet
* alex_joni prods skunkworks_
skunkworks_: you mean it only happens when you are driving the pin to GND externally?
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
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
(or whatever other test you can devise to see whether the pin is being driven)
SWPLinux: no, the pci 8255 board from futurlec
jepler: where do you set the directions?
alex_joni: 129 WRITE((dir&3) | ((dir & 0xc) << 1) | 0x80, ioaddr, 3);
offset 3 from the base register of an 8255 is the direction/mode register
page "4-235" (pdf page 5) gives the meaning of the bits. http://www.diamondsystems.com/files/binaries/har82c55.pdf
jepler.. I am actually changing directions of the pin thru my volt meter..
so - very high inpedence.
shoult the (hal_bit)ci_not(i) = (int)!t, be ok?
skunkworks_: I don't understand what you mean "changing directions".
polarities I bet..
is it in volts mode or amps mode?
going from +5 to ground
had to ask
I do know a bit of electronics. :)
describe what you're doing to me as though i'm a 3-year old
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"
* alex_joni puts on the wizard hat
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.
what setting is the meter on?
and that pin is configured as input?
I am using the voltmeter as a large ressiter.
I mean the hal driver exported pin, it toggles?
I am using halmeter
halmeter switches between false and true as I move the lead from ground to +5v
* skunkworks_ hopes he is making sense.
alex_joni: "!t" will be 0 or 1, it should be fine to assign that to a hal_bit_t
skunkworks_: yes, if your mental model of a multimeter in VDC mode as a large-value resistor is accurate
the equivalent resistance to the load should be around 10 megohm
1..10megohm, depending on the meter
usually scopes are around 1M, meters are in the 10M range, but it does vary
jepler: then how about c(i) = t; ?
I know this should be fixed by the compiler..
or should the != 0 return 0/1 ?
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.
alex_joni: this is the same as hal_parport does: 525 *(port->status_in[b]) = indata & mask;
jepler: ok, sorry for asking.. it was a longshot
skunkworks_: I didn't ask this before.. do you see anything in dmesg ?
skunkworks_: how long does it take for the HAL pin to change?
or in syslog or /var/log/messages?
I will look
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
I am running it in a servo thread
* skunkworks_ doesn't know how fast he could run the 8255 card
take a look at the read*.tmax numbers
it should be <1usec or so, depending
that's parport, not PCI8255
oops my mistake
what gpl program was it whose author was on emc-users saying it could be useful as a hal gui editor frontend?
what CPU speed?
hmm - That might have been the 2.4ghz
I'm pretty sure tmax is in clock cycles
in either case, it would be <2 us, so base thread is OK for that function
cradek: was that it? I couldn't remember
[18:27:23] <cradek> http://article.gmane.org/gmane.linux.distributions.emc.user/5597
it was geda I think
I even started looking at geda sources.. but it was a pita
(at first glance)
well, I think I'll go find out what's going on. bbl maybe
whee.. it _compiles_
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
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
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
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
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
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
jmkasunich_: I think the joints_axes is now in an advanced state of fixing the joint/axis namings throughout canon/task/GUIs
that doesn't mean the issues are fixed, that is up next..
and I haven't touched anything jogging related
cradek: it would be nice if you could take a look at the joints_axes branch sometimes
(at least jmkasunich_ mentioned you wanted to work on teleop jogging, and other nontriv fixes)
I've tried, but I'm fixated on cutter comp, but am happily watching your commits go by
ok, this doesn't have to be today.. can wait for a while
good night all
good night alex
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)
when you weren't giving it transitions, was the input always low? or always high?
it might not be the transitions as much as the state