#linuxcnc-devel | Logs for 2015-09-27

Back
[00:10:05] <skunksleep> He posted some plots. http://www.linuxcnc.org/index.php/english/forum/20-g-code/29685-g76-pause-in-z-during-exit-taper-linux-cnc-270#63040
[07:54:41] <jepler> well those certainly do look wrong
[07:57:20] <jepler> there's wrong at the start too, with zvel overshooting (?) and then spending the whole threading cycle catching up
[07:57:26] <jepler> > Oh, I have also noticed the occasional uncommanded axis move when moving the other axis - roughly of the order of magnitude of the backlash compensation - wonder if this has any relation. I suspect not much testing is done with backlash compensation values of other than zero. Related??
[07:57:44] <jepler> I certainly haven't been testing with any backlash. this could be relevant.
[07:58:23] <jepler> I dunno offhand if joint-vel-cmd would include any contribution from backlash compensation
[07:58:47] <jepler> I can't be bothered to log in to the forum to get the attached config
[07:58:54] <jepler> stupid forums (yes I know it's ours)
[08:23:39] <skunkworks> heh
[08:24:02] <skunkworks> I added backlash to the sim config and didn't see the issue.
[08:24:08] <skunkworks> I posted some more questions..
[08:24:51] <skunkworks> jepler: I could email it to you
[08:25:07] <skunkworks> I probably not going to have time to hack into it and make it run in sim
[08:25:15] <skunkworks> until later atleast
[08:26:37] <skunkworks> emailed
[08:40:03] <archivist> that log in to get attachments is so closed rather than open, needs a volunteer to fix that
[08:41:30] <jepler> I think that forum software does it with the best of intensions -- so that the forum can't be used to e.g., distribute malware linked from e-mail, since it won't work for almost all recipients of the spam
[08:42:27] <jepler> intention :-P
[08:43:29] <archivist> for adding the attachment yes
[08:47:43] <jepler> yeah that config needs work before it'll run without attached hardwrae
[08:50:27] <jepler> it has 1/20th the acceleration of sim lathes
[09:04:27] <jepler> I've still failed to reproduce it, but his plots of Zvel show that something crazy is going on in the threading cycle, and it's starting even before the part the poster noticed with the weird Z velocity profile all through the plot
[09:06:33] <archivist> way back in the days of me trying out threading I had some hunting/z speed variation that cradek traced and updated
[09:07:58] <archivist> does the user have a low count encoder?
[09:09:45] <jepler> > Homemade 60ppr spindle encoder for spindle RPM.
[09:09:46] <jepler> yeah pretty low
[09:09:56] <jepler> but if it worked in 2.6 you'd want it to work as well in 2.7.
[09:20:50] <jepler> on top of all my other changes I reduced the spindle to 15cpr quadrature (60 counts per revolution) and that gets me a velocity plot that looks more like his 2.6 plot than anything I've seen so far
[09:21:01] <jepler> also copying inifile velocities and accelerations
[09:25:21] <jepler> now reproduced http://emergent.unpythonic.net/files/sandbox/thread-glitch-reproduced.png
[09:30:40] <skunkworks> and that doesnt happen in 2.6?
[10:08:49] <jepler> I haven't testd 2.6..
[10:10:44] <pcw_home> skunksleep: do you have a stock 2.7 installation? Wondering if it has the latest mesaflash that works with the 7I92
[10:11:19] <pcw_home> ( earlier versions had a typo in the FPGA name )
[10:12:17] <jepler> OK, config files and minimized ngc file to reproduce the forum bug report: http://emergent.unpythonic.net/files/sandbox/0001-config-and-ngc-to-reproduce-bug-report-by-verticalpe.patch
[10:12:52] <jepler> low spindle ppr causes the weird ramping at the start of the spindle synch move, but is the same in 2.6 and 2.7 by his plots
[10:13:02] <pcw_home> is that bug backlash related?
[10:13:28] <jepler> not sure yet, I didn't try with just the vels and accels but not the backlash
[10:13:31] <jepler> will check
[10:14:14] <jepler> taking out backlash does not fix the scope plot
[10:14:48] <jepler> patch updated
[10:18:10] <jepler> patch update utterly botched
[10:19:28] <KGB-linuxcnc> 03Jeff Epler 052.6 ef90426 06linuxcnc 10src/hal/components/toggle2nist.comp toggle2nist: does not require floating-point * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ef90426
[10:19:28] <jepler> patch re-updated
[10:21:17] <jepler> my 2.6 and 2.7 plots look essentially like the user's 2.6 and 2.7 plots respectively
[10:21:28] <jepler> the patch applies to 2.6 and 2.7 for testing in either version
[10:29:45] <jepler> (personally I think the 2.7 z velocity plot looks fishy and is probably due to very low acceleration rates, but the OP was happy with it in 2.6 so..)
[10:32:57] <jepler> er, the 2.6 z velocity plot looks fishy
[12:52:42] <micges> seb_kuzminsky: mesaflash 3.2.0 ready for packaging
[12:53:16] <micges> seb_kuzminsky: master branch
[13:00:03] <Tom_itx> what was added?
[13:00:17] <Tom_itx> mebbe i should grab it
[13:01:28] <micges> nothing new, just prepared for packaging
[13:01:45] <Tom_itx> k
[13:01:51] <micges> you;ve already used all new stuff from it
[14:01:55] <skunkworks> cradek: any thoughts on the threading issue?
[14:03:55] <pcw_home> skunkworks: whats difference between your latest sane looking plots and the glitchy ones?
[14:06:16] <cradek> I haven't looked at any of it. is 2.7 worse than 2.6?
[14:08:35] <jepler> cradek: yes
[14:08:48] <cradek> heck
[14:09:25] <jepler> the latest thing I have noticed is that the F-number affects the shape of the Z velocity weirdness
[14:09:48] <jepler> but an F-number shouldn't have any effect in a G33 .. should it?
[14:09:50] <cradek> well that ain't right
[14:09:57] <cradek> yeah, shouldn't
[14:11:38] <jepler> if you remove or comment out the line "G1 F1" the weirdness goes away. If you remove just "G1" it stays.
[14:12:16] <cradek> does rob know?
[14:13:58] <jepler> not from me
[14:16:26] <cradek> I am pretty sure the new planner uses the old planner for spindle-sync and other tricky things like combined rotary axis moves, so if there's any difference it's being fed wrong somehow
[14:24:29] <jepler> anyway, it also looks like programming F0 before G33/G76 might be tried as a workaround
[14:35:39] <cradek> that sounds like a good clue
[14:41:34] <pcw_home> should I suggest F0 on the forum?
[14:48:42] <skunksleep> We noticed f interaction when Chris and Jeff were down. Rob fixed it at that point. (It would cap the synced move to the current feedrate)
[14:49:14] <skunksleep> jepler: good find
[14:49:29] <skunksleep> I have not emailed rob yet
[15:13:00] <skunksleep> zlog
[15:16:01] <skunksleep> Posted on the forum and emailed rob
[15:18:52] <skunksleep> pcw_home: when I configured the 7i92 I used the mesaflssh from micges repository. The one from linuxcnc didn't work iirc
[15:20:14] <pcw_home> I though it had been updated for the 2.7 release
[15:33:47] <andypugh> Does anything log the program line that a f-error happens at?
[15:34:01] <andypugh> (or the program stops for any other reason)
[15:34:52] <pcw_home> logging the peak ferror might be nice also
[15:36:43] <andypugh> It would make it easier to find out where or how to re-start the machining.
[15:41:36] <skunksleep> Sticky way?
[15:44:14] <andypugh> Not sure, it’s a switched-axis config and I think it might be mis-tuned. Though it was working