Back
[10:06:40] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes12 a687caa 06linuxcnc 10lib/python/rs274/glcanon.py 10src/emc/usr_intf/axis/scripts/axis.py axis.py,glcanon.py rework icons display (JA) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a687caa
[10:06:40] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes12 8a4b6ec 06linuxcnc 10(9 files) configs/sim/axis/ja_tests(new)temp sim configs JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8a4b6ec
[12:17:28] <ikcalB> hi guys. We've switched to a new MB lately, which provides excellent realtime capability (BIOS = stock => HT, VTx, ... all the bad enabled), still well below 20µs jitter (rather <10). BOARD: Fujitsu Siemens D3243-S mini ITX
[12:18:57] <ikcalB> yet we've got increasingly often: "unexpected realtime delay ... In recent history there were...". I looked up the code, and want to ask, whether I understand `src/emc/motion/control.c@258` correctly:
[12:20:20] <ikcalB> if I've got a board, which constantly has ultra low latency, occurs to has 1 cycle which is 20% above the 'recent history', the code issues a warning. not configurable, and no matter how little this delay is in relation to our thread-times?
[12:28:50] <mozmck> ikcalB: Are you using RTAI?
[12:32:02] <ikcalB> mozmck: yes we are. what are you thinking?
[12:40:08] <pcw_home> for velocity mode systems that have external hardware (velocity mode servos or hardware stepgens)
[12:40:09] <pcw_home> I would advocate removing the real time error pop-up and just logging the error (and say counting the occurrences ) ,
[12:40:11] <pcw_home> if it does not cause a following error, why do we care?
[12:40:12] <pcw_home> while I'm dreaming, I would also like independent following error limits set for warning and for fault
[12:46:41] <jepler> I agree that someone should have the courage to remove the "realtime delay" message from motion
[12:47:23] <jepler> that was added at a time that we didn't have an indication of an actual missed deadline from the RTOS and we created this heuristic
[12:53:14] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/remove-heuristic-delay-warning ec56cef 06linuxcnc 10src/emc/motion/control.c motion: remove heuristic delay warning * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ec56cef
[12:53:25] <jepler> I can't really test it since I have no rtai systems atm
[12:53:27] <jepler> but something like the above
[12:53:57] <mozmck> nice!
[12:54:28] <mozmck> I was wondering why that was there as well as in rtapi
[12:54:33] <jepler> I'm pretty sure at the time we added that, we thought (rightly or not) that some RTAI version actively in use didn't indicate missed periods / overruns at all
[13:08:57] <ikcalB> jepler: many tnx. we're deploying some machines atm - but only with upstream binaries. as soon as that's available, we'll be happy to test that!
[13:10:04] <jepler> I hope someone will test it, since as I've stated I can't. No rtai system, and certainly none that spuriously show that message.
[13:10:25] <jepler> ultimately it's up to seb_kuzminsky what goes into a future 2.7 release
[13:48:28] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes12 5589031 06linuxcnc 10(8 files in 7 dirs) motion: disallow jogging axis w locking indexer JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5589031
[15:10:54] <seb_kuzminsky> ikcalB: you can test jepler's branch by installing the deb from here:
http://buildbot.linuxcnc.org/dists/wheezy/scratch-rt/binary-i386/linuxcnc_2.7.4~jepler.2.7.remove.heuristic.delay.warning~ec56cef_i386.deb
[15:11:05] <seb_kuzminsky> (for wheezy/rtai)
[15:23:17] <jepler> thanks seb_kuzminsky, buildbot
[16:09:58] <seb_kuzminsky> i had disabled deb building on armhf because the buildbot didn't know how to parallelize the deb build, and it took like 4 hours
[16:10:33] <seb_kuzminsky> i recently taught the buildbot to build each deb with something like "-j $(nproc)", and the u3 builds linuxcnc.deb in 68 minutes, maybe it's time to turn it back on
[16:10:43] <seb_kuzminsky> i'll try it
[16:25:48] <jepler> I hope I didn't get too grumpy on-list
[17:10:44] <CaptHindsight> nah
[17:15:16] <cradek> > Every ARM SBC is different and terrible in its own way.
[17:15:21] <cradek> ain't that the truth
[17:18:30] <CaptHindsight> I try to get the point across that it's tough to beat a low cost to free PC with an ARM board for machine control with a GUI
[17:19:42] <CaptHindsight> especially with Intel offering new boards with cpu's for <$50
[17:21:27] <cradek> and I imagine they actually boot the OS you already have, and run the binaries you already have, and manage to have working USB and network and video
[17:23:29] <cradek> (ok not always video)
[17:27:02] <CaptHindsight> many ARM boards claim that they run some Linux distro or image
[17:28:22] <CaptHindsight> then when you decide to try it and follow 17 different howto's that don't work you find that yeah it boots but ...
[17:28:49] <CaptHindsight> its far from having all the drivers or a stable toolchain
[17:34:03] <CaptHindsight> memleak is playing with a new ARM board, going to see if he can build his own kernels but still use the binary video drivers
[17:54:39] <tinkerer> @ Mr. Grumpy: ;)
[17:56:20] <tinkerer> I've a questions to the spi transfer in the 7I90HD
[17:56:54] <tinkerer> is the transfer full or half duplex?
[18:00:53] <tinkerer> e.
[18:00:53] <tinkerer> Master asserts /CS
[18:00:53] <tinkerer> Master sends 0x1000A830 7I90HD echos dummy data
[18:00:53] <tinkerer> Master sends 0x00000000 7I90HD echos register data @0x1000
[18:00:53] <tinkerer> Master sends 0x00000000 7I90HD echos register data @0x1004
[18:00:55] <tinkerer> Master sends 0x00000000 7I90HD echos register data @0x1008
[18:00:57] <tinkerer> Master de-asserts /CS
[18:02:47] <tinkerer> is the "dummy data" due to full duplex?
[18:06:14] <seb_kuzminsky> jepler: your email was a breath of fresh air
[18:07:55] <tinkerer> jepler: around?
[18:46:22] <seb_kuzminsky> linuxcnc-build: force build --branch=master 0000.checkin
[18:46:23] <linuxcnc-build> build #3981 forced
[18:46:23] <linuxcnc-build> I'll give a shout when the build finishes
[19:10:34] <linuxcnc-build> build #2161 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2161
[19:15:40] <linuxcnc-build> build #3981 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3981
[19:19:03] <jepler> make: *** [.html-images-stamp] Illegal instruction
[19:19:54] <jepler> also in the failure back in build 2156
[19:20:23] <jepler> Segmentation fault
[19:20:24] <jepler> make: *** [.html-images-stamp] Error 139
[19:20:29] <jepler> build 2153
[19:20:40] <jepler> not always the same though
[19:21:16] <jepler> and of course sometimes it succeeds
[20:12:06] <jepler> no failures locally on my u3, so I'm inclined to agree it's hardware.
[20:12:12] <jepler> too bad the u3 is out of production
[20:21:25] <seb_kuzminsky> the c2 seems like the replacement
[20:22:11] <seb_kuzminsky> maybe the fan seized and the cpu overheated and now it's cooked
[20:22:15] <jepler> for building linuxcnc? yes it seems like a likely choice.
[20:22:35] <jepler> that would be too bad, but it sure could be :(
[20:22:51] <seb_kuzminsky> i'm gonna try setting a fan pointing at it and see if that helps
[20:23:08] <jepler> did you put fresh thermal paste on when you re-seated the heatsink?
[20:23:14] <seb_kuzminsky> because i don't really feel like messing with another stupid little arm board at the moment
[20:23:18] <seb_kuzminsky> no :-/
[20:23:21] <jepler> istr it came with some janky adhesive only
[20:23:29] <jepler> I don't blame you. spend time on more important things.
[20:23:32] <seb_kuzminsky> i looked but couldnt find my little tube of the gunk
[20:23:43] <seb_kuzminsky> i wonder where i can buy some locally
[20:28:30] <mozmck> In inch units, it seems to be common to refer to inches-per-minute (IPM). In metric, is is mm-per-minute, or is mm-per-second more common?
[20:29:08] <cradek> well gcode is mm/min; I can't answer any more generally than that
[20:29:12] <jepler> In distance-per-time mode, F-numbers are always per minute
[20:29:34] <mozmck> Ah, ok - didn't think to check what the gcode was for metric. thanks.
[21:57:59] <seb_kuzminsky> linuxcnc-build: force build --branch=master 0000.checkin
[21:58:00] <linuxcnc-build> build #3982 forced
[21:58:00] <linuxcnc-build> I'll give a shout when the build finishes
[22:36:56] <KGB-linuxcnc> 03Chris Morley 05pnc_bugfix_2.7 0ddc05a 06linuxcnc 10src/emc/usr_intf/pncconf/build_HAL.py pncconf: fix tandem stepper axis configs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0ddc05a
[22:36:56] <KGB-linuxcnc> 03Chris Morley 05pnc_bugfix_2.7 1197715 06linuxcnc 10src/emc/usr_intf/pncconf/tests.py pnncof: fix error when testing with encoders * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1197715
[22:58:47] <linuxcnc-build> build #188 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/188
[23:00:38] <linuxcnc-build> Hey! build 0000.checkin #3982 is complete: Success [3build successful]
[23:00:38] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3982