Back
[00:12:03] -!- micges_ has quit [Quit: Leaving]
[00:28:59] -!- andypugh has quit [Quit: andypugh]
[00:31:32] <KimK> pcw_home: I just looked at the 7i69 manual (hostmot2 RS-422 serial to Opto-22 24-modules x2). Thanks for providing "Mesa mode" and "Opto-22 mode", nice, that would save a lot of renumbering stickers. (0=23, 1=22, etc.)
[00:32:30] -!- ve7it has quit [Remote host closed the connection]
[00:39:12] -!- asdfasd has quit [Ping timeout: 264 seconds]
[00:49:57] -!- rob_h has quit [Ping timeout: 256 seconds]
[00:56:04] -!- joe9 has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
[01:00:40] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[01:01:16] -!- jfire has quit [Quit: Leaving.]
[01:12:13] -!- ravenlock has quit [Ping timeout: 245 seconds]
[01:22:49] <cmorley1> kwallace: Gscreen
[01:23:03] <cmorley1> shows Y2 view
[01:39:06] -!- Wildhoney has quit [Ping timeout: 264 seconds]
[01:46:36] <pcw_home> Yeah since the data goe through the interface software anyway it was a chance to get the pinout right for OPTO22
[02:04:49] -!- stsydow has quit [Quit: Verlassend]
[02:11:00] -!- jthornton_ [jthornton_!~john@162.72.171.228] has joined #linuxcnc-devel
[02:11:01] -!- jthornton has quit [Read error: Connection reset by peer]
[02:11:01] -!- JT-Shop has quit [Read error: Connection reset by peer]
[02:11:06] -!- JT-Shop-2 [JT-Shop-2!~John@162.72.171.228] has joined #linuxcnc-devel
[02:12:11] -!- Jakobud has quit [Quit: Leaving]
[02:34:41] <KGB-linuxcnc> 03chrisinnanaimo 05master 7a49309 06linuxcnc 10configs/sim/gscreen_custom/industrial_handler.py * gscreen config -fix DTG labels with more then XYV axes
[02:47:31] -!- Valen has quit [Ping timeout: 245 seconds]
[02:52:07] -!- Brandonian has quit [Quit: Brandonian]
[02:54:01] -!- yhoje has quit [Client Quit]
[02:56:52] -!- Valen has quit [Client Quit]
[03:00:04] -!- RangerRick has quit [Remote host closed the connection]
[03:03:32] -!- Keknom has quit [Quit: Leaving.]
[03:24:54] -!- krusty_ar has quit [Remote host closed the connection]
[03:55:26] -!- AR_ has quit [Ping timeout: 245 seconds]
[04:03:23] -!- exeunt has quit [Ping timeout: 245 seconds]
[04:05:30] -!- Valen has quit [Quit: Leaving.]
[04:21:27] -!- deedubs has quit [Ping timeout: 260 seconds]
[04:34:42] -!- FinboySlick has quit [Quit: Leaving.]
[04:57:15] -!- sumpfralle has quit [Quit: Leaving.]
[05:09:02] -!- jp__ has quit [Ping timeout: 252 seconds]
[05:24:07] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[05:24:40] -!- tjb1 has quit [Quit: tjb1]
[05:33:47] -!- dhoovie has quit [Ping timeout: 246 seconds]
[05:54:26] -!- dhoovie|2 has quit [Ping timeout: 246 seconds]
[05:54:54] <kwallace> cmorley1: Sorry I missed you. I started going through the gscreen files. There is a big difference in how the standard LinuxCNC, GScreen and my systems work. I'm trying to figure out the best way to show the rear tool configuration and realized just flipping the view over, so that Y points away from the viewer, should make a lot of the tweaks we've made with glcanon and hershey unneeded.
[05:58:32] <cmorley1> Y2 has a few problems : text is backwards
[06:01:26] -!- Fox_Muldr has quit [Ping timeout: 246 seconds]
[06:01:59] <cmorley1> and the tool is hidden
[06:04:43] -!- kwallace1 [kwallace1!~kwallace@smb-4.sonnet.com] has joined #linuxcnc-devel
[06:05:19] -!- kwallace has quit [Ping timeout: 264 seconds]
[06:06:12] -!- hashfail has quit [Ping timeout: 248 seconds]
[06:07:11] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[06:07:21] -!- gimps has quit [Ping timeout: 240 seconds]
[06:07:28] <cmorley1> or I think it is - I may have Y offsets that are messing that up...
[06:08:32] <kwallace1> I had to fix the text with our current version. We use a rear_tool flag to conditionally change the glstring or somesuch commands for each feature problem that comes up. For some reason I had not looked a glnav to see what the y2 view did. Rather than the rear_tool flag it seems that the y2 function should be where the view and related feature orientations should be set. It seems not all of the view parameters are controlled in the set_view fu
[06:12:52] <cmorley1> somebody else figured out the Y2 view. It was a AXIS add on with .axixrc file. I just added it to gnav.py in master and added access to it from gremlin
[06:13:18] <cmorley1> def set_view_y2(self):
[06:13:18] <cmorley1> self.reset()
[06:13:18] <cmorley1> glRotatef(90, 1, 0, 0)
[06:13:18] <cmorley1> glRotatef(90, 0, 1, 0)
[06:13:18] <cmorley1> mid, size = self.extents_info()
[06:13:18] <cmorley1> glTranslatef(-mid[0], -mid[1], -mid[2])
[06:13:18] <cmorley1> self.set_eyepoint_from_extents(size[0], size[2])
[06:13:19] <cmorley1> self.perspective = False
[06:13:19] <cmorley1> self.lat = -90
[06:13:20] <cmorley1> self.lon = 0
[06:13:20] <cmorley1> self._redraw()
[06:13:25] <cmorley1> from gnav
[06:15:11] <kwallace1> It doesn't seem to touch the text bits at all. In LinuxCNC the text is adjusted of each view in hersey based on the extents values which doesn't always work.
[06:19:31] <cmorley1> Well you have deeper understanding of it then me. strangely in Y2 the axis text is flipped but the extends numbers are not.
[06:21:18] <cmorley1> I assume extents is drawn after the plot is flipped....
[06:26:48] <kwallace1> I don't know because they are handled in different areas of the code, maybe tacked on at different times. I actually thought you were the expert.:) I feel like I'm only seeing the trunk of the elephant.
[06:30:26] <kwallace1> Is there anything between the parameters being set in gscreen.py and gremlin.py? I see something like self.widget.gremlin.xxxxx = somevalue but I don't see how it gets to gremlin.
[06:36:48] -!- steves_logging has quit [Ping timeout: 260 seconds]
[06:38:43] -!- thecubical has quit [Quit: Page closed]
[06:47:01] <kwallace1> As for the text, I think everything gets placed in a set reference frame. Changing the view rotates the frame and everything in it, so the text and some other things need to be changed to face the viewer, but the the plot and axis pointers need to follow the reference frame. That's why I'm thinking the things that need to keep facing the viewer should be a least called out in the set_view_x,y,z,y2... functions in glnav. What would be nice is t
[06:49:10] -!- tanepiper has quit [Ping timeout: 256 seconds]
[06:51:04] <kwallace1> This OpenGL stuff is pretty nifty stuff, I wish I had the time to learn more. The documentation often talks about it being used for video games so Gremlin should be able to be brought up to the level of these games.
[07:03:00] -!- kwallace1 [kwallace1!~kwallace@smb-4.sonnet.com] has parted #linuxcnc-devel
[07:18:48] -!- R2E4_AWY has quit [Read error: Connection reset by peer]
[07:25:35] Cylly is now known as Loetmichel
[07:52:02] -!- 20WAB5CI3 [20WAB5CI3!~quassel@2a01:e34:ee61:a5f0:5957:199:b0d8:9e58] has joined #linuxcnc-devel
[08:01:09] -!- racycle has quit [Quit: racycle]
[08:17:06] -!- toastyde1th has quit [Ping timeout: 245 seconds]
[08:33:50] -!- b_b has quit [Changing host]
[08:37:39] -!- rob_h [rob_h!~rob_h@027c16a0.bb.sky.com] has joined #linuxcnc-devel
[09:08:00] -!- pjm has quit [Read error: Connection reset by peer]
[09:17:22] -!- mackerski has quit [Client Quit]
[09:30:12] -!- vladimirek has quit [Remote host closed the connection]
[09:31:32] <KGB-linuxcnc> 03git 05dynload-rtapi 9067043 06linuxcnc 10src/ 10rtapi/Submakefile 03rtapi/flavor1.c 03rtapi/rtapi_flavor.h 03rtapi/rtapi_load.c * rtapi flavor loading example
[09:31:33] <KGB-linuxcnc> 03git 05dynload-rtapi 97d6a04 06linuxcnc 10src/ 03rtapi/rtapi_kdetect.c 03rtapi/rtapi_kdetect.h * import kdetect
[09:31:36] <KGB-linuxcnc> 03git 05dynload-rtapi 07416f7 06linuxcnc 10src/ 10hal/hal.h 10hal/hal_lib.c * hal_lib: introduce constructors, hal_rtapi_attach()/hal_rtapi_detach()
[09:31:44] <KGB-linuxcnc> 03git 05dynload-rtapi b31fec3 06linuxcnc 10src/hal/hal_lib.c * hal_lib: remove refcounting scheme
[09:31:49] <KGB-linuxcnc> 03git 05dynload-rtapi b9a5e9b 06linuxcnc 10src/rtapi/sim_rtapi_app.cc * rtapi_app: carry over from rtapi-startup-sequencing
[09:31:56] <KGB-linuxcnc> 03git 05dynload-rtapi fdf068e 06linuxcnc 10src/ 10Makefile 03rtapi/rtapi_main.c * rtapi.so: add rtapi_app_main/rtapi_app_exit stubs
[09:32:03] <KGB-linuxcnc> 03git 05dynload-rtapi 2acab34 06linuxcnc 10scripts/realtime.in 10src/hal/hal_lib.c 10src/rtapi/rtapi_main.c * catch up commit before me crashing
[09:32:10] <KGB-linuxcnc> 03john 05dynload-rtapi 97e4b9e 06linuxcnc 10src/ 10(11 files in 2 dirs) * rtapi: herd all rtapi_*() calls through rtapi_switch for universal binary
[09:32:17] <KGB-linuxcnc> 03git 05dynload-rtapi 331ae3c 06linuxcnc 10src/ 10(7 files) * rtapi: dont EXPORT_SYMBOL anything except rtapi_switch
[09:32:23] <KGB-linuxcnc> 03git 05dynload-rtapi f0d650c 06linuxcnc 10src/rtapi/rtapi_shmem.c * rtapi_shmem: fix typo
[09:32:29] <KGB-linuxcnc> 03git 05dynload-rtapi 3956e82 06linuxcnc 10src/ 10(7 files) * rtapi: remove all exported symbols except rtapi_switch
[09:32:35] <KGB-linuxcnc> 03git 05dynload-rtapi 57a85ce 06linuxcnc 10src/emc/motion/stashf.c * stashf.c: include rtapi.h to get proper symbol visibility
[09:32:42] <KGB-linuxcnc> 03git 05dynload-rtapi 3b6741b 06linuxcnc 10src/rtapi/Submakefile * rtapi: build ulapi.so
[09:32:48] <KGB-linuxcnc> 03git 05dynload-rtapi 42b3ec6 06linuxcnc 10src/ 10hal/Submakefile 10hal/hal_lib.c * hal: remove ULAPI objects from hal_lib link
[09:32:55] <KGB-linuxcnc> 03git 05dynload-rtapi b20fc2f 06linuxcnc 10src/ 10rtapi/Submakefile 10rtapi/rtapi.h 10rtapi/rtapi_common.c * rtapi: make rtapi functions go through a pointer, not a struct ref
[09:33:02] <KGB-linuxcnc> 03git 05dynload-rtapi 3e455f2 06linuxcnc 10src/ 10hal/Submakefile 10hal/hal_lib.c * hal_lib/ULAPI: dynload ulapi.os - first round
[09:33:10] <KGB-linuxcnc> 03git 05dynload-rtapi 64593ba 06linuxcnc 10src/rtapi/rtapi_proc.h * rtapi: export rtapi_dir
[09:33:15] <KGB-linuxcnc> 03git 05dynload-rtapi f4b1583 06linuxcnc 10src/hal/hal_lib.c * hal_lib.c: touchups
[09:33:24] <KGB-linuxcnc> 03git 05dynload-rtapi e75e060 06linuxcnc 10src/hal/hal_lib.c * hal_lib.c: TODO note
[09:33:26] <linuxcnc-build> build #46 of precise-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/46 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[09:35:18] -!- Wildhoney has quit []
[09:37:09] <linuxcnc-build> build #844 of lucid-rtai-i386-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/844 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[09:39:49] <linuxcnc-build> build #845 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/845 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[09:44:53] -!- V0idExp has quit [Ping timeout: 252 seconds]
[09:46:11] <linuxcnc-build> build #847 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/847 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[09:46:41] <linuxcnc-build> build #844 of hardy-amd64-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-realtime-rip/builds/844 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[09:46:45] <linuxcnc-build> build #845 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/845 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[10:07:47] -!- syyl_ws has quit [Quit: Verlassend]
[10:19:46] -!- moonlite has quit [Ping timeout: 260 seconds]
[10:19:47] -!- speakman has quit [Ping timeout: 260 seconds]
[10:19:47] -!- adb has quit [Ping timeout: 255 seconds]
[10:19:47] -!- syyl_ has quit [Ping timeout: 255 seconds]
[10:19:47] -!- logger[mah] has quit [Ping timeout: 255 seconds]
[10:19:47] -!- korsi has quit [Ping timeout: 260 seconds]
[10:19:48] -!- postaL has quit [Ping timeout: 255 seconds]
[10:19:48] -!- emel has quit [Ping timeout: 260 seconds]
[10:19:49] -!- logger[mah] [logger[mah]!~loggermah@mah2.mah.priv.at] has joined #linuxcnc-devel
[10:19:49] -!- speakman_ has quit [Changing host]
[10:19:52] -!- vax- has quit [Ping timeout: 260 seconds]
[10:19:52] -!- zomg has quit [Ping timeout: 260 seconds]
[10:20:15] -!- stsydow has quit [Remote host closed the connection]
[10:20:40] -!- korsi [korsi!~korsi@adsl-82-141-118-85.kotinet.com] has joined #linuxcnc-devel
[10:20:41] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[10:20:46] zomg is now known as Guest27442
[10:22:41] <linuxcnc-build> build #843 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/843 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[10:25:19] jthornton_ is now known as jthornton
[10:31:12] -!- phantoneD has quit [Ping timeout: 276 seconds]
[10:37:52] <linuxcnc-build> build #848 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/848 blamelist: Michael Haberler <git@mah.priv.at>
[10:37:58] <linuxcnc-build> build #845 of hardy-amd64-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-realtime-rip/builds/845 blamelist: Michael Haberler <git@mah.priv.at>
[10:49:35] -!- skunkworks has quit [Remote host closed the connection]
[11:17:45] <linuxcnc-build> build #844 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/844 blamelist: Michael Haberler <git@mah.priv.at>
[11:25:32] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:35:15] -!- mourner has quit [Quit: mourner]
[11:53:17] Guest27442 is now known as zomg
[11:55:59] -!- fomox has quit [Ping timeout: 246 seconds]
[12:06:56] -!- micges [micges!~micges@acxc34.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[12:23:46] -!- Valen has quit [Quit: Leaving.]
[12:43:04] -!- ravenlock has quit [Remote host closed the connection]
[12:56:54] -!- stsydow has quit [Ping timeout: 252 seconds]
[12:57:56] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[13:03:54] -!- mourner has quit [Quit: mourner]
[13:13:03] -!- syyl__ has quit [Ping timeout: 276 seconds]
[13:28:52] -!- theorbtwo has quit [Ping timeout: 248 seconds]
[13:32:42] <KGB-linuxcnc> 03git 05dynload-rtapi 22e3e0b 06linuxcnc 10scripts/rtapi.conf.in 10src/Makefile.inc.in 10src/Makefile.modinc.in 10src/configure.in * configure: add GIT_VERSION tag in config.h, Makefine.*inc, rtapi.conf
[13:32:42] <KGB-linuxcnc> 03git 05dynload-rtapi 042a9bb 06linuxcnc 10src/ 10hal/hal_lib.c 10rtapi/rtapi.h 10rtapi/rtapi_common.c 10rtapi/rtapi_main.c * rtapi, hal_lib: add GIT_VERSION string, sanity checks
[13:32:47] <KGB-linuxcnc> 03git 05dynload-rtapi 6c2bec6 06linuxcnc 10src/configure.in * configure: fix usage of get-version-from-git
[13:44:25] -!- mhaberler has quit [Quit: mhaberler]
[13:45:52] -!- JoeyJoeJo has quit [Read error: Connection reset by peer]
[13:47:54] <linuxcnc-build> build #849 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/849 blamelist: Michael Haberler <git@mah.priv.at>
[13:48:01] <linuxcnc-build> build #846 of hardy-amd64-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-realtime-rip/builds/846 blamelist: Michael Haberler <git@mah.priv.at>
[13:56:25] R2E4 is now known as R2E4_awy
[14:12:11] -!- Spida has quit [Remote host closed the connection]
[14:17:36] -!- Spida has quit [Ping timeout: 264 seconds]
[14:27:55] -!- tjb1 has quit [Quit: tjb1]
[14:29:58] <linuxcnc-build> build #845 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/845 blamelist: Michael Haberler <git@mah.priv.at>
[14:30:57] -!- kwallace [kwallace!~kwallace@smb-27.sonnet.com] has joined #linuxcnc-devel
[14:33:48] -!- maximilian_h has quit [Quit: Leaving.]
[14:35:50] -!- AR_ has quit [Ping timeout: 240 seconds]
[14:40:22] -!- chillly has quit [Quit: Leaving]
[14:46:09] JT-Shop-2 is now known as JT-Shop
[14:49:21] -!- zzolo has quit [Quit: zzolo]
[14:54:26] -!- theorbtwo has quit [Read error: Connection reset by peer]
[14:57:13] -!- kwallace1 [kwallace1!~kwallace@smb-55.sonnet.com] has joined #linuxcnc-devel
[14:59:00] -!- kwallace has quit [Ping timeout: 264 seconds]
[15:05:40] nuke is now known as Guest90209
[15:07:45] <seb_kuzminsky> .sb goto -30
[15:07:49] <seb_kuzminsky> err
[15:08:34] <skunkworks> heh
[15:08:47] <cradek> seb_kuzminsky: on a mac?
[15:09:01] <cradek> also, hi!
[15:12:24] <seb_kuzminsky> hi!
[15:12:29] <seb_kuzminsky> yes, a mac :-/
[15:12:37] <seb_kuzminsky> i have no idea where page up is on this thing
[15:12:55] <cradek> wonder if you could add some keys to one of those...
[15:13:07] <seb_kuzminsky> maybe with a scanned matrix keypad ;-)
[15:13:11] <cradek> haha
[15:13:23] <seb_kuzminsky> oh, fn+up seems to act like page up
[15:14:04] <cradek> mac hardware seems neat in many ways, but the keyboard has stopped me from ever getting one (I'd get an older one, and run linux on it, of course)
[15:14:19] -!- krusty_ar has quit [Ping timeout: 264 seconds]
[15:14:29] <seb_kuzminsky> the hardware is the best i've ever used
[15:14:42] <seb_kuzminsky> it's still running mac os, due to work requirements
[15:14:46] <cradek> https://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/Clamshell_iBook_G3.jpg/200px-Clamshell_iBook_G3.jpg
[15:14:52] <cradek> I actually have one of these, and it still works fine
[15:15:01] <cradek> running dapper
[15:15:09] <cradek> brb
[15:15:19] <seb_kuzminsky> wow, looks like something from toys'r'us
[15:16:55] -!- korsi_ [korsi_!~korsi@adsl-82-141-118-85.kotinet.com] has joined #linuxcnc-devel
[15:21:36] <cradek> yeah, they made very silly-looking machines for a while
[15:21:40] -!- korsi has quit [*.net *.split]
[15:21:40] -!- L33TG33KG34R has quit [*.net *.split]
[15:21:40] -!- DaViruz has quit [*.net *.split]
[15:21:40] -!- ssi has quit [*.net *.split]
[15:21:41] -!- blommer has quit [*.net *.split]
[15:21:41] -!- pcw_home has quit [*.net *.split]
[15:21:41] -!- ds3 has quit [*.net *.split]
[15:21:41] -!- cpresser has quit [*.net *.split]
[15:22:38] -!- mk0 has quit [Quit: Leaving]
[15:24:12] -!- jepler has quit [Ping timeout: 264 seconds]
[15:28:16] <cradek> seb_kuzminsky: any more progress with the SMP rtai build on UP?
[15:28:18] -!- stsydow has quit [Ping timeout: 264 seconds]
[15:33:25] -!- pcw_home [pcw_home!~chatzilla@ip-66-80-167-54.sjc.megapath.net] has joined #linuxcnc-devel
[15:46:40] -!- jepler [jepler!~jepler@emc/developer/pdpc.professional.jepler] has joined #linuxcnc-devel
[15:48:28] speakman_ is now known as speakman
[15:51:16] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[15:54:21] <seb_kuzminsky> cradek: sort of
[15:54:24] <seb_kuzminsky> https://github.com/SebKuzminsky/rtai/commits/prerelease-3
[15:54:42] <seb_kuzminsky> that branch runs on a UP machine with an SMP kernel
[15:54:56] <seb_kuzminsky> but i still have that strange problem that crashed my mill, i haven't debugged that at all
[15:55:05] <seb_kuzminsky> brb
[15:55:12] <skunkworks> should I run it on the k&t
[15:55:14] <skunkworks> ?
[15:55:16] <skunkworks> ;)
[15:58:49] <pcw_home> Wonder how a crash like that can happen? Watchdog should bite in any real crazyness,
[15:58:51] <pcw_home> if position commands were crazy you would expect a following error
[15:58:52] <pcw_home> if position command were out of range you would expect a soft limits error
[15:59:54] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[16:00:00] <cradek> it would be nice to know whether the watchdog bit
[16:00:45] <pcw_home> do the soft limits do a stopping distance calc?
[16:00:52] <cradek> it seems something about seb's estop is not good enough to prevent a crash, so I don't think we can conclude that a crash means the watchdog DIDN'T work
[16:01:58] <pcw_home> for servos you really want to dump the DC bus on estop
[16:02:23] <pcw_home> coasting is not good
[16:02:24] <cradek> I think his machine disconnects the motors from the drives and brakes them
[16:02:59] <cradek> but that is from memory and has not been proven by looking at the wiring diagram OR the machine :-)
[16:03:20] <pcw_home> do soft limits do a stopping distance calculation?
[16:04:17] <cradek> stops at the soft limit are controlled stops just like any other jog destination
[16:05:16] <pcw_home> OK so that adds to the mystery of what can cause a crash like this
[16:05:30] <cradek> but I doubt he even issued a move - soft limits are moot
[16:06:45] <pcw_home> Ahh so soft limits are just applied to the planner
[16:07:20] <cradek> they're really only a thing for jogging
[16:08:27] <cradek> because if you program g0 x99999, it will never be issued. it's not like it gets shortened at the limit, like a "continuous" jog does
[16:08:58] <pcw_home> OK
[16:09:07] <seb_kuzminsky> so i started linuxcnc with the version of rtai in that branch above, and the 5i22 immediately got a watchdog bite
[16:09:19] <seb_kuzminsky> i reset it with halcmd, and it immediately bit again
[16:09:25] <seb_kuzminsky> so i quit linuxcnc and restarted it
[16:09:39] <seb_kuzminsky> and it immediately ran away and crashed my machine :-(
[16:09:48] <seb_kuzminsky> that was the last time i ran it
[16:09:57] <seb_kuzminsky> i haven't tried to debug it o ranything since then
[16:10:17] <pcw_home> I can see you would not like a repeat performance
[16:10:36] <seb_kuzminsky> i need to set up a spare machine to test this stuff with
[16:10:51] <seb_kuzminsky> i have a computer i can use, i just haven't gotten to it
[16:10:54] <cradek> is there a time at startup where we're not watchdog-protected?
[16:11:20] <pcw_home> almost seems like that
[16:11:37] <seb_kuzminsky> yes there is
[16:11:56] <seb_kuzminsky> when the card is first initialized by hm2_register(), the watchdog is not set to run
[16:12:05] <cradek> on second thought, I can't conclude that is the problem. Imagine the watchdog gets petted regularly, but the dac command is mangled
[16:12:23] <seb_kuzminsky> as soon at you 'halcmd start' and start running hm2_read/hm2_write/hm2_pet_watchdog, the watchdog is initialized
[16:12:44] <pcw_home> You should get a following error in that case (DAC mangled)
[16:13:08] <seb_kuzminsky> this behavior was deliberate, so that the watchdog timeout could be on the order of the servi period, not on the order of the 'init-to-start' interval
[16:13:09] <cradek> it ran long enough, with watchdog petting going on, that you brought it out of estop...?
[16:13:51] <cradek> I assume it did this as soon as you hit machine on?
[16:14:23] -!- cncinator has quit [Read error: Connection reset by peer]
[16:14:24] <seb_kuzminsky> i dont remember now if the runaway happened when i turned the machine on (F1, F2) or when i commanded it to home
[16:14:51] <seb_kuzminsky> which would be useful to know... sorry, i was tired and a bit frazzled
[16:15:11] <pcw_home> do you have reasonable ferror numbers?
[16:15:20] <seb_kuzminsky> yes, they're all small
[16:16:15] <seb_kuzminsky> err, not as small as they should be, but still small
[16:16:16] <pcw_home> so either it thought it was a sane trajectory or motion was not looking/running
[16:16:19] <seb_kuzminsky> http://git.highlab.com/?p=emc2-config-bp-r2e3.git;a=blob;f=bp-r2e3.ini;h=f845c163d6bf200c728edc1055ddae36535129b0;hb=HEAD
[16:16:26] <seb_kuzminsky> 258 FERROR = 0.050
[16:16:26] <seb_kuzminsky> 259 MIN_FERROR = 0.005
[16:16:46] -!- mourner has quit [Quit: mourner]
[16:17:00] <cradek> it could have been be writing but not reading
[16:17:07] <cradek> maybe reading is totally broken
[16:17:28] <cradek> that makes it a "regular" runaway due to feedback loss
[16:17:51] <pcw_home> yeah that a possibility
[16:18:18] <pcw_home> thats where the PID saturation check can help
[16:18:21] <cradek> that might make your limit switches not work too (!) if they are hooked into hal instead of estop
[16:18:46] <seb_kuzminsky> my limit switches are not hooked into hal, they are only hooked into the estop
[16:19:07] <cradek> oh right, I remember doing the hard override button
[16:19:17] <seb_kuzminsky> yeah, thanks for that ;-)
[16:19:33] <cradek> heh can you run it without simon's help?
[16:19:50] -!- R2E4 has quit [Ping timeout: 272 seconds]
[16:20:38] <seb_kuzminsky> i can for now, but when i put the touch screen on the front of the machine i'll need a shop assistant
[16:22:22] -!- jfire has quit [Quit: Leaving.]
[16:22:39] <pcw_home> There's no I term so a runaway seems somewhat unlikely (you would have to have a commanded
[16:22:42] <pcw_home> move so small that it did not exceed the ferror yet generated enough P*E to runaway at full speed)
[16:23:13] -!- skorasaurus has quit [Quit: left the building.]
[16:31:25] <seb_kuzminsky> i'm bummed that paolo hasn't picked up the rtai bugfixes that shabby and i have been sending him
[16:32:11] <seb_kuzminsky> i should try to put out a new versions of linux-image-rtai and rtai-modules for folks to test
[16:32:25] <seb_kuzminsky> i'm leaving on a weeks vacation tomorrow, i'll try to do it tonight
[16:32:37] <skunkworks> what!?
[16:32:58] <cradek> cool! going somewhere fun I hope.
[16:33:08] <seb_kuzminsky> florida with the kids :-)
[16:33:20] <seb_kuzminsky> i'll bring my laptop and do some hacking at night ;-)
[16:33:38] <seb_kuzminsky> i really want to fix the mdi queue bug in master, so that we can start merging 2.5 into master again
[16:34:15] <cradek> yeah I saw this morning that someone is asking on the forum about that halui bugfix...
[16:34:36] <cradek> I wish this wasn't all falling to you
[16:34:56] <seb_kuzminsky> is that the one where halui mdi commands get hung up?
[16:34:57] <cradek> is it a hairy merge (with tests!) or a rewrite?
[16:35:09] <seb_kuzminsky> it's a rewrite :-/
[16:35:15] <cradek> no, the jogging-wrong-axis bit
[16:35:32] <seb_kuzminsky> mdi queueing is different enough in 2.5 vs master that the fix in 2.5 doesn't fix the bug in master
[16:35:38] <seb_kuzminsky> ah, that
[16:35:51] <seb_kuzminsky> hhm
[16:36:00] <cradek> he could trivially cherrypick it. not like it's complicated.
[16:36:01] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[16:36:40] <cradek> he's probably using buildbot/master so it's easiest for him to just wait for someone to handle it
[16:37:14] <seb_kuzminsky> do we know he's on master?
[16:37:24] <seb_kuzminsky> oh yeah, the bug isn't in 2.5
[16:37:25] <cradek> it's only broken in master
[16:37:29] <seb_kuzminsky> right
[16:37:55] <seb_kuzminsky> how about i cherry pick the fix into master right now? and watch out for it when i merge next
[16:38:48] <seb_kuzminsky> actually i bet 'git merge' will do the right thing automatically, but i'll keep an eye on it
[16:39:16] <cradek> yeah, if you do that, it'll merge fine
[16:39:28] -!- skunkworks has quit [Ping timeout: 256 seconds]
[16:40:06] -!- tjb1 has quit [Read error: Connection reset by peer]
[16:40:06] tjb1_ is now known as tjb1
[16:42:28] -!- ebarch has quit [*.net *.split]
[16:42:28] -!- archivist has quit [*.net *.split]
[16:42:28] -!- Celelibi has quit [*.net *.split]
[16:47:10] <KGB-linuxcnc> 03jepler 05master 9489b1c 06linuxcnc 10src/emc/usr_intf/halui.cc * halui: don't represent joint number in a hal_bit_t!
[16:47:20] <cradek> yay
[16:48:36] <seb_kuzminsky> ok, if the OP runs v2.6.0-pre0-4251 or newer from the buildbot, they'll have the fix
[16:48:56] <pcw_home> one of the bits is all the same?
[16:49:27] <seb_kuzminsky> huh?
[16:49:45] <pcw_home> the old duck joke
[16:49:54] <seb_kuzminsky> half of all bits are the same ;-)
[16:50:04] <seb_kuzminsky> i dont know the duck joke
[16:50:32] <pcw_home> A straight man!
[16:51:21] <pcw_home> whats the difference between a duck?
[16:51:59] <seb_kuzminsky> it can neither swim?
[16:52:34] <pcw_home> one of its legs is both the same
[16:52:52] <seb_kuzminsky> surrealist humor
[16:53:33] <pcw_home> Must be ancient, heard it from my father
[16:56:14] <seb_kuzminsky> you guys know the flamig duck method for project management?
[16:56:19] <seb_kuzminsky> *flaming
[16:56:30] <seb_kuzminsky> find the nearest flaming duck and stomp on it...
[16:56:52] <pcw_home> That SOP here
[16:57:09] <seb_kuzminsky> and everywhere i've worked, no matter what the bosses say ;-)
[16:57:43] <cradek> if you're surrounded by flaming ducks, it's hard to imagine a better method in the short term
[16:58:27] <cradek> and what software person isn't surrounded by flaming ducks
[16:59:01] <seb_kuzminsky> speaking of ducks, my new employer requires code review of every commit, and i like it
[16:59:23] <seb_kuzminsky> we've found many bugs before they made it into production
[16:59:32] <seb_kuzminsky> this is sometimes called rubber duck debugging
[16:59:56] <cradek> that's probably the best way to improve quality
[16:59:58] <seb_kuzminsky> except with coworkers instead of rubber duckies
[17:01:12] <cradek> keeps you honest too - maybe I oughta look at that stupid realloc one more time - I'd look silly if seb figured out how it's wrong
[17:02:28] <cradek> given that every use of realloc is 90% likely to be wrong, how many reviewers do you need to be 99% sure one is right?
[17:02:44] -!- tjb1 has quit [Quit: tjb1]
[17:02:59] <seb_kuzminsky> is realloc that error prone?
[17:04:59] <cradek> it can move the pointer but often doesn't, so people relying on testing are doomed
[17:06:04] <cradek> but anyway, yeah, pre-commit review is great and you should be happy to work somewhere that knows enough to know that
[17:07:16] <seb_kuzminsky> we also have a really good Quality Engineering department that spends all their time writing tests, which is pretty sweet
[17:09:48] -!- krusty_ar_ has quit [Remote host closed the connection]
[17:12:56] <mozmck> I need something like that. I'm the only one who looks at my code, and some of it at least is a mess!
[17:18:48] -!- stsydow has quit [Ping timeout: 264 seconds]
[17:22:58] -!- stsydow has quit [Client Quit]
[17:26:34] <skunkworks_> I have a lot of comments like 'redo the right way'
[17:26:49] <skunkworks_> or 'If this works - optimize code'
[17:27:02] <skunkworks_> Or 'sorry'
[17:34:18] -!- mackerski has quit [Ping timeout: 245 seconds]
[17:44:54] -!- cncinator has quit [Quit: Verlassend]
[17:47:04] <cncbasher_> could someone check stepconf in 2.5.2 , i believe the custom_postgui.hal file is missing a line for spindle at speed
[17:47:18] <cncbasher_> works fine in master
[17:50:43] -!- 20WAB5CI3 has quit [Remote host closed the connection]
[17:56:47] <jepler> mhaberler: will the multiple-rtos-in-one-build be for userspace threads only, or do you want to support kernel modules and userspace threads from the same build?
[17:56:57] <jepler> the former seems like a substantially more approachable problem
[17:57:01] <mhaberler> it works with rtai already
[17:57:12] <mhaberler> no distinction
[17:57:55] <mhaberler> the branch I pointed you to builds on any base; it just cant build & distinguish them yet
[17:58:32] <mhaberler> I'm right now plugging in the autodetection and compatibility checks - that wasnt an issue so far with one flavor per build
[18:00:08] -!- DaViruz has quit [Read error: Connection reset by peer]
[18:00:33] <jepler> let me ask an unrelated question: do all the flavors we're looking (rtai + the new ones, I don't care about rtl) at support a userspace model? if so, is there a reason to even keep a kernel module model?
[18:01:06] <mhaberler> RTAI has no usable userspace model as far as I can tell
[18:01:39] <mhaberler> that's really the remaining one; xenomai kernel threads are possible but are being deprecated
[18:02:21] <mhaberler> it builds and runs; it's just that there's no upside to it; on some boards xeno-user gives better performance than xeno-kernel
[18:02:43] <jepler> I thought userspace realtime was "lxrt" in rtai
[18:02:51] <jepler> though it's possible we didn't enable it since we didn't need it(?)
[18:02:54] <mhaberler> yes, but no giaranttes
[18:03:05] <mhaberler> guarantees wrt latency as far as I can tell
[18:03:12] -!- adb_ [adb_!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[18:03:26] -!- adb_ has quit [Read error: Connection reset by peer]
[18:03:34] <jepler> oh ok, so I'm hearing that lxrt under rtai has serious caveats
[18:03:44] <mhaberler> maybe I'm totally off though
[18:04:24] <mhaberler> well it would be an interesting experiment if it can be assured lxrt has hard RT behaviour - dumping kernel thread styles would dramatically simplify internal APIs
[18:04:50] <jepler> that was my guess as well
[18:04:51] <mhaberler> but to be honest, I am not firm on lxrt behavior
[18:06:03] <mhaberler> the way I read it currently 'dump kernel threadstyles altogther' implies dumping RTAI, and I dont see that as palpable yet
[18:06:17] <mhaberler> in case such decisions actually were to be made
[18:06:42] <mhaberler> which is why I'm going with both
[18:08:06] <jepler> there is certainly more investigation needed before making a decision like that
[18:08:07] <zultron> mhaberler, the Xenomai team says they're dropping in-kernel fp support for Xenomai v.3. Do you happen to know if that's provided by Xenomai itself or the i-pipe?
[18:08:27] <jepler> ouch that would sure harm us and our use-cases!
[18:08:41] <jepler> except I guess we are using a userspace model in Xenomai?
[18:08:48] <zultron> If in-kernel fp support is provided by i-pipe, that would cause problems for RTAI in the future.
[18:09:02] <mhaberler> well that was one of the reasons why I copped out of xeno-kernel, I got the dressing down by Gilles over at the xenomai list
[18:09:23] <mhaberler> I cant really tell, this aint my space of clue
[18:10:18] <mhaberler> I kludged up xeno_math.ko to keep it limping, but I'm unenthused still
[18:11:03] <mhaberler> that maybe should be a question for xeno list, or Wolfgang Denx
[18:11:29] <jepler> mhaberler: is it at all a simplifying assumption if a particular *build* is either for userspace or kernelspace, rather than both?
[18:11:42] <jepler> so we'd have an rtai-type kernel build which would eventually become legacy
[18:11:57] <jepler> and another build which is "any userspace flavor we have headers for, including sim/non-rt"
[18:12:20] <mhaberler> well they are kinda ships in the night, only shm and loadable ko's/.so's
[18:12:28] <zultron> I think that will only simplify the makefiles.
[18:12:38] <mhaberler> dramatically, yes
[18:13:14] -!- V0idExp has quit [Quit: Leaving.]
[18:13:16] <jepler> do you have any wish to build kernel modules for multiple kernel versions .. or just for one kernel version?
[18:13:24] <mhaberler> it also opens the route to things which were hard to do with both styles around, like the VPT idea
[18:13:40] <zultron> We're planning on being able to build for multiple kernels, yep.
[18:13:43] <mhaberler> being able to walk the motion or trajectory queues at will
[18:13:57] <zultron> One rtapi.ko for each kernel version.
[18:14:06] <mhaberler> in one go, thats the challenge
[18:14:15] <zultron> Yes, in one go.
[18:14:51] <jepler> I am surprised you find that an important goal
[18:15:14] <mhaberler> multiple kmods.. well I would think that switching by a reboot would make it easier to isolate bugs and measure relative performance
[18:16:03] <mhaberler> well how would you build the package otherwise; well maybe theres a way to split the modules build from the rest
[18:16:33] <cradek> very very long ago we had modules in a separate deb, per kernel
[18:16:47] <mhaberler> re goal.. it was an implicit assumption I made, but it might not make sense/there might be more than one way to achieve the goal
[18:17:34] <mhaberler> modules doesnt translate into kernel version anymore
[18:17:45] <mhaberler> so it isnt kernel modules throughout
[18:17:59] <zultron> It doesn't seem like an important goal to me either, but it's trivial given that the build infra is there.
[18:18:01] <mhaberler> but separate packaging is an option
[18:18:35] <jepler> debian has had various ways to package module source and build them for the running kernel, too
[18:18:53] <jepler> but for linuxcnc.org, we've always had one kernel per supported os version so we didn't need that
[18:19:02] <mhaberler> actually the userland part in this branch only has one related dependency I could think of, the xenomai userland libs; I havent seen any RTAI specific libs yet (lxrt?)
[18:19:40] <jepler> there's a liblxrt.so.1 which would be a runtime dependency of rtai lxrt
[18:19:53] <mhaberler> well with the unified binary one build supports an arbitrary number of kernels assuming the modules can be built
[18:19:58] <mhaberler> aja
[18:20:05] <jepler> anyway, I think that either of the following would be simplifying assumptions that would only be inconvenient for a few developers of kernels:
[18:20:10] <zultron> As far as packaging, I plan to have separate packages for each thread flavor, and if someone actually needed a single build for multiple kernel thread kernel versions, it could build separate packages for each.
[18:20:20] <jepler> easiest: build is EITHER "all supported userspace models" or "one specific kernel model"
[18:20:26] <zultron> (Packaging for RedHat)
[18:20:33] <jepler> next easiest: build is "all supported userspace models" plus "zero or one specific kernel model"
[18:21:07] <mhaberler> the difficulty isnt the styles; it's reworking directory infrastructure to support that
[18:21:24] <mhaberler> that is still TBD
[18:21:53] <jepler> it would be nice to try to move linuxcnc packaging further towards common distro layouts at the same time as long as that is being looked at
[18:22:08] <mhaberler> but if we can call make with the proper args and have a set of threadstyle speciific modules and support .so's nbuilt that'd be terrific
[18:22:15] <zultron> And also telling the funky make system to compile src/rtapi multiple times. :P
[18:22:51] -!- dway has quit [Quit: NOOOOOOooooooooo……]
[18:22:58] <jepler> if you have any specific questions about gnu make or the current linuxcnc makefiles I will do my best to answer them.
[18:23:33] <jepler> also remember you'll have to make the comp program do something other than what it does now in terms of building modules outside the tree
[18:23:38] <zultron> I'll be thinking about that kind of question as we go, jepler. My goal is to get LCNC packages accepted into Fedora.
[18:23:47] <jepler> it's not called LCNC.
[18:23:53] <zultron> Sorry, I'm lazy.
[18:24:12] <zultron> The package would probably be called 'linuxcnc'.
[18:24:12] <jepler> sorry, I'm still tired from the trademark problems, and I know that somebody else calls a product they sell "lcnc" -- and it's even related to cnc.
[18:24:40] <jepler> bbl, time to get back to $DAY_JOB
[18:24:40] <mhaberler> well I think the most fruitful route would be to separate buildng of all userland programs, and all the modules (.ko/.so) and support .so's at the toplevel make goal target: that is semi-there
[18:24:49] <mhaberler> sure
[18:25:14] <mhaberler> but I think the separate module/.so build would be the route to go
[18:25:48] <mhaberler> configure.in will be impacted quite a bit I guess
[18:25:50] <jepler> I recall being unable to figure out how to make the kernel build put outputs in a different location than the inputs. if you figure it out, let me know
[18:26:01] <mhaberler> ha. good one.
[18:26:13] <mhaberler> I claim MBA rights ;)
[18:26:15] <jepler> you'll need that to build for two kernel versions, that's for sure
[18:26:21] <zultron> I think I remember seeing your comment about that in the Makefile.
[18:26:22] <jepler> make bites (my) ass?
[18:26:37] <mhaberler> I see
[18:26:39] <jepler> anyway, really leaving now..
[18:26:44] <mhaberler> sure, thanks!
[18:33:51] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[18:39:22] -!- FinboySlick has quit [Quit: Leaving.]
[19:06:17] -!- tmcw has quit [Remote host closed the connection]
[19:11:24] -!- ler_hydra has quit [Remote host closed the connection]
[19:13:29] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 18.0/20130108033621]]
[19:16:29] <seb_kuzminsky> hey andypugh, the halui "jog the wrong axis" bug is fixed in master now, version v2.6.0-pre0-4251-g9489b1c and later have the fix
[19:16:45] <seb_kuzminsky> in case you happen to be on the forums and wouldnt mind telling the guy who had that problem
[19:17:25] <kwallace1> cmorley1: I started playing with y2 in GScreen. A lot of what what I said last night is not valid. My understanding so far is that y2 is picked up by glnav which rotates the whole 3D reference frame and it's contents, or rather the point of view and redraws it, but pretty muc stops there. It's up to glcanon.py to finish by rotating and moving the labels, extents and markers to face the viewers new viewpoint. So for instance, the label module
[19:20:22] <kwallace1> I started playing with GScreen to add these bits, but it crashes pretty hard while testing changes. My LinuxCNC version doesn't crash, so I'll work on it, then document what was done, so maybe it can be applied to GScreen.
[19:21:46] <kwallace1> Actually nothing in GScreen should change, just glcanon.py.
[19:22:41] -!- micges_ [micges_!~micges@adgy40.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[19:26:48] -!- micges has quit [Ping timeout: 276 seconds]
[19:29:26] micges_ is now known as micges
[19:32:28] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[19:33:46] -!- Guest90209 has quit [Quit: Page closed]
[19:36:44] -!- theorbtwo has quit [Remote host closed the connection]
[19:44:25] -!- kwallace [kwallace!~kwallace@tmb-241.sonnet.com] has joined #linuxcnc-devel
[19:45:42] -!- kwallace1 has quit [Ping timeout: 264 seconds]
[19:54:32] -!- erictheise_ has quit [Quit: erictheise_]
[19:59:11] -!- Err has quit [Ping timeout: 245 seconds]
[20:17:29] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[20:37:44] -!- DJ9DJ has quit [Read error: Connection reset by peer]
[20:38:54] <andypugh> OK, will do. Just need to place an RS order
[20:39:49] -!- crank has quit [Ping timeout: 256 seconds]
[20:44:11] -!- erictheise has quit [Quit: erictheise]
[20:57:32] <andypugh> (This is why I need to place an RS order:
http://www.independent.co.uk/news/science/why-the-world-is-running-out-of-helium-2059357.html )
[20:58:41] <andypugh> No, that isn't the reason at all. That's completely the wrong link.
[20:59:24] <andypugh> Ah well, it could be worse, it's an interesting-ish article.
[21:10:17] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:13:10] -!- jfire has quit [Read error: Connection reset by peer]
[21:23:52] -!- sumpfralle has quit [Ping timeout: 256 seconds]
[21:23:55] <seb_kuzminsky> andypugh: thanks for reporting the bug here & reporting the fix back
[21:24:00] R2E4_awy is now known as R2E4_
[21:24:57] <andypugh> I wonder how many of the other 2800 are problems?
[21:26:02] -!- stsy has quit [Remote host closed the connection]
[21:45:10] <seb_kuzminsky> the other 2800 what?
[21:58:50] -!- DJ9DJ has quit [Quit: bye]
[22:00:11] -!- ravenlock has quit [Remote host closed the connection]
[22:10:42] -!- Loetmichel has quit [Ping timeout: 272 seconds]
[22:32:39] -!- Valen has quit [Quit: Leaving.]
[22:33:21] <andypugh> Didn't clang find 2800 instances of a boolean being set from an int?
[22:34:13] -!- bedah has quit [Quit: bye]
[22:40:37] <seb_kuzminsky> not that i know of
[22:40:39] <seb_kuzminsky> bbl
[22:46:20] -!- eykreinecke1 has quit [Ping timeout: 240 seconds]
[22:48:46] -!- toastydeath has quit [Ping timeout: 245 seconds]
[22:52:23] -!- zzolo has quit [Quit: zzolo]
[23:07:43] -!- AR_ has quit [Ping timeout: 264 seconds]
[23:10:19] -!- fomox has quit [Remote host closed the connection]
[23:21:11] -!- adb has quit [Ping timeout: 255 seconds]
[23:29:20] -!- jthornton has quit [Read error: Connection reset by peer]
[23:29:21] -!- JT-Shop has quit [Read error: Connection reset by peer]
[23:29:22] -!- jthornton_ [jthornton_!~john@162.72.171.228] has joined #linuxcnc-devel
[23:29:25] -!- JT-Shop-2 [JT-Shop-2!~John@162.72.171.228] has joined #linuxcnc-devel
[23:33:45] -!- stsydow has quit [Remote host closed the connection]
[23:52:03] <KGB-linuxcnc> 03andy 05master 24f213d 06linuxcnc 10src/hal/drivers/mesa-hostmot2/ 10sserial.c 10sserial.h * Give the integrator some clues about smart-serial card modes.
[23:52:39] -!- Spida has quit [Read error: Operation timed out]
[23:53:19] -!- tmcw has quit [Remote host closed the connection]
[23:53:35] -!- odogono has quit [Quit: odogono]
[23:57:25] -!- Nick001-Shop has quit [Remote host closed the connection]
