Back
[00:33:47] <linuxcnc-build> build #4033 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4033 blamelist: Jeff Epler <jepler@unpythonic.net>
[06:50:51] <skunkworks> wow..
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/150558
[06:53:50] <skunkworks> such advancements!!
[06:53:52] <skunkworks> Imagine being able to touch the graphics screen and rotate the screen around in 3D space. While it is running! Let's see Fanuc do that! Or use the mouse to pan and zoom the display. How about pausing the motion and the motion immediately stops.
[07:16:36] <skunkworks> I initially had the spindle encoder plugged into encoder.00 - so when I rotated the spindle - X dro would count ;)
[07:27:08] <Tom_itx> we all need to rotate our screens
[07:27:38] <Tom_itx> makes parts cut so much better
[07:44:42] <skunkworks> You didn't dare touch the preview in mach3 because it would cause motion problems
[07:48:05] <skunkworks> sorry * 'could cause motion problems..'
[08:11:00] <skunkworks> https://www.youtube.com/watch?v=MaH_Nlh4sxk
[08:12:38] <skunkworks> zlog
[08:16:05] <archivist> I would not dare measure that on my thread pitch measuring machine :)
[08:20:01] <skunkworks> It is hard to see - but it sure looks like the thread gauge doesn't fit well
[08:20:26] <skunkworks> you can see the shavings are inconsistant - the second to the last path takes hardly nothing
[08:20:52] <skunkworks> but the nut fits
[08:21:11] <archivist> rattling fit
[08:21:23] <skunkworks> ;)
[08:23:43] <archivist> funny thing is, a rattling fit is a requirement in clockmaking
[08:24:07] <archivist> but it has to the right rattle
[10:57:08] <seb_kuzminsky> jessie-backports has a 4.4.6-rt kernel
[11:12:02] <pcw_home> wonder if its any good, all the 4.4.x kernels I've tried were terrible
[11:12:20] <pcw_home> (latency or stability wise)
[11:16:29] <pcw_home> so big spikes in motion-command-handler.time seem to be from new TP
[11:16:30] <pcw_home> ~17 us peak with old TP vs 71 usec peak with new
[11:19:06] <mozmck> how often do you see them?
[11:19:12] <cradek> wonder if there's a trouble situation that could be massaged
[11:19:26] <pcw_home> its gcode dependent
[11:19:45] <cradek> can you make a minimized gcode program that causes one?
[11:19:45] <mozmck> oh, I see you said a couple times a day...
[11:21:18] <pcw_home> i have been running a very dense torus png to gcode program to test things and it takes hours to run but I suspect a simple test would show the issue
[11:22:20] <cradek> if you can trigger on it, plot motion.program-line
[11:22:31] <pcw_home> this is with a 3.16 Ghz core duo, an Atom might trip on this at anything faster than 1 KHz or so
[11:23:02] <pcw_home> yeah let me try a shorter program
[11:41:34] <seb_kuzminsky> heh yeah my machine crashed with that rt kernel in the first 5 minutes
[11:44:19] <pcw_home> Ive had much better luck with the 4.1.x kernels
[11:49:12] <jepler> $ uname -a; uptime
[11:49:12] <jepler> Linux babs 4.4.0-trunk-rt-amd64 #1 SMP PREEMPT RT Debian 4.4.1-1~0.jepler8~1 (2016-02-16) x86_64 GNU/Linux
[11:49:15] <jepler> 11:23:23 up 24 days, 23:01, 130 users, load average: 0.52, 0.52, 0.46
[11:49:37] <jepler> I've had fine luck on 4.4, though without a close eye on latency. also 64-bit kernel and userspace here, it could matter(?)
[11:50:02] <pcw_home> Ive had stable with terrible latency or great latency and hard crashes
[11:50:48] <pcw_home> but I've only done 32 bit
[11:59:25] <pcw_home> ( terrible meaning 100s of usecs )
[12:00:04] <pcw_home> great latency meaning 24 or so usec on the core Duo and 7 or so usec on the G3258
[12:10:03] <pcw_home> Ha just got 91 usec peak motion-command-handler time but my trigger was set too low so lost the program line
[12:17:03] <cradek> interesting - I would expect it to be -controller, not -command-handler
[12:17:17] <cradek> it's almost as if I don't know how any of that works
[12:19:37] <pcw_home> motion controller is less spikey (maybe 10-1 max vs average)
[12:20:09] <pcw_home> command handler is more like 1000-1
[12:47:40] <pcw_home> spikes _seem_ to happen at G0
[12:55:56] <pcw_home> hard to tell, another large spike at G1-G2
[12:56:31] <pcw_home> sorry G2 --> G1
[13:28:43] <cradek> I don't understand why command-handler is even doing anything when gcode is just running
[13:34:56] <PCW> its hard to tell there may be significant delays between the line number and the delay spike
[13:35:25] <PCW> the spikes are not there if gcode is not running
[13:47:52] <cradek> do you have them fairly reproducable now?
[13:48:08] <cradek> you said an older version didn't do it. you could, in theory, bisect it
[14:10:14] <PCW> if i disable the new TP t get only 1/5 the spike magnitude
[14:10:21] <PCW> I get
[14:22:37] <jepler> I bet -command-handler does very very little if there isn't actually a command for it to read from task via shared memory..
[14:24:09] <jepler> what we may need is a way to finally split the command-handler and controller into separate HAL functions that can go on different threads
[14:24:45] <PCW> yes on the core duo average is a couple hundred instructions (say 100 ns)
[14:24:45] <jepler> .. but they mutually touch so much structured data and that means it's a lot of work to make sure controller never sees a partially updated memory area
[14:25:34] <PCW> wonder why the new TP is so much worse
[14:33:22] <skunkworks> I assume it is doing a lot more math?
[14:34:29] <seb_kuzminsky> does it get better if you turn down the look-ahead?
[14:35:50] <PCW> I didnt try that yet, I need a better torture gcode with mixes of G2,G3, G1 an G0
[14:49:11] <skunkworks> PCW, is that time or clock cycles?
https://imagebin.ca/v/2cmVnlYB6EAQ
[14:57:25] * skunkworks is aways confused as to what is time and what is clock cycles
[15:08:15] <jepler> skunkworks: it's not well-documented, let alone clear from e.g., pin names...
[15:09:03] <PCW> clock cycles
[15:09:15] <PCW> (at 3.16 GHz)
[15:16:36] <skunkworks> isn't 60k 18us?
[15:18:32] <PCW> yes, about
[15:20:23] <PCW> the peaks on the core duo (using the tmax parameter) are up to 91 usec ( ~288000 clocks )
[15:20:41] <skunkworks> ah - ok
[18:12:55] <skunkworks> zlog
[18:31:14] <andypugh> This is a strange one:
[18:31:15] <andypugh> http://www.pastebin.ca/3455566
[18:31:52] <andypugh> This is my generic turning sub, called from a galdVCP button that does an O<sub> call with a bunch of paramters.
[18:32:54] <andypugh> If I machine a taper (#6) then it works fine, until I set the taper angle back to zero. Then I get the very odd erir message “unknown operation beginning with e”
[18:34:33] <andypugh> Sorry, mis-reading my own G-code. #7 is the taper angle.
[18:52:10] <jepler> O106 ENDIF
[18:52:16] <jepler> surely it's not the double space here
[18:52:45] <jepler> .. I don't see anything obvious but I only spent about 2 minutes looking at the code
[18:53:46] <andypugh> I can try removing the spare space.
[18:54:35] <andypugh> I could also make the condition [LT -0.00001] too.
[18:59:11] <jepler> I didn't succeed in making it happen here
[18:59:55] <jepler> I ran with sim/axis/lathe.ini, moved the capture of <_x> and <_z> to before the tool change, and called it like:
[18:59:59] <jepler> G0 X0 Z.5
[19:00:01] <jepler> O<turning> call [1] [300] [1] [99] [1] [1] [0]
[19:00:04] <jepler> tested with recent-ish master-ish branch
[19:00:15] <jepler> full file is
https://emergent.unpythonic.net/files/sandbox/tu.ngc
[19:04:51] <andypugh> I think it is something wierd with the GUI passing a very, very, small negative number in param #7
[19:05:25] <cradek> well that's a quite inscrutable error then
[19:08:28] <andypugh> I will investigate tomorrow maybe, I was more interested in making parts today.
[19:09:13] <cradek> do you mean: Unknown operation name starting with e
[19:09:27] <andypugh> Sounds about right
[19:10:24] <cradek> heh "operation name"
[19:10:38] <andypugh> I wonder if something is getting “error” passed as a number from Python/Glade
[19:10:39] <cradek> that means it's inside [square brackets] and is e not followed by q (making eq)
[19:10:58] <cradek> I can get that by typing #1 = tan[1e-10]
[19:11:05] <cradek> but ... I can't imagine how you'd get that
[19:11:07] <andypugh> Aha!
[19:11:14] <cradek> but how...!?
[19:11:33] <andypugh> The numbers come from a spinbox in my lathe gui
[19:11:51] * cradek squints
[19:11:57] <cradek> I'm still not seeing it
[19:12:26] <cradek> ohhhh it constructs a mdi call and you think it's saying O1 call [1e-10]?
[19:12:30] <andypugh> Well, the number displays as -0.000000 but perhaps Glade is passing “1e-300” or something?
[19:12:45] <andypugh> Yes,
[19:13:02] <cradek> ok, at first I didn't think of it literally being in the mdi call line
[19:13:10] <andypugh> But, typing “0” in the box and pressing enter doesn’t fix it. Which is annoying
[19:13:31] <cradek> yuck, so maybe it's a gui/spinbox/toolkit problem
[19:14:40] <andypugh> The MDI GladVCP button lest you use a special syntax to substitute python variables into the MDI.
[19:15:32] <cradek> so maybe it's using something like %g when it should use something like %f
[19:15:56] <andypugh> http://linuxcnc.org/docs/2.7/html/gui/gladevcp.html#_parameter_passing_with_action_mdi_and_toggleaction_mdi_widgets
[19:16:18] <jepler> >>> "%s" % 1e-100
[19:16:18] <jepler> '1e-100'
[19:16:18] <jepler> >>> "%f" % 1e-100
[19:16:18] <jepler> '0.000000'
[19:16:22] <andypugh> (it’s HAL pins, now I look, not Python variables)
[19:17:13] <jepler> ..I see that you have no control at the configuration level over how gladevcp is turning the float value into a string value..
[19:18:38] <andypugh> Argh! Why is GitHub search so _deliberately_ broken?
[19:19:45] <jepler> it is using Python string.Template
[19:19:45] <jepler> >>> string.Template("${x}").substitute(x=1e-10)
[19:19:46] <jepler> '1e-10'
[19:20:01] <jepler> string.Template doesn't seem to give any control over how a non-string object is converted to a string, it always does it by str()
[19:20:17] <jepler> so there's no spot to change from %g to %f or whatever
[19:20:45] <jepler> $ git grep -n Template -- "*.py"
[19:20:45] <jepler> lib/python/gladevcp/hal_actions.py:437:class HalTemplate(string.Template):
[19:20:48] <jepler> lib/python/gladevcp/hal_actions.py:461: template = HalTemplate(self.command)
[19:22:34] <andypugh> I was using the github version of the sourcecode purely so it was easy to post a link. But th search is so utterly broken “You can't use the following wildcard characters as part of your search query: . , : ; / \ ` ' " = * ! ? # $ & + ^ | ~ < > ( ) { } [ ]. The search will simply ignore these symbols.”
[19:22:57] <cradek> oh sure, you'd never find those in source code anyway
[19:23:47] <jepler> https://emergent.unpythonic.net/files/sandbox/0001-untested-work-around-1e-10-problem.patch
[19:24:24] <cradek> 1?
[19:24:42] <jepler> I said untested!
[19:25:11] <jepler> but yeah it's much more likely to work without that line
[19:26:05] <jepler> updated:
https://emergent.unpythonic.net/files/sandbox/0001-untested-work-around-1e-10-problem.patch
[19:29:27] <andypugh> Surely it would be better to fix G-code to accept exponent notation :-)
[19:29:53] <andypugh> I will try to remember to try it out tomorrow. But it’s late here now.
[19:31:11] <andypugh> Night all
[19:31:11] <cradek> I thought that too, but after 5 seconds I realized e is a word
[19:31:15] <cradek> g'night
[19:31:38] <andypugh> It took me about as long, hence the smiley.
[19:31:46] <cradek> figured :-)
[20:18:47] <cradek> I cringe to think of the spinbox implementation that gives you 1e-10 after (I assume) you click up for a while and then back down
[20:26:01] <jepler> yeah me too, but turns out it's not hard at all
[20:26:01] <jepler> >>> x = 0.0
[20:26:02] <jepler> >>> x += 0.1; x += 0.1; x += 0.1
[20:26:02] <jepler> >>> x -= 0.1; x -= 0.1; x -= 0.1
[20:26:02] <jepler> >>> x
[20:26:04] <jepler> 2.7755575615628914e-17
[20:26:13] <jepler> oh floating point, is there no problem so simple you can't screw i tup
[20:28:51] <cradek> bbbbut that's not how you should implement it
[20:29:31] <cradek> i=0; i++; i++; i++; i--; i--; i--; i*0.1
[20:30:10] <cradek> although I've written a range/wraparound error haven't I
[20:30:34] <jepler> only if someone clicks two billion times, I suppose
[20:30:38] <cradek> yeah
[20:34:49] <jepler> but in this kind of box you may also be able to type 0.1, or maybe even 0.33, and then still click the up and down arrows
[20:35:30] <cradek> oh, then you're so doomed
[20:43:16] <jepler> nah, you could use decimal arithmetic
[20:43:28] <jepler> then every human will be happy with the outcome of adding 0.1 or entering 0.33
[20:44:21] <jepler> ob:
http://www.smbc-comics.com/index.php?db=comics&id=2312
[20:44:29] <jepler> er that's not the right link
[20:45:12] <jepler> http://www.smbc-comics.com/index.php?id=2999
[21:16:27] <cradek> oh good, I don't have to go looking for that one now
[22:22:12] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 d1f2324 06linuxcnc 10lib/python/rs274/glcanon.py glcanon.py updates readability etc for JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d1f2324
[22:22:13] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 634fb67 06linuxcnc 10src/emc/usr_intf/gremlin/gremlin.py gremlin.py: update WRAPPED_ROTARY,num_joints JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=634fb67
[22:22:13] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 c06e26c 06linuxcnc 10lib/python/gladevcp/hal_gremlin.py hal_gremlin.py remove adjust of lathe home[] JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c06e26c
[22:22:14] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 4d2e47c 06linuxcnc 10(5 files in 5 dirs) glcanon.py: new func GlCanonDraw:init_glcanon() JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4d2e47c
[22:22:18] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 05e0118 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py gscreen update for joints_axes +debugging aids JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=05e0118
[22:22:23] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 cb5adf8 06linuxcnc 10lib/python/rs274/glcanon.py 10src/emc/usr_intf/axis/scripts/axis.py glcanon.py establish no_joint_display locally JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cb5adf8
[22:46:42] <linuxcnc-build> build #2377 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2377 blamelist: Dewey Garrett <dgarrett@panix.com>
[22:58:47] <linuxcnc-build> build #4035 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4035 blamelist: Dewey Garrett <dgarrett@panix.com>
[23:38:11] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 103bfe9 06linuxcnc 10docs/man/man9/kins.9 kins.9 fix example error JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=103bfe9