Back
[00:10:22] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #96: Part of the problem of this issue is that Axis switches to Teleop mode at a time when Motion is on a Joint soft limit. This causes the never-ending NML-issue-storm in Task. Inhibiting the switch to Teleop avoids the issue-storm.... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-232858552
[00:18:10] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #76: No, i only did the fun easy part. I still have to do the tedious bits:... 02
https://github.com/LinuxCNC/linuxcnc/issues/76#issuecomment-232859241
[00:18:45] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #76: No, i only did the fun easy part. I still have to do the tedious bits:... 02
https://github.com/LinuxCNC/linuxcnc/issues/76#issuecomment-232859241
[00:23:48] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #91: @ikcalB Is the lack of this functionality in 2.6 a problem for you or anyone you know of? 02
https://github.com/LinuxCNC/linuxcnc/pull/91#issuecomment-232859732
[06:28:39] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc commented on issue #96: For identity-kins machines it's possible to avoid this situation completely. I see two options: ... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-232923145
[06:29:09] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc commented on issue #96: For identity-kins machines it's possible to avoid this situation completely. I see two options: ... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-232923145
[06:37:22] <KGB-linuxcnc> 03John Thornton 052.7 aee5df1 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt Docs: add info about updating * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=aee5df1
[06:37:37] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc commented on issue #96: For identity-kins machines it's possible to avoid this situation completely. I see two options: ... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-232923145
[07:02:14] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc commented on issue #96: For identity-kins machines it's possible to avoid this situation completely. I see two options: ... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-232923145
[07:07:13] <jepler> well last night I found several variations of "make threads exit at shutdown" but that was by *not* using pthread_cancel, but by simply using a cancel flag that is checked at the place pthread_testcancel is now
[07:08:05] <jepler> so I should probably make that change (pthread_testcancel -> if(task->cancel) pthread_exit(nullptr), and similar in Posix::task_delete)
[07:14:40] <jepler> hm debian has a security update for php today, but none in the ubuntu that runs the forum yet .. unless they got theirs out a week ago, the last time I updated it?
[07:16:19] <jepler> .. nope
[07:16:26] <jepler> well now I'll just worry
[09:36:33] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #96: The idea of ignoring joint limits on id-kins machines feels strange after everyone worked so hard on the JA branch to create them, but maybe doing so simplifies things for (most) users. ... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-232960557
[10:52:06] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc commented on issue #96: Oh, the validation is pretty simple, and it can be skipped for inihal changes as long as the machine behaves more or less normally when the limits break.... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-232983228
[10:54:41] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc commented on issue #96: Oh, the validation is pretty simple, and it can be skipped for inihal changes as long as the machine behaves more or less normally when the limits break.... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-232983228
[11:38:17] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #111: Teach Interp to reject arcs that reach outside the axis soft limits 02
https://github.com/LinuxCNC/linuxcnc/issues/111
[11:39:39] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #111: I think this is a duplicate of #80. Close if you agree. 02
https://github.com/LinuxCNC/linuxcnc/issues/111#issuecomment-232996414
[11:39:49] <cradek> > The extents of the arc are easy to determine
[11:39:52] <cradek> [citation needed]
[11:52:26] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #96: How's this sound for a design:... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-232999620
[11:54:07] <seb_kuzminsky> cradek: am i missing something there? arc-center +/- radius, or arc endpoints if that's less restrictive
[11:54:29] <seb_kuzminsky> err, modulo P
[11:54:52] <archivist> the rotation
[11:55:23] <cradek> how do you know which of the 4 +- directions to check?
[11:55:33] <seb_kuzminsky> archivist: right, coordinate system rotation affects all this
[11:56:06] <seb_kuzminsky> cradek: i think i'd want to determine the bounding box of the arc, and make sure *it* fits in the axis soft limits
[11:56:19] <seb_kuzminsky> since we have cuboid soft limits that should do it
[11:56:27] <cradek> no, that will throw out a lot of perfectly fine arcs
[11:56:37] <archivist> and bums like me that hang a rotary off to the side and spin it for large arcs :)
[11:56:38] <cradek> any cam software generates huge-radius arcs that look kinda like straight lines
[11:56:55] <cradek> you would disallow all of those
[11:57:13] <seb_kuzminsky> but the endpoints of those huge arcs make the bounding box small, and make it fit inside the soft limits
[11:57:31] <cradek> ok I guess I don't know what you mean by bounding box
[11:58:00] <cradek> (I thought you meant center +- radius along both axes)
[11:58:03] <seb_kuzminsky> the box that contains the programmed arc, including considering the start & end points
[11:58:08] <seb_kuzminsky> like in this picture:
http://stackoverflow.com/questions/32365479/formula-to-calculate-bounding-coordinates-of-an-arc-in-space
[11:58:21] <cradek> ok sure! but that'll be hard.
[11:58:36] <seb_kuzminsky> hmm
[11:59:16] <cradek> I agree that's the right solution! I disagree it's easy.
[11:59:32] <seb_kuzminsky> you've thought much more about this than i, so i believe you that there are difficulties i'm neglecting
[11:59:38] <cradek> please prove me wrong and I will try to break it for you
[11:59:38] <seb_kuzminsky> i'll ponder while getting a coffee
[12:01:02] <cradek> I should look at the arc representation at that level and then get coffee too
[12:04:15] <cradek> //FIXME: there was limit checking tests below, see if they were needed
[12:04:17] <cradek> umm
[12:04:21] <cradek> so ... we removed all that?
[12:05:28] <cradek> looking at checkInterpList()
[12:07:59] <jepler> if so I bet it was before any of "us" were here
[12:08:06] <jepler> but who knows!
[12:10:45] <cradek> the turn tells you which way to walk around the quadrants and consider them. you have initial and final directions (just rotate the radial vectors). maybe it's not so hard.
[12:11:19] <cradek> once you've found that you've considered 4, you can go ahead and stop
[12:11:38] <jepler> getting the right axis-aligned quadrants under rotation seems like the main trick then?
[12:12:00] <cradek> you have to check the perpendicular direction too, which it also never did
[12:12:21] <jepler> did you find this old and now-deleted implementation, or are you brainstorming a fresh implementation?
[12:12:31] <cradek> yeah I think the hard part is finding which quadrants to consider
[12:12:43] <cradek> fresh
[12:12:55] <cradek> the old one didn't do much
[12:13:55] <cradek> it's nice that you have final arc representation at this stage, not r/ijk
[12:27:11] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky closed issue #111: Teach Interp to reject arcs that reach outside the axis soft limits 02
https://github.com/LinuxCNC/linuxcnc/issues/111
[12:27:34] <seb_kuzminsky> thanks for pointing out #80 jepler
[12:28:56] <seb_kuzminsky> http://mathoverflow.net/questions/93659/find-the-bounding-box-of-a-circle-segment/93934#93934
[12:29:39] <seb_kuzminsky> all soft limit checks have to happen in G53, right? so by this time we've undone any coordinate system translation & rotation
[12:29:44] <jepler> side(?) question: if we decided to implement cylindrical work volumes (which is probably a dandy idea) this gets harder again doesn't it
[12:30:42] <seb_kuzminsky> it certainly changes
[12:30:46] <cradek> seb_kuzminsky: at this level you don't have to worry about any of that. in fact maybe rotation is already taken care of?
[12:30:55] <seb_kuzminsky> cradek: i think it must be
[12:31:08] <seb_kuzminsky> jepler: why is cylindrical work volumes desirable?
[12:31:13] <seb_kuzminsky> *are
[12:31:31] <cradek> robots are more cylindrical than rectangular
[12:31:37] <jepler> seb_kuzminsky: it was mentioned on another of these issues. they certainly describe the work volume of a linear delta, and may be more appropriate for hexapods too
[12:32:03] <jepler> no code's written afaik
[12:32:04] <cradek> well describe more closely a linear delta anyway
[12:32:20] <seb_kuzminsky> i can see an argument for trying to supporting different-shaped work volumes for different kins, maybe that's what we're talking about?
[12:33:14] <seb_kuzminsky> maybe the kins would supply a plugin to Interp as well as to Motion, and the interp part would do axis (and joint?) soft-limit violation detection?
[12:33:20] <cradek> hm if you have a kins api for "check this point for me" you won't really know what points to check
[12:33:38] <seb_kuzminsky> yeah, it would have to be "check this Line or this Arc"
[12:33:44] <seb_kuzminsky> all the motion primitives
[12:33:50] <cradek> bleh
[12:33:58] <seb_kuzminsky> and Task could use it for jogs
[12:36:20] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #80: Some hand-wavy discussion here:
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-07-15.html#11:39:49 02
https://github.com/LinuxCNC/linuxcnc/issues/80#issuecomment-233010338
[13:42:04] <seb_kuzminsky> cradek: is this the lathe you have?
https://forum.linuxcnc.org/forum/54-user-exchange/31264-hardinge-chnc-super-precision-lathe-for-sale#77517
[13:48:51] <kwallace1> That looks similar to my HNC:
http://www.wallacecompany.com/cnc_lathe/HNC/00003-1a.jpg
[13:50:20] <seb_kuzminsky> kwallace1: do you like yours?
[13:50:46] <cradek> pretty similar, but later than mine
[13:50:58] <cradek> HNC was an NC lathe, CHNC is CNC
[13:52:47] <kwallace1> I like mine, but it doesn't get used very much.
[13:53:24] <cradek> same
[13:53:35] <kwallace1> I'm not too keen on the threaded spindle.
[13:53:47] <cradek> it's a good chucker, no tailstock, most useful for making short <= 1" diameter parts
[13:58:42] <kwallace1> My Feeler gets used more (on the right background):
http://www.wallacecompany.com/cnc_lathe/00006-1a.jpg
[14:00:41] <kwallace1> My HNC to LinuxCNC conversion was pretty easy. Maybe easier with reusing the resolvers.
[14:01:58] <seb_kuzminsky> no tailstock seems like a bummer
[14:04:56] <kwallace1> I use the tailstock on the Feeler mostly for drilling which is handled on the turret on the HNC.
[14:05:45] <cradek> the resolvers are really nice, amazing resolution
[14:06:10] <cradek> yes I agree about drilling. it's good at that.
[14:07:33] <cradek> it really is for making lots of small precise parts
[14:07:53] <cradek> it's not a general purpose lathe
[14:08:45] <kwallace1> I haven't worked out having multiple tools at each "pocket" yet, though I may have put it off long enough to have someone else fix it.
[14:09:22] <cradek> mine's modulo so T1 and T9 are at the same turret position (but have different offsets of course)
[14:09:54] <seb_kuzminsky> a friend has an emco 120, i have tool envy
[14:12:20] <cradek> seb_kuzminsky: my HNC was super easy to run on single phase power. the main transformer that runs the servo amps was already single phase.
[14:15:57] <kwallace1> How common is CAN Bus on CNCs? I am biased toward Modbus but I have been playing with CAN Bus on a Jaguar and I may get sucked into playing with it more.
[14:16:24] <cradek> don't know, I think of that as a thing that's just in cars
[14:19:39] <jepler> Xenomai comes with some canbus hardware drivers for whatever that's worth
[14:19:59] <kwallace1> The CAN topic seems to come up now and again, maybe more on Machinekit. Hmm:
http://www.osadl.org/Abstract-6-RTAI-in-CAN-bus-based-Networ.rtlws11-abstract6.0.html?&no_cache=1
[14:24:05] <jepler> the answer is the same as always: if you want a hardware interface that isn't there yet, you get to do your own research and write your own driver
[14:24:12] <jepler> and if you're not tooooo tiiiirrrreeeeeddddd after that, then make us a PR
[14:31:16] <jepler> a canbus packet is a maximum of 8 bytes, and a packet of that size takes 108 bit times (11-bit address) or 128 bit times (29-bit address). canbus operates at a mere 1Mbit/second. You should probably spend no more than 300us out of a 1ms servo thread waiting on I/O, so you only get 300 bit-times or less than 24 bytes transfer per ms
[14:31:29] <jepler> I don't think it's an appropriate choice for position control (encoders, steppers, etc)
[14:33:31] <jepler> so that leaves stuff you might do in non-realtime and then the constraints on what APIs you can use to talk to hardware become a lot more relaxed: anything you can install on linux.
[14:39:07] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc commented on issue #96: Sounds pretty good.... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-233044700
[14:39:56] <kwallace1> It looks there are four bus types on page 15 here: file:///home/kwallace/Downloads/2003%20MY%20S-Type%20Electrical%20Guide.pdf maybe I should take up knitting instead.
[14:40:41] <kwallace1> Oops. bad link
[14:42:50] <kwallace1> http://www.jagrepair.com/images/Electrical/STypeElectrical/2003%20MY%20S-Type%20Electrical%20Guide.pdf
[14:55:12] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc commented on issue #96: Sounds pretty good.... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-233044700
[15:10:56] <jepler> who is "pkmcnc", do I know them by another name?
[15:11:20] <skunkworks> I just know him from the youtube videos..
[15:11:51] <jepler> oh yes I've seen some of those videos
[15:46:33] <seb_kuzminsky> jepler: i think pkmcnc is Andrew Kyrychenko <amkyrychenko@gmail.com>, he's got several commits in master, mostly related to hexapods
[16:01:19] <jepler> seb_kuzminsky: ah thanks
[16:17:51] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #96: I think non-cuboid axis soft limits are an interesting idea, but outside the scope of this particular issue.... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-233066468
[18:20:01] <seb_kuzminsky> yay weekend
[18:29:41] <JT-Shop> you looking at the chnc?
[18:35:37] <seb_kuzminsky> haven't heard back from the seller yet
[18:35:52] <seb_kuzminsky> i'll go at least look at it this weekend if he's up for it
[18:36:07] <seb_kuzminsky> not sure the weight is worth the work volume, if you know what i mean
[18:38:18] <JT-Shop> what is the X and Z on that one?
[18:38:24] <JT-Shop> I have a CHNC I
[18:39:28] <JT-Shop> the CHNC I has a 16C spindle... might ask what that one is
[18:39:55] <JT-Shop> Doesn't cradek have a HNC?
[18:45:18] <JT-Shop> time to retire for the night
[18:45:26] <seb_kuzminsky> yeah, he says it works well and was easy to convert
[18:45:35] <seb_kuzminsky> ok see you later :-)
[20:17:22] <skunkworks_> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/151022
[20:24:04] * cradek makes a gesture
[20:25:48] <PCW_> skunkworks_: have you tested eth_packet_loss?
[20:28:28] <skunkworks_> only slightly.
[20:28:49] <skunkworks_> I could run it on the matsuura - but we have had Zero problems with 2.7.4
[20:28:58] <skunkworks_> * I will run it on the matsuura
[20:29:01] <PCW_> I'm pretty sure there a bug on some systems
[20:29:11] <PCW_> there's
[20:29:13] <skunkworks_> what is that?
[20:29:30] <skunkworks_> the forum post? (I was just reading it)
[20:29:48] <skunkworks_> (10k)
[20:31:19] <PCW_> if you set the read timeout setting low enough it should drop all slow packets (and if low enough will trip the max error count)
[20:31:21] <PCW_> but this does not appear to work on all systems
[20:33:54] <PCW_> it works on my G3258 (32 bit Wheezy Intel MAC) and The Zotac (64 bit Mint 17.3 RTK MAC) but does not work on my core Duo (32 bit Ubuntu 14.04 Intel MAC)
[20:35:16] <PCW_> on the core DUO you can set the timeout limit arbitrarily low but it never (or rarely) drops packets
[20:36:32] <skunkworks_> huh - my laptop is an i7 - I could try that. but it would be jessie
[20:38:10] <PCW_> on 10Ks problem it may just be the the Liva is not a good Preempt-RT network host machine but I think theres some value in just
[20:38:12] <PCW_> dropping the rare late packets, but it doe not appear to work everywhere
[21:07:07] <jepler> yeah, I'm bummed it didn't help this user
[21:10:13] <jepler> my testing was targeted at making sure that it behaved well if a packet just never would arrive, not at setting the wait time lower than the worst case round trip time of a read operation
[21:20:07] <jepler> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/network-rps.html
[21:34:28] <skunkworks_> mine is 00
[21:36:16] <jepler> from the text it sounds like it would be beneficial to set it to something nonzero, but I am confused by what to set it to
[21:36:28] <jepler> comma-separated numbers? hex numbers? binary numbers? maybe any of the above?
[21:37:00] <jepler> .. so that the packet would always be steered to the RT CPU
[21:39:43] <skunkworks_> https://www.novell.com/support/kb/doc.php?id=7015585
[21:41:41] <skunkworks_> http://moblog.wiredwings.com/archives/20100827/howto-enable-receive-packet-steering-rps-on-linux-2-6-35.html
[22:14:17] <KGB-linuxcnc> 03Jeff Epler 05master 4d19316 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt updating-linuxcnc: flatten heading hierarchy * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4d19316
[22:21:00] <pcw_home> jepler: any idea why the timeout doesn't work on some systems? (not sure about 10Ks system but it definately does not work on one of my systems)
[22:21:02] <pcw_home> I guess if it hung in a system call rather than waiting for the RX int it might behave this way but whys its any different in different systems I cant guess
[22:21:03] <pcw_home> also a comparison failureof some kind might do this
[22:21:16] <jepler> pcw_home: no not really any theories
[22:22:02] <jepler> it'll kill realtime and might change the result, but it'd be interesting to see what strace shows. it can timestamp when the syscall was entered and also time within syscall..
[22:22:36] <jepler> the loop is: non-blocking recv, exit loop if we got data back; delay 10us; exit loop if we reached deadline; otherwise back to recv
[22:23:01] <jepler> it's simple enought that I can't convince myself it's my bug lurking there but I could be wrong
[22:23:27] <pcw_home> yeah on the system that does not work I can set the time to 1% or 0% and it runs the same as 80
[22:23:52] <pcw_home> very weird
[22:25:02] <jepler> I should try this laptop with current 2.7, it's core 2 with intel nic. maybe I'll be "lucky" and get the same behavior.
[22:25:32] <jepler> heck I haven't tried setting the timeout to 1% on my desktop where I did all the development, so I don't know how it does either
[22:26:08] <jepler> but .. not tonight
[22:26:32] <pcw_home> yeah Core Duo is where I have the issue but unfortunately I have different OS's on each system
[22:26:55] <jepler> yes kernel version would be good to know as well
[22:28:51] <pcw_home> 4.1.27-rt30 32 bit on the one with trouble but 4.1.27-rt30 32 bit is ok on the G3258
[22:30:28] <pcw_home> I've changed the kernel a few times on the Core Duo and I've never seen timeouts work
