SWP_Away is now known as SWPadnos
SWP: you still here?
new emc2, emc2-dev, emc2-axis packages, containing the new trajectory planner, in the ubuntu repository
uh - yeah, I'm here
remember the joystick prog?
we were talking about using stat to identify the device major and minor numbers
is that something you've done?
I'm not sure it's stat
but there's got to be a way
man 2 stat shows a couple fields in the stat struct
but neither of them seems to match up with what is expected
man 1 stat is a cmd line prog
right, and that does tell you major and minor
strace stat to see what syscall it uses
so, I wonder where I can find the source for stat(1)
apt-get source fileutils or some such
dpkg -S /usr/bin/stat
or that ;)
apt-get source coreutils
do you know how to get the major/minor numbers of a device node (from C)?
I suppose it would be in the inode, if all else failed
stat(1) calls lstat(2)
so the data must be returned by lstat (or stat), just where in the struct?
actually, the dev_t probably has it
there are two of them
st_dev, and st_rdev
st_dev is 0x000c, st_rdev is 0
but the major is 13 (0x0d)
dunno how to get from one to the other
# define major(dev) (((dev) >> 8) & 0xff)
# define minor(dev) ((dev) & 0xff)
hmm - I think there are macros to extract the major/minor from dev_t
yeah, saw those
they ain't gonna turn 0x000c into 0x000d
in stat(1), they come from statbuf->st_rdev
which seems to be zero for /dev/js0
does stat(1) get it right?
is the stick plugged in?
yes and yes
is the rest of your stat buffer valid?
just a sec
john@ke-main-ubuntu:~/emcdev/emc2head$ stat -c "DEV: %d Major: %t Minor: %T" /dev/input/js0
DEV: 12 Major: d Minor: 0
john@ke-main-ubuntu:~/emcdev/emc2head$ bin/hal_joystick -d /dev/input/js0
device = '/dev/input/js0'
prefix = 'joystick.0'
st_dev: c st_rdev: 0
major: 0 minor: 12
that is applying major() and minor() to st_dev, not rdev
huh, it works
that looks like 12 in both cases, to me
(when applying major/minor() to rdev
even tho printf ( "%d", statbuf.rdev) shows zero
how does it get d?
for major? d is hex for 13
type = long long unsigned int
using %lld fixes it for me
yeah, here too
that type is hidden (on purpose), its just dev_t in the man page
if I use major and minor it can stay hidden
err - any time ;)
I owed you one after your hours of work this afternoon
good thing we're even again
one day, I'll actually remember something before cradek finds the information by looking for it
(or remembering faster)
SWPadnos: I'll tie one hand behind my back
I can plead disability due to Windoes XP 64-bit
SWP: remember yesterday, both 13 and 15 for joysticks?
[06:00:09] <jmkasunich> http://www.ussg.iu.edu/hypermail/linux/kernel/0101.0/0091.html
that's a mighty old mail
but they're both still in there I think
I don't see any other 13 char driver
there is a 13 block number though
hmmm - you should probably check that the device is a char device as well
yet another non-obvious bit of info
char or block
duh, st_mode, S_ISCHR
* jmkasunich needs to rtfmp
what question? I didn't hear anything
allright, releases done, email sent, bedtime
another very productive day
thanks again for your help on that last one
no prob, it was educational
more than you wanted to know maybe
nope, I want to get up to speed on the TP someday
be assured the rest of it sucks less than that - you were in the evil part
ok goodnight all
good night for me as well.
see you tomorrow, I think
SWPadnos is now known as SWP_Away
steves_logging is now known as stevestallings
cradek: the wiki says this: If you are installing EMC2 on a different Debian-based distro, here are .deb packages for a patched realtime kernel, rtai modules and EMC2 (follow the instructions from http://timeguy.com/cradek/emc/ubuntu
do you think your packages are actually useful for other debian-based distros, or should that line be taken out?
[14:30:48] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2
Is their anything specific in the breezy packages that would make them unsuitable for other debian distributions?
Like the ubuntu specific kernel patches?
SWP_Away is now known as SWPadnos
rayh, I think most apps are supposed to be compatible, but the ubuntu people do mention that their packages aren't always compatible with stock debian
Yep. Seems most distros try to set themselves apart.
I think it's a technical thing in this case
I guess I don't see a difference between ubuntu specific or fedora core.
I do keep grinning as RH stock soars.
there are sometimes patches that the ubuntu team makes that aren't accepted in the "upstream" distributions
so they end up with incompatibilities
I had a little RH stock a few years ago
almost made 10% in one day, then lost 90% as the bubble burst ;)
that was my one foray into stock market investing
Ah I got it when it was < $7
Expect < $50 next year.
heh -I got it when it was $60, and put in a sell order for $69.
it went up to $67 that day, then slid ever downward ;)
Well we do what we can.
yep. sold at a $900 loss, and decided I should do things I'm good at ;)
Never figured out what I'm good at.
hmmm -maybe that's my problem too
Wife has my grave marker picked out. Says "Here lies rayh, the only thing he finished was life."
We just had a post on the wiki that linked to an upload of a binary for Andrews wire edm
I removed the link becuz I think it may be owned by GeoFischer Co or somebody
any advice on such on the wiki? our responisbility?
it was the operating system for an Andrews WireEDM
The download limitations should be the responsibility of the owner of the warz
it's good to keep that stuff off the wiki
it can always be restored if needed / appropriate
well I stomped on te link, not the file
i notified who I figgered the sender was, ( guessed )
stevestallings is now known as steves_logging
cradak: thanks for updating the emc2 'testing'. i just did a cvs update with configure and make. the make crashed at 'make: *** No rule to make target '../configs/hexapod-dim/emc.nml' need by conifgs'. Stop'
did you re-configure?
err - re-run .configure
Roguish: did you use cvs up -dP from the toplevel directory?
i was in the src directory
back up a directory and try again
you should always issue cvs commands from the top directory
(there are rare occasions where developers do things in a lower directory, but not many)
and even developers sometimes get bit in the ass by it
but hopefully then they say "ow, my ass" and use the top directory
I'm tempted to put a script in my top dir that does:
i'm doing it now. guess i got to the 'cd src' a little early. cvs is a little slow this morning.
cd src && ./configure --enable-run-in-place --with-make-quiet
and another that does
cd src && make && sudo make setuid
actually the first one should do cvs up -dP && cd src && configure
I was thinking that a makefile could be put in emc2/ that essentially does $$MAKE -C `pwd`/src/
(+- some punctuation)
speaking as an idiot, the more 'idiot proof' you can make something, the better. the difficulty lies in not being idiot enough to be a real idiot, like me.
want to see the real scope of open source development? /join #commit
that channel gets CIA messages from every project using CIA
I've seen that - it scares me
makes you realize how big the OSS world is
kinda slow considering that there are 6.5 billion people who could be helping ;)
jmkasunich: bdilive farm build succeeded
new emc2, emc-dev packages in the ubuntu repository
* alex_joni heard some bad news
the Motenc-100 is out of production
is that the ISA card?
nope, thats the 8 channel card
I don;t think motenc has an isa
ok. i may be thinking STG
yeah, STG is ISA
well, I guess the mesa card continues to look better
though it has no true analog onboard
I think the mesa is loads cheaper
IMO the pricing of the motenc is probably what killed it
yes, loads. the mesa car dis $200 in single quantity
for $300 or so, you can have that plus an analog I/O add-on card
cradek: are you there?
seen you put a fix
for the canon stuff (motionTolerance)
and made a new release
you put that only in one place
there is also the test above
nothing crucial, it will just cause the stuff to get sent more frequently
for example if I do G64P0.1 4 times, it sends it 4 times
so don't worry about it (moving TESTING or anything), it's a minor inconsistency, not even a bug
is there a case where it would not be sent when necessary?
hmmm - is that checking a local copy, or the status struct?
only if you set it a few times to the same value
then it doesn't need sending
ok. that's bad then
SWPadnos: how so ?
it should be sent every time, since there could be other (remote) UIs
no, this is not about UI's
unless I'm at the wrong level in the hierarchy ;)
it goes to motion
and there is only 1 motion (I sure hope so ;)
cradek: that should do the trick.. sorry I borked it in the first place ;)
I should have tested
yeah, me too.. but I guess, that's why TESTING is there ;)
[Global Notice] Hi all. In a moment we're going to be performing some quick maintenance. About 4,000 users on a main rotation server will be detached from the network and reconnected. Please bear with us.
SWPadnos is now known as SWP_Away
this is fscking annoying
axis getting stomped on every time I cvs up and make
put axis code in a subdir of emc2, and it'll get built automatically
I thought I saw something about that, but I can't find the message
it needs to be in emc2/axis/
isn't there a special incantation needed too?
just ./configure --enable-run-in-place
put a copy of axis-latest in emc2/src (emc2/src/axis-latest)
then run configure
it should say it found a copy of axis in that directory
axis-lates, or axis?
axis*, but it won't work right with 1.1 or 1.2, because those need 'sudo' to install, and install files outside the run-in-place directory.
when I untar axis-latest, I get something like axis-<number>
that should be fine
axis-ps999 indicates the exact version of axis
does make use the latest one found?
if I download a later one I need to erase the older tree to keep it from getting confused?
best to remove the others so there's no ambiguity
* jmkasunich makes a "update-axis" script to go with his "update" one
rm -rf axis-ps* && get the latest (ftp command maybe) && untar && cd src && configure (with RIP)
you can also do axis via anonymous CVS now
I'm not so sure checking out axis from within my developer checkout of emc is a good idea
I actually have emc2 and axis parallel, and in emc2/src a symlink to ../../axis
ah - that's even better
when you are updating the cvs tree CVS ignores the link because that dir isn't in CVS/Entries?
I don't even think it prints a "? axis" line
the symlink doesn't seem to cause any problems when updating emc
sounds like a plan
just tried to delete my old axis-ps436 tree
there are things owned by root in there now!
can I safely remove them?
(this is in the build/ tree)
since it doesn't install things under /usr/lib or /usr/share, the axis 1.3 install doesn't require 'sudo' for run-in-place
seems to have built ok, will test in a few secs
well, I caught it exceeding accel spec (but not my much
spec is 0.4 accel, seems like it hit 0.415 or 0.420
I think cradek would like to know about that
is it for one cycle or many cycles?
at least 1 ;-)
when I detect it, I immedately hit the limit switch
(I = the hal config)
so it stops right away, no way to see what would happen next
hmm, I seem to have figured out how to lock up axis
what did you do?
I take that back
I seem to have figured out how to confuse the mouse pointer
I tried to load a file and them I hit the estop button before the load was done
so I got the "busy" cursor and it stayed, and stayed
interesting; you shouldn't be able to click things while loading.
and the load didn't finish, must have aborted it
you mean you clicked the toolbar button?
or something else?
anyway, I clicked on file again (with the busy cursor) and I was able to laod the file, and it went back to normal cursor
the (X) button on the button bar
right underneath the file menu
back to accels
I think you can repeatably get the cursor to stay in "menu" Mode as well
either something is wrong with my hal file / instrumentation
or something is wrong with Z
are you using any step generation, or just command out -> position in?
looking at X,Y.,Z accel signals (2nd derivitave of pos)
using stepper, but looking at the output from the TP, not the feedback from the stepgen
ok - just wondering
X and Y accel are very smooth at 0.1 in/sec^2 per sec
(or maybe its mm/sec^2, this is the torture config I got from jepler)
Z accel shows severe jitter
oops, I can
I can't type
X and Y accel are very smooth at 0.1 in/sec^2 per DIV!!!
fscking ' is too close to enter
so it is
Z accel shows jitter of about half a division, in fact it looks like its quantized
at 0.1 IPS^2 per div on Z as well?
maybe I'm looking at feedback by mistake
this is TP command out, not PID?
no PID on a stepper config
right - duh
I'm so used to the USC, kind of a hybrid
I'm definitely looking at the TP output
this jitter is taking place at the servo rate, not the traj rate
halscope really needs more colors
yeah, one per trace would be good ;)
(colon-P is tongue stuck out ;) )
I wonder if this jitter is the 24 bit resolution of hal floats amplified by double differentiation?
not at 0.1 / div, I'd think
thats the accel
differentiating at 1mS
so quantisation of 0.000001 in position becomes 0.001 in vel and 1.0 in accel
it could be, but remember that those 24 bits can shift around
what kind of velocities?
(are you testing at)
jmkasunich: I noticed jitter when I used very low acceleration
jmkasunich: but the FE was still good, so I ignored it
Z pos is 0.7825, Z vel is 0.045/sec and decreasing at 0.2/sec ^2
cradek: I'm inclined to agree that its noise
that's a pretty low Z vel
I assume that the ddt block scales for the sample rate...
with Z = 0.7825, position quantization is .00000005, so the velocity jitter on the differntiator output would be 0.00005, and the accel jitter on the second diff output would be 0.05, which is damn close to what I see
who'd a thunk it
SWP: yes, the block does ((this_sample - prev_sample) / sample_period)
the original 0.00000005 is from the number of digits in a float?
I just saw that
it would be a delta without it ;)
yes, 24 bits = 1/16million * the position of 0.78
the quantization error should be independent of the actual value, only proportional to its order of magnitude
(it=the actual value)
yes, the .78 is the order of magnitude
the error will be the same over a 2:1 range, then step to a new level
anyway, I'm surprised that it is FP quantization, but I'm convinced now
double differentiation at a 1KHz sample rate multiplies position quantization error by a million
sure. I suppose the TP is starting from "source data", so it wouldn't be quite so sensitive
right, the TP is basically an integrator instead of a differentiator
I wonder how things would be at a 2KHz or 10KHz servo rate though
I think the TP would be fine
it isn't differentiating anywhere
if you think about it, this is the classic resolution issue - when you look at a small difference between two large things you get errors
in this case the two large things are the two positions and the small diff is the distance moved in a millisecond
thats the reason the X and Y accels look so clean, they're very close to zero
the positions are close to 0?
that's why I was seeing it bad in A - the numbers are MUCH bigger
move X to 20 and see what happens ;)
I got a trip on the first blend in the program
prior to the blend the jitter was centered around -0.2 (limit is +/- 0.4)
during the blend the accel headed for -0.4, and the jitter took ot past the limit
this was pretty much a reversal, I assume
hard to say, I was using jepler torture program (XYZ, no A), its just a ball of furr
Z velocity was positive, heading toward zero, when the blend begins (X and Y begin to move), Z heads to zero faster
probably was going to reverse, but tripped first
duh... look at the gcode john ;-/
G0 X0 Y0 Z20
G0 X2 Y-4 Z16
so yes, a reversal
that's what it looked like ;)
hal 2.0 definitely needs to support doubles for its analog signals
then the jitter won't show up inless you look at the 4th derivative
so what do we do about this?
all it means is that I can't use HAL to catch you if you allow 1 sample of excessive accel
you should expand the tripp point to include the possible quantization error, and then re-run the test
-0.45001 or something, in this case
the possible error is at least 10% of the accel limit
oh so you're using a specially-crafted test, not the usual stepper limits
right, I have double ddt blocks, then both vel and accel signals go to comparators
any signal out of bounds for even one servo cycle and I hit the limit switch inputs
and EMC stops with a hardware limit fault
wow, that sounds like a good test
I thought it would be
is axis.n.joint-vel-cmd used?