Back
[00:08:28] <cradek> well it came to me during dinner - the interp resyncs before or after each mdi command, and since the move is deferred, it ends up with the wrong current position
[00:08:58] <cradek> this makes the straight moves degenerate, so they are discarded, so you get a wrong starting point for the arc, which gives a deranged arc.
[00:12:29] <cradek> so what is the fix?? don't resync the interp except if you leave/enter mdi mode (ugh, task change) or don't allow comp in mdi?
[00:25:58] <cradek> yep, that fixes it (don't resync)
[00:26:07] <cradek> wonder what it breaks...
[00:39:52] <cradek> hm, that code is as old as the hills
[00:40:04] <cradek> but, I can't find anything that breaks when I remove it
[00:46:11] <cradek> I tested all the cases I can think of that require a resync, and they do have one (mode change, interrupted move, probing, tool change motion)
[00:50:47] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/task/emctask.cc:
[00:50:47] <CIA-2> EMC: remove unnecessary interp syncs between all mdi commands, because this causes
[00:50:47] <CIA-2> EMC: you to be unable to use cutter comp in mdi mode. the cases that actually need a
[00:50:47] <CIA-2> EMC: sync still have it: mode change to mdi (you might have jogged), after
[00:50:47] <CIA-2> EMC: interrupted mdi move, after probing in mdi, after tool change in mdi.
[00:50:50] <cradek> * cradek shivers
[01:15:36] <jepler> cradek: check if that fixes T1 then M6 as separate MDIs
[01:15:42] <jepler> there's an sf issue about it
[02:46:05] <cradek> yeah, I guess I fixed that too
[02:46:26] <cradek> I did t2 / g0x1 / m6
[03:11:05] <jepler> the HTR involved unhooking the loopback temporarily
[03:21:45] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hostmot2.9: better function descriptions (thanks to Walt Rogers for the feedback)
[03:30:18] <cradek> oh, I didn't even read it...
[03:37:59] <jepler> I know the feeling
[03:38:23] <cradek> if my build ever finishes I'll try it
[03:41:43] <jepler> I know the feeling
[03:41:44] <jepler> 'night
[03:52:17] <cradek> build build build
[03:52:19] <cradek> jeez
[04:05:20] <cradek> jepler: yep, it's fixed too
[04:07:56] <jepler> cradek: hooray
[04:12:44] <cradek> pure luck
[09:55:30] <alex_joni> cradek: yay
[09:59:52] <alex_joni> I see you closed the bugreport, and assigned it to yourself before you did that
[10:00:05] <alex_joni> wonder why SF doesn't email the old assignee in that case
[12:18:41] <CIA-2> EMC: 03tissf 07TRUNK * 10emc2/docs/src/gcode/coordinates_fr.lyx: french translation update
[12:18:48] <CIA-2> EMC: 03tissf 07TRUNK * 10emc2/docs/src/lathe/lathe-user_fr.lyx: french translation update
[13:51:56] <cradek> did you guys finish the hardy packages? what's the apt url?
[13:53:27] <cradek> BigJohnT: I fixed comp + mdi, thanks for finding the problem
[13:53:36] <BigJohnT> cool cradek
[13:54:29] <alex_joni> cradek: same as before, but using emc2.3
[13:54:54] <cradek> I bet you are right that the docs should say something about it. if you don't understand that each move is deferred until the corner can be determined, it might seem very strange
[13:55:42] <alex_joni> cradek: deb
http://www.linuxcnc.org/hardy hardy base emc2.3
[13:55:51] <cradek> thanks
[13:56:00] <BigJohnT> yes it does seem strange
[13:56:02] <cradek> I may do some boring work (haha) today - if so I will use the package
[13:56:10] <alex_joni> heh
[13:56:22] <alex_joni> BigJohnT: I was thinking about that threading chapter
[13:56:23] <BigJohnT> don't fall asleep if it is too boring
[13:56:38] <alex_joni> and I think it should be about connecting an sim-encoder
[13:56:59] <alex_joni> maybe even a section about the 1ppr threading (with a big warning that it's _far_ from perfect)
[13:57:13] <BigJohnT> I did mention that an encoder or similar was needed in the user manual
[13:57:25] <alex_joni> but basicly how the encoder gets connected, what pins need to be connected to the motion controller
[13:57:39] <alex_joni> spindle-revs & spindle-pos and index-enable and whatnot
[13:57:40] <BigJohnT> that should be in the integrators manual
[13:57:59] <BigJohnT> I think there is a small bit on it now but it needs to be expanded
[13:59:23] <BigJohnT> I have a spindle feedback section but it is empty :(
[14:00:41] <alex_joni> spindle feedback is probably the superchapter for threading
[14:01:00] <alex_joni> I think there are a couple different spindle feedbacks
[14:01:20] <BigJohnT> G41 or G42 D- is that the same as loading a tool or is it a diameter or has the D been dropped for G41.1...?
[14:01:24] <alex_joni> 1. you can have a PID to control a VFD to set an exact velocity
[14:01:39] <alex_joni> 2. encoder feedback for threading
[14:01:45] <alex_joni> e.g. position feedback
[14:01:51] <alex_joni> for threading and rigid tapping
[14:01:56] <alex_joni> 3. velocity feedback for CSS
[14:02:45] <BigJohnT> does velocity come from an encoder?
[14:03:14] <alex_joni> it can
[14:03:26] <alex_joni> the encoder component has a velocity output
[14:18:43] <BigJohnT> * BigJohnT needs to order an encoder to play with
[14:24:43] <alex_joni> you can use a stepgen to simulate it ;)
[14:24:50] <alex_joni> sim lathe does that
[14:24:51] <alex_joni> iirc
[14:25:06] <BigJohnT> I thought that there was a sim encoder...
[14:26:10] <BigJohnT> bbl breakfast calls
[14:36:46] <alex_joni> bbl
[14:56:38] <BigJohnT> for EMC to do threading and other spindle cooridnated things like CSS you need to load an encoder and add update-counters to a thread...
[14:57:04] <BigJohnT> have and input to encoder.0.phase-a
[14:57:33] <BigJohnT> and/an
[14:57:54] <BigJohnT> have an input connected to encoder.0.phase-a
[14:58:00] <BigJohnT> anything else
[15:02:15] <fenn> connect encoder.0.velocity to spindle.speed-in or whatever
[15:02:29] <BigJohnT> ok thanks fenn
[15:08:12] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: clean up
[15:11:26] <fenn> docs never got split into separate packages eh?
[15:11:49] <BigJohnT> not that I know of
[15:12:29] <fenn> <- running out of disk space
[15:28:36] <BigJohnT> so encoder.n.velocity is the same units as motion.spindle-speed-in ? I see velocity is in units per second on the man page but nothing for speed in
[15:37:51] <cradek> alex_joni:
http://pastebin.ca/1350260
[15:38:01] <cradek> jepler: also ^
[15:38:38] <cradek> bbl (dangit)
[15:46:48] <cradek> jepler: bin/stepconf:105: distdir = "/etc/emc2/sample-configs/common"
[15:47:21] <cradek> the sample config move is incomplete. at least pickconfig and stepconf don't know about it.
[15:53:21] <jepler> cradek: huh -- I was sure I had tested pickconfig
[15:53:22] <jepler> !!!
[15:53:33] <jepler> what's it do, still point at the ones in /etc that weren't automatically removed?
[15:56:38] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/examples/spindle.lyx: add info on spindle feedback, can someone who knows proof read this?
[15:57:14] <BigJohnT> * BigJohnT is off to town
[15:57:21] <jepler> BigJohnT: by the way, anytime there's a checkref_en error that means the docs on linuxcnc.org aren't being updated...
[15:57:49] <BigJohnT> jepler: I thought I fixed that...
[15:57:58] <BigJohnT> I'll go back and look
[15:58:18] <jepler> BigJohnT: I last got a notification of the error at Date: Sun, 1 Mar 2009 09:16:41 -0600 (CST)
[15:58:38] <BigJohnT> ok
[15:59:11] <BigJohnT> I know about where it is...
[16:00:35] <BigJohnT> :/ I get it on my hardy machine but not on this one
[16:00:47] <jepler> that's interesting!
[16:01:21] <BigJohnT> doing a make clean on the hardy
[16:08:23] <fenn> BigJohnT: i think spindle-speed-in is rps because of lathe.hal: net spindle-rps-filtered lowpass.0.out scale.0.in motion.spindle-speed-in
[16:11:18] <fenn> and that's how stepconf does it too: net spindle-velocity encoder.0.velocity => motion.spindle-speed-in
[16:14:51] <CIA-2> EMC: 03fenn 07TRUNK * 10emc2/docs/man/man9/motion.9: clarify units on spindle-speed-in
[16:15:02] <BigJohnT> thanks fenn
[16:17:07] <BigJohnT> * BigJohnT forgets to commit a file again :/
[16:18:56] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/html/gcode.html: if you forget to commit all your changes it breaks everyone else
[16:34:56] <BigJohnT> I guess the build bot doesn't catch the checkref_en error...
[16:48:29] <jepler> it's only seen when building html
[16:48:38] <jepler> it must be that none of its incarnations do
[19:23:24] <fenn> 90% [Connecting to www.linuxcnc.org (208.113.228.112)]
[19:27:45] <fenn> looks like the webserver is having trouble
[19:43:56] <jepler> agreed, here too
[19:57:09] <alex_joni> cradek: did you have any locally changed files in /etc/emc2 ?
[19:57:11] <cradek> jepler: looks like it should start with the sample configs tree closed once you have custom configs, and also it renames it
[19:57:28] <cradek> alex_joni: no; besides I think it left all of them
[19:57:57] <alex_joni> odd.. I had emc2-sim installed, and had to remove it to install the new emc2 package
[19:58:02] <alex_joni> so I didn't get that..
[19:58:18] <cradek> I just changes 2 to 3 in souces.list and upgraded
[19:58:28] <alex_joni> right
[19:58:30] <cradek> yeah I think it left everything in /etc
[19:59:02] <alex_joni> I'll try shortly after I finish dinner ;)
[20:30:10] <jepler> cradek: that's what dpkg is supposed to do with config files
[20:30:18] <jepler> just because it was removed in the new version doesn't mean it should remove yours
[20:31:19] <jepler> dreamhost outage is affecting linuxcnc.org:
http://www.dreamhoststatus.com/2009/03/01/spoiler-lives-up-to-its-name/http://www.dreamhoststatus.com/2009/03/01/spoiler-lives-up-to-its-name/
[20:42:13] <alex_joni> guess that's why my apt-get install is failing :)
[20:45:33] <SWPLinux> huh. :)
[20:45:47] <alex_joni> jepler: hmm.. so that means users will still have those older (2.2.) sample configs there forever?
[20:46:07] <alex_joni> or should we suggest they need to uninstall emc2, then install the new emc2 for 2.3 ?
[20:46:20] <alex_joni> (maybe by running an upgrade script)
[20:58:22] <jepler> alex_joni: there's some way to tell dpkg to remove the files ("purge"?)...
[20:59:48] <alex_joni> yes, purge removes them
[21:00:06] <alex_joni> but I'm not sure if we can call dpkg --purge from the upgrade of the package
[21:00:57] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: add new location of configs, so stepconf can find the common stuff
[21:01:01] <jepler> probably not
[21:07:58] <alex_joni> the only way I see is using a postinst which removes them
[21:14:14] <jepler> we could put a note: if it bugs you, you can remove these by hand
[21:14:17] <jepler> most users won't notice
[21:14:31] <jepler> (e.g., a 2.3 pickconfig shouldn't show files from there)
[21:14:37] <alex_joni> it doesn't
[21:15:48] <alex_joni> site is back up
[21:17:18] <jepler> and the /etc case should probably be removed from stepconf...
[21:26:32] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: remove /etc case for sample configs, as suggested by jeff
[21:35:08] <alex_joni> jepler: if seb drops by later (if I'm not here at the time), I added some comments/ideas regarding mesa cards to
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emc2.3Status
[21:40:37] <alex_joni> jepler: btw, nice page on updating to 2.3, was just starting to write one when I noticed you already have :)
[21:40:57] <alex_joni> do you plan to write to the emc-devel list?
[21:41:36] <jepler> on the one hand, somebody should
[21:41:55] <jepler> on the other hand, I was tempted to try to get beta2 out soon and announce it instead
[21:42:01] <alex_joni> I think it would be best to keep the first announcement out of the -users list
[21:42:07] <jepler> ok sure
[21:42:22] <alex_joni> maybe keep beta1 (with the problems we already discovered) for devels
[21:42:29] <alex_joni> they can surely handle them
[21:42:47] <jepler> anyway, I can announce b1 tonight on the devel list so we keep the schedule intact :)
[21:42:55] <jepler> I'll get to it in the next few hours
[21:42:56] <jepler> bbl
[21:43:09] <jmkasunich> an intact software dev schedule? isn't that blaspheme?
[21:46:53] <alex_joni> not just yet
[21:50:51] <alex_joni> is the brown bar over the picture on stepconf by purpose?
[21:51:37] <alex_joni> http://imagebin.org/39720
[21:53:07] <SWPLinux> the image isn't big enough to take up all the space - your stepconf window is taller than mine
[21:53:35] <SWPLinux> I wonder if the height was changed when ehj added the extra stuff to stepconf
[21:53:41] <dgarr> an anomaly with hal_input:
http://pastebin.ca/1350495
[21:54:51] <alex_joni> I see the basic machine information page is as tall (because of ports 2 & 3)
[21:55:23] <alex_joni> and the "advanced configuration options" page is also pretty tall
[21:56:27] <SWPLinux> gotta run. see you later
[21:57:20] <cradek> did someone fix pickconfig or should I?
[21:57:38] <alex_joni> pickconfig seems ok here..
[21:58:15] <cradek> it should rename and close the sample configs tree if you have custom configs - it doesn't because it doesn't know the path for this special rule now
[21:58:27] <alex_joni> ah
[22:00:27] <alex_joni> cradek: if it's convenient for you to fix it, go ahead
[22:00:32] <alex_joni> if not, I can do it here
[22:01:07] <cradek> ok, I can do it in a minute
[22:01:22] <cradek> I was just reading about dgarr's problem with hal_input
[22:01:41] <alex_joni> then I'll do it now
[22:02:22] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/tcl/bin/pickconfig.tcl: notice new sample-configs location
[22:02:34] <cradek> ah thanks
[22:02:47] <alex_joni> I think it's a rounding problem
[22:02:50] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/hal/user_comps/hal_input.py.diff?r1=1.13;r2=1.16;f=h
[22:03:40] <alex_joni> hmm.. it used to set the -counts to halfrange initially
[22:03:45] <cradek> yeah, and I'm sure I don't understand it
[22:03:54] <alex_joni> now it sets it to absinfo.value
[22:04:02] <alex_joni> which sounds like the value read
[22:04:50] <alex_joni> the comment for the change: "for absolute axes, make sure that the pin starts out driven by the right value at startup
[22:05:37] <alex_joni> dgarr: my guess would be that your device returns the 128 as the initial position
[22:05:57] <alex_joni> (even if after bumping it returns to 127)
[22:06:34] <cradek> you could use abs-*-flat to make some range around 127 be 127
[22:06:55] <alex_joni> cradek: I think it's a conceptual change
[22:06:59] <dgarr> it seems to me the problem is that its value (whatever it is) as reported by hal_input changes after the button is touched the first time and returned to its neutral position
[22:07:14] <alex_joni> initally the half of the range was used for startup
[22:07:24] <alex_joni> now the actual value reported is used at startup
[22:07:27] <cradek> dgarr: yes but I think alex is saying that may be what the device actually does
[22:07:42] <alex_joni> (even if badly articulating that)
[22:07:45] <dgarr> well that will be awkward
[22:07:53] <dgarr> to fix
[22:07:57] <alex_joni> dgarr: right..
[22:08:12] <cradek> did you try using flat?
[22:08:12] <alex_joni> the old behaviour is probably preferred for devices like yours
[22:08:48] <alex_joni> but for absolute value axes it's not ok
[22:10:37] <alex_joni> I think the way to check is to plug in the device, then look for the value of the axes in /proc somewhere
[22:10:48] <alex_joni> without loading hal_input
[22:12:37] <dgarr> btw, the joypad i used is very cheap and very commoh like:
http://tinyurl.com/dlyalw
[22:41:08] <dgarr> i tried this: plug in device, find usb id, then: cd /sys/bus/usb/devices/1-0:1.0; find . -type f -exec cat {} >|/tmp/a.0 \; ; then push and hold some buttons and find . -type f -exec cat {} >/tmp/a.1 \; ; diff /tmp/a.[01] -->nil :(
[22:52:26] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[23:03:56] <alex_joni> try diff -a
[23:04:07] <alex_joni> maybe it doesn't check the files (are they binary?)
[23:04:56] <dgarr> these are ascii
[23:05:05] <alex_joni> ah, odd then
[23:05:17] <alex_joni> maybe you can try cradek's idea (as mine are fresh out)
[23:05:45] <dgarr> i'm trying to figure out flat -- i thought it was a comp but now i see it is a param in hal_input
[23:16:39] <alex_joni> good night all