#linuxcnc-devel | Logs for 2016-02-21

Back
[09:09:17] <jepler> oh geez: http://blog.linuxmint.com/?p=2994 "Beware of hacked ISOs if you downloaded Linux Mint on February 20th!"
[09:32:33] <jepler> not only has atmel's "debugwire" been reverse engineered, it's pretty simple. http://www.ruemohr.org/docs/debugwire.html
[10:47:32] <Tom_itx> Dan does alot of reverse engineering on stuff
[11:32:39] <skunkworks_> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/150246
[11:34:13] <skunkworks_> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/150248
[11:36:49] <archivist> I wonder what he is smoking
[12:37:21] <pcw_home> Hey "how we operate" ( makes me feel like a gangster )
[13:41:58] <KGB-linuxcnc> 03Jeff Epler 05master f87c024 06linuxcnc 10src/Makefile 10src/Makefile.modinc.in uspace: Work around reported docker /dev/stdout bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f87c024
[13:41:58] <KGB-linuxcnc> 03Jeff Epler 05master e8151f0 06linuxcnc 10src/Makefile.modinc.in uspace: remove duplicate ld step in Makefile rule * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e8151f0
[13:43:12] <jepler> "Of course, the question we are trying to answer is not whether a person who becomes a zombie should be considered dead under state law. Answering this question is only the first step of the analysis. Ultimately, our goal is to determine whether such a person should be considered a decedent for federal estate tax purposes" http://esoterx.com/2014/05/27/philosophical-zombies-legal-issues-of-the-liv
[13:43:18] <jepler> ing-dead/
[14:26:56] <AndChat-396416> Sound like they are trying to use time to correct a position problem
[14:27:11] <AndChat-396416> Again
[14:28:19] <jsskangas> evening
[14:28:38] <jsskangas> well at least this side of ball...
[14:29:41] <jsskangas> I'v been thinking and developing idea to implement RTCP on linuxcnc for a while now.
[14:31:10] <jsskangas> problem has been that i want to jump between RTCP and normal mode, but i think ihave got around that problem
[14:37:56] <jsskangas> I use custom command to jump between these modes. when switching from normal to RTCP. Nomal mode position is used to calculate to be position in RTCP before and set as current position in RTCP.
[14:38:47] <jsskangas> this way no axis jump happens when switching between different coordinate modes
[14:43:15] <jsskangas> only problem is i need to make some changes to kinematics.h int kinematicsInverse(const EmcPose * pos, Ineed to get write acees for pos. to write current position for pos->tran.x, y and z
[15:38:27] <jepler> The original person who worked on 5-axis in linuxcnc put the tool offsets into kinematics. We later decided to view that as a bad design, because either a lot of layers (all the way from realtime back to the interpreter) had to be touched to deal with step changes in position when changing the tool offset.
[15:38:54] <jepler> instead, we now view 5axiskins as a good design that fits with linuxcnc. With 5axiskins, you have 5 joints and 8 axes -- two full sets of cartesian axes, plus your two rotaries
[15:39:21] <jepler> the kinematics is defined so that XYZ is in relative to the table and UVW is relative to the tool (so W is always along the tool)
[15:40:07] <jepler> all that said, you can of course modify the prototype of kinematicsInverse in your copy of linuxcnc. If you come up with a useful result, it may help others, so let us know what your results are.
[15:42:15] <jsskangas> Hello jepler
[15:42:42] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15sirop opened pull request #41: PktUART driver for MESA (06master...06master) 02https://github.com/LinuxCNC/linuxcnc/pull/41
[15:44:37] <jsskangas> Basic idea for this is, I like to work with linuxcnc like with other commercial cnc controllers like iTNC 530 or 840D
[15:45:25] <jsskangas> I doo lot of work witch include 3+2 indexing and 5-axis machining
[15:46:34] <jsskangas> When doing 3+2 indexing I dont want to fix my coordinate on rotating table, so then I use my normal setup in linuxcnc
[15:47:07] <jsskangas> But when doing 5 axis work I want to fix my coordinate system in rotating table
[15:47:36] <jsskangas> this leads to jumping between two different setups
[15:48:40] <jsskangas> to my knowledge currently they can not exist in same setup
[15:50:54] <jsskangas> So basically Im trying to implement two kinematics in one setup and smooth transition between these two setups
[15:51:31] <jsskangas> its not a big change that need to be done to make it work
[15:52:56] <jsskangas> so far I have succeed
[15:53:52] <jsskangas> I made my own kinematics that can jump between two or several different kinematics
[15:55:26] <jsskangas> only thing left to do at this point is rewriting pos->tran.n from inverse kinematcis function
[15:55:49] <jsskangas> and there I would need some help
[15:59:37] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky closed pull request #41: PktUART driver for MESA (06master...06master) 02https://github.com/LinuxCNC/linuxcnc/pull/41
[16:23:17] <jepler> I am confused about #41 -- was it really opened and closed in the last hour? How does that oddball abc838 have a 14-day-old comment in it then?
[16:23:52] <zeeshan-mill> hi, i am having a hard time removing "jerkiness" at corners
[16:24:09] <zeeshan-mill> i am using 2.7.2, with g64 on
[16:24:47] <zeeshan-mill> i have tried using a tolerance method in my cam to reduce small line segments. the file size goes fro 430kb to approx 112kb
[16:25:02] <zeeshan-mill> running both files has little effect at the feedrate at corners
[16:25:41] <zeeshan-mill> increasing ARC_BLEND_OPTIMIZATION_DEPTH = 50 to 670 has had little effect
[16:26:25] <CaptHindsight> zeeshan-mill: https://www.youtube.com/watch?v=70rd9fK-UGg&feature=youtu.be&t=205 is this the video?
[16:26:53] <AndChat-396416> Are you using a q tolerance?
[16:27:08] <zeeshan-mill> yes capt
[16:27:26] <zeeshan-mill> AndChat-396416, im using whatever 2.7.2 comes with default
[16:27:38] <zeeshan-mill> i should explicitly type g64
[16:27:41] <zeeshan-mill> lemme try that
[16:28:42] <zeeshan-mill> nope didnt help
[16:29:25] <AndChat-396416> I would try g64px.xxx where x.xxx is how close you want it to follow the path
[16:30:05] <pcw_home> yeah like
[16:30:06] <pcw_home> g64 p0.002 q0 .002
[16:30:31] <zeeshan-mill> n2255
[16:30:39] <zeeshan-mill> okay let me try that
[16:31:38] <AndChat-396416> Yes.. though if you don't specify a q then q=p
[16:31:58] <zeeshan-mill> didnt help
[16:32:10] <zeeshan-mill> lemme try something larger
[16:32:15] <zeeshan-mill> like 0.010
[16:32:36] <AndChat-396416> Are you running metric or english?
[16:32:39] <pcw_home> I thought the naive CAM detector was only turned on with Q
[16:33:36] <zeeshan-mill> 0.010 helped
[16:33:46] <zeeshan-mill> but still jerks
[16:33:47] <zeeshan-mill> inches
[16:34:06] <AndChat-396416> What is acceleration?
[16:34:11] <zeeshan-mill> 10in/s^2
[16:34:27] <pcw_home> _very_ slow acc
[16:34:32] <zeeshan-mill> hm
[16:34:42] <pcw_home> thats probably your limitation
[16:34:45] <zeeshan-mill> what should it be? :P
[16:35:20] <pcw_home> as much as you can get without excessive following errors
[16:35:20] <AndChat-396416> Whatever your drives handle :)
[16:35:28] <seb_kuzminsky> jepler: that reinforces my belief that abc838 is a malfunctioning robot
[16:35:45] <zeeshan-mill> okay i guess time to retune :)
[16:37:42] <seb_kuzminsky> jepler: ah, no
[16:38:05] <seb_kuzminsky> abc838 commented on a commit from July 17 2015, and that commit was included in the bogus PR
[16:38:15] <jepler> ah so it's github being too clever
[16:38:48] <seb_kuzminsky> well, in github's defense it does say "abc838 commented on 2f12e51 14 days ago"
[16:39:10] <seb_kuzminsky> and the commit sha is a link to the commit
[16:41:22] <zeeshan-mill> holy cow at 35in/s^2
[16:41:24] <zeeshan-mill> they are so response
[16:41:29] <zeeshan-mill> im wondering why the hell i had it set so low
[16:42:33] <Tom_itx> zeeshan-mill, working better now?
[16:43:27] <zeeshan-mill> the accel is so much nicer
[16:43:32] <zeeshan-mill> im moving it back and forth, its so quick
[17:09:25] <zeeshan-mill> okay x axis went from 10 to 26 in/s^2
[17:09:35] <zeeshan-mill> y went from 10 to 34
[17:09:48] <zeeshan-mill> z from 10 to 16
[17:10:05] <zeeshan-mill> with about 2in/s^2 buffer from when errors occur
[17:14:45] <zeeshan-mill> unfortuantely the problem is still there
[17:14:49] <zeeshan-mill> its much better now though
[17:33:50] <zeeshan> seems like all those accel settings allow me to cut at 100 ipm
[17:33:56] <zeeshan> with no changes in speeds
[17:34:03] <zeeshan> its when i try to do 200 ipm is when the trouble happens :P
[18:28:13] <pcw_home> need better drives :-)
[18:28:46] <zeeshan> yes :P
[18:28:55] <zeeshan> definitely will be choosing better ones for the lathe conversion