Back
[00:16:02] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[00:31:37] -!- yuyi has quit [Remote host closed the connection]
[00:33:51] -!- kingarmadillo has quit [Ping timeout: 246 seconds]
[00:42:03] -!- jthornton has quit [Ping timeout: 244 seconds]
[00:42:25] -!- JT-JA13 has quit [Ping timeout: 252 seconds]
[00:42:44] -!- JT-Shop has quit [Ping timeout: 260 seconds]
[00:50:14] -!- JT-JA13 [JT-JA13!~john@198.45.191.246] has joined #linuxcnc-devel
[00:50:38] -!- jthornton [jthornton!~john@198.45.191.246] has joined #linuxcnc-devel
[00:50:59] -!- JT-Shop [JT-Shop!~john@198.45.191.246] has joined #linuxcnc-devel
[00:54:07] <cradek> the local paper's reporting some busted windows and trailers in lincoln, but probably nobody is badly hurt
[00:55:39] -!- tobias47n9e_ has quit [Ping timeout: 265 seconds]
[01:07:57] -!- skunkworks_ [skunkworks_!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[01:25:45] <seb_kuzminsky> glad you guys are ok
[01:26:05] <seb_kuzminsky> there's plenty of room with no tornadoes 500 miles to the west
[01:35:09] <cradek> heh I bet the storm sewer improvement bond passes (on tomorrow's ballot)
[01:35:14] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[01:36:28] <cradek> wow the paper has photos of 6" diameter hail
[01:52:02] -!- kalxas has quit [Quit: Goodbye]
[01:52:04] <skunkworks_> yike
[01:52:09] <skunkworks_> yikes!
[01:54:50] <seb_kuzminsky> yikes
[01:55:42] <linuxcnc-build> build #1560 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/1560 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:55:57] -!- skunksleep has quit [Ping timeout: 250 seconds]
[02:02:40] <linuxcnc-build> build #3300 of 4007.deb-precise-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/3300 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:06:30] <skunkworks_> the carousel component is pretty cool.
[02:07:05] <skunkworks_> it seems to be working as expected. the issue with the tool chain being 1 off I think is that it isn;t seeing the index at the right time
[02:07:24] <seb_kuzminsky> http://i.imgur.com/y03W9gb.jpg
[02:07:43] <linuxcnc-build> build #477 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/477 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:07:50] <linuxcnc-build> build #542 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/542 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:08:05] <linuxcnc-build> build #2128 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/2128 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:08:28] <linuxcnc-build> build #1172 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/1172 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:08:30] -!- pandeiro has quit [Remote host closed the connection]
[02:08:38] <linuxcnc-build> build #1868 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/1868 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:08:44] <jepler> I'm still here too, didn't blow away
[02:08:46] <skunkworks_> it calls tool 1 - one too far. the index switch is on the correct pocket.
[02:08:59] <linuxcnc-build> build #290 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/290 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:09:10] <seb_kuzminsky> that's what i get for unhorking the buildbot
[02:09:20] <linuxcnc-build> build #3300 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/3300 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:09:28] <linuxcnc-build> build #476 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/476 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:09:53] -!- JT-JA13 has quit [Ping timeout: 244 seconds]
[02:09:57] <linuxcnc-build> build #1871 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1871 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:10:06] -!- jthornton has quit [Ping timeout: 246 seconds]
[02:10:08] <linuxcnc-build> build #543 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/543 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:10:24] -!- JT-Shop has quit [Ping timeout: 244 seconds]
[02:10:56] <linuxcnc-build> build #1208 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/1208 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:17:11] -!- seb_pocket has quit [Ping timeout: 250 seconds]
[02:20:27] -!- anth0ny_ has quit [Client Quit]
[02:21:34] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:22:14] -!- JT-Shop [JT-Shop!~john@198.45.191.246] has joined #linuxcnc-devel
[02:22:14] -!- JT-JA13 [JT-JA13!~john@198.45.191.246] has joined #linuxcnc-devel
[02:22:14] -!- jthornton [jthornton!~john@198.45.191.246] has joined #linuxcnc-devel
[02:30:11] -!- andypugh [andypugh!~andypugh@12.1.118.71] has joined #linuxcnc-devel
[02:30:44] <skunkworks_> andypugh, work as expected.
[02:30:47] <skunkworks_> works
[02:31:11] <andypugh> Grand
[02:31:33] <skunkworks_> I think we need to play with the index location. it i calling pocket 1 - one pocket after the one with the index switch
[02:31:46] <skunkworks_> I need to halscope the pocket and index senors
[02:32:47] <skunkworks_> Btw - I think I found a bug. - if the first tool you call is the last tool (20 for me) it finds the index - then instead of rotating one backwards - it rotates all the way around to 20
[02:33:15] -!- anth0ny_ has quit [Quit: anth0ny_]
[02:33:38] <seb_kuzminsky> bug in axis preview in master
[02:34:07] <seb_kuzminsky> on an unhomed non-id-kins machine (sim/axis/gantry), F1, F2, jog around, the DRO updates but the preview tool cursor does not move
[02:34:13] <seb_kuzminsky> was it always like that?
[02:34:47] <seb_kuzminsky> Home All, switch to world mode and everything works right: the dro updates *and* the preview tool cursor moves
[02:35:21] <skunkworks_> non-id-kins?
[02:35:36] <seb_kuzminsky> that config uses gantrykins
[02:36:05] <seb_kuzminsky> 2.7.4 behaves the same way...
[02:36:08] <seb_kuzminsky> so, shrug
[02:36:52] <seb_kuzminsky> it's not a regression
[02:44:10] <andypugh> skunkworks_: That sounds like a rather minor bug, as it does find the right tool, though inefficiently. I am vaguley curious as to why that happens, though.
[02:45:33] -!- anth0ny_ has quit [Client Quit]
[02:46:03] <andypugh> Have you managed to absolutely test that passing through index with an OR setup never ever, gets the tool wrong by one? That sceario woulld be dangerous and concerns me.
[02:48:59] -!- anth0ny_ has quit [Client Quit]
[02:49:21] <skunksleep> I have not done anything more than just hooking up the raw 2 switches
[02:49:48] <skunksleep> Ran out of time.
[02:50:57] -!- anth0ny_ has quit [Client Quit]
[02:52:17] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[02:52:51] <seb_kuzminsky> ugh, my commit the other night, 5fb0e8178, is broken
[02:53:54] <seb_kuzminsky> task needs to be in Auto mode to deal with the PLAN_OPEN message, and i changed that
[02:56:04] -!- skunksleep has quit [Ping timeout: 252 seconds]
[02:56:05] <seb_kuzminsky> it's sad to me that the axis splash gcode preview has been relying on a bug this whole time
[02:56:43] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:03:26] <andypugh> Has it been so long that the bug is actually a feature?
[03:03:53] <seb_kuzminsky> the behavior that the bug allows is certinaly desirable
[03:03:58] <skunksleep> (And I am a little fuzzy on how to hook up the Or)
[03:04:21] <seb_kuzminsky> splash gcode is great, but the intent of the code is clearly to disallow it
[03:07:00] <seb_kuzminsky> splash gcode is loaded at startup, before the machine's come out of estop and been homed
[03:07:30] <seb_kuzminsky> when the machine is not homed, it is not allowed to switch to Auto mode (aka gcode-running mode)
[03:07:54] <andypugh> I am unsire of the issue being described, but is it that the fact that Axis displays “LinuxCNC” despite not beng in a position to mill it, and eithout loading it, is a bit odd?
[03:08:35] <seb_kuzminsky> yeah, that's the wrong but useful effect of the bug i've been wrestling with lately
[03:09:08] <seb_kuzminsky> linuxcnc *does* load the splash gcode (and the Axis preview displays it), even though it shouldnt be allowed to load it
[03:09:59] <seb_kuzminsky> i'm thinking task should allow *opening* a gcode file when unhomed, but not *running* it until the machine is homed
[03:10:16] <seb_kuzminsky> but then i went and looked at implementing that in task and got discouraged by how hairy task is
[03:10:19] <andypugh> Well, if you fix it, we will see far fewer YouTube videos of barely-working macines making a bad job of hacking out our project name. That might be a good thing.
[03:10:41] <mozmck> Hi seb, have you given any thought to my comments on gantries?
[03:11:03] <seb_kuzminsky> i think it's important for users to have quick success, of sorts, so i dont want to break splash gcode functionality
[03:11:09] <skunksleep> Do you or the index with the pocket sensor and then run it to the carousel index input?
[03:11:12] <seb_kuzminsky> mozmck: i've thought about it some
[03:11:42] <seb_kuzminsky> i understand your position as this: you want three jog modes, not two
[03:11:44] <andypugh> But, I have to be at work at 7am east coast time, so time to sleep.
[03:11:55] <seb_kuzminsky> 1. free mode, like now, where each joint jogs independently of all others
[03:12:05] <seb_kuzminsky> 2. wold mode, like now, where you jog axes, not joints
[03:12:19] <seb_kuzminsky> 3. the new mode, where you jog each joint, but kins runs and updates the other joints
[03:12:30] <seb_kuzminsky> is that a fair representation of what you're thinking of?
[03:12:35] <seb_kuzminsky> andypugh: good night
[03:13:17] <mozmck> Well, I would just say I want 2. world mode only, but I may not be understanding your third option
[03:14:06] <andypugh> skunksleep: Sorry, running on empty trying to synchronise body clocks. 23:13 local time, 0413 “me” time.
[03:14:16] <mozmck> So that is is not possible to jog joints.
[03:14:46] -!- andypugh has quit [Quit: andypugh]
[03:15:04] <mozmck> I really need to get some time to work with ja.
[03:15:52] <seb_kuzminsky> you and me both, pal
[03:16:24] <seb_kuzminsky> mozmck: i thought we talked about that and decided that sometimes you *do* want to jog joints
[03:16:37] <seb_kuzminsky> when setting up the machine, or when squaring a gantry that's gotten racked, etc
[03:16:40] <seb_kuzminsky> no?
[03:17:05] <mozmck> No, I could see someone possibly wanting that, but for me/us, we do not want that.
[03:18:06] <mozmck> Too dangerous and I can't see it really being useful for any of the machines we deal with. You fix racking by homing with a switch on each side.
[03:18:25] -!- anth0ny_ has quit [Quit: anth0ny_]
[03:19:48] <seb_kuzminsky> so for your product, you want to disallow jogging until you're in world mode?
[03:19:57] <mozmck> If a machine that moves 1000 IPM can get into a mode where you can jog only one side, and you do it accidentally, you could break the gantry in a hurry.
[03:20:07] <seb_kuzminsky> (and you'd enter world mode the usual way, by homing and switching to world)
[03:20:19] <seb_kuzminsky> i totally agree that's a bad situation
[03:20:48] <seb_kuzminsky> i too am worried about that exact thing with the machine at my local hackspace
[03:20:58] <seb_kuzminsky> i want to make it safer for people to use
[03:21:05] <mozmck> No I would rather have a way to make it be in world mode even before homing - or simply be in world mode all the time unless homing.
[03:21:21] <seb_kuzminsky> disallowing jogging in joint/free mode seems like the way to go, to me
[03:21:23] <mozmck> Yes, us too - because we have to deal will supporting them!
[03:21:34] <seb_kuzminsky> heh, me too :-)
[03:21:45] <mozmck> Well, the problem with that, is that some people don't even use home switches.
[03:22:15] <mozmck> Plus, if you don't allow jogging, and the head happens to be in the middle of the table, homing will take forever!
[03:22:25] <seb_kuzminsky> world mode before homing is not generally possible, because not all non-identity kins (aka non-trivial kins) have knowable world positions until the joint positions are known
[03:23:29] <mozmck> Hmm, so is a gantry kins not identity? Or could one not be made?
[03:23:43] <mozmck> How does motion know if it's identity?
[03:23:57] <seb_kuzminsky> "identity kins" means a 1-to-1 mapping between joints and axes
[03:24:11] <seb_kuzminsky> gantrykins has 2 joints to one axis, so it's not id kins
[03:24:30] <seb_kuzminsky> the kinematics module registers with motion and reports whether it's id-kins or not
[03:24:52] <seb_kuzminsky> via the kinematicsType() function
[03:26:33] <mozmck> Hmm, maybe I could make a gantry kins and have it tell motion it's identity ;-)
[03:27:30] <seb_kuzminsky> that't wouldnt work, unfortunately
[03:27:43] <mozmck> Not surprising
[03:27:59] <seb_kuzminsky> because you'd not get to set two joints' positiong from the one axis position
[03:28:07] <seb_kuzminsky> it might work, but that'd be another bug ;-)
[03:28:43] <mozmck> Well, somehow I'll figure it out. Right now the gantry.comp component is working quite well.
[03:29:10] <seb_kuzminsky> i'm glad it's making a viable product for you, that's really great
[03:29:28] <seb_kuzminsky> gantry.comp uses trivkins, right?
[03:29:45] <seb_kuzminsky> i should say, your config uses trivkins and gantry.comp, right?
[03:30:05] <mozmck> Yes
[03:30:23] <mozmck> I used trivkins even before I started using gantry.comp
[03:30:29] <seb_kuzminsky> yeah
[03:30:51] <mozmck> but gantry.comp allows auto-squaring to multiple switches
[03:31:26] <seb_kuzminsky> yeah
[03:31:37] -!- anth0ny_ has quit [Quit: anth0ny_]
[03:36:22] -!- anth0ny_ has quit [Client Quit]
[03:51:41] -!- anth0ny_ has quit [Quit: anth0ny_]
[04:10:54] -!- dgarr has quit [Quit: Leaving.]
[04:11:04] -!- skunksleep has quit [Ping timeout: 240 seconds]
[04:24:00] <seb_kuzminsky> wait, i was wrong about 5fb0e8178, it's not broken after all
[04:24:21] <seb_kuzminsky> Task *does* allow TASK_PLAN_OPEN when not in Auto mode
[04:24:28] <seb_kuzminsky> so i think it's all ok
[04:29:46] <seb_kuzminsky> no its not ok
[04:29:47] <seb_kuzminsky> ugh
[04:30:22] -!- Tom_itx [Tom_itx!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[04:42:17] -!- zlog [zlog!~zlog@ip68-102-196-26.ks.ok.cox.net] has joined #linuxcnc-devel
[04:48:26] <seb_kuzminsky> oh i see, i wasnt considering enough of the nested switch statements in task
[04:49:28] <seb_kuzminsky> EMC_TASK_PLAN_OPEN *is* allowed without Mode=Auto in State={OFF,ESTOP,ESTOP_RESET}, but in State=On it's only allowed if Mode=Auto
[04:50:34] <seb_kuzminsky> which means my 5fb0e817 is buggy, since it doesn't enforce Mode=Auto if State=On
[04:54:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master e15d107 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py Revert "axis: call linuxcnc.task_plan_synch() to force a var file write" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e15d107
[04:55:47] <linuxcnc-build> build #3341 of 2000.docs is complete: Failure [4failed rsync-docs-to-www.linuxcnc.org] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/2000.docs/builds/3341 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:17:10] <linuxcnc-build> build #4104 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4104 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:20:22] -!- kwallace [kwallace!~kwallace@162.222.30.12] has parted #linuxcnc-devel
[05:24:09] -!- JT-JA13 has quit [Ping timeout: 244 seconds]
[05:24:09] -!- jthornton has quit [Ping timeout: 244 seconds]
[05:24:40] -!- JT-Shop has quit [Ping timeout: 244 seconds]
[05:25:09] -!- teepee has quit [Ping timeout: 244 seconds]
[05:26:52] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[05:28:36] -!- JT-Shop [JT-Shop!~john@198.45.191.246] has joined #linuxcnc-devel
[05:28:37] -!- JT-JA13 [JT-JA13!~john@198.45.191.246] has joined #linuxcnc-devel
[05:28:39] -!- jthornton [jthornton!~john@198.45.191.246] has joined #linuxcnc-devel
[05:33:15] -!- ve7it has quit [Remote host closed the connection]
[05:36:30] -!- the_wench [the_wench!~the_wench@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[05:51:15] -!- JT-JA13 has quit [Ping timeout: 250 seconds]
[05:51:32] -!- JT-Shop has quit [Ping timeout: 244 seconds]
[05:52:11] -!- jthornton has quit [Ping timeout: 276 seconds]
[05:56:46] -!- Mathnerd314 has quit [Ping timeout: 265 seconds]
[06:03:58] -!- jthornton [jthornton!~john@198.45.191.246] has joined #linuxcnc-devel
[06:04:02] -!- JT-JA13 [JT-JA13!~john@198.45.191.246] has joined #linuxcnc-devel
[06:04:02] -!- JT-Shop [JT-Shop!~john@198.45.191.246] has joined #linuxcnc-devel
[06:38:09] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15sirop commented on issue #48:
https://github.com/LinuxCNC/linuxcnc/pull/48/commits/59847ca427716c23fae63cf331d3040eb82d666a:... 02
https://github.com/LinuxCNC/linuxcnc/pull/48#issuecomment-218071247
[06:44:47] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[06:49:27] -!- rob_h [rob_h!~robh@94.0.120.220] has joined #linuxcnc-devel
[07:16:42] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[08:17:25] -!- kingarmadillo has quit [Ping timeout: 265 seconds]
[08:32:40] -!- amiri has quit [Ping timeout: 252 seconds]
[08:44:03] -!- cradek has quit [Read error: Connection reset by peer]
[08:44:11] -!- cradek [cradek!~chris@outpost.timeguy.com] has joined #linuxcnc-devel
[08:45:19] -!- jepler has quit [Ping timeout: 252 seconds]
[08:48:19] -!- jepler [jepler!~jepler@emc/developer/pdpc.professional.jepler] has joined #linuxcnc-devel
[08:50:44] -!- Kucharsky [Kucharsky!~kvirc@hostg.touk.pl] has joined #linuxcnc-devel
[09:04:46] -!- skunksleep has quit [Ping timeout: 244 seconds]
[09:14:00] -!- kalxas has quit [Changing host]
[09:15:14] -!- b_b has quit [Changing host]
[09:18:37] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[09:36:20] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[10:16:04] -!- skunkworks_ has quit [Ping timeout: 240 seconds]
[10:19:21] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[10:19:29] -!- Komzpa has quit [Ping timeout: 250 seconds]
[10:32:34] -!- rob_h has quit [Ping timeout: 240 seconds]
[10:39:43] -!- Daerist has quit [Ping timeout: 252 seconds]
[10:59:24] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[10:59:39] -!- skunkworks__ [skunkworks__!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:05:48] <skunkworks__> This laptop runs 73c running rt_preempt.
[11:19:36] -!- kingarmadillo has quit [Ping timeout: 246 seconds]
[11:30:32] <Tom_itx> missed some logs... loss of power
[11:35:20] -!- skunkworks__ has quit [Read error: Connection reset by peer]
[11:43:02] <jepler> skunksleep: a little toasty!
[11:45:36] <skunkworks_> a little ;)
[12:02:38] <skunkworks_> Inverting the pocket signal fixed the off by 1 tool chain homing
[12:07:21] -!- chillly has quit []
[12:15:07] -!- skunkworks__ [skunkworks__!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:15:54] <skunkworks_> fun things you think about a you're drifting off to sleep
[12:16:06] <skunkworks_> *as
[12:17:00] <skunkworks_> the pocket senor was a prox sensor. when it was hooked into the opto22 board - we didn't know if it was the correct logic
[12:18:08] <skunkworks_> *didn't think about it not being the correct logic
[12:37:13] -!- Azitrex has quit [Read error: Connection reset by peer]
[12:40:10] -!- sel [sel!~sel@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[12:40:26] -!- sel has quit [Remote host closed the connection]
[12:45:39] -!- als_ [als_!~als@h127.56.88.75.dynamic.ip.windstream.net] has joined #linuxcnc-devel
[12:52:14] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[12:55:35] <als_> cradek,
http://pastebin.com/jvuiaqtA probably should have made the changes this way in hind sight ,Sorry!
[12:59:20] <KGB-linuxcnc> 03Al Smart 05master fd36b4b 06linuxcnc 10docs/src/gui/pyvcp.txt 10lib/python/pyvcp_widgets.py standardized a python null pointer & fix a docs error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fd36b4b
[12:59:37] <cradek> thanks!
[13:04:48] <als_> thank you
[13:08:19] -!- sebb has quit [Quit: Wychodzi]
[13:14:01] <KGB-linuxcnc> 03Jeff Epler 052.6 3724b9b 06linuxcnc 10configs/sim/manual-example.ui configs: let it trigger a gladevcp bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3724b9b
[13:14:02] <KGB-linuxcnc> 03Jeff Epler 052.6 409125e 06linuxcnc 10lib/python/gladevcp/hal_actions.py gladevcp: Fix mdi error with tiny values * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=409125e
[13:14:52] <KGB-linuxcnc> 03Jeff Epler 052.7 23aafb0 06linuxcnc 10lib/python/gladevcp/hal_actions.py Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=23aafb0
[13:15:46] <KGB-linuxcnc> 03Jeff Epler 05master 6c0b1f9 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis: use task_plan_synch instead of unneeded change to MODE_MDI * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6c0b1f9
[13:29:35] -!- als_ has quit [Quit: Leaving]
[13:38:28] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[13:48:43] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[13:52:30] <skunkworks__> disabled a few things in the bios like speedstepping and now the temp is 56
[13:52:32] <skunkworks__> c
[13:52:43] <skunkworks__> (spu is now 2.8ghz
[13:53:50] <skunkworks__> (cpu now is at 2.8ghz instead of 3.4)
[13:54:11] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[14:00:56] <skunkworks__> that is much better.. No thermal melt down.
[14:09:18] <skunkworks__> heh - servo-thread.tmax is 769us...
[14:09:28] <skunkworks__> so far
[14:10:07] <skunkworks__> still running though
[14:10:16] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #48: I just noticed that the commits on your branch do not follow our policy. You must provide a signed-off-by line in the commit message, to certify that you are submitting your patches under our license, GPLv2+. For more information,
http://linuxcnc.org/docs/2.7/html/code/contributing-to-linuxcnc.html#_signed_off_by_policy... 02
https://github.com/LinuxCNC/linuxcnc/pull/48#issuecomment-21816
[14:15:39] <pcw_home> skunkworks__ servo-thread.tmax is probably determined by hm2_blahblah-read.tmax
[14:17:22] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15sirop commented on issue #48: Yes, I'd like to know if there is an elegant way to add a signed-off-by line to each commit of mine. 02
https://github.com/LinuxCNC/linuxcnc/pull/48#issuecomment-218171144
[14:21:24] <pcw_home> if these latency peaks are rare you can choose to just drop the read and try again next cycle
[14:21:25] <pcw_home> by using Jeplers eth-packet-loss branch and setting the read timeout to say 500 usec (50%)
[14:22:40] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #48: I use something like this:... 02
https://github.com/LinuxCNC/linuxcnc/pull/48#issuecomment-218172754
[14:23:26] -!- rob_h [rob_h!~robh@2.124.122.54] has joined #linuxcnc-devel
[14:24:45] -!- Azitrex has quit [Ping timeout: 265 seconds]
[14:36:29] <skunkworks__> cool - have to try that
[14:37:05] -!- kwallace [kwallace!~kwallace@162.222.30.12] has joined #linuxcnc-devel
[14:38:40] <pcw_home> you do need to set your following errors wide since motion will see stale position data
[14:38:42] <pcw_home> (the actual errors caused by the stale data are not bad and can largely be tuned around)
[14:40:39] -!- ivansanchez has quit []
[14:41:29] <skunkworks__> read timeout is currently set at 80
[14:41:41] <jepler> .. which means 80% of thread period
[14:42:16] <skunkworks__> easy enough
[14:42:32] <jepler> if the value is >100 then it is in ns
[14:42:36] <jepler> I got a little too clever :-/
[14:42:39] <pcw_home> I had it running with about 5% packet loss yesterday, it eventually reached the fatal error trip point after a couple hours
[14:42:41] <pcw_home> where I think this can be useful is systems (like this one ) that may get a error once a day or so at 3 KHz
[14:44:29] <skunkworks__> random thread that made me laugh.
http://www.cnczone.com/forums/uccnc-control-software/307124-random-feed.html
[14:49:19] <skunkworks__> latency test runs great for days - linuxcnc runs great for days but when I try to run the 7i92 it will trip a realtime error after 20 minutes
[14:49:29] <skunkworks__> something with the nic maybe
[14:50:41] <pcw_home> check the read tmax
[14:50:44] <skunkworks__> 82579LM
[14:51:11] <pcw_home> you have irq coalesing off?
[14:52:00] <skunkworks__> yes - setup according to the hm docs
[14:53:08] <pcw_home> what do ping times look like?
[14:54:12] <pcw_home> like:
[14:54:14] <pcw_home> sudo chrt 99 ping -i .001 10.10.10.10 > foo
[14:55:53] <skunkworks__> the read.tmax is currently running at 489us
[14:56:14] <skunkworks__> and now a realtime error
[14:56:18] <skunkworks__> let me run the shrt
[14:56:20] <skunkworks__> chrt
[14:56:37] <mozmck> Interesting quote from the thread skunkworks__ just posted, "space industry applications they have started reverting back to rs232 from ethernet because its more reliable."
[14:56:44] <mozmck> Anyone know if that is true?
[14:59:17] <mozmck> It would not really surprise me - rs232/485 is reliable and simple.
[14:59:49] <pcw_home> a lot less software/hardware involved
[15:01:16] <pcw_home> on the other hand ive now had a 7I76E running at work for almost 2 years (and close to one year at 4 KHz) with not a single packet lost
[15:01:26] <skunkworks__> .246ms pings
[15:01:31] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15sirop commented on issue #48: Ok, it was `git rebase -i HEAD~3 --exec="git commit --amend -CHEAD -s" PktUART_LinuxCNC` .... 02
https://github.com/LinuxCNC/linuxcnc/pull/48#issuecomment-218185417
[15:01:46] <pcw_home> thats fairly terrible
[15:03:06] <pcw_home> PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
[15:03:07] <pcw_home> 64 bytes from 10.10.10.10: icmp_seq=1 ttl=64 time=0.085 ms
[15:03:09] <pcw_home> 64 bytes from 10.10.10.10: icmp_seq=2 ttl=64 time=0.067 ms
[15:03:10] <pcw_home> 64 bytes from 10.10.10.10: icmp_seq=3 ttl=64 time=0.068 ms
[15:03:12] <pcw_home> 64 bytes from 10.10.10.10: icmp_seq=4 ttl=64 time=0.067 ms
[15:03:43] <KGB-linuxcnc> 03Jeff Epler 05master 645fef3 06linuxcnc Merge branch 'PktUART_LinuxCNC' of
https://github.com/sirop/machinekit * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=645fef3
[15:04:09] <skunkworks__> oh well
[15:04:19] <pcw_home> are you sure irq coalescing is off? doesnt look like it
[15:07:03] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[15:07:20] <skunkworks_> http://pastebin.com/eSxU9Dwp
[15:08:05] <skunkworks__> what was the command line to do it?
[15:08:45] <pcw_home> sudo ethtool -C ethN rx-usecs 0
[15:09:58] <skunkworks__> so.. that worked - <100us
[15:10:18] <skunkworks__> do you need ethtools installed for the line in the interface to work?
[15:10:26] <skunkworks__> I didn't have it installed
[15:10:39] <skunkworks__> let me reboot and see
[15:11:51] <pcw_home> yeah the interfaces file needs to have ethtool installed to do those tweaks
[15:11:51] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[15:12:01] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[15:12:20] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed pull request #48: PktUART driver for MESA (06master...06PktUART_LinuxCNC) 02
https://github.com/LinuxCNC/linuxcnc/pull/48
[15:12:26] <seb_kuzminsky> yay!!
[15:13:09] <skunkworks__> yes - now it has <100us ping times
[15:19:53] <skunkworks_> still get a realtime error
[15:20:07] <skunkworks_> let me run a non-ethernet config just to make sure my memory
[15:25:58] -!- Azitrex has quit [Read error: Connection reset by peer]
[15:31:16] <pcw_home> Heres the stuff that I look at to see where the time goes:
[15:31:18] -!- Daerist has quit [Remote host closed the connection]
[15:31:18] <pcw_home> http://freeby.mesanet.com/my.halshow
[15:31:19] <pcw_home> (you will have to change the 7i76e's to 7i92's)
[16:18:48] -!- Komzpa has quit [Ping timeout: 276 seconds]
[16:19:03] -!- Kucharsky has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
[16:39:27] <skunkworks_> cradek, jepler, does this work?
http://pastebin.com/qygLPPTK
[16:41:45] <seb_kuzminsky> looks good to me skunkworks_
[16:42:17] <skunkworks_> the html/pdf docs get created from that - correct?
[16:42:49] <seb_kuzminsky> yeah, that's right
[16:42:54] <seb_kuzminsky> do you want me to push that to master?
[16:43:06] <jepler> 2.7 I imagine
[16:43:24] <skunkworks_> I would think 2.7
[16:43:26] <skunkworks_> right
[16:43:34] <seb_kuzminsky> k
[16:45:12] <seb_kuzminsky> skunkworks_: is that output from "git show"?
[16:45:25] <skunkworks_> git gui..
[16:46:05] <seb_kuzminsky> run 'git format-patch HEAD^' and paste the result, it'll be easier to apply correctly
[16:46:31] <skunkworks_> ok
[16:48:16] <seb_kuzminsky> should our uspace debian package Recommend ethtool, so it gets installed by default but can be removed without removing linuxcnc.deb?
[16:48:52] <skunkworks_> http://pastebin.com/uwV2hD7c
[16:48:56] <skunkworks_> is that better?
[16:50:50] <seb_kuzminsky> yeah, that's the right format
[16:51:03] <skunkworks_> ok - I will remember that - thanks
[16:51:29] <seb_kuzminsky> hm, for some reason it dropped the SoB line that you added
[16:51:48] <seb_kuzminsky> maybe because the commit message is otherwise empty?
[16:52:30] <skunkworks_> ? Signed-off-by: Sam Sokolik <samcoinc@gmail.com>
[16:52:32] <seb_kuzminsky> yeah, if i add a non-header-looking line before the SoB it works fine
[16:53:21] <skunkworks_> heh - I was trying to do it without asking questions ;)
[16:53:26] <KGB-linuxcnc> 03Sam Sokolik 052.7 6ceba7a 06linuxcnc 10docs/man/man9/hm2_eth.9 irq-coalesce requires ethtools * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6ceba7a
[16:57:00] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[16:59:24] <skunkworks__> OOOooohhh
[17:01:52] <skunkworks__> running an hour with a non-ethernet config - no issues. 74us tmax servo thread
[17:04:29] -!- rob_h has quit [Ping timeout: 260 seconds]
[17:04:58] -!- rob_h [rob_h!~robh@94.10.127.12] has joined #linuxcnc-devel
[17:26:09] <skunkworks__> does motion.servo.overruns not increment in uspace?
[17:27:12] -!- basiclaser has quit [Quit: Connection closed for inactivity]
[17:27:20] <skunkworks__> or doesn't unexpected realtime delay equal motion.servo overrun?
[17:35:16] <pcw_home> Dont remember if Ive ever seen it increment
[17:36:56] <pcw_home> but if you get a real time error with Ethernet, look at the things in that halshow file
[17:44:03] <jepler> src/emc/motion/motion.c: hal_param_u32_new("motion.servo.overruns", HAL_RW, &(emcmot_hal_data->overruns), mot_comp_id);
[17:44:06] <jepler> src/emc/motion/motion.c: emcmot_hal_data->overruns = 0;
[17:44:11] <jepler> it's only ever assigned 0, in 2.6 branch, regardless of RTOS
[17:44:21] <seb_kuzminsky> lol
[17:44:23] <jepler> er 2.7
[17:44:30] <jepler> after I took out the heuristic overrun detection code
[17:48:16] <jepler> seb_kuzminsky: any reason not to
https://emergent.unpythonic.net/files/sandbox/0001-motion-remove-overruns-parameter.patch ?
[17:51:11] <seb_kuzminsky> looks ok, remove it from the struct too
[17:51:18] <jepler> ah yep
[17:51:25] <seb_kuzminsky> if someone has it linked it'll break their hal file :-(
[17:51:29] <jepler> it's a param
[17:51:38] <seb_kuzminsky> oh!
[17:51:53] <seb_kuzminsky> so they'd have to script halcmd to access it
[17:51:59] <seb_kuzminsky> that's probably fine to remove
[17:52:07] <jepler> patch updated
https://emergent.unpythonic.net/files/sandbox/0001-motion-remove-overruns-parameter.patch
[17:53:05] <seb_kuzminsky> https://www.youtube.com/watch?v=vCadcBR95oU
[17:56:14] <jepler> should I watch the whole video first?
[17:56:25] <seb_kuzminsky> yes
[17:59:53] <KGB-linuxcnc> 03Jeff Epler 052.7 01e82b2 06linuxcnc 10(5 files in 3 dirs) motion: remove overruns parameter * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=01e82b2
[18:00:36] <seb_kuzminsky> sharp!
[18:02:18] <skunkworks_> http://imgur.com/5BxlcJV
[18:05:12] <skunkworks_> pcw_home, ^
[18:08:05] <skunkworks__> if I read that right - the read time spikes before the servo thread
[18:09:47] <PCW> so whats the read-time.tmax?
[18:11:48] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[18:11:57] <skunkworks_> 191688428.. 68ms
[18:12:07] <skunkworks_> :)
[18:12:59] <skunkworks_> maybe the ethernet on this laptop goes through usb ;)
[18:16:18] <PCW> The USB-Ethernet adapter I have works much better than that :-)
[18:16:57] <PCW> it will even run a hour or so at 1 KHz before it gets a 10 ms delay
[18:18:02] <PCW> wonder what triggers that ( Ethernet power management? )
[18:19:09] <PCW> Is this the Laptop?
[18:22:17] <skunkworks__> yes
[18:22:35] <skunkworks__> let me look through the bios
[18:27:26] <skunkworks__> yah - I don't see anything
[18:28:15] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 8ae3058 06linuxcnc 10(54 files in 3 dirs) docs/src/motion/5-axis-kinematics.txt new doc JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8ae3058
[18:28:17] -!- skunkworks_ has quit [Ping timeout: 250 seconds]
[18:29:18] <PCW> As Ive said before the Dell laptop works OK as long as you dont touch the backlight controls
[18:29:54] <skunkworks__> same here. Just don't use the ethernet ;)
[18:30:44] <PCW> I have not tried the latest kernel on the laptop you might try the latest 3.18 kernel
[18:32:47] <PCW> looks like that's 3.18.29-rt30
[18:36:54] <skunkworks__> don't think it is smi - it runs longer than a couple minutes
[18:37:47] -!- md-2 has quit [Quit: Leaving...]
[18:39:14] <PCW> and its not a lost packet, it eventually gets around to receiving it
[18:39:58] <skunkworks__> something just gets hung up.
[18:40:11] <skunkworks__> I will have to try the 3.18 kernel when I get a chance
[18:40:56] <PCW> make sure the kernel config or kernel command line settings are for performance mode
[18:42:47] <skunkworks__> this time it was only 2.3ms ;)
[18:43:51] <PCW> Yeah those sound like power management, not sure what else can take so long
[18:44:21] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[18:44:27] -!- b_b has quit [Remote host closed the connection]
[18:45:40] -!- maurris has quit [Read error: Connection reset by peer]
[18:46:31] <PCW> I'd try a different kernel before giving up, I've found the 4.4 kernels rather flakey
[18:46:32] <PCW> ( though they might be needed to run really new hardware like my N3150 based Zotac mini PC)
[18:46:51] <archivist> any of the motherboards have phone home causing problems?
[18:47:21] -!- skunkworks__ has quit [Ping timeout: 250 seconds]
[18:47:29] <PCW> not that Ive seen
[18:50:18] <PCW> a couple days uptime with Preempt-RT:
[18:50:20] <PCW> http://freeby.mesanet.com/3.18.11-rt7.png
[18:53:04] <skunkworks_> the latency looks really good on this thing too - just the ethernet doesn't play well
[18:55:01] <jepler> if that thing has expresscard you could always try a plug-in adapter
http://www.newegg.com/Product/Product.aspx?Item=9SIA3912D67735 though I don't even know the state of expresscard support in linux so word of caution
[18:58:54] <skunkworks_> I had that in the back of my mind..
[19:17:31] -!- skunkworks__ [skunkworks__!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[19:17:46] <skunkworks__> http://imgur.com/buaT6zQ
[19:20:11] <skunkworks_> heh - the second you ping the mesa card you get a 600us delay
[19:23:33] <jepler> that's no good
[19:37:51] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal 4a3801e 06linuxcnc 10(5 files in 3 dirs) EU_Surplus_FastSeal_0_6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a3801e
[19:40:16] -!- skunkworks__ has quit [Ping timeout: 244 seconds]
[19:48:17] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[20:12:22] -!- maurris has quit []
[20:45:04] -!- tobias47n9e__ has quit [Ping timeout: 240 seconds]
[21:14:39] -!- chillly has quit []
[21:37:17] -!- pandeiro has quit [Remote host closed the connection]
[21:37:38] <tinkerer> hi mesa experts
[21:39:21] <tinkerer> have someone a simple working example config for the 7i90 and steppers for testing?
[21:43:05] <PCW> you could use a 7i43 sample config and just change a name or 2
[21:43:43] <tinkerer> ok thanks
[21:44:21] -!- kalxas has quit [Ping timeout: 246 seconds]
[22:20:03] -!- kalxas_ has quit [Quit: Goodbye]
[22:37:55] <tinkerer> PCW: forward stepping works but backward I get a following error. hmmm...?
[22:38:12] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[22:46:13] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8201:5d87:8c19:825f:a944:3d5] has joined #linuxcnc-devel
[22:46:28] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8201:5d87:8c19:825f:a944:3d5] has parted #linuxcnc-devel
[22:53:42] <PCW> thats pretty strange
[22:53:52] <PCW> what hardware?
[22:53:55] -!- skunkworks_ [skunkworks_!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[22:55:15] <tinkerer> 7i90 over spi and raspberrypi2 :)
[22:55:59] <tinkerer> I've wrote a driver for the raspi
[22:57:38] <tinkerer> now I'm testing it without motors. just logic analyzer
[22:57:50] <PCW> I've seen this before, I think is a ARM issue
[22:58:32] <PCW> something busted with float/integer conversions
[22:58:52] <tinkerer> hmm, which kind? it works with my pluto well
[22:58:57] <tinkerer> ahhhh
[22:59:14] <tinkerer> ok, thanks for the hint
[22:59:39] <tinkerer> maybe rtai_math?
[23:00:15] <PCW> is this linuxcnc or machinekit (and what version)? I think this showed up running hm2_eth on a ARM host
[23:00:30] <tinkerer> machinekit
[23:01:42] <PCW> I thought this was fixed with machinekit but not sure when or how or if they do versions
[23:03:19] <tinkerer> is this a hostmot2 issue?
[23:04:11] <tinkerer> 'cos as I said my pluto driver works well.
[23:05:33] <PCW> Can't remember if its a hostmot2 issue or ARM math issue but the code that trips the bug is in hostmot2
[23:05:35] <PCW> (I dont remember the details but I think a float to 32 integer conversion is broken on ARM, = sign lost)
[23:06:51] <PCW> (in the stepgen and possibly elsewhere)
[23:07:00] <tinkerer> ok, thanks for the hint. will dig in :)
[23:21:24] <PCW> looks like a hostmot2 stepgen bug that happens to work on x86 (its been fixed for a while in linuxcnc)
[23:21:51] <PCW> stepgen.c line 275
[23:22:42] <tinkerer> yes, who else, if not jepler have fixed it :)
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blobdiff;f=src/hal/drivers/mesa-hostmot2/stepgen.c;h=85060ee764b432f2bade32c875c29b0156508c78;hp=a971847d4da6b8978d2171f800a79ac89c4d2f98;hb=8b536f47153db14bf6001c3c1c7b69bcc84b6389;hpb=e082ca2f983a87357081afdd23e15b45ebe017e7
[23:47:47] -!- rob_h has quit [Ping timeout: 260 seconds]
