Back
[02:09:27] <linuxcnc-build> build #311 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/311 blamelist: Chris Radek <chris@timeguy.com>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <jthornton@gnipsel.com>, John Thornton <bjt128@gmail.com>
[05:42:15] <emcPT> Hello
[05:42:15] <emcPT> Can someone inform where gcode.parse is located
[05:42:16] <emcPT> This appears around line 1690 in glcanon.py
[05:42:16] <emcPT> My poor debug skills prevents from finding where the method is implemented
[05:59:34] <emcPT> Found it. Thanks
[06:28:52] <skunkworks> zlog
[07:33:27] <jepler> hm but eventually I ended up with
[07:33:27] <jepler> hm2/hm2_7i92.0: sserial_write:Timeout waiting for CMD to clear
[08:18:32] <pcw_home> Thats the normal error you get when the previous write gets delayed
[08:18:34] <pcw_home> so much that the sserial xfer is not done by the next servo thread time
[08:25:58] <skunkworks> The matsuura computer is up and linuxcnc running - the only time I got an error was when we unplugged the 7i69 ;)
[08:29:39] <jepler> pcw_home: it wasn't recovering, the sserial error count was up over 100,000 overnight
[08:31:46] <pcw_home> Hmm that is the normal error I see if you get a latency spike so the previous write is delayed
[08:32:01] <jepler> I hope to look into it more this weekend
[08:32:06] <pcw_home> the next cycle works
[08:32:54] <pcw_home> its something that maybe should go through the sserial error filter
[08:40:15] <pcw_home> It is possible there are still bugs in sserial that can cause a hang but I haven't seen one in quite a while (many versions back)
[08:40:17] <pcw_home> Theoretically, regardless of what happens on the serial link, the command will complete in a maximum of measured
[08:40:18] <pcw_home> sserial device response time (measured when device is probed at startup) +40 usec
[08:44:15] <pcw_home> Does linuxCNC work with absolute encoders?
[08:44:17] <pcw_home> https://forum.linuxcnc.org/forum/38-general-linuxcnc-questions/30959-no-force-homing-and-min-max-limits-for-axes
[08:44:18] <pcw_home> seems like you would need to tell motion that you have absolute encoders
[08:44:50] <jepler> I thought several absolute encoders were supported, but of course I have zero experience with them
[08:46:29] <pcw_home> I _think_ OPs issue is that they want no_force_homing=1 but then soft limits are not setup
[08:59:15] <cradek> part of real support for absolute encoders would be coming up in an already-homed state when appropriate
[08:59:21] <cradek> and no, there is not support for that, that I know of
[09:00:17] <cradek> but I'd think you could just use the homing method that causes no motion to get into that state, if you already had absolute feedback of whatever kind
[09:04:07] <pcw_home> It sounds like the soft limits are not setup in that case, but I have not verified this
[09:05:19] <skunkworks> I would think you would have to go to a known location first - then home with no motion.
[09:05:30] <skunkworks> then soft limits should work
[09:05:51] <skunkworks> but how do you initially setup that location?
[09:06:49] <pcw_home> you are always in a known location with absolute encoders :-)
[09:08:20] <pcw_home> no need to home or move at startup
[09:21:15] <archivist> only after you told it the first time
[09:25:29] <pcw_home> not sure what you mean, the SSI absolute encoders I have have permanent memory (gears)
[09:26:39] <pcw_home> resolute encoders have the absolute position written on the scale
[09:27:03] <pcw_home> Okuma encoders also use gears
[09:27:29] <archivist> machine to the number in the encoder relation
[09:28:19] <pcw_home> That can be done once in the factory...
[09:28:52] <archivist> er, machine integrators are the "factory"
[09:29:37] <pcw_home> right but its not something linuxcnc needs to handle
[09:30:10] <pcw_home> (well a absolute offset might ease setup)
[09:30:15] <archivist> sure it is, how else will 235.5 = 2" from the left
[09:30:50] <archivist> ie some constant has to be setable by a once off real homing
[09:31:00] <pcw_home> Nope
[09:31:52] <archivist> unbolt the ballscrew turn a gnats, now what
[09:32:18] <pcw_home> one thats done its good forever
[09:33:06] <archivist> every maintenance and build and each time you lose that offset
[09:33:11] <pcw_home> in other words home is somewhat meaningless with absolute encoders
[09:34:21] <pcw_home> no home switches needed or wanted
[09:34:59] <emcPT> at least limit/safe switches are normally present
[09:35:11] <pcw_home> sure
[09:36:01] <archivist> think about it, the software has no clue until you home once, you do not know machine mechanical position with encoder absolute numbers
[09:36:13] <pcw_home> but they are not used for position reference and the machin is ready to run without any kind of homing sequence
[09:36:20] <archivist> unless you know scale and offset
[09:36:49] <pcw_home> Those are fixed so homing is not requred
[09:37:00] <archivist> this is basic mechanics machine to encoder number
[09:37:48] <pcw_home> sure thats no different with absolute encoders, what is different is that homing is not needed
[09:40:00] <pcw_home> (one of the main advantages of absolute encoders)
[09:40:33] <archivist> without an initial home, you cannot know the absolute encoders N in relation to a machine 0, this is a mechanical problem that needs homing when new and after repair or loss of that offset
[09:41:00] <mozmck> That would simply be done in the ini file I would think...
[09:41:11] <archivist> I agree after on can use the encoders absolute position
[09:41:35] <archivist> on/one
[09:45:02] <jepler> I am fairly confident you can express that in a linuxcnc inifile, but you would still have to "home all" as part of the linuxcnc startup procedure.
[09:46:39] <pcw_home> archivist: the machines with absolute encoder I've seen have no home switch (as it is not needed)
[09:47:41] <jepler> hm, no, that's not what HOME_SEARCH_VEL = 0, HOME_OFFSET != 0 does
[09:47:58] <jepler> I guess somebody with a stake in it should do something
[09:47:59] <archivist> then the integrator has to jog carefully to some place to inform the machine/work out the offset
[09:48:44] <archivist> far better that a real home is there to calibrate that one off
[09:48:59] <pcw_home> machines with volatile absolute position memory (Fanuc Panasonic etc) have a recovery procedure
[09:49:00] <pcw_home> where you do just that (jog to a specific position )
[09:51:56] <seb_kuzminsky> emcPT: i think you're looking for src/emc/rs274ngc/gcodemodule.cc
[09:51:59] <pcw_home> but the whole point of absolute encoders is that for normal use
[09:52:01] <pcw_home> you can avoid the slow (and sometimes hazardous) home procedure
[09:57:35] <seb_kuzminsky> this gui conversation on the list makes me want to revive liblinuxcncui
[09:57:37] <seb_kuzminsky> bbl
[10:28:06] <emcPT> anyone knows why there are ioControl.cc and ioControl_v2.cc? Are both used?
[10:29:10] <cradek> due to bad judgment, we now have two separate iocontrol binaries with different features
[10:29:32] <skunkworks> one or the other. iocontrol_v2 was an attempt to fix issues perceived issues with iocontrol...
[11:20:59] <seb_kuzminsky> "we" should pick one and remove the other
[12:15:39] <KGB-linuxcnc> 03John Morris 05zultron/m98m99 cab68fe 06linuxcnc 10(79 files in 19 dirs) M98/M99 subprograms * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cab68fe
[12:15:39] <KGB-linuxcnc> 03Jason Penn 05zultron/m98m99 716b614 06linuxcnc 10src/emc/rs274ngc/interp_read.cc Made interp_read.cc ignore "O" words that are not an "O" word but just a program title, i.e. "OBoreProject", * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=716b614
[12:15:39] <KGB-linuxcnc> 03John Morris 05zultron/m98m99 fc39d9a 06linuxcnc 03tests/interp/sprutcam-mach-post-bug/expected 03tests/interp/sprutcam-mach-post-bug/test.ngc 03tests/interp/sprutcam-mach-post-bug/test.sh Test for previous commit, "OBoreProject" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fc39d9a
[14:48:35] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 02ab263 06linuxcnc 10src/emc/ini/inihal.cc inihal.cc: local home_offset update missing JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=02ab263
[17:25:48] <jepler> Subject: [ANNOUNCE] 4.6-rc7-rt1
[17:25:48] <jepler> Subject: [ANNOUNCE] 4.6-rc7-rt1
[17:25:49] <jepler> Subject: [ANNOUNCE] 4.6-rc7-rt1
[17:25:49] <jepler> Subject: [ANNOUNCE] 4.6-rc7-rt1
[17:25:53] <jepler> err sorry about that
[17:26:50] <jepler> I guess I'm just excited every time -rt comes out on a new kernel
[17:26:58] <jepler> and this time it's early enough to be in the -rcs
[18:05:10] <andypugh> Does anyone know a neat Pythonic way to get two ints from a tuple of strings?
[18:05:33] <andypugh> Specifically: j,a = int(match.group(1,2))
[18:05:54] <andypugh> Hmm, forget that, a failed attempt.
[18:06:02] <andypugh> j,a = match.group(1,2)
[18:06:18] <andypugh> Maybe I should just split it over two lines.
[20:22:39] <skunkworks> https://www.youtube.com/watch?v=kXLF0u-tdT0
[20:33:03] <skunkworks> zlog
[21:10:25] <jepler> https://emergent.unpythonic.net/files/sandbox/eth-sserial-recovers2.png
[21:10:47] <jepler> I'll leave this up overnight at 5% packet loss
[21:12:51] <jepler> the traces are, top to bottom: the sserial state machine resetting itself after each lost packet, a read-back watchdog output (so you can see it sticking in one state or another during reset), the counter of lost ethernet packets, and the counter of sserial errors; one error is accounted after each reset is complete, which is probably right. but more oddly, the error count is zeroed if a second los
[21:12:57] <jepler> t packet occurs at just the right time in the recovery process. that's weird.
[21:15:39] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 42b212d 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: avoid glitches when starting to run * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=42b212d
[21:15:39] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 9eb6628 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: avoid long wait after lost packet * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9eb6628
[21:15:39] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 551d2ae 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: avoid timeouts 'waiting for CMD to clear' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=551d2ae
[21:15:45] <jepler> branch slightly rebased and pushed
[21:34:47] <mozmck> can the packet loss stuff be backported to 2.7?
[21:44:20] <jepler> I suspect that at a technical level, it would not be hard to cherry-pick it to be based on 2.7 instead of master branch.
[21:46:47] <jepler> .. yes that works (cherry pick completes and it compiles, didn't run it)
[21:48:37] <jepler> obvously there's a higher standard of needing to hear "tested and works for me" before it goes in a stable branch
[21:48:40] <jepler> etc etc
[21:49:01] <jepler> and it touches outside of hm2_eth, so it could unintentially and negatively affect other board types as well
[22:38:10] <seb_kuzminsky> jepler: do you remember what's up with 3724b9bd3?
[22:52:06] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 aaf5c94 06linuxcnc 10debian/configure debian/configure: modernize usage/help message * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=aaf5c94
