Back
[04:16:56] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pippin88 opened pull request #77: Corrected gmoccapy typos (06master...06LCNCScreen) 02
https://github.com/LinuxCNC/linuxcnc/pull/77
[05:19:35] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_2 96c2b8a 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py Merge branch 'master' into gmoccapy_2 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=96c2b8a
[05:25:17] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal 10451c8 06linuxcnc 10src/Makefile 10src/emc/usr_intf/gmoccapy/gmoccapy.py Merge branch 'master' into EU_Surplus_FastSeal * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=10451c8
[07:59:51] <andypugh> It interesting what you find when poking about in the code. I wonder what USE_SPINDLE_FORCE was meant to do?
[08:05:08] <pcw_home> USE_SPINDLE_FORCE Luke?
[08:43:55] <jepler> > If the USE_SPINDLE_FORCE or USE_SPINDLE_TORQUE mode is in effect, ...
[08:45:04] <jepler> > If the force on the spindle exceeds force (in newtons), reduce the feed rate until the force on the spindle drops below that amount. Otherwise, use the programmed feed rate.
[08:45:31] <jepler> hm buildbot website seems to have fallen over altogether :-/
[09:03:34] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #77: @pippin88 thank you for offering a contribution to LinuxCNC. Correcting typos is not glamorous work, but I appreciate that you have done it.... 02
https://github.com/LinuxCNC/linuxcnc/pull/77#issuecomment-226942914
[09:33:58] <andypugh> jepler: I failed to find that, though perhaps I didn;t look hard enough.
[09:58:01] <pcw_home> Theres some kind of adaptive feed code in LinuxCNC?
[10:03:00] <jepler> pcw_home: no, but it was planned for back when NIST designed the canon API
[10:06:14] <jepler> andypugh: those are both from the internet, not our source tree
[10:06:30] <andypugh> Ah, OK.
[10:07:03] <andypugh> It seems like a reasonable idea, but can be done already with adaptive feed.
[10:14:27] <mozmck> That would be interesting to play with. How do they measure the force on the spindle I wonder?
[10:15:06] <mozmck> Off the top of my head I can imagine maybe a pressure transducer(s) around the spindle bearing?
[10:15:18] <pcw_home> Maybe just spindle torque
[10:15:37] <pcw_home> or a torque mode servo
[10:16:40] <pcw_home> or a velocity mode servos with torque feedback to host (either analog or Ethercat etc)
[10:16:47] <mozmck> Interesting. I guess I'm thinking about what it might take to add something like that to an existing spindle.
[10:17:48] <pcw_home> with Modbus you often have the already (though a bit slow)
[10:17:52] <mozmck> How accurate would torque measurements be? I was cutting some 1/16" aluminum with 1/8" carbide bits and kept snapping them.
[10:18:09] <pcw_home> some VFDs have a analog torque output
[10:18:59] <mozmck> Well, I use a makita rf1100 router in my table right now :-) I might have to replace that to get any kind of measurements.
[10:19:35] <mozmck> Although maybe if I measured force on the router mount it could be useful.
[10:19:45] <Tom_itx> current feedback maybe
[10:20:27] <mozmck> do you think there would be enough variation at 10000 rpm with an 1/8" bit to stop from breaking it?
[10:21:04] <Tom_itx> doubtful
[10:21:21] <mozmck> that was my gut feeling as well
[10:32:00] <pcw_home> Yeah I suspect with smaller tools its not going to be that helpful unless you
[10:32:02] <pcw_home> had fast force measurement from the spindle mount
[11:03:53] <Roguish_> tool load can also be measured to a degree with spindle current.
[11:06:03] <dgarr> jepler: my rebase of joints_axes15 fails on debian jessie 64bit, see
http://www.panix.com/~dgarrett/stuff/ja15_rebase.txt
[11:06:56] <dgarr> not sure if i should revert to optind=0 or something else?
[11:40:41] <andypugh> dgarr: I am half-way through a huge change based on JA14. I can imagine rebasing that being fun.
[11:41:31] <andypugh> Possibly too big, I can see it taking as long as JA has to be merged.
[11:43:57] <seb_kuzminsky> the buildmaster ran out of disk again. I had *just* added another 30 gigs to it. i'm turning down the lifetime of old debs
[11:48:47] <andypugh> Maybe add 30TB next time?
[11:49:50] <andypugh> 30GB really is quite a lot when you think about reading it, isn’t it?
[11:50:07] <andypugh> Eeeh, when I was a lad we though 16k was a lot.
[11:52:16] <Tom_itx> and 10Mb hdd cost more than Tb ssd's do now
[12:12:39] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes15 0a4650e 06linuxcnc 10src/emc/kinematics/xyzbc-trt-kins.c xyzbc-trt-kins.c unused dz in kinematicsInverse JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0a4650e
[12:24:06] <JT-Shop> what is the current rt patch in use? I tried 4.6 this morning but it won't boot
[12:24:53] <JT-Shop> https://www.kernel.org/pub/linux/kernel/projects/rt/
[12:45:45] <jepler> I picked up whatever was in jessie-backports last, 4.4 I guess.
[12:46:59] <JT-Shop> thanks
[12:47:30] <JT-Shop> how do you tell what is in jessie-backports?
[12:48:56] <jepler> well, fwiw, that kernel I have is not in jessie-backports now
[12:49:41] <jepler> but anyway, in any of the usual ways such as using apt-cache search, apt-cache policy, packages.debian.org, etc
https://packages.debian.org/wheezy/linux-image-rt-amd64
[12:49:41] <pcw_home> My experience is that 4.4 and 4.6 are not really good for general use yet (Either terrible latency or crashes either on boot or after a few minutes running) I do have 4.6 running a a quite new CPU reliably but its useless as a general OS as it only runs well on some hardware
[12:50:02] <jepler> the upper right on that page links to each debian codename that has a version of that package in it
[12:50:26] <jepler> so there are none for jessie or jessie-backports, but there are for wheezy (3.2) and stretch/sid (4.6)
[12:51:25] <pcw_home> 3.2 is so old it will have trouble with a lot of current hardware
[12:51:42] <jepler> all old packages from debian are at
http://snapshot.debian.org/package/linux/4.4.6-1~bpo8%2B1/ but they cannot directly be installed with apt
[12:51:50] <jepler> pcw_home: yes I am not *advocating* that by any means
[12:51:54] <pcw_home> (it doesnt support the intel 2xx MACs for example)
[12:52:56] <jepler> maybe you can get packages from there but you have to disable following all the normal validity checks of a package. instructions at
http://snapshot.debian.org/ mention using apt-get -o Acquire::Check-Valid-Until=false
[12:53:19] <jepler> anyway it's an irritating state of affairs to say the least
[12:53:48] <pcw_home> I keep hoping the latest kernel will work on my Core Duo but they either have 170 usec latency or crash after a few minutes
[12:54:35] <pcw_home> I've gone back to 4.1.20-rt23 on the Core Duo
[13:30:49] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 0000.checkin
[13:30:50] <linuxcnc-build> build forced [ETA 59m01s]
[13:30:51] <linuxcnc-build> I'll give a shout when the build finishes
[13:30:53] <seb_kuzminsky> linuxcnc-build: force build --branch=2.7 0000.checkin
[13:30:58] <seb_kuzminsky> linuxcnc-build: force build --branch=master 0000.checkin
[13:31:00] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[13:31:06] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[13:57:25] <linuxcnc-build> build #4230 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/4230
[14:11:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 1bdc574 06linuxcnc 10tests/halui/mdi/test-ui.py tests: longer timeout in halui mdi test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1bdc574
[14:17:57] <dgarr> jepler: ^^ any ideas getopt,optind=1,bsd?
http://www.panix.com/~dgarrett/stuff/ja15_rebase.txt
[14:37:56] <jepler> dgarr: I can reproduce something like what you're reporting in master branch
http://paste.debian.net/740047/
[14:48:27] <dgarr> jepler: i get same result for your example on ja15 uspace both 32 bit and 64bit
[14:50:11] <linuxcnc-build> build #4242 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4242
[14:50:11] <linuxcnc-build> build forced [ETA 59m01s]
[14:50:11] <linuxcnc-build> I'll give a shout when the build finishes
[14:57:07] <JT-Shop> pcw_home: and jepler thanks for the info
[15:06:33] <dgarr> jepler: however, when i try your halrun -T example on vbox debian wheezy rtai there are no errors (ja15) and minimal_xyz.ini loads ok
[15:06:58] <dgarr> (32bit)
[15:15:37] <jepler> dgarr: OK that is interesting to know
[15:16:03] <jepler> haltcl: loadusr -w true
[15:16:03] <jepler> Program 'true' finished
[15:16:03] <jepler> haltcl: loadusr true
[15:16:03] <jepler> loadusr: invalid option -- 'u'
[15:26:03] <jepler> dgarr: further reading
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=192834
[15:26:56] <jepler> (commenter is wrong that the behavior is fixed in debian lenny, or else it broke again)
[15:32:56] <dgarr> any objections to me reverting the commit that changed optind in the joints_axes15 branch?
[15:34:49] <jepler> yes, please do not do that
[15:34:56] <jepler> I am adapting ted's fix for master branch
[15:37:14] <KGB-linuxcnc> 03Jeff Epler 05master d9b80fc 06linuxcnc 10src/configure.in 10src/hal/utils/halcmd_commands.c halcmd: Unportably reset getopt state * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d9b80fc
[15:37:14] <KGB-linuxcnc> 03Jeff Epler 05master f6952d2 06linuxcnc 03tests/halrun-getopt-reset/README 03tests/halrun-getopt-reset/expected 03tests/halrun-getopt-reset/test.hal tests: test for the getopt reset bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f6952d2
[15:39:58] <dgarr> jepler: ok -- is it ok to cherry-pick these commits to ja15 or should i do another rebase?
[15:40:49] <jepler> dgarr: either way is fine with me
[15:40:55] <andypugh> Puzzling: ImportError: /home/andypugh/linuxcnc-dev/lib/librs274.so.0: undefined symbol: _Z18GET_EXTERNAL_SPEEDi
[15:41:14] <jepler> andypugh: $ c++filt _Z18GET_EXTERNAL_SPEEDi
[15:41:14] <jepler> GET_EXTERNAL_SPEED(int)
[15:41:22] <dgarr> ok thanks, i will wait until after the buildbot builds with your commits
[15:41:27] <jepler> if you think GET_EXTERNAL_SPEED is defined, perhaps it has the wrong arugment list?
[15:41:36] <andypugh> COuld be
[15:41:46] <jepler> src/emc/nml_intf/canon.hh:extern double GET_EXTERNAL_SPEED();
[15:41:49] <andypugh> Though it compiles cheefully.
[15:42:10] <andypugh> Ah, it doesn’t look like that any more ;-)
[15:42:11] <jepler> src/emc/task/emccanon.cc:double GET_EXTERNAL_SPEED()
[15:42:21] <jepler> probably you missed changing this one
[15:42:37] <jepler> C++ happily lets you define functions with the same names but different numbers and types of arguments, it's a feature
[15:42:39] <andypugh> Does the _Z81 mean something?
[15:43:06] <jepler> dgarr: yes, it has something to do with >>> len("GET_EXTERNAL_SPEED")
[15:43:06] <jepler> 18
[15:43:08] <andypugh> jepler: Yes, I have even read about polymorphism. I might even have used it
[15:43:13] <jepler> er andypugh
[15:43:47] <jepler> andypugh: when an error message is about a symbol starting _Z, then I always take that symbol, chop it off at a "." if there is one, and send the rest to c++filt
[15:43:54] <jepler> it can tell me what that symbol actually is
[15:44:55] <andypugh> OK, thanks. I was initially wondering if I had accidentally typed in the wrong window and messed up the name.
[15:48:31] <andypugh> Am I reading things wrong, or is this a set of placeholder functions that don’t actually do anything useful ?
[15:48:34] <andypugh> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/gcodemodule.cc#L558
[15:49:33] <jepler> pretty much
[15:50:03] <jepler> but they have to have a definition (and, in some cases, an innocuous return value) or you get a link error instead of a preview window
[15:51:39] <andypugh> Ah, those do preview, so are the dummy-interpreter?
[15:51:56] <andypugh> Makes sense, now.
[16:01:55] <andypugh> Woohoo! LinuxCNC is now booting again.
[16:03:57] <linuxcnc-build> Hey! build 0000.checkin #4243 is complete: Success [3build successful]
[16:03:57] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4243
[16:04:00] <linuxcnc-build> build forced [ETA 1h06m23s]
[16:04:00] <linuxcnc-build> I'll give a shout when the build finishes
[16:05:51] <andypugh> OK, so it segfaults when I start a spindle, but that’s not a huge surprise.
[16:25:46] <andypugh> 46 files changed, 1507 insertions
[16:26:12] <andypugh> I am surprised by the file count. but imagined i had changed more lines.
[17:48:01] <linuxcnc-build> Hey! build 0000.checkin #4244 is complete: Success [3build successful]
[17:48:01] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4244
[17:51:49] <KGB-linuxcnc> 03Jeff Epler 05joints_axes15 e0ee8bf 06linuxcnc 10src/configure.in 10src/hal/utils/halcmd_commands.c halcmd: Unportably reset getopt state * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e0ee8bf
[17:51:50] <KGB-linuxcnc> 03Jeff Epler 05joints_axes15 2341e7f 06linuxcnc 03tests/halrun-getopt-reset/README 03tests/halrun-getopt-reset/expected 03tests/halrun-getopt-reset/test.hal tests: test for the getopt reset bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2341e7f
[18:57:29] <andypugh> https://forum.linuxcnc.org/forum/9-installing-linuxcnc/31072-netmos-9865-pci-parallel-port-help?start=50#76270
[18:57:43] <andypugh> I am right in thinking that thsi is bad advice?
[19:04:55] <pcw_home> A slower base thread will give a raspier pulse stream (larger magnitude beats between step rate and base thread rate)
[19:05:38] <andypugh> So, not smoother, as claimed?
[19:06:05] <pcw_home> no, larger phase errors
[19:09:55] <pcw_home> if timing was marginal a slower base thread might help (longer pulses if reset is not used)
[19:11:57] <andypugh> I guess I am interested in why Tommylight believes that?
[19:21:02] <pcw_home> Might be an interesting experiment
[19:24:41] <pcw_home> I have heard from customers that the could achieve faster step rates with the hardware
[19:24:42] <pcw_home> stepgen (30 /40 % more) even when the software stepgen was capable of generating the
[19:24:44] <pcw_home> required rates. My theory is that the beats between the base thread and the step rate can excite
[19:24:45] <pcw_home> resonances (but this is just a guess)
[19:25:43] <andypugh> Maybe just that the granularity is lower, so the speed steps (ie accel) are lower?
[19:26:57] <pcw_home> possibly
[19:27:26] <pcw_home> (of course there are speed steps at the servo thread rate also)
[19:28:02] <jepler> maybe you should modify hostmot2 to add 20-40us jitter to step times and see how pronounced a negative effect it can have
[19:36:06] <andypugh> Fascintaing:
https://www.youtube.com/watch?v=0hlvhQZIOQw
[19:36:38] <andypugh> If I suddenly became wealthy, I can actually imagine deciding to do a maths degree.
[19:38:51] <pcw_home> hostmot2 can do that already
[19:39:32] <pcw_home> just set the base frequency down to 50 or 25 KHz
[19:40:10] <pcw_home> (not sure the driver knows how to do this and keep the scaling right)
[19:56:35] <linuxcnc-build> build #406 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/406 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[21:53:19] <skunkworks> I managed to mdi a circle - went past the soft limit and hit the over travel switch..
[21:53:29] <skunkworks> I am going to see if I can get it to do it in sim.
[21:54:00] <skunkworks> (errored that soft limit was exceeded - but also hit the over travel limit.
[22:39:23] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pippin88 opened pull request #78: Gmoccapy tooltips (06master...06gmoccapy-tooltips) 02
https://github.com/LinuxCNC/linuxcnc/pull/78