Back
[08:51:05] <skunkworks> jepler, ran from Wednesday.. no problems. Going to update now
[08:52:47] <skunkworks> wondering if some of the problems I was having was with the power supply
[08:53:07] <skunkworks> I think it was a phone charger - 5v 1a
[09:39:41] <CaptHindsight> might be old news here but
https://lists.debian.org/debian-devel-announce/2016/05/msg00001.html
[09:39:53] <CaptHindsight> Debian i386 architecture now requires a 686-class processor
[09:41:59] <jepler> I think our requirement of a working APIC in practice already excluded all those systems already
[09:50:42] <pcw_home> running on 20+ year old PCs doesn't seem like much fun anyway
[10:02:16] <seb_kuzminsky> hey now, stop poking fun at cradek
[10:02:40] <cradek> :-P
[10:05:08] <jepler> I think the machine he really wishes he could decommission is a P3 at least
[10:05:29] <cradek> yeah I think it's a P3-700
[10:05:41] <cradek> probably at most 15 years old
[10:11:36] <skunkworks> hmm - the 'set' coil doesn't stay blue when the rung goes off. A bit unnerving.. but the contact referencing the coil does stay on.
[10:13:18] <archivist> my 5 axis has a Compaq Deskpro from 1998
[10:14:21] <cradek> is that also P3?
[10:16:18] <archivist> dunno what the processor is, I know it lacks memory
[10:16:32] <cradek> yeah that's the usual problem
[10:16:46] <skunkworks> I had recently used a deskpro for a control.. (within the last 2 years)
[10:16:50] <cradek> processors have been "fast enough" for a few decades now
[10:16:54] <skunkworks> I pretty sure it was a P3
[10:17:55] <archivist> but the upgrading hardware gravy train is too expensive for me
[10:19:34] <jepler> cradek: did you ever decide whether we would issue a last 2.5 release before letting seb_kuzminsky turn off the lucid buildslave?
[10:19:42] <jepler> er, hardy ?
[10:20:13] <cradek> oh right, he even did work to let me do that, and then I forgot again
[11:15:09] <seb_kuzminsky> saying "no more 2.5 releases" is a valid way forwards ;-)
[11:15:18] <seb_kuzminsky> jepler: thanks for the feedback on task_plan_synch
[11:15:23] <seb_kuzminsky> looked that way to me too
[12:34:41] * skunkworks_ hugs linuxcnc
[12:59:22] <seb_kuzminsky> http://static1.squarespace.com/static/52d4acc0e4b086fdf73bb33b/t/54c733e0e4b0c1586e20bb64/1422341090448/
[13:08:26] <skunkworks_> PCW, do you have a current pid stepper config with dpll?
[13:14:07] <pcw_home> I think the 7I92 config is pretty close
[13:15:43] <pcw_home> http://freeby.mesanet.com/7i92step.zip
[13:19:48] <skunkworks_> (this is for a 7i92 - thanks!_
[13:20:21] <skunkworks_> that works better. the config that I had been using didn't work well with this laptop.
[13:23:38] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 48adf09 06linuxcnc 10src/emc/motion/command.c command.c fix unexpected conditions test JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=48adf09
[13:31:37] <seb_kuzminsky> i'm getting pretty excited for ja
[13:48:39] <skunkworks_> I still have to test it again - the issue I was having on the K&T was jogwheel jogging was causing following errors
[13:49:07] <skunkworks_> but that was a month or 2 ago and I never tried deweys suggestions..
[13:51:41] <pcw_home> Did I read correctly that the JA branch has provisions for linked axis homing?
[14:01:43] <jepler> I think it's in this branch, which builds on ja13: origin/ja13-teleop-after-homing
[14:01:52] <jepler> er not that one
[14:03:25] <jepler> maybe it is on the latest ja branch
[14:03:33] <jepler> 55b81ce7abb5 documents it, is on branch joints/axes13
[14:48:58] <seb_kuzminsky> ja13-teleop-after-homing just makes the machine switch automatically to world mode as soon as it's finished homing
[14:49:37] <seb_kuzminsky> i think now that we have incremental world-mode jogging and jogwheel world-mode jogging, there's no reason to stay in joint mode other than for homing
[15:49:08] <JT-Shop> and getting out of a jam, setting up a machine, testing...
[15:51:09] <JT-Shop> and I'm too poor to afford home switches so I have to jog everything to match marks
[16:01:12] <seb_kuzminsky> true...
[16:01:45] <seb_kuzminsky> in my proposal joint mode is still available, it's just not the default mode for a homed machine any more
[16:02:13] <jepler> oh I'm slowly decoding "I'm too poor..." into sarcasm
[16:02:22] <seb_kuzminsky> hmm
[16:02:56] <jepler> god help me, I just spent over $150 on a keyboard
[16:03:21] <seb_kuzminsky> we have a gantry machine at the local hackspace, two joints on the Y axis. near the Y home switches there's a number of scars from everyone homing, then jogging and racking the gantry (because they forgot to switch to world mode)
[16:03:49] <JT-Shop> and ja13 takes care of that nicely
[16:04:06] <seb_kuzminsky> it does?
[16:04:13] <seb_kuzminsky> i mean: i don't think it does.
[16:04:33] <seb_kuzminsky> i just built ja13 on that machine the other day, and it still stayed in joint mode after homing
[16:04:48] <JT-Shop> yep you go right into world after a home all
[16:05:06] <seb_kuzminsky> on a non-identity-kins machine?
[16:05:06] <JT-Shop> I've not tried homing axis by axis
[16:05:16] <JT-Shop> translate please
[16:05:48] <seb_kuzminsky> did you observe that behavior on a machine without a simple 1-to-1 mapping between joints & axes?
[16:06:01] <seb_kuzminsky> on the gantry machine i have, it does not do that
[16:06:10] <seb_kuzminsky> after a Home All (in Axis) it stays in joint mode
[16:06:51] <JT-Shop> I have joint 0 = X axis, joint 1 and joint 2 = Y axis and joint 4 = Z axis
[16:07:05] <jepler> which UI program are you each using?
[16:07:11] <seb_kuzminsky> i use axis
[16:07:18] <JT-Shop> so no I have not tried a regular xyz configuration
[16:07:20] <JT-Shop> axis
[16:07:47] <seb_kuzminsky> http://s2.quickmeme.com/img/aa/aadcd968fbae17016d14456cdad396dabc7fa92909fbd87033640b226a20a760.jpg
[16:09:57] <KGB-linuxcnc> 03Jeff Epler 05joints_axes13 d66f09b 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis: restore exponential backoff when waiting for s.axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d66f09b
[16:11:48] <seb_kuzminsky> JT-Shop: which commit are you on?
[16:11:49] <jepler> with ja13 at the ref I just pushed, I started configs/sim/gantry.ini and did F1 F2 ctrl-home
[16:11:57] <jepler> my DRO continues showing joints
[16:12:57] <jepler> and pressing up-arrow changes joint 1 and not joint 3, so I think I've "virtually racked" my machine
[16:13:12] <seb_kuzminsky> that's the behavior i observed with 9b231b8aaef, last tuesday, on the XYZY gantry machine i have
[16:13:24] <jepler> huh and I have this on the terminal, wonder what it is..
[16:13:24] <jepler> TCL error in asynchronous code:
[16:13:24] <jepler> invalid command name "35988256<lambda>"
[16:13:27] <JT-JA13> 6da3928
[16:14:39] <seb_kuzminsky> i don't have that commit
[16:14:41] <seb_kuzminsky> and i just fetched
[16:15:36] <jepler> $ git show 6da3928 --
[16:15:37] <jepler> fatal: bad revision '6da3928'
[16:15:39] <jepler> me either
[16:15:59] <JT-JA13> I'm not exactly sure how to get the last commit number
[16:16:05] <JT-JA13> I got that from gitk
[16:16:30] <seb_kuzminsky> git show will tell you
[16:17:41] <seb_kuzminsky> jepler: are you on stretch? i get tclish errors there
[16:17:49] <jepler> seb_kuzminsky: nah, wheezy
[16:18:04] <seb_kuzminsky> chicken
[16:18:08] <jepler> the stretch tclish error I'm aware of pertains to selecting axis/joint 1
[16:18:10] <JT-JA13> commit d8c891a7dfef2998cfe11af5f60af4ecd6da3928
[16:18:28] <jepler> ah that ref is known to me
[16:18:42] <JT-JA13> I think I'm one behind
[16:18:46] <seb_kuzminsky> yeah, that's near the tip of ja13
[16:18:48] <jepler> if you are going to show just part of a ref, it's the leading part you want
[16:18:49] <seb_kuzminsky> strange!!
[16:18:51] <JT-JA13> seb_kuzminsky: did you set the ini option?
[16:19:10] <seb_kuzminsky> no
[16:19:14] <seb_kuzminsky> what ini option?
[16:19:21] * seb_kuzminsky is out of touch
[16:19:22] <JT-JA13> [KINS]
[16:19:26] <JT-JA13> AUTO_TELEOP=20
[16:19:32] <seb_kuzminsky> ffs
[16:19:46] <jepler> docs/src/config/ini-config.txt:* 'AUTO_TELEOP = 20' - (Axis gui) Switch to teleop mode after successful
[16:19:50] <jepler> even documented apparently
[16:19:56] <JT-JA13> just tested on an XYZ machine and works as expected
[16:20:30] <jepler> .. specific to AXIS apparently, while I think seb's is more generic
[16:20:55] <JT-JA13> I've only tested Axis
[16:21:30] <seb_kuzminsky> 706bcb326776bf844681daabcfb35ebff5abb5cb
[16:21:41] <seb_kuzminsky> 27 files changed, 932 insertions(+), 660 deletions(-)
[16:21:57] <seb_kuzminsky> i'm not going to feel too bad about not knowing this
[16:22:04] <seb_kuzminsky> and i'm going to claim that my solution is better
[16:22:39] <seb_kuzminsky> implemented in Motion, in 3 lines (+3 lines of comments): f0b1089528025036d226b97ae1c06449bd5f60aa
[16:22:46] <seb_kuzminsky> works for all UIs
[16:23:40] <seb_kuzminsky> bbl
[16:23:43] <jepler> see ya
[16:24:33] <JT-Shop> I need to push my latency-launcher branch for a look see... I have almost everything working
[16:25:29] <JT-Shop> except when you build a RIP and type in latency I get command not found even though the file is in the bin directory and it is executable
[16:36:03] <jepler> in what way does it work, then?
[16:36:34] <JT-Shop> I can do ./latency in the bin directory
[16:36:42] <JT-Shop> and it runs
[16:37:15] <JT-Shop> which has me slightly puzzled
[16:37:30] <jepler> what you're saying is indeed surprising
[16:38:24] <JT-Shop> and after running make I did sudo make setuid
[16:39:49] <jepler> if you push it to a fresh branch and ping me I'll take a look and see if I can figure it out
[16:40:10] <JT-Shop> ok thanks
[17:45:05] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 8fef1b4 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_lathe.ini 10configs/sim/gmoccapy/gmoccapy_lathe_imperial.ini 10configs/sim/gmoccapy/gmoccapy_postgui.hal gmoccapy lathe sim configs revert 2joint xz JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8fef1b4
[17:45:05] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 0b86428 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt updating-linuxcnc.txt add info for gui updates JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0b86428
[17:49:29] <dgarr> if you decide to switch to teleop in motion, it trust that you will also fix jogging in all the guis it breaks
[17:49:46] <dgarr> fixing guis one at a time would allow a sooner merge and better decisions on retaining guis (imo)
[17:50:10] <seb_kuzminsky> are there guis that won't deal properly with the teleop/joint mode changing?
[17:50:26] <seb_kuzminsky> how do they handle things like halui changing the mode on them?
[17:50:56] <dgarr> most of them are hardcoded to joint jog, most don't handle halui changes, read the docs updated by the last commit
[17:51:15] <seb_kuzminsky> well that's a bummer
[17:51:35] <seb_kuzminsky> joint jogging is totally the wrong thing to do on non-identity-kins machines like gantries
[17:51:36] <dgarr> i am not inclined to fix them and when i recommend deleting them someone complains
[17:52:54] <dgarr> i fixed/updated in axis,tklinuxcnc,mini, linuxcncrsh -- someone elses turn or do like axis and let each gui designer support [KINS]AUTO_TELEOP
[17:54:15] <dgarr> or whats another 8 years to wait for someone to fix keystick?
[17:54:41] <seb_kuzminsky> so axis watches for all joints to home, then waits 20 seconds (or whatever [KINS]AUTO_TELEOP says), then switches to teleop?
[17:54:52] <seb_kuzminsky> (i haven't read your axis patches)
[17:55:23] <jepler> it waits for all axes to home, but gives up after 20 seconds
[17:55:30] <jepler> (20 seconds from when? I don't know)
[17:55:56] <dgarr> it has been done and documented for a long time, timimg starts at Home-all
[17:57:09] <dgarr> i've been working with pkmcnc (hexapods) and have supportive reports on the implementation on real hardware
[17:58:07] <seb_kuzminsky> hexapods sure benefit from that kind of feature
[18:00:02] <dgarr> hexapods also benefit from the synchronization of the last homing move (tested) and calibration using new ini hal pins for HOME_OFFSET (also tested)
[18:00:15] <seb_kuzminsky> i love those parts
[18:01:37] <dgarr> i've tried to keep docs/src/getting-started/updating-linuxcnc.txt updated -- too bad noone bothers to read it
[18:02:13] <jthornton> they will
[18:04:19] <dgarr> switching-to-teleop-in-motion is ideal but sometimes perfect is the enemy of good, unless you want to update guis that 1)you didn't write, 2)nobody uses
[18:04:31] <jthornton> is this the correct gnu
http://paste.ubuntu.com/16326393/
[18:04:55] <PCW> jepler: the stepgen seems ok with even 5% or so packet loss with your latest patch!
[18:04:57] <PCW> (I did set the error limit to 50 so you need a pretty bad burst of errors to exceed this)
[18:05:10] <jepler> PCW: 5%? wow that's far more than I imagined handling
[18:05:27] <jepler> this is physically induced noise?
[18:06:06] <seb_kuzminsky> dgarr: help me understand the changes you've made to ja, and the changes that are still remaining to support teleop-after-homing-in-motion
[18:06:30] <PCW> No just RX timeouts generated by setting the receive timeout very low
[18:06:37] <jepler> ah
[18:06:42] <seb_kuzminsky> is it just that all guis need to detect the teleop/free mode and put the right arguments in the jog nml command to task?
[18:07:02] <dgarr> why don't you try the sims and see for yourself
[18:07:24] <seb_kuzminsky> ok thanks
[18:08:13] <jepler> most of the UIs are based on Python and the "emcmodule", too bad I never wrote documentation for it or we could update it with the new practice that is required in UIs
[18:08:41] <andypugh> jepler: Not too late to finish the job you started :-)
