Back
[08:33:46] <skunkworks_> zlog
[08:53:02] <KGB-linuxcnc> 03Norbert Schechner 05master 34adff7 06linuxcnc 10docs/src/gui/gmoccapy.txt docs - gmoccapy - minor changes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=34adff7
[08:53:02] <KGB-linuxcnc> 03Norbert Schechner 05master 2e61e5e 06linuxcnc Merge branch 'master' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2e61e5e
[08:53:02] <KGB-linuxcnc> 03Norbert Schechner 05master 02d8980 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_2_1_6_3 - release number change, due to init_glcanondraw() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=02d8980
[10:03:10] <skunkworks> http://pastebin.com/CKCY9kfc
[10:03:37] <skunkworks> this is the current iteration of master. (converted one of my configs)
[10:06:33] <skunkworks> this is the result after homing..
[10:06:36] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot-41.png
[10:06:49] <skunkworks> notice Z axis velocity
[10:07:24] <skunkworks> I don't see anything wrong in the ini..
[10:08:31] <cradek> yeah since it's trivkins I'd expect homing Z to honor [JOINT_2] MAX_VELOCITY
[10:09:37] <cradek> are you watching a pin that might have a step change when homing ends?
[10:09:46] <cradek> no, that would mess up the ACC too if you're using a chain of ddts
[10:10:24] <cradek> might want to scope it anyway to be sure of when it happens (maybe also scope the homing state pin)
[10:10:31] <skunkworks_> unless a thread order changed in the conversion?
[10:10:33] <skunkworks_> ok
[10:10:52] <cradek> also check twice to make sure you're running the config you think you are
[10:11:37] <skunkworks> 99% sure - only one I converted to master on this machine
[10:19:49] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot-42.png
[10:22:22] <cradek> wow, wonder how fast it would go! only the last one in state 11 gets capped.
[10:23:29] <skunkworks_> That is joint velocity - So I don't think it is a thread order issue
[10:24:25] <skunkworks_> this all started with
http://forum.linuxcnc.org/10-advanced-configuration/27368-new-trajectory-planner-testers-programs-wanted?start=220#83998
[10:25:56] <cradek> I know rob notices our github bug reports
[10:26:10] <cradek> although I wonder if it's even his problem
[10:26:19] <cradek> I think homing doesn't use that planner
[10:26:21] <cradek> hmm
[10:26:38] <skunkworks_> I have not seen this behavior in 2.7...
[10:29:35] <skunkworks_> This config homes correctly before conversion to master
[10:29:50] <skunkworks_> the config will not re-home in master either.
[10:31:31] <skunkworks_> never mind - it won't rehome in 2.7 unless you move it.
[10:53:15] <skunkworks> 2.7
http://electronicsam.com/images/KandT/testing/Screenshot-44.png
[10:55:00] <skunkworks_> I have not gotten an error like on the forum during coordinated motion yet.. He says he got a following error - I wonder if the 'not following the arc happens after the following error. (as the axis slow to a stop._
[10:55:35] <skunkworks_> I still have to hack his config though.
[10:55:45] <skunkworks_> could be config specific
[12:59:16] <skunkworks> not seeing what he is on the fourm
[12:59:24] <skunkworks> forum
[12:59:35] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot-45.png
[12:59:46] <skunkworks> his ini with my sim hal-ness
[13:14:19] <skunkworks> does this make sense?
https://forum.linuxcnc.org/10-advanced-configuration/27368-new-trajectory-planner-testers-programs-wanted?start=230
[13:37:35] <cradek> I'd also expect coasting down, after an ferror during an arc, to jump off tangent to the arc
[13:45:06] <skunkworks_> right
[13:45:31] <cradek> so of course the question is: why the ferror
[13:51:18] <skunkworks_> right
[13:52:57] <skunkworks_> the thread orders look right
[13:53:03] <skunkworks_> he says it is the same spot..
[14:12:40] <skunkworks_> SO - you can't trigger on a program line in halscope?
[14:13:05] <cradek> sure why not?
[14:14:39] <skunkworks_> I have it set to rising source 1 (motion.program-line)
[14:15:40] <skunkworks_> oh - wait - what is the difference between normal and auto trigger?
[14:15:57] <skunkworks_> that did it - I had it on auto
[14:19:54] <pcw_mesa> Is it possibly a stepgen problem? (the HM2 and perhaps other hardware stepgen drivers "get lost" if you have large servo thread latency)
[14:19:56] <pcw_mesa> having Axis backplot the commanded position rather than the feedback position would isolate the TP from tuning issues
[14:21:47] <skunkworks_> pcw_mesa, the x and yy are servos - z is stepper
[14:23:22] <pcw_mesa> but the Axis backplot defaults to feedback position so you cant tell a tuning issue from a TP issue
[14:23:42] <skunkworks_> oh - right
[14:25:41] <pcw_mesa> you will still get a FE, but if you get a FE and the commanded position plot is OK , its a tuning issue
[14:25:43] <pcw_mesa> so looking at the commanded position plot would help isolate the cause
[14:28:16] <skunkworks> it supposedly ferrors around line 35/36 but I don't see it here - it certainly peaks the acceleration quite often.
[14:28:18] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot-47.png
[14:33:07] <andypugh> So, I have figured out that this problem exists with the boring cycle with stock Touchy or modified Touchy
[14:33:49] <andypugh> I can run the other cycles, they work, but boring makes the whole machine unresponsive. (including unresponsive to jogwheels hooked up to motion)
[14:33:55] <andypugh> https://www.youtube.com/watch?v=8WuBO2Z1UTw
[14:36:00] <andypugh> The boring cycle: (
http://pastebin.com/9CPL5RuU ) gets as far as the toolchange, so at least that part is working.
[14:36:28] <andypugh> But, the spindle does not start.
[14:39:07] <andypugh> I guess it’s time to scatter the G-code with (debug,)s
[14:44:22] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/home_vclamp 716b214 06linuxcnc 10src/emc/motion/homing.c homing.c search,latch: honor [JOINT_n]MAX_VELOCITY * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=716b214
[14:44:28] <dgarr> skunkworks: i believe you homing plot identifies a separate problem where homing velocities can exceed [JOINT_N]MAX_VELOCITY. Can you test this branch (based on master/ja)?
[14:46:18] <skunkworks_> dgarr, awesome! I will test it asap
[14:46:37] <dgarr> thanks -- i will read back this evening
[14:47:35] <cradek> he's a wizard
[14:54:37] <cradek> (gosh that's an old mistake)
[14:54:48] <andypugh> cradek: Did you see my puzzling video?
[14:55:40] <cradek> nope
[14:56:02] <cradek> does task crash?
[14:56:12] <andypugh> Not sure how to tell?
[14:56:14] <cradek> anything on stdout or stderr or dmesg?
[14:56:56] <andypugh> Nothing at all unusual on dmesg
[14:57:04] <andypugh> Nor stdout
[14:57:12] <cradek> hmm
[14:57:23] <andypugh> Where is stderr?
[14:58:17] <skunkworks> dgarr: Fixes the problem here
http://electronicsam.com/images/KandT/testing/Screenshot-48.png
[15:01:21] <andypugh> cradek: At the moment the python handler for the embedded tab emits a “click” event for the (invisible) MDI action. I wonder if there is value in calling the routines a different way? I did it that way because it (in theory) allows other people to add tabs using only Glade.
[15:01:24] <skunkworks_> dgarr: I don't think the forum problem is a TP problem.. (atleast that is my feeling)
[15:13:21] <skunkworks_> hmm - they are steppers with encoders.
[15:13:34] <skunkworks_> pcw_mesa, do the pid parameters look ok for that?
[15:14:27] <skunkworks> P = 170
[15:14:27] <skunkworks> I = 0
[15:14:27] <skunkworks> D = 0
[15:14:27] <skunkworks> FF0 = 0
[15:14:27] <skunkworks> FF1 = 0.994
[15:14:28] <skunkworks> FF2 = 0.000025
[15:14:30] <skunkworks> BIAS = 0
[15:14:32] <skunkworks> DEADBAND = 0.003
[15:14:34] <skunkworks> MAX_OUTPUT = 0
[15:20:17] <andypugh> cradek: Any suggestions on how to tell the status of Task?
[15:31:02] <pcw_mesa> with closed loop system its hard to tell (looks about right though)
[15:41:05] <andypugh> cradek: Well, something is clearly wrong. I ran “linuxcnc -l > linuxcnc.txt” homed the machine, and ran the boring cycle. I then repeated with the facing cycle into linuxcnc2.txt. Both with DEBUG=7FFFFFFF
http://www.pastebin.ca/3747384
[15:49:25] <andypugh> I think I see the problem. The cut is zero. So it it making an infinite number of zero-length spindle-synched moves. I am_fairly_ sure that the cut isn’t zero in the GUI, though.
[15:53:18] <andypugh> Well, I was wrong. The cut _was_ zero. I feel rather foolish. I have wasted three evenings of my own time and lots of your time on this.
[16:53:20] <cradek> andypugh: yay! Glad you found it!
[17:49:37] <andypugh> Yes, and I am glad it is a bug with the operator and not LinuxCNC
[21:36:47] <KGB-linuxcnc> 03Dewey Garrett 05master dc2ff49 06linuxcnc 10src/emc/motion/homing.c homing.c search,latch: honor [JOINT_n]MAX_VELOCITY * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dc2ff49
[21:37:34] <KGB-linuxcnc> 05dgarr/home_vclamp 716b214 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=716b214
[21:38:19] <cradek> if you program a zero and get a hung linuxcnc instead of an error message, that's a linuxcnc bug!
