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