Back
[06:43:30] <SWPadnos> yay! good night
[17:59:26] <skunkworks> for threading- would you setup a software pid loop similar to what is internal to stepgen?
[17:59:46] <skunkworks> (wondering if it would have to be user tuned for some reason...)
[18:00:12] <skunkworks> Or if all the info is there to just make it work
[18:17:38] <fenn> i'd think it would 'just work' because all the joints already have PID, so the fact that commanded position is a physically unrealizable trajectory is OK
[18:19:13] <fenn> it's a bit harsher than normal since there's no accel limiting? so you'd see PID oscillations that wouldnt show up with more gentle treatment (talking out my ass here)
[18:19:36] <skunkworks> heh
[18:19:44] <skunkworks> I think it may be a bit over my hea
[18:19:45] <skunkworks> head
[18:22:06] <fenn> i think on jmk's setup you'd see the same velocity oscillation with a step function
[18:31:32] <fenn> // we'll have to wait for spindle sync; might as well
[18:31:33] <fenn> // stop at the right place (don't blend)
[18:32:38] <skunkworks> heh
[21:25:35] <jmkasunich> cradek:
http://jmkasunich.com/pics/thread-bobble-1.ngc
[21:25:53] <jmkasunich> demonstrates the bobble without my complex O-word program (on my mill)
[21:26:00] <jmkasunich> next step is to try it on a sim config
[21:30:17] <jmkasunich> just reduced it quite a bit - only need two consecutive G33 moves to get the bobble
[21:36:43] <jmkasunich> another data point: changing the spindle speed from 580 RPM to 315 RPM doesn't make the bobble go away
[21:36:58] <jmkasunich> it is delayed a bit (the first segment takes longer) and is a bit smaller
[21:37:20] <jmkasunich> but in relative terms, it is almost as large, compared to the desired velocity (which is smaller at the lower spindle speed)
[22:32:00] <jmkasunich> very interesting - on sim-lathe, the threading program acts really weird
[22:32:33] <jmkasunich> it doesn't follow the programmed path at all
[22:32:45] <jmkasunich> and it doesn't assert spindle-index-enable at all
[22:39:48] <SWPadnos> that's weird (especially considering the threading cradek did at Fest last year)
[22:39:53] <SWPadnos> it seemed to work ...
[22:44:43] <jmkasunich> this is sim-lathe
[22:44:57] <jmkasunich> not cradeks-lathe or nist-lathe
[22:45:01] <SWPadnos> understood
[22:45:03] <jmkasunich> my real lathe works fine
[22:45:09] <SWPadnos> it's weird that it would act so different
[22:45:22] <jmkasunich> I'm running simulator mode on a non-RT box
[22:45:35] <jmkasunich> shouldn't matter, but apparently it does)
[22:45:37] <SWPadnos> hmmm. even I can do that ;)
[22:45:49] <jmkasunich> very simple test
[22:45:54] <jmkasunich> start sim-lathe
[22:46:20] <jmkasunich> F1; F2; MDI M3S500; G0Z1; G33K0.03Z0;
[22:46:25] <jmkasunich> the G33 move does nothing
[22:46:59] <jmkasunich> motion doesn't assert hal pin motion.spindle-index-enable
[22:48:05] <jmkasunich> EMC thinks that the G33 move completed instantly - if you issue a G1 or G0 next, it is executed
[22:49:29] <SWPadnos> the current position doesn't update
[22:49:36] <SWPadnos> commanded or actual
[22:49:55] <jmkasunich> yeah, it didn't really "complete" the G33 - more like discarded it
[22:49:58] <SWPadnos> that tells me that the move isn't executed at all, not that it seems to be done immediately
[22:50:00] <SWPadnos> right
[22:50:23] <jmkasunich> what i meant by done immediately is that subsequent commands don't get blocked
[22:50:30] <SWPadnos> ok
[22:50:49] <jmkasunich> if there was some hal or encoder issue (like encoder not running), a G33 will hang waiting for a spindle index pulse, but thats not the case here
[22:51:10] <SWPadnos> ah. do a G1 move before the G33 and it works
[22:51:17] <SWPadnos> there's no feed rate specified
[22:52:02] <jmkasunich> hmm
[22:52:21] <jmkasunich> I don't see how a G33 should care if there is an F word set
[22:52:43] <jmkasunich> but it does
[22:52:48] <jmkasunich> F0 breaks it again
[22:52:54] <SWPadnos> yep. do G1Z1F60 instead of G0Z1 and the G33 works
[22:53:11] <jmkasunich> you don't even need the G1
[22:53:21] <jmkasunich> just do F1, then G33, and it works
[22:54:04] <SWPadnos> I noticed that because I tried a G1 move (without an F word) after the G33, and I got an error
[22:55:07] <jmkasunich> ok, I'm still seeing a difference between sim and real
[22:55:14] <jmkasunich> on the real lathe, F0 doesn't break G33
[22:55:36] <jmkasunich> this could be a version thing - I'm running sim on TRUNK, and real lathe on 2.2.latest
[22:56:30] <SWPadnos> hmmm. I suppose I should look at the version I have for sinm
[22:56:32] <SWPadnos> sim
[22:56:57] <jmkasunich> updating and building my 2.2 checkout - gonna try sim there
[22:57:03] <SWPadnos> well, it says pre-2.3 CVS head, but I'm not sure how new it is
[22:57:09] <SWPadnos> probably from just before Wichita
[22:57:46] <SWPadnos> hmmm. looks like we might lose power soon
[22:57:57] <jmkasunich> ice storm?
[22:58:02] <SWPadnos> yep
[22:58:25] <SWPadnos> slushy / snowy / icy now. already have >1 inch and more coming down
[22:58:44] <jmkasunich> ok, this is definitely a version thing - 2.2.4 works, trunk doesn't
[22:58:44] <SWPadnos> should be fun driving to Boston tomorrow
[22:59:36] <SWPadnos> heh - I should turn off that annoying warning again ;)
[22:59:57] <jmkasunich> F1, F2, M3S500, G0Z1, G33K0.03Z0, on 2.2.4 the G33 move happens, on trunk it doesn't
[23:02:24] <SWPadnos> well the config hasn't changed, so unfortunately it's in the code ;)
[23:03:21] <jmkasunich> an annoyance: if emc-environment won't run if its already run once
[23:03:38] <jmkasunich> which is a problem if you are switching back and forth from one checkout to another in the same shell
[23:03:53] <SWPadnos> I'd just use different shells
[23:05:09] <jmkasunich> yeah, but annoying anyway - I had two shells open with emc-environment in both - one for running emc, one for halcmd
[23:05:12] <jmkasunich> now I need four
[23:05:17] <SWPadnos> heh
[23:05:29] <SWPadnos> emc &, then halcmd in one shell
[23:05:37] <jmkasunich> yeah, yeah
[23:05:39] <SWPadnos> though messages can get annoying
[23:05:41] <SWPadnos> :)
[23:06:17] <jmkasunich> well, dinnertime here
[23:06:53] <jmkasunich> F1, F2, M3S500, G0Z1, G33K0.03Z0, on 2.2.4 the G33 move happens, on trunk it doesn't
[23:07:14] <jmkasunich> F1, F2, M3S500, G0Z1, F1, G33K0.03Z0, the G33 move happens on both
[23:07:51] <SWPadnos> that should help narrow it down
[23:08:28] <jmkasunich> this was a digression - I wonder if the bobble that I was originally trying to reproduce is version depenedent
[23:08:30] <SWPadnos> did you try your earlier 2.2 version before updating?
[23:08:44] <jmkasunich> no
[23:08:58] <SWPadnos> ok
[23:09:07] <jmkasunich> the real machine is using packaged 2.2, here I'm using cvs 2.2 (pre 2.2.4 I think)
[23:09:22] <jmkasunich> or maybe its pre-2.2.5
[23:09:52] <SWPadnos> hmmm. I did an update, but I still get pre-2.2.3 in the image popup
[23:10:07] <SWPadnos> that should change to pre-2.2.4, shoulnt't it?
[23:10:16] <jmkasunich> dunno at the moment
[23:10:23] <jmkasunich> I'm in my trunk shell
[23:10:29] <SWPadnos> oh, it's just "pre-2.3", so no it shouldn't
[23:10:36] <jmkasunich> ah, thats trunk
[23:10:45] <SWPadnos> yes
[23:14:26] <jmkasunich> the bobble happens on sim-lathe, trunk, when running the short g-code program at
http://jmkasunich.com/pics/thread-bobble-1.ngc
[23:14:42] <jmkasunich> you have to do "F1" before you run the program, or it will skip the G33
[23:15:26] <jmkasunich> so two distinct issues - skipping G33 (trunk only) and bobbles (trunk and 2.2)
[23:36:13] <skunkworks> so - it skips g33 if no feed rate is specified?
[23:36:26] <SWPadnos> if the current feed rate is zero, yes
[23:36:32] <skunkworks> yes
[23:36:34] <skunkworks> ok
[23:36:40] <SWPadnos> so either before you set Fxx or if you later set F0
[23:38:01] <alex_joni> jmkasunich: does the G33 reach motion?
[23:38:14] <alex_joni> or does it get killed at canon level?
[23:40:01] <SWPadnos> I don't think it can be reaching motion, because the commanded position doesn't change
[23:40:30] <SWPadnos> doesn't that imply that CANON doesn't think there should be any motion?
[23:48:54] <alex_joni> don't think so
[23:49:14] <alex_joni> but it's easy enough to check.. just turn on debug
[23:49:42] <SWPadnos> like DEBUG=1 gazillion? ;)
[23:50:26] <alex_joni> echo 5 > /proc/hal/debug
[23:50:28] <alex_joni> :P
[23:50:43] <SWPadnos> heh
[23:51:06] <SWPadnos> two commands are issued, both are EMC_TRAJ_SET_SPINDLESYNC
[23:51:29] <alex_joni> can you paste?
[23:51:42] <SWPadnos> (+232,+40, +0.0,0.0300000,\000,)
[23:51:44] <alex_joni> those are canon stuff
[23:51:45] <SWPadnos> and
[23:51:47] <alex_joni> EMC_*
[23:51:54] <alex_joni> EMCMOT is motion..
[23:51:54] <SWPadnos> (+232,+40, +0.0,0.0000000,\000,)
[23:52:03] <SWPadnos> one se
[23:52:05] <SWPadnos> c
[23:52:16] <alex_joni> SWPadnos: pastebin the last 10-20 lines
[23:52:27] <alex_joni> it's important if they only get to the queue
[23:53:05] <SWPLinux> emcTaskPlanExecute(M3S500) returned 0
[23:53:06] <SWPLinux> Outgoing motion id is -2.
[23:53:08] <SWPLinux> Issuing EMC_SPINDLE_ON -- (+1304,+48, +0,500.000000,)
[23:53:09] <SWPLinux> Issuing EMC_TASK_PLAN_EXECUTE -- (+509,+280, +10,G33K0.03Z1,)
[23:53:11] <SWPLinux> NML_INTERP_LIST::append(nml_msg{size=40,type=232}) : list_size=1, line_number = -3
[23:53:12] <SWPLinux> NML_INTERP_LIST::append(nml_msg{size=40,type=232}) : list_size=2, line_number = -3
[23:53:14] <SWPLinux> emcTaskPlanExecute(G33K0.03Z1) returned 0
[23:53:15] <SWPLinux> Outgoing motion id is -3.
[23:53:17] <SWPLinux> Issuing EMC_TRAJ_SET_SPINDLESYNC -- (+232,+40, +0,0.030000,\000,)
[23:53:18] <SWPLinux> Issuing EMC_TRAJ_SET_SPINDLESYNC -- (+232,+40, +0,0.000000,\000,)
[23:53:27] <SWPLinux> that's al
[23:53:28] <SWPLinux> l
[23:53:41] <alex_joni> you're running sim too?
[23:53:48] <SWPLinux> yes
[23:54:12] <SWPLinux> same commands when F1 was specified (and the motion happens)
[23:54:17] <alex_joni> did you do the echo.. ?
[23:54:33] <SWPLinux> one sec. let me make sure it's acting how I think it is
[23:56:00] <SWPLinux> ah, ok. the machine position had ben saved between runs, so I had t move to 0 first :
[23:56:01] <SWPLinux> :)
[23:56:36] <SWPLinux> here are the two moves, with an F1 in between:
[23:57:03] <SWPLinux> hmmm. maybe I'll pastebin - one sec
[23:57:20] <alex_joni> make sure you have the hal debug turned up
[23:58:08] <SWPLinux> http://pastebin.ca/934655
[23:58:12] <SWPLinux> I'll do that next
[23:58:38] <alex_joni> although I noticed someoen didn't add a debug message to spindlesynch
[23:58:57] <SWPLinux> hmmm. I'm on sim - there is no /proc/{hal,rtapi}
[23:59:38] <alex_joni> I notice there's a missing EMC_TRAJ_LINEAR_MOVE there
[23:59:44] <SWPLinux> indeed
[23:59:46] <alex_joni> bet that one looks at the current vel