Back
[00:24:02] <andypugh> Do kinematics modules only get called when an Axis is moving? I am not seeing quite what I would expect to see
[00:34:49] <andypugh> I have simplified, and the plot thickens....
[00:34:52] <andypugh> http://www.pastebin.ca/1887429
[00:35:14] <andypugh> I just got "NaN" as dy in the halmeter.
[00:35:23] <SWPLinux> hmm
[00:35:50] <andypugh> - and + are overloaded in posemath, but I haven't referenced posemath
[00:36:11] <cradek> this is C, there's no such thing
[00:36:24] <andypugh> As the only operator being used to calculate dy is a -, I am puzzled to see how I can have a NaN
[00:37:30] <andypugh> Of course, if tran.y is a NaN, then I guess so will be dy....
[00:38:05] <SWPLinux> sqrt
[00:38:34] <SWPLinux> but you're not (theoretically) using negative numbers in the sqrt call
[00:39:13] <andypugh> No, and even if I did, hyp might be NaN, but not dy
[00:40:27] <andypugh> I guess it is a chain of nonsense. hyp = 0, costan = NaN, joints[5] = NaN, tran.y = NaN, dy = NaN
[00:41:10] <andypugh> A NaN contagion
[00:41:48] <cradek> so you think hyp=0 causes it all?
[00:41:54] <cradek> they do spread fast
[00:41:59] <andypugh> I think there is a fair chance of that
[00:42:32] <andypugh> The only way to get NaN is 0/0 I believe, anything else /0 is +-Inf?
[00:46:53] <SWPLinux> no, there are a bunch of rules on how to get a nan
[00:47:24] <SWPLinux> not least of which is that anything (almost?) combined with a NaN yields a NaN
[00:47:45] <SWPLinux> incidentally, I think the math is wrong
[00:48:05] <andypugh> Yeah, I am pretty sure the maths is wrong.
[00:48:09] <SWPLinux> isn't the intent that you will have a kerf angle adjustment, which will be combined with any programmed A angle?
[00:48:20] <SWPLinux> and other stuff
[00:48:25] <andypugh> No, the A angle is the kerf adjustment
[00:48:30] <SWPLinux> oh, hmmm
[00:50:24] <andypugh> It's not my maths. Well, it is partly my maths,but I think I will be tearing it up and starting again.
[00:50:50] <SWPLinux> heh
[00:55:31] <andypugh> One sign that the maths is wrong, I think, is that when I home Z it goes to 250 (the home position) then slowly goes back to zero... (though I am not entirely sure what the normal behaviour is for a joint that is homed without a sequence or a switch)
[01:19:23] <andypugh> Time to sleep.
[01:21:04] <andypugh> But, current problem is that my forwardkins sets A to zero when the movement stops. Is there any reason that A has to depend on joint positions? Can I just pass it through unchanged via a storage variable inside the kins?
[11:56:16] <micges_work> mozmck: hello
[12:11:01] <jepler> I have private mail from cmorley that he's tested the modbus patches and they work for him. Also mail from dave that he's been working on a waterjet conversion (using his version of the modbus stuff) on 10.04 using mozmck's kernel debs and will post pictures soon
[12:17:57] <micges_work> I'm sure that unpluggging and plugging ethernet cable hangs up realtime on mozmck 10.04 rt kernel
[12:18:09] <micges_work> I't 100% repeatable
[12:18:15] <micges_work> It's
[12:20:45] <jepler> yuck.
[12:21:01] <jthornton> do you have to have emc running when you unplug the cable?
[12:26:33] <jthornton> I just unplugged and plugged the ethernet cable on mine with the latency test running with no ill effects
[12:30:26] <micges_lucid> logger_dev: bookmark
[12:30:26] <micges_lucid> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-06-21.txt
[12:34:51] <micges_lucid1> jthornton: when I unplug when emc is running, realtime don't want to unload when closing Axis
[12:39:43] <jthornton> I started axis then unplugged ethernet then shut down axis then plugged the ethernet back in and started axis again but didn't see any problem. Do I need to check something else?
[12:41:43] <micges_lucid1> jthornton: no that's it
[12:42:00] <micges_lucid1> maybe it's some eth driver problem
[13:04:56] <jthornton> ok, I'm not sure how to tell what driver I'm using
[13:07:24] <jthornton> connection information at the top shows Driver: forcedeth
[13:09:29] <jthornton> gotta run now
[17:29:24] <cradek> we're in ann arbor and all's well
[17:30:22] <micges> cradek: you and few others arrived earler right?
[17:30:49] <SWPLinux> cradek: wanna go to that Ethiopian place tonight?
[17:31:18] <cradek> we just got here...
[17:31:26] <SWPLinux> heh
[17:31:27] <cradek> sure
[17:31:47] <SWPLinux> I'm leaving in the next 15 minutes or so, so I should be there between 5 and 6
[17:32:00] <cradek> ok
[17:32:26] <cradek> have you determined that it is open?
[17:32:56] <SWPLinux> yes, they serve dinner every night (from what I could see), it's only lunch that they skip on Mondays
[17:33:10] <cradek> ok cool
[17:33:16] <SWPLinux> that page said "now open for lunch", but there's a dinner meny
[17:33:18] <SWPLinux> u
[17:33:38] <SWPLinux> it probably wouldn't hurt to call
[17:34:12] <cradek> right, let us know
[17:34:31] <SWPLinux> ok
[17:34:40] <SWPLinux> I'll contact you when I arrive as well
[17:34:52] <cradek> ok
[19:32:40] <CIA-4> EMC: 03cradek 07separate-g92 * r476a688cef77 10/ (2 files in 2 dirs): fix AXIS preview
[19:32:41] <CIA-4> EMC: 03cradek 07separate-g92 * r2c6f4fd8679f 10/src/emc/rs274ngc/interp_internal.hh: comment fix
[19:34:59] <micges> cradek: what is purpose of separate-g92? separate origin offset logic from g92 offset logic?
[19:35:51] <cradek> yes g5x and g92 are separated for several reasons: g92 works in rotated g5x coordinate systems, and guis can show the offsets separately if they choose to
[19:36:58] <micges> I see, cool
[19:38:59] <cradek> http://timeguy.com/cradek-files/emc/run-with-different-g92-offset.png
[19:39:34] <cradek> I ran the program with X=2 G92 offset (causing red backplot) then cleared it with G92.1 and reloaded the program (white)
[19:40:03] <cradek> the g5x systems have various offsets and rotations so you can see how they interact
[19:40:51] <micges> neat
[19:43:40] <CIA-4> EMC: 03cradek 07separate-g92 * r8e979df8fc0b 10/lib/python/rs274/glcanon.py: fix dro
[19:43:41] <CIA-4> EMC: 03cradek 07separate-g92 * r66cfbd8c7df1 10/src/emc/usr_intf/Submakefile: emcrsh doesn't build yet...
[20:10:10] <CIA-4> EMC: 03cradek 07separate-g92 * racec1e5bbf9e 10/lib/python/rs274/glcanon.py: pretty up the bigdro a bit
[20:10:12] <CIA-4> EMC: 03cradek 07separate-g92 * rd06511a8101d 10/src/emc/rs274ngc/interp_find.cc: fix changing systems and g10 l20
[20:49:39] <SWPLinux_> SWPLinux_ is now known as SWPLinux
[20:56:46] <cradek> wth, glRotatef takes degrees
[20:57:05] <SWPLinux> ust like G-code, luckity
[20:57:09] <SWPLinux> lickilt
[20:57:11] <jepler> I new that already, but what a surprise
[20:57:13] <SWPLinux> glarg
[20:57:18] <jepler> argh, knew
[20:57:33] <SWPLinux> phew
[21:03:30] <cradek> http://timeguy.com/cradek-files/emc/show-offsets.png
[21:05:39] <cradek> jepler: the hershey module doesn't know how to draw "G" :-/
[21:09:25] <jepler> cradek: whoever wrote it shouldn't have cut so many corners
[21:10:36] <cradek> I wonder if whoever wrote it recalls how those numbers were generated
[21:13:53] <cradek> jepler: in addition to the click-select not working, I think I'm not getting line stipple in master - they just look solid.
[21:16:35] <CIA-4> EMC: 03cradek 07separate-g92 * r1afa8b46314a 10/lib/python/rs274/glcanon.py: show the offsets in the preview
[21:16:36] <CIA-4> EMC: 03cradek 07separate-g92 * re5ae4f70c426 10/nc_files/systems.ngc: this should show g5x and g92 both
[22:35:09] <andypugh> This is odd.
[22:35:44] <andypugh> I have a stepgen where the position-fb constantly counts up, despite the fact that the position-cmd is zero
[22:37:18] <seb_kuzminsky> are you in position control mode or velocity control mode?
[22:37:34] <andypugh> Free mode
[22:37:53] <andypugh> Just powered up, in joint mode
[22:38:28] <seb_kuzminsky> i meant the stepgen itself, not the motion controller
[22:38:32] <andypugh> I am meddling with kinematics, but my understanding is that kins is not even called in join mode?
[22:38:48] <andypugh> Good point, not my ini file.
[22:39:04] <andypugh> loadrt stepgen step_type=0,0,0,0,0,0
[22:39:10] <andypugh> So, position then?
[22:39:27] <seb_kuzminsky> yes
[22:39:28] <seb_kuzminsky> hmm
[22:40:05] <andypugh> It does seem spooky, doesn't it?
[22:40:16] <seb_kuzminsky> call the exorcist!
[22:40:48] <seb_kuzminsky> is stepgen.X.counts counting up along with .position-fb?
[22:41:19] <andypugh> Yes
[22:41:42] <seb_kuzminsky> is .enable true?
[22:41:46] <andypugh> Yes
[22:42:00] <seb_kuzminsky> what's .frequency?
[22:42:37] <andypugh> 10006.8
[22:42:48] <seb_kuzminsky> huh
[22:43:15] <andypugh> All sliders to zero has no effect.
[22:43:38] <seb_kuzminsky> is there a .velocity-cmd pin? what's its value?
[22:43:47] <andypugh> I am going to swap the hal to trivkins to see if that makes any difference (but the manual says that kins is not used in joint mode)
[22:43:53] <andypugh> No pin
[22:44:02] <seb_kuzminsky> and you said .position-cmd is 0 and not changing.. strange
[22:44:43] <andypugh> Well, every time it f-errors (at 100mm, quite wide limits as the moment) pos-command takes on the current value
[22:45:13] <andypugh> So it is increasing while we speak in steps of 100mm
[22:45:26] <andypugh> But only when it f-errors out.
[22:48:17] <andypugh> The even stranger thing is, this is a gantry config and joint[1] is explicitly set to the same value as joint[0], but only joint[0] is wandring.
[22:49:24] <andypugh> It _isn't_ a problem with trivkins. It seems the manual isn't quite correct about whether kinematics is used in free/joint mode...
[22:53:00] <andypugh> But hang on, this is the output of a stepgen, it still ought to follw the position-cmd, even if that position-cmd is gibberish from a kinematics module?
[23:25:35] <PCW> OK got around to testing a 5I23 with a bad bit file (I hacked my loader so it didn't bit reverse when it should have) and didn't see any problem
[23:25:36] <PCW> the expected thing happens, no CRC error because no valid sync so bitfile load is just ignored and subsequent correct loads work fine
[23:45:41] <andypugh> Any ideas?
http://imagebin.ca/view/yTBJvH9.html
