cradek: no problem - no offense taken
disable feedhold disable.... has a nice ring to it ;-)
I prefer enable feedhold disable disabling
how about motion.inhibit
hey -that could work ;)
ray gave me the idea with the inhibit ring
it would default to false (not inhibited), so people who don't need it can ignore it
it wouldn't interact with anything else
it just makes things stop
wouldn't that be !motion.enable?
motion.enable is an output, used to turn on servo amps, PID loops, etc
I believe it toggles with "machine on"
hmmm - I must be confusing the meaning of HAL_IN
and it would/should stay on during an inhibit - you want the amps and PID to remain active, you just don't wnat to move
if ((retval = hal_pin_bit_newf(HAL_IN, &(emcmot_hal_data->enable), mot_comp_id, "motion.enable")) != HAL_SUCCESS) goto error;
or I might be confused
same as the feedhold poin
looks like I'm confused
maybe I'm thinking of axis.enable as the output
damned if I know what motion-enable does
maybe it does what we want already?
it has the right name. I'll check
I worked on those hal manpages before the 2.1 release, but I didn't do one for motmod ;-(
every pin should be documented
actually, I found the old NIST site (still there, just _emc instead of emc in the name) - they had very good docs on all ini parameters and that kind of stuff
I also found the NIST mail archive from around 1999 to 2003 (when it was shut down)
hmmm - from the release of emc1.17 at least
interesting - I did "halcmd setp motion.enable false" and got a dialog box from axis:
"motion stopped by enable input"
and now all the run-related buttons don't work
well I wonder why thats there?
unless it was supposed to be part of an estop chain
even after reenabling motion, and reloading the file, and loading a different file
ah - duh
what is the machine on and estop state?
axis sets machine off (or motion does)
right - it went to machine off
it's a stop input, not a pause input
so I was half right: enable was related to machine on/off ;-)
yep - it's just a machine off input - you can't go to machine on when that input is false
and it sets machine off
ok - so what this tells me is that we need more of the functions provided by NML to be duplicated by HAL pins
like pause, single step, etc.
(actually, NML may be a red herring - I toned down my original thought but not enough to eliminate NML from what I wrote ;) )
we need to think hard before we duplicate everything
somehow that just doesn't seem right
it's certainly possible to have a HAL component that deals with some machine logic (like ladder or whatever), which talks to something like halui, which then sends NML messages to do things (though that's already duplication, since halui needs all those functions)
in fact, it's already there, in halui
just not RT
this is getting hairy
you could say that
the other thought that flitted briefly across my mind was some sort of machine logic layer between NML and the motion controller
so it can intercept commands, etc
yeah. I'm not sure it makes sense to have the system stop when the motion controller gets stopped (paused)
an external "system logic" component could decide when to pause motion
right now "motmod" is the RT part of EMC though, right?
(in other words, the stuff that makes all the HAL pieces and the UI and stuff into the unit known as EMC)
motmod is a really big and complicated HAL component ;-)
that just happens to listen to commands from task
motmod is doing double duty - it deals with task, and it does motion
and some I/O
it does motion as commanded by task
and some I/O ;-)
but task has commands for non-motion things, like spindle and coolant
task doesn't have commands for anything
task issues commands
canon executes them (of course, canon is executing as part of the task process)
ok - "task issues commands for things other than motion" ...
oh, I dunno
but they all get sent through the motion module, I think (anything that deals with RT/hardware anyway)
its all a big mishmash, and then somehow emcmot_foo commands wind up i shared memory, and then I start to care
step 2: then a miracle occurs ...
nah, the miracle happens, the a command appears and motmod does some non-miracalous things with it
right: step 1: a user command is input to task. step 2: miracle. step 3: HAL has work to do ;)
stepn -INF through 0 are unimportant ;)
wtf was matt thinking... posting a 5000x12000 pixel image
damn. what was the name of that software I just installed
firefox about had a stroke
I got a big black box
could you paste the URL here?
[01:18:43] <jmkasunich> http://www.mattshaver.com/diag/index-by-size.html
I suspect ht'll pay when his bandwidth cap is reached ;)
oh - I couldn't even load that one - got an error. the second came up all black
I gotta try to see if I can figure out ed's stepgen issue
he provides such nice bug reports, I really want to help him ;-)
I noticed the xor2 component, just before I got his email ;)
tha tis a large image
some funny lines in emccanon.cc.egypt.png
I think maybe he should have used that diagramming software I found before (and can't remember the name of_
jepler convinced me ray is right about that exit move
well partly :-)
you mean that it doesn't matter? :)
if you don't want to gouge the part, move away from it before you turn off comp
and I'd just like to say "duh" to that
(the arc is still broken though)
there's got to be some way of using the existing arc comp functions to get the right exit arc
I'm just not sure if it's more pain than it's worth
(I meant the entry functions - you know, backwards)
well it's only about 5 lines of code - the exit would be the same
right - just the decisions about addition and subtraction are for the most part opposite
also, you have to keep a little more state to realize this is the first move after turning off comp
comp-off would have to set that state, line and arc would clear it after any special handling
how does comp-on determine that it's the entry move?
some state fiddling like that
oh, so the same thing backeards then ;)
let me look at that
first = (settings->program_x == UNKNOWN);
* cradek winces
#define UNKNOWN 1e-20
one of the doubles serves as a boolean using a special number
oh, great ;)
I'm going to change that first, it's terrible
hmm I borked it
(yay regression tests)
I wonder if 1E-20 is an exact binary fraction
that seems unlikely since it's a power of 10?
yes, it does seem unlikely
did you look at/follow the math (in that comment) for the entry arc fix?
I'd like it to be understandable - if it's not, I'll fix it
for instance someone should be able to build on that work to fix the exit arc
I'll read it again and see if I frok it
my intent is that it would let you draw the same picture I drew
sure. though my non-understanding shouldn't be taken as an indication that the comment (or the code) sucks ;)
well I doubt you were the slow one in grade school.
hmmm. you had mentioned a time zone fix - I only see it on my edgy machine, not dapper
heh - thanks :)
I got it the other day on dapper
is it called tzdata?
no, locale-something I think
ah - locales
$ zdump -v /etc/localtime|grep 2007
/etc/localtime Sun Mar 11 07:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 CST isdst=0 gmtoff=-21600
/etc/localtime Sun Mar 11 08:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 CDT isdst=1 gmtoff=-18000
^^ to verify
cool - thanks
yeppers - that's the one
so - are all the comments for the big functions in interp_arc.cc under scrutiny, or is it one or more of the callers in interp_convert?
mostly I was concerned about the one in convert_arc_comp1 (starting with "imagine a right triangle")
that explains the arc translation and should allow an interested person to fix the exit arc
I don't have the word triangle in interp_convert.cc
you must not be updated
I just did, about 3 minutes ago
maybe I had editid that file - let me do it again
what should the version be?
* $Revision: 1.65 $
* $Author: cradek $
* $Date: 2007/03/10 02:19:49 $
P means protected, right? (in an update)
ok - that is odd then. I just updated, interp_convert.cc is marked P, and I have version 1.58
more odd: I just created a g-code file with about 80 reps of "G0 Z0.1 G0 Z0"
when I opened it in axis, it said "no % at end"
so I added one
SWPLinux: cvs stat interp_convert.cc
now it says "bad character"
use M2 :)
you have to have M2/M30 or matching % signs (start and end)
the error is bogus then
it's a little mean of it to insult your character though
pretty pathetic that I work on a CNC control and don't know basic g-code
just because you didn't memorize the whole ngc spec
jmkasunich: more humorous than pathetic, I think
it actually said "bad character used" so I didn't take it personally
ok - I had a Kate error
it should have said "bad character used an extra % character"
I seem to recall somebody reporting a completely different error message (the realtime one) that was also truncated
dunni if there is any connection
I was joking about the character of the user ;)
* jmkasunich ducks as joke hurtles overhead
cradek: I don't think I understand the phrase "A_ang is the angle of the triangle itself"
AB_ang is the angle from A to B with the center as the vertex (if I understand correctly)
A is the triangle's angle
AB is the direction of the AB vector in the world
do you mean the angle of arc for the compensated move?
ok - then maybe it's the phrase "AB_ang is the direction of A->B"
that I don't get (or they're redundant comments or something)
ok (please fix!)
should probably have said 'the vector AB' since I can't put the arrow over it
but I don;t understand ;)
ah- duh - I just realized what I screwed up
ok, thanks for the sanity check
it really needs an image
B is the *center* of the arc, not the midpoint of the arc
(I've been known to stick an image in the source directory for documentation)
hmm. I was looking at it differently every time I looked at it, I think ;)
A is the endpoint, offset however it needs to be for comp purposes
B is the centerpoint, C is the midpoint of the chord across the compensated arc
ok - you're doing exactly what we had in the diagram I made (and jmk improved)
i.e. keep looking until you find a right triangle in there somewhere?
the right triangle falls out of it
fwiw I looked up the law of sines/cosines before I found the easy way
actually, I'm not sure if your way or jmk's way is easier ;)
depends whether you think an equation 10 lines by 80 columns wide is easy
what equation is that?
my stuff had nice short expressions
in your email?
that was the derivation. the equations are only about 8 lines long, and not 80 columns
the derivation is long, but the resulting formulas werent
and it's all algebra, no trig
I only scanned it, regretting that we duplicated work, but continued because I was 90% done
of course, I was using var names like xp3, and you probably have foo->barsgsdk->ssdbgkjl->x
oh yeah - it would be 80 columns then ;)
heh - reminds me of a funny story
one sqrt, 6 divides (by three numbers), the rest is add/sub/mult
that's probably a better solution then
mine has a few hypots and atan2s
please feel free to rewrite it (as long as you do the exit case too!)
doing the math is easy
figuring out the code is not
a college professor (calculus 2 or something not too advanced) was asked how many variables he had ever used in a real equation. We expected a number like 6 or 8, maybe 10. He said 63. (!) It would be even funnier if I could remember what in the real world had 63 independent variables.
argh - I hate unreproducable bugs
Need to get 230MB of updates...
fresh install from old CD
or did they release a huge update
yeah, install that has been sitting around for a long time
the mill's on a "new" computer now
* jmkasunich tries running tort.ngc
not holding out much hope
jmkasunich: not getting anything wrong?
he should run exactly the same test and see if he triggers it
<stupid hat> you are using his config, right? </stupid hat>
his hal file, his ini file
this is the test he said triggers it
do we know his computer specs?
actually he didn't say it _does_ trigger it
he said it might
he didn't send me the g-code that triggered it
and in any case, it happened after 20 minutes of g-code
for you, or for him?
ok -never for you
tort runs fairly long...
so, do we know his computer specs?
the symptom he's describing (dir pin change state while velocity is not near zero) has never happened for me
tort is maybe 1/2 done
there may be specs in the previous threads
ok - BASE_PERIOD 20000 seems pretty wide open
I was wondering what happens if the base thread functions are running, and there's another timer interrupt (if they happen to be a bit long one time)
I could see a big latency hit making his motor lose sync
but he's pretty confident that dir actually changed state
does RTAI notice that they're still going and delay executing them again, or does the new interrupt cause a new execution, which then returns and allows the previous one to finish?
I doesn't nest them
its a thread, not an ISR
it runs, then said "I'm going to sleep, wake me when its time to run again"
though the RTAI scheduler should be parlty in the ISR
can't get awakened till it sleeps
tell me if I'm crazy, but I thought when I cranked the base period too tight, I got missed periods (but that would certainly be detected now)
so if the base thread is running when a new interrupt occurs, then that time tick gets lost, since the task is already awake?
if an interrupt appears while its still running, RTAI probably says "I got a timer interrupt, but nobody is waiting on one, so forget it"
ok, yeah that
I'm not sure it's detected/reported
I doubt its detected
the slow thread reports, but the fast ones don't
if nothing else, the check in motion would catch it
oh! that's true
that's only for the servo (or traj) thread
I think cradek just realized something about that realtime check
it only catches bad stuff - a few 10s of uS here and there will be un-noticed
and it only looks in the slowest thread
well it could miss dropped base periods.
is he near the limit of his step generation or could he increase the base period?
sorry - gotta paste URLS for myself:
scale 16000, maxvel 0.44 in/sec
[03:27:55] <SWPadnos> http://pastebin.ca/387751 http://pastebin.ca/387755
Fetched 280MB in 6m18s (740kB/s)
Fetched 280MB in 6m18s (740kB/s)
yeah but I didn't mean to paste it
yeah the updates are taking longer to install than to download
funny -I hav ethe opposite problem ;)
you aren't using a PII then
he has steplen = 3 and stepspace = 4
hmmm - nope
so his max rate is low
and dirsetup and dirhold of 20
those are in periods right?
he could run the thread at 1/4 the speed then?
for 2.2 I want to change them to ns, but...
1/3 or so, yes
this gives less step jitter
yeah - same size pulse, better granularity
c'mon ed, read your email.....
but 400 uS seems like a lot of dirsetup/dirhold
* jmkasunich paces impatiently
you could read the comment on arc comp :)
his driver is not teh shit ;-)
no, I could not read the comment on arc comp
if I'm gonna do anything it will be either fpga stepgen, or a revision of the sw stepgen
(the algorithm that peter wallace and I worked out for doing stepgen (dealing with steplen, space, dirsetup and hold, etc) is more elegant than what I have in sw
a timer that triggers a state machine?
and it gives much nicer feedback with sub-step resolution
with the feedback taken from the accumulator
the key is that the dds has a hold input that freezes it
right, while the state machine (step generator) is running
if there is a dir change, the dds gets frozen until setup and hold times have expired
ok - I remember a bit of the discussion
the old approach let the dds free-run and dropped illegal pulses
(readback for me)
that meant the accum could not be used for feedback, I had to count the output
so I had one step resolution on the fb
right. this has the disadvantage of possibly generating incorrect frequencies (correctable in the driver)
the new version?
it only pauses the dds on a direction change
the old one could discard pulses on a dir change
no real diff there
ok - I was thinking that you pause the DDS during step generation as well
ddr output pulse triggers a chain of three oneshots
PeteW made the steps a fixed duty cycle so that wouldn't happen (essentially using DDS to generate edges, not steps)
steplen, dirhold, dirsetup
if a dir change is pending dds is held until all three time out
dir is allowed to change when the 2nd times out
step is set true when the first one starts, and false when it times out
steplen should be delayed if dirsetup is still going
it will be (the next pulse will be delayed - the current one is going in the current direction, so there is no problem
the problem case was: request up step, 30nS later dir changes, 30nS later, request down step
now, its request up step, timer chain starts, 30ns later (requested) dir changes, dds holds, long time later timers time out, dds resumes, 30nS later request down step
maybe I meant dirhold. the steplen one-shot (and the step output) should only be started if the dirsetup (I think) one-shot is timed out
the only way it can start is if the dds sends a request
basically the dirsetup timer has an "inhibit step" output
and the dds won't send a request if its being held
ah - right. DDS is held if either dirsetup or dirhold are on - got it
dirhold should be started at the end of the step pulse, I think
darn - flowsnake would be a nice test program, except my test config is looking for errors on Z, not X or Y
yeah, its a chain
ah - chain of three oneshots ...
steplen is started, when it ends dirhold starts, when it ends, dirsetup starts
* SWPLinux really removes his stupid hat this time
in fact, you just gave me an idea that might save gates
instead of three timers, just have one
and a mode
it gets loaded with the sum of all three times and counts down
turning it into a step generating state machine ;)
when it hits dirhold+dirsetup, you know that steplen has passed, so you end the pulse
I'd just reload it
when it hits dirsetup, you know that hold time has passed, so you update the dir output
when it hits zero, you unhold the dds
one preload, down count, stop at zero and two equality detectors, is probably less gates than three counters
plus an adder and an extra register
unless the adder output can be used directly in one of the comparators
the driver will compute dirsetup+dirhold, and dirsetup+dirhold+steplen
three registers, as now, but they will have the sums in them
the big sum is used to load the counter
the middle one and the dirsetup register are the comparator inputs
ok - that can work as well, but it's less robust than an independent set of numbers
in fact, the comparators can be merged
two target values, a bit to select which one to compare, and the counter value = 4 inputs = one LUT per bit
I'll have to try it both ways, see if there is a significant difference in gate count
you also need the zero comparison, though that's only 1 LUT per 4 bits
or less, if the counters underflow can be used
if there were three counters, they'd all need zero detects anyway
equality is a nasty one though - it's more prone to error than >= or <=
but fewer gates
you mean if somebody changes the value in mid count?
which is guaranteed
the result would be an extra long step pulse, or hold time, or setup time
as the counter loops around
but who changes their steplen while machining a part?
with a 32-bit counter at 100 Mhz, that could be a very long time
well, nobody I guess
not 32 bits
those timers are 12 bits right now
I forogt that this is the timing contstraints we're talking about
oh - what base freq?
dammit, the black hole has claimed another victim
I was fiddling with a large wood screw - a sample somebody gave me for a project
I dropped it, and it disappeared
it's 3-1/2" long with a 5/8" diameter head!
don't roll around too much
you're guaranteed to run over it
if that meant I found it, fine
how can something that big vanish, when dropped a couple of feet
I'm always amazed at how far, and in what directions, things can go when dropped from chair height
I found it
it bounced, then rolled - you know how things with skinny points and large heads roll
it rolled around a corner and hid
around and around
I can't believe this - it looks like I need to unwrap a new IEC power cord
you gotta be kidding
I don't see any unused IEC ends in my office
I have a whole box of them
I do too, but I can't imagine what happened to all the ones that used to clutter up the desk (and the floor ...)
I guess I do have 3 computers, 7 monitors, several peripherals, and several wall-warts plugged in
aha! the soldering station isn't in use
your monitor to computer ratio is backwards
I guess one monitor isn't in use, so I could unplug it
* jmkasunich wants a nice fast server that I will never sully with a gui
the standard 3-pin computer cord
at the computer end
steves_logging is being a wiseguy
logger_emc can't decide whether to stay or go.
I went through all Ed's messages from December and he never mentions anything about the hardware
jtr, I wonder if someone is fiddling with it - it doesn't look like it's netsplits
but it could be the only client connected to calvino
I was considering responding to steveS with something about how much of the image he can see at once, but I restrained myself :)
cradek: jepler: I just started running flowsnake.ngc, and I got a popup: "AXIS error param 2:0.000000"
oh, and more
jmkasunich: that seems like interp debug output - are there magic comments or something?
whats a magic comment?
there are o words
(DEBUG, some crap here)
ok, it's a feature then
plus the ability to print variable values, not just strings
if you say so ;-)
the dialog title bar shouldn't say error then
I can't argue with that
hmm, I got a couple reversals
3mS long, 2mS after the command reversed
it's very hard to use a flexible keyboard on your lap
one of those rubber ones?
much better with a board between me and it
much better in the trash and replaced by a real keyboard?
I almost ordered a buckling spring keyboard today
not in this case - it's for the CNC and I expect to mount it behind a metal plate
jmkasunich: how many do you want?
I have a rubber one too, with the same plans
it'll be sealed if I do that
cradek: one should last forever
this one actually works, but not when it's flopping around
jmkasunich: remind me to bring one to fest for you
I can nearly touch-type on it almost as well as I nearly touch-type on a real keyboard
they are not rare, but they're also not everywhere you look
I have one on every machine I use - you'll be ruined as soon as you have one
this one is "new" - dated 91
does anyone recall which BDI is based on kernel 126.96.36.199-magma?
I just updated emc 2.0.3 to 2.1.1 and it worked perfectly
I think it's 4.30 or so
cradek: you can get them new: http://www.pckeyboard.com/customizer.html
$59 - not a bad price, actually
they're available on eBay from time to time as well
[04:37:04] <jmkasunich> http://www.clickykeyboards.com/index.cfm/fa/categories.main/parentcat/9231
can you get them without the windows keys?
I still haven't learned to tolerate those
101 key, not 104
the photo shows windows keys
[04:38:39] <SWPLinux> http://us.st11.yimg.com/us.st.yimg.com/I/pckeyboards_1914_68416
they don't have the mutant enter key either
I've always wanted one of those but I think they're extremely rare
they seem to have them in stock at $70 each
they have 5 in stock
I added 20 to my cart and thy limited it to 5
hmmm - still says 5 for me
bummer. I guess I need to update that BDI so I can compile EMC2 again
did you just buy one?
well, I'm trying
web commerce, you know
I only added them to a cart, then emptied it
how much are they? (not seeing the price)
that does look like a good keyboard for a CNC though
I saw a pic of that when I was surfing this afternoon, but it was from a collector, not for sale
looked like a good idea
[04:47:18] <SWPLinux> http://www.clickykeyboards.com/index.cfm/fa/items.main/parentcat/11298/subcatid/0/id/146730
but I'd want to retain a conventional mouse too, for cad and such
sure. the nice thing about that keyboard is that the cord ends in separate connectors - you can always add another USB mouse (or touchscreen ...)
4 remaining in stock.
well, I use a kvm
and it's not some proprietary driver to get both from one connection
no, it's back from when computer parts were good
does anyone have any ideas for installing Ubuntu to a machne that is currently running something else (BDI)?
the machine has no CD/DVD, and no USB
and no floppy
it does have ethernet and a hard drive
the same way you installed BDI?
by disassembling it and plugging a spare CD-ROM?
(which I no longer have)
maybe I do have it
I bet that would be simplest
but it's still a royal PITA
in the long run
well, I can't install it, just connect it for the install, then remove it and close up the case
there's no room for a CDROM
it's the little kiosk touchscreen PC
SWPadnos, what about a USB key boot?
that does sound like a pain
hard with no USB
it's ethernet or HD for me, and I don't think it can netboot
you could try dist-upgrade I guess
even if it works, it will take forever and a half
and I'll be left with BDI 4.5x
I mean point it at the ubuntu repos
3 remaining in stock
I guess I probably should try installing XUbuntu and getting it configured
hmm - that may work
heh - selling fast
I wouldn't bet much on it
jmkasunich: I bet you won't see those for sale again except at collector prices
on the ubuntu dist-upgrade? - me either
if you're not in a hurry, you could run it overnight for the heck of it
I'll have to figure out how two get a regular mouse to co-exist with it
u guys have seen the industrial KBs by intermec haven't you?
intermec - meybe
jmkasunich: plug in a USB mouse, it will just work
they are fully sealed and have a multi level backlight
backlight? what for?
I guess some laptops have keyboard lights too
so you can see them in poor lighting conditions?
cradek: have you ever actually used one of the M5-1 keyboards?
I wonder how sensitive the trackball is?
no, but I think it's the normal IBM keyboard plus trackball
petev: what kind of proces do they have on those KBs? the industrial ones I've seen are usually several $hundred+
probably it's relatively low resolution compared to modern
you can prevent that trackball from sending core events to X, and use it as an auxiliary device
I got some for pretty cheap on ebay
it may have perfect resolution for jogging
they seem to come up quite often
I think I got 2 new for $100
I'm not getting the kb for the machine, I'm getting it for my main keyboard
the CNC will get a cheap rubber KB
I tried those
they seem to fail pretty easy
I may have seen those - I remember several sealed (stainless) backlit keyboards with trackballs a year ago or so
the rubber ones?
had the virtually indestructable thing
peice of $hit
half the keys stopped working
I tried several at Micro Center, and found only one model that more or less worked (so I bought one)
steves_logging is now known as steve_stallings
could someone be so kind as to paste in the correct repositories for ubuntu/EMC ?
.... just caught up reading back, joined for real, .... yes, wise guy comment about graph files, but why does a 800KB file give Foxfire a fit?
it rescales it
and the image is 12k+ x 5.5k+ pixels
it was fine when viewed as a scrunched collection of scribbles
click to enlarge to 100% and it gets nasty
so does Internet Exploder and it does not have problems
I had one problem with Mozilla on Windows, but none with FireFox
.. so the expaned image chews up all available system memory?
I didn't have crashing, just slow
a crapload of my memory is tied up with VMs (the compile farm)
so it started a swapfest
I think there's another task bug - my 'machine on' output stayed enabled when I exited emc
tha could be an oops, for sure
I thought we fixed that once
or the driver not running long enough to update the output
hmm, might be a motmod bug, shouldn't motmod clear that pin before it gets rmmoded?
wow, the saved joint position is neat, I hadn't used that yet on my real machine
when does the realtime stop happen?
probalby before the rmmod...
so forget what I said
so setting a pin is useless :)
gotta set/clear the pin, wait at least a few ms, then start shutting down
so - any takers for pasting in the ubuntu/EMC2 sources.list ?
guys, what is the appropriate routine to use for printing error messages from user space?
there is no consistency in the code that I see
rcs_print for some parts, rtapi_print for others, I think
why rtapi if it never runs RT?
SWPadnos_: deb http://www.linuxcnc.org/emc2/
I want to finish this INI stuff already
it's been dragging way too long
because the parts that talk to the RT system also use the RTAPI layer for other stuff?
SWPadnos_: deb-src http://www.linuxcnc.org/emc2/
there is probably not a good reason for stuff that will never use RT to make RTAPI calls
thanks for that - I need all of the stock ones as well - I'm going to try the dist-upgrade from BDI 4.30-ish :)
oops - we had already hit both. sorry
some of the code is just using fprintf
ok, I'll /msg you
go to swpadnos_
so is the concensus that it should be rcs_...
dunno - you could probably standardize on printf for the ini stuff - that should be usable without RCS or RTAPI
but I'm not sure how the messages are expected to be used there ...
swPadnos: got it?
can't some of those messages make it into the emc gui?
right now low level stuff is just printing
yep. the other option is to return error messages and leave it to the caller to output them
and all differently
this is why I ask
the caller always makes the decision based on the error return
but I don't want to dup the print code
so I want to stick something in the exception class
did inifile print before?
ok, then use fprintf for now
and the callers printed too
we can standardize later, I think
with different routines
the new code replaces both
so I would like to get it right
hmmm. the callers use rcs_print, fprintf, and rtapi_print_* - any others?
that's mostly what I saw
ok. rtapi_print is probably not needed because as you pointed out, no RT code directly uses ini files (at this point)
right, and that's only usermotintf
at least I didn't see it anywhere else
rtapi_print is a simplification for code that may run in RT or userspace - it's defined differently in the two cases
do you recall where rcs_print is used?
in many of the other ini modules
and some of the ui interface stuff
ok. and halcmd is the only other consumer of ini settings? (other than the GUIs, which don't use this library, do they?)
its the only one using the C wrapper
oh - you said ui interface stuff
the GUIs do use it
hey I found my rotary axis
I'm thinking rcs_, it will only be in one spot so it will be easy to change, but I don't want to break anything
I guess rcs_print should be the one
heh - beat me to it
I don't think this is what Ed was describing, but its still annoying:
[05:27:15] <jmkasunich> http://jmkasunich.dyndns.org/pics/stepgen-dir-toggle-1.png
what's the staircase trace?
frequency - an internal param of stepgen, after scaling and accel limiting
its in Hz
heh - only 382M of upgrades :)
that's about 10 minutes to download, 4 hours to install
no, 40 minutes to download, 10 hours to install (it's a celery 500/512M)
that's faster than my PII-400/256M then
I hope so
this machine actually works pretty well
base period 50000 is plenty for my mill
it seems very slow because of the terrible video controller, but I guess it has reasonable compute capacity
this one can get to 20000, and I think I've had it at 16000
I might be able to do that, but it would make it (even) less responsive
the max latency has never been over ~5000 or so
KDE and an onboard integrated video controller (buffer in the chip) - not the fastest combination
I'd try a faster hard drive, but I don't know that the motherboard will support anything over 32G
not even one slot?
(and I don't have any fast drives under that)
2 slots, PCI
one shared ISA
oh, you can't add a video card, duh
I can, but not with the internal monitor, of course
I could ad done actually, but it would need to have lvds output, which is very rare
hmmm. I wonder how X deals with two touchscreens
I'm not sure that the touchscreen driver had an offset value for the reported coordinates
swpadnos, are you using the event driver for the touch?
JMK - do you know what corresponds to/caused the reversal of direction in the HAL scope run that you captured
nope - it's the elo driver
the integrated touchscreen is serial - dunno if that works with evdev
or is elo the chip?
elo is the touch overlay manufacturer
they have a Linux driver, and I think it may be included with later kernels
(don't know that for sure)
I use the evtouch driver for X
USB or serial touchscreen?
you attach it to an event driver
I used a udev thing to make it the same every time
ok - I have a serial touchscreen
and every fricking time you boot it's a different event driver number
I know the hotplug is iffy with that (no plug events), I'm not sure the serial screen can be used with evdev (I'm betting not)
like USB, which can reorder the devices at any plug/unplug event
the evdev didn't work so hot and didn't have the long and 1.5 touch things
but evtouch may work with serial too
I don't think I have anything other than tap, double-tap, drag, and tap-drag
and dragging doesn't do anything but move the pointer - you need to tap-drag to act like a click/drag
steve_stallings: I'm writing an email to Ed and the list now with my interpretation of the picture
jmkasunich: are you thinking of adding the fractional step value (DDS accumulator or something) to the position feedback?
if anybody cares about the stepgen thing, the mail is on the list
regardless of whether a step has been generated
I was just reading it :)
I guess if I had read that far, I would have had my answer
the feedback will actually be a long long, with 48.16 or something resolution
and the DDS acc is the .16
actually, the dds is 16.16, and the driver handles rollover and maintains the upper 32 bits
or I might just make the accum 48.16 or so
is that the way stepgen is now?
today the accum is something like 1.31 or 0.32
and steps are counted in another variable
because sometimes the steplen/dirhold/etc logic drops a step due to timing variations
with a hold on the dds, nothing ever gets dropped, so the accum _is_ the feedback
now that I think about it, the accum will probably become 32.32
ok - no biggie. just change the update_feedback routine to use the DDS count as a fraction - the feedback is a float anyway
right, feedback position will be the 32.32 value converted to a double, and divided by both scale, and 2^32
now i just have to code it... but I'll do that tomorrow - its 1am
if I start now, I'll be up till 4 or later
I was thinking it could be as easy as adding or subtracting (depending on the sign of the adder) ddsvalue * scale / 2^31
in the slow thread, of course
all I have to do is take the accum and scale it
right - the scale is scale (parameter) / MAXACC (2~31-1, I guess)
2^31, that was
something like that
anyway - good night
I'm not sure if the existing accum is 1.31 or 0.32
and the new one might not be 32.32 either
no need to change the accum
why not though?
using a long long int for the accum should have minimal effect on the fast thread
and saves me screwing around in the slow thread
more changes that aren't necessary
I bet if you had an extra 4 bits of resolution, it would fix the problem
my mind is made up - the FPGA approach is simple and clean and IMO it is the way the software should work too
oh, sure. for least impact you can just use the accum as it is. changing the accum is more invasive
but also more correct in a sense
less invasive and more testable than a lot of other changes that are being discussed and/or done right now ;-)
if there's a safer and less invasive stopgap for 2.1 and an entire better solution for 2.2, that would be fine
wait until I have the new approach working, then we can debate what is appropriate for 2.1.2
jmkasunich: which branch are you thinking of targeting?
I always do stuff in head, then I backport if its important enough
and/or tested enough ;-)
that reminds me I think I forgot a backport
that's smart, I should go too
yep, that makes three
steve_stallings is now known as steves_logging
... and goodnight
darn.. missed you, but I got your email
32326:binding file /home/jepler/emc2.head/rtlib/freqgen.so to /home/jepler/emc2.head/rtlib/stepgen.so: normal symbol `step_type'
that's trunk not head :P
what's that 'binding file' ?
trunk reminds me of an elephant.
rayh: yeah, there is a resemblance :D
for some reason, when you load both freqgen and stepgen in the simulator, they get the same step_type array, so you may get wrong/undesired step generators created
I don't understand why, though
I like head ;)
CVS repositories are like a hydra: many heads
I guess I'm supposed to understand that now. It is all so confusing though.
think like a tree. TRUNK is main development, each leaf would be a HEAD of some other branch of development
I don't seem to be able to command a tool diameter comp with today's checkout.
probably just me...
rayh: what's happening?
* alex_joni is hunting that bug
the same file I made the image from yesterday does not offset at all today.
runs the same path as tool 0
was it line or arc entry? I don't remember the file
[16:48:39] <rayh> http://imagebin.org/7562
ok I'll punch that one in soon, I'm at the wrong computer now
what's tool 1 dia?
I think .5
must have been inch.
cradek: yay.. nailed that bug
alex_joni: the machine-on?
yay thank you!
you'll never guess where it was
but it would be nice if you try :P
ok, how about task?
* cradek is running out of guesses
halcmd stop :P
motion controller doesn't execute any more
so even if task sends the machine off (DISABLE) command, it couldn't be executed
ok I see
* cradek waits for the patch email
it's 4 lines moved around
it's easy to miss this kind of thing - all my testing has been in sim
yeah, it happend (hard to catch) when the runscript was cleaned up a bit
the old way of shutting down HAL was tedious
lsmod & co
[17:03:36] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/scripts/emc.in.diff?r1=1.60;r2=1.61
I'll backport it to 2.1 now
it's good to be usefull from time to time ;)
well I knew you were the right person to ask about it
oh im getting really wierd results.
If I run a sim config from a couple days ago mini shows the file about the way I expect it to.
no comp but
If I run it with sim config from today the plot is way wrong
cradek: maybe you can test that fix on 'max' later?
it's hard for me to check actual parport pins while the modules/HAL are shutting down ;)
alex_joni: I certainly will
rayh: your file runs fine for me! are you sure you got a full update and compile?
cradek: might be AXIS vs. mini ?
no, I actually ran it, not just preview
Let me make clean and try again.
mini also works right here
This will be a while.
[17:23:20] <cradek> http://timeguy.com/cradek-files/emc/raysemi-mini.png
pardon the bad picture - I don't know how to crop, so I resized the window
I use gimp but...
that's with D0 and D4, D4 is 0.9in
darn that looks just right.
I'm built for sim, not realtime, but that seems unlikely to change it
I'm cleaning mine too
rayh: looks right after a cvs update/clean/rebuild here
ok maybe I broke something obscure, instead of outright like usual
Some goofy stuff.
what need I do to test here?
can you post a screenpic
alex_joni: I'll pastebin the program
[17:35:32] <cradek> http://pastebin.ca/389329
Why would the selection of sim in rayh/configs/ be any different from emc2-head/configs/
you could diff them to find out what's different
and yet the plot is completely different between the two and no comp
diff -Ru rayh/configs/sim emc2-head/configs/sim
I must have gotten a borked download
the only diff is the location of the programs directory
is the time right on your computer?
time and date
(that can sometimes lead to bogus compiles)
btw what do we have to do to get the time change tomorrow?
just install the available ubuntu updates
they sent out a fix a few days ago
hmm.. it seems to go on the line without comp
* alex_joni updates again
alex_joni: do you have a tool #3?
I did a M6T1 in MDI
I used d1 I think. If this is my file.
I see no M6 in that program
you really don't need to change to a tool to use it's diameter.
rayh: I have little clue about comp so far ;)
I'll try a new cvs up and make and see if it's the same still.
probably should do a complete checkout again.
CVS wouldn't know if a file got twisted up during download, would it.
I don't think so
ssh is supposed to ensure the integrity of the data it transfers
you could remove the files in src/emc/rs274ngc and do an up
well that's true
besides, what are the odds that a garbled file is valid "C" source code
cradek: anything else to do, than simply run the program?
alex_joni: change it between D0 and D3 or whatever tool you want to use, and see if it offsets around the shape
it's D3 now, and it just walks the line (no offset from what I can tell)
what's the diameter of tool 3?
the lines will move - you have to run it twice to see the difference
the tool always follows the line
what is clarkexx
ok, it works now..
I changed the diam of the tool, and reloaded the tooltable
screenshot coming up
rayh: something to do with 3-phase motors, added recently by jmk
(recently meaning in the last month or two)
The Clarke transform can be used to translate a vector quantity from a
three phase system (three components 120 degrees apart) to a two phase
oh okay. i get it.
what's the nsa_tap.o
that's where the NSA taps in
[17:46:48] <alex_joni> http://imagebin.org/7571
national servo academy torque adjustment procedure
Right. I wouldn't be surprised at all.
"we gonna torque on you a bit, boy."
alex_joni: that sure looks right
cradek: yep, thought so too
Then it's got to be my system.
glad to know that
rayh: say again please, what's the behavior you see?
rayh: is it really TRUNK you're checking out?
maybe you have a v2_1_branch checkout
I don't see any extra files in the cvs dir.
if it's there..
cvs stat src/emc/rs274ngc/interp_convert.cc
no tag file.
still way wrong. I'll do a complete checkout.
or up -dPAC (I think)
or maybe only A or C
This is fascinating.
maybe I'll just move mini and up.
petev was having some trouble compiling last night, which I couldn't reproduce
rayh: can you put a screenshot online?
* alex_joni wonders how it's wrong..
What i'm seeing on the display looks like it's rotated way off from where it should be and doesn't rotate to a "normal" view no matter what I do.
on my other machine, I get a strange default view in mini, and when I try to change it (I moved rot-x) I get "Error: domain error: argument not invalid range" popup
omain error: argument not in valid range
"expr "$A * $adir" / $scaler"
so is the view wrong in mini, or is the radius comp wrong? I still don't understand what's going on
I've seen a strange error message twice this morning domain error: argument not in valid range.
seems to be coming from tcl.
yes probably a divide by zero in that expr I just pasted
* rayh needs a vacation.
I'm going to go vacation in a miniature waterfall for a while
* alex_joni can't rotate the backplot in mini to something usefull
this program has no Z movement.. right?
I can if I use an old configs/sim/mini.ini
oh - ini changes have probably screwed up the tcl interface to ini files
but I can't if I use emc-head/config/sim/mini/ini
wait - using the same mini program, or using a different mini?
using just a config in a different place.
ahhh.. bet I know what the problem is
(I'd bet you know what the problem is :) )
* rayh looses all bets!
then feel free to bet against me
do you see any differences in the two configs? (with diff)
I just looked at the .ini files between the two. the location of the program directory changed.
any hal, tbl, or nml file changes?
SWPadnos: I saw a few changes lately
0.039.. vs inch
INPUT_SCALE = 4000 vs INPUT_SCALE = 4000 0.0
ray - how old is the "other" ini?
but neither was the problem
ok - those are pretty old though - several weeks, right?
SWPadnos: way before 2.1.x
ok - thought so
so you guys are thinking pete's changes last night broke tcl ini reading?
it's possible, but I'm not sure
pastbin coming up.
I got the "domain error: argument not in valid range" out of the blue
while not touching the interface
[18:15:22] <rayh_> http://www.pastebin.ca/389353
You mean it might not be me?
would you mind rerunning the diff with -u?
there is no real difference there
you still need the -u
I only see the max_joints I added there
different tool diameters
rayh: that one is easier to read
1.5 vs. 0
SWPadnos: but even jogging is wrong
yes, -u would be nice
this is _not_ comp or tool related
sure - the mini problem isn't, but the tool comp one may be ;)
tool comp works OK here
[18:18:59] <rayh_> http://www.pastebin.ca/389364
the display in mini is wrong..
mini and tkemc tend to read directly from the ini file for a few variables.
using some sort of thing in emcsh
emcsh probably uses the nml/rs274 library, which has ini file stuff in it (I think)
tkemc works OK
now the inifile reading stuff is in its own shared library, libemcini.so
that's a good thing
both the backplot & jogging and the comp stuff
still used in emcsh though, right?
yes, libemcini.so is linked into emcsh
One thing that turns out different between my two runs here is that I'm using rayh/emc2/nc-files/vartest.ngc for both
so the part program is in different paths for each run as is the config.
rayh_: no, something is really broken
just start mini, and try to jog
and watch the backplot
(without loading any program)
OT: alex - can you fix the documentation page on linuxcnc.org - it says "the upcoming EMC version 2.1" ...
works as promised with the old ini.
rayh_: really? wtf?
with the new ini it is "strange days indeed, mamma!"
most peculiar - whoa
all the plotting is along a single line
rayh_: if you put it on 3D, then it'snot
but it's like space has folded
and so has my head.
what is traj[axes] in the inis?
is there an imagebin of this problem? I am running configs/sim/mini.ini against head and I don't see anything that looks wrong
saw that error for a second and it died.
change the loadrt line to 8 instead of traj[axes]
I think that's it SWPadnos
hmmm - with -v, will the runscript display all hal commands (like that loadrt)?
SWPadnos: no, I don't think so
I'd like to see that output
you'd have to pass an extra flag to halcmd to do that, not just to the runscript
good feature request though
I don't know that halcmd has a -v option
-v display results of each command
* alex_joni wonders what the connection between mini and motion controller is
but it won't display the actual command
no, I don't think so
SWPadnos: think it barfs by not getting enough data?
or by looking at uninitialized stuff?
ok, so to see what actually gets run, remove the loadrt line from the .hal file and stick it in the ini as a HALCMD= line
alex_joni, I'm thinking something like that
SWPadnos: I fixed it by removing the max_joint=[TRAJ]AXES
but I don't know - it's just a difference in the systems
or by changing [TRAJ]AXES to something else than 3
% emc_abs_cmd_pos 1
% emc_abs_cmd_pos 4
ok, so it's not initialized
and mini barfs internally..
I'll fix it
all 3 of the unused axes have weird values on my system
maybe different ones than on yours
jepler: right.. guess they were assumed to be inited by motion
which doesn't anymore :)
oh darn, it's worse
* alex_joni investigates
I think task reads data from uninitialized locations
max_joints was added to unclutter the HAL listings, right?
and save some memory
ok, so just leave everything alone except the export function
well.. kinda, but the export function is the one that allocs the mem
I wouldn't worry about the memory (unless that was the real reason for it ;) )
oh, that is a problem ;)
but it shouldn't need to read axis 4 on systems with 3 axes
task does it right I think..
AXIS and tkemc too
OT: I can't find the page that describes installation of emc2 on edgy - does anyone have a link?
ve had mini sitting here a bit and I've got wild lines running all over the display.
ah - thanks
hmmm. and the RTAISteps page may help if I want actual realtime
(which I do)
the position numbers don't change but the canvas gets really wierd lines.
rayh_: that's because A,B and C change
when I shut down I saw a pile of these.
program_units inch 0
program_units inch 1
rayh_: that comes from mini.tcl
set units [emc_program_linear_units]
puts "program_units $units"
set jogType $jogIncrement
hmmm. linuxcnc.org isn't very large font friendly
But why is it changing.
Is units changing when I switch active axis?
I only have linear on the screen.
I get that when jogging
program_units inch 0 (for jogging on X)
program_units inch 1 (for jogging on Y)
program_units inch 2 (for jogging on Z)
oh -- "axis to jog"
puts "program_units $units $axisToJog"
puts "program_units $units $axisToJog"
wow. tools and view tools is really going to confuse the crap out of newbee users.
what's tools & view tools ?
tkemc does seem to work properly.
Tools is a recent addition to tkemc.
under there you find halscope and halshow.
but I keep clicking that tools when I really want to change tool diameter.
rayh_: that's my fault - please rename as appropriate
I wanted not only AXIS users to be able to start the hal tools
I like the ability.
maybe Utilities ?
But what's going on with mini and why shouldn't we throw it out.
rayh_: I'm still investigating that
I like utilities. that's good.
ok, I think I fixed it
jepler: you around?
rayh: still around to test?
problem with pluto_servo
pluto_servo_rbf.h is generated at make time
but it is also in CVS
I think thats alright, IF everyone who changes the .rbf does a make before they commit, so both the .rbf and the .h file changes get committed
can someone else look if the mini backplot is ok now?
yep. i'm here.
i'll get it and test
* alex_joni reminds people he's not a tcl coder :/
it got removed in rev 1.6 but added on the branch in 188.8.131.52
alex_joni: Why has this just become an issue?
and why would an older config run it properly but the current not?
rayh: the current config only sets up as many axes as are defined in the ini
an older config sets up 8 joints in the motion controller
the problem was with mini that queried the position for 6 axes, even if only 3 existed
But how did the older config set up 8
motmod has 8 by default
I'm not sure how the extra 2 map, but the first 6 are the same as XYZABC
oh the issue was in hal not in the ini file.
sort of. motion wasn't updating any unused axes (when asked for only 3), but mini was still reading the data
emcmot (the original motion module) had 8 axes - don't ask me why
technicly those are joints
when it got ported over to emc2 we kept that "feature"
alex_joni, right ;)
right, but it didn't make the distinction
at least, not everywhere
jepler: thanks for figuring out the pluto thing - it was messing with the compile farm's mind
rayh: how confusing would it be for users if we change the ini?
AXIS_* -> JOINT_*
if the farm scripts see changes to the local repository, they assume something is wrong, and pout about it
alex_joni, quite, I imagine
though it should be OK for 22, since ini changes are allowed for point revs
I'm thinking more like allowing both..maybe that's an alternative
jmkasunich: thanks for bringing it to my attention
I'd want to see how many places read joint data. if it's only in inniaxis.ini, that's probably fine
okay I see the difference in the startup that caused the issue.
* rayh lights a joint.
try lighting an axis
It will be confusing for a while.
They don't smell nearly as sweet.
its one of those things.... we can confuse the majority of people for whom there is little or no distinction between joint and axis
or we can really screw up those who really need to know the differnce
(robot people, non-trivkins people, etc)
It would clarify joint v world a bit.
jmkasunich: that's why I'm starting to think to allow both
I saw some discussion about the [traj] limits applying to world and joint limits applying only to that axis.
that joint ;-)
rayh, that's an interesting point. what if you want to limit velocity in X to a value different from Y, on a non-trivkins machine?
you would then need joint and world coordinate limits, in addition to overall TRAJ limits
don't forget A B C speed limits
in world coords
* rayh has a headache from thinking about the last thing.
here's another headache for you..
* alex_joni needs a way to switch to joint view from g-code
I'm thinking about a robot or something that has an actuator - like a fork. left/right you can really move, but forward/back you can't or the item may fall out of the fork
s/joint view/joint control/
alex_joni, that would likely be a big spec change
That linkage would certainly make more sense.
SWPadnos: I know :(
but you can't really drive a puma without
and there are no letters left (except for E) :)
maybe a modal like G91
then XYZABC refer to J0..5 (although that's bad..)
* alex_joni writes other interp for robots on his wishlist
Pose is more adquately described as xyzrpw
SWPadnos: there are singularities through which you can't move a puma in worldview
at least not with the current kins.. it freaks out
hmmm. what kind of pose do they show up at?
that's a tough one :)
it's a singularity, dammit!
I know the joint locations.. but pose..
x_nr y_nr -inf ...
a funny tilted 8
do you think it's a +/- pi thing?
A stewart platform has well defined singularities but we have no way of limiting motion around one.
SWPadnos: sure is
yeah - I was just thinking about the discussions we had about workspace "keepouts"
They seem to be related
Like a very complex work envelope.
yep - clamp avoidance and such
It is much larger than a single joint limit
yeah - it's volumes to avoid
and with a lathe chuck barriers is a biggie.
and also more complex limits than "this parallelopiped XxYxZ in size"
at least in the case of a hexapod
that's a lotta axes
and presumably most/all of them can't execute a full rotation
or at least, not beyond one rotation
(ie, no sliprings)
Axa 1:340 ° (opþional 450 °)
Axa 2:215 °
Axa 3:290 °
Axa 4:358 °
Axa 5:270 °
Axa 6:600 °
that would be joint limits and would work now.
rayh: yes, but you can't limit it to go to X2300 Y2100 Z1800 A170 B20 C0
only after trying to get there you'll get joint errors
but task (commanding in carthesian coords) will be happy
trying to drive it
kins needs to be able to tell motion the min and max extent of a given move
for each joint
there are combinations of positions that must be further constrained.
I don't think that's correctly done even for trivkins (ie, for an arc, are there mod echecks than start/end and maybe midpoint?)
that was supposed to be "more checks ..."
SWPadnos: fixed the Docs page on linuxcnc.org
of course, that's not a kins operation at the moment - it's traj/motion
Hey alex. Thanks for fixing mini.
rayh: np, glad it works
* alex_joni feels proud to understand enough tcl to fix 6 lines :D
Glad also that we now have axis pins only for the number of joints we have defined.
I'd never have thought to connect the mini failure with the change there though.
* SWPadnos feels proud that he can see differences in a diff file
jepler, you have an edgy install (right?) - is that x86 or x86_64?
We gotta run to town. Catch you all later.
SWPadnos: x86 .. I think (vmware on an x86-64 machine)
SWPadnos: yes, x86
jepler, ok - I guess I'm in mostly uncharted territory on x86_64 + edgy then :)
no SMP even]
cradek, whee as in "you got the jogwheel working on your physical hardware" or some software thing? ;)
on physical hardware
well it had worked before, but the mill has been "apart" for a while
cool though - I think I bought my jogwheel at the same place you did :)
hmm - maybe not
alex_joni: your changes does fix the machine-on problem! I just edited /usr/bin/emc of my 2.1.1 install
you backported that, right?
I also fixed mini ;)
I saw - thanks
(after breaking it first) :D
I guess we can't blame petev?
I'd say it was bad design :P
the mini backplotter is copyrighted by paul_c
incidentally - any thoughts on the error printing problem petev was working on?
not fair blaming the guy who's not here
oh - that's normal
cradek: I was only kidding..
I think the expression is "he's not here, he's the asshole"
should have tested it more
SWPadnos: where did you hear that?
way back when at my old company :)
oh- he's not here - it must be his fault
strange - there's an interaction between jogwheel and keyboard jogging
two points of control ...
sometimes if you play with the wheel while in a jog, it speeds up
hmmm - I see some errors in the code petev sent
but he's right - error returns from ini loads aren't always checked
he's not here ..
neither is JonE, but I'm not sure we can pin this one on him ;)
another comp bug: http://pastebin.ca/389609
nan2 doesn't sounds good
(run with a .5 dia tool)
hmmm. is the arc through the original endpoint checked for validity?
oh - you used enough 9's to make ir pass the test
yeah if you make it .25, it errors
but the .24999 passes whatever tests and then bombs
it's actually an invalid acr, but not invalid ehough to be flagged
and you end up with a centerpoint somewhere beyond China? ;)
well, following errors
I haven't even looked at the output yet
hmm.. it didn't bomb here
* SWPLinux is looking at ini error returns instead of comp right now
but it produced a weird result
alex_joni: in sim you may not see it - I think the tool flies away briefly
d5 is the diameter of tool #5 .. right?
hmmm. kp_enter should be bound the same as enter for pickconfig.tcl
make tool 5 .5inch
yeah, I did that
I get a square corner
that's right, except for the flying away that I think is happening
it appears correct here as well, both in preview and when run (in sim)
yeah, but in stepper it jumps
it jumps in all 3 directions
joint 1 following error
joint 2 following error
joint 0 following error
emc/task/taskintf.cc 595: Error on axis 0, command number 322
emc/task/taskintf.cc 595: Error on axis 1, command number 322
emc/task/taskintf.cc 595: Error on axis 2, command number 322
weird - I'm trying to run ./bin/rs274 and the terminal beeps when I press "r"
I can hit tab and get a list of executables, and I can type many other letters/symbols
crap. I think I accidentally ran "bind rs" in that terminal
geez Matt - make up your mind ;)
cut the first part with emc2.1.1
on the mill
cradek: any issues?
nope just those we already fixed
wonder if we should make 2.1.2 today
why is jack ensor messing with the SMI stuff? does he really have a SMI problem?
I'm not sure he knows what kind of problem he has, nor how to find out ....
unless he's sure he has an SMI problem he's wasting a lot of effort (but you know this already)
I think he mentioned his motherboard brand (QDI?), but I'm not sure what other hardware info he's mentioned
I suspect he's getting any old rt problem, and settled on SMI to try to fix it
no - I think someone (Alex?) mentioned SMI as something that can cause RT overruns over long periods (64 seconds apart)
I understand, but I'm saying that's probably not the problem he has
but it depends on him if he can count to 64 seconds
I really like jepler's quick gcode reference (and how it is on the menu) - I use that all the time
jepler: wonder if this would be any good for stippler: http://shop.elv.de/output/controller.aspx?cid=74&detail=10&detail2=14163&refid=
oh - the applications menu - I was looking for it in Axis
does anyone want to look at the degenerate case in comp (nan2.ngc)? I'm tired of working on comp - if nobody else wants to, I'm tempted to make 2.1.2 release today
although jmk might want to do something to stepgen too
maybe I should wait
yeah - I'd wait for at least the simple fix to stepgen
cradek: I might give it a shot tomorrow
the comp stuff..
but maybe you can give me some hints where the magic happens
no pressure, it's been that way for a long time
I'm about to respond to Stuart Stevenson - is this correct?
The config files should work fine. You need to put the connections to AXIS in a separate hal file, and load that file with a line in the ini file as follows:
POSTGUI_HALFILE = my_hal_file.hal
the magic is all in interp_convert.cc
SWPadnos: yes that's what I did to get the jog wheel to work
cradek: and the error in nan2 is convert_arc related?
yes I think so
I think it will be in convert_arc_comp2
there may be a similar case in arc_comp1 (if the arc is the entry move)
oh fsck :)
this means I need to take out pen&paper
alex_joni: it's probably some terrible way the different tolerances interact
did you try making it verbose and check the ARC_FEEDs it calls ?
Issuing EMC_TRAJ_LINEAR_MOVE -- (+220,+88, +0,0.902616,-3.909346,0.079056,0.000000,0.000000,0.000000, +2,0.566700,0.566700,20.000000,)
Issuing EMC_TRAJ_CIRCULAR_MOVE -- (+221,+140, +0,0.902616,-3.909346,0.079056,0.000000,0.000000,0.000000,0.902616,-3.909346,0.079056,0.000000,0.000000,0.039370, -1, +3,1.000000,0.566700,20.000000,)
it looks like it's exactly degenerate - the start, center, and end points are the same
oh, so too small of a circle
usually it catches a circle like that.. right?
maybe comp should just skip issuing the arc if it's too tiny
if you specify it with G2
(no comp involved)
let me try
error: "zero radius arc"
when you use r format, it doesn't give that error, you get "isnan error in emcTrajCircularMove" on stdout
so that's a second bug
=> g0x0y0; g2x0y0r0
should give an interp error, but it doesn't
I really wonder how it gets as far as emcTrajCircularMove
theta1 = atan2(canonEndPoint.y - center.y, canonEndPoint.x - center.x);
shouldn't that barf?
probably get theta1=nan
a test shows theta1 = 0