Back
[07:11:31] <skunkworks> z;pg
[07:11:34] <skunkworks> zlog
[09:10:28] <REEEN> Hello guys I have a little question ...
[09:11:17] <REEEN> Iam trying to write a routine which sets the z tool offset in the tooltable to the current position in g53
[09:11:34] <REEEN> But there is no gcode param for that
[09:11:51] <REEEN> Any ideas ?
[09:14:59] <REEEN> I can only find the coordinates in G54 to G59.x
[09:24:18] <mozmck> REEEN: as far as I know, you have to home the machine to set g53
[09:26:04] <REEEN> Yes but thats not waht I asked for :) I wanted to know whether there is a gcode param to get the current g53 position or another way to pass that value to the tooltable in a routine
[09:26:05] <mozmck> hmm, that's probably not what you are asking.
[09:26:35] <cradek> REEEN: use g10 l11
[09:26:49] <cradek> http://linuxcnc.org/docs/html/gcode/gcode.html#sec:G10-L11
[09:27:31] <cradek> it isn't exactly what you asked for, but it is the normal way to do this
[09:28:04] <cradek> > .... use that fixture to measure tools without regard to other currently-active offsets.
[10:18:14] <Roguish> hey all. guess i've been sleeping for a few days, but what's up with the mailing lists? I haven't received any emails since the 16th ????
[10:18:26] <seb_kuzminsky> Roguish: SF's mailing lists are down
[10:18:30] <seb_kuzminsky> they're working on it
[10:18:36] <seb_kuzminsky> the last update was yesterday:
http://sourceforge.net/blog/sourceforge-developer-pages-back-online/
[10:18:48] <cradek> the bugtracker is working now
[10:18:51] <Roguish> okie dokie. thanks.
[10:20:00] <seb_kuzminsky> heh
[10:20:44] <seb_kuzminsky> i don't see anything between 2.6.4 and 2.6.6 that could cause #427, speaking of bugs
[11:14:15] <skunkworks> 2.6 has a lot of gmocca changes...
[11:17:24] <skunkworks> has he tried to see if axis acts the same? I suppose he can't just swap it out
[11:20:10] <seb_kuzminsky> i don't see how a change in gmoccapy could cause that change in behavior, but i also dont see anything else that could cause it
[11:20:39] <seb_kuzminsky> cradek has asked rick lair to bisect 2.6.4 to 2.6.6 to look for it, we'll see what he finds
[12:07:32] <REEEN> Iam sorry I was offline for a while, cradek, you told me to use g10l11? How does that work ?
[12:07:49] <REEEN> I don't get it from the manual ...
[12:08:06] <cradek> what part don't you understand?
[12:08:39] <REEEN> How do I use it ?
[12:11:27] <REEEN> I wanted to set the current g53 coordinates for all tools so I can use them in every coordinate system
[12:13:21] <seb_kuzminsky> tool offsets are independent of which coordinate system you currently have active
[12:14:06] <REEEN> Yes, but if I touch off a tool in g54 and then switch to g55 and touch off again the offset is wrong
[12:15:44] <seb_kuzminsky> once you've touched off a tool in any coordinate system, you dont have to touch it off again (until you change the physical tool length offset, for example by re-mounting it in its tool holder)
[12:16:32] <REEEN> Yes, but if I touch off another tool in a different coordinate system
[12:16:52] <REEEN> Then they are independant from each other
[12:17:33] <REEEN> It works only if I use the old tool zo set the coordinate system
[12:18:03] <seb_kuzminsky> wait, are you talking about tool-length touch-off or workpiece touch-off?
[12:18:19] <REEEN> Tool length offset
[12:18:34] <REEEN> I want to do the following :
[12:20:10] <REEEN> I have a tool length sensor and I want to use it to measure my tools but not after every toolchange I only want to measurr them once I put the measuring Instrument on the same position everytime I use it.
[12:21:28] <seb_kuzminsky> ok, that sounds like a perfectly normal way to use a tool length sensor
[12:21:37] <REEEN> Yes
[12:23:00] <REEEN> My current routine sets the coordinate system to the current g54 coordinates and so it doesn't work if I change my reference point in g54 or change the coordinate system and measure another tool
[12:24:24] <REEEN> Thats the problem
[12:24:53] <seb_kuzminsky> i dont understand the last thing you said
[12:25:45] <seb_kuzminsky> if i load a tool and click "Touch Off" in the Axis GUI, and enter a tool length offset, then that TLO works even if i move the G54 coordinate system around, and it works if i switch to any other coordinate system
[12:26:06] <seb_kuzminsky> same thing if i load a tool and apply its stored TLO from the tool table with G43
[12:26:42] <REEEN> If you touch off a tool what do you enter in the length offste ?
[12:27:27] <seb_kuzminsky> in Axis you enter the desired coordinate (in the currently selected coordinate system) of the tool's controlled point
[12:27:52] <seb_kuzminsky> Axis compares that to the currently selected coordinate system's offset, and computes the offset added by the tool
[12:28:24] <seb_kuzminsky> that, the offset added by the tool, is what gets stored in the tool table
[12:28:42] <seb_kuzminsky> that offset gets used whenever you G43 this tool, no matter what coordinate system you're in (G54, G55, etc)
[12:29:10] <REEEN> Yes I know but what are the desired coordinates you enter for that tool ?
[12:29:14] <mozmck> You enter it by hand? Sounds like REEEN is trying to automate it with a sensor?
[12:29:55] <REEEN> Yes and the problem is I don't know which coordinates to enter for the tool
[12:30:23] <REEEN> Iam currently entering the current z pos in g54 and that is wrong
[12:30:25] <mozmck> I think I understand the problem, but I don't know the solution. I've not used tool offsets yet.
[12:30:27] <seb_kuzminsky> our docs on coordinate systems could maybe use a description of tool length offsets:
http://linuxcnc.org/docs/2.6/html/common/User_Concepts.html#_coordinate_systems
[12:31:11] <seb_kuzminsky> we have this:
http://linuxcnc.org/docs/2.6/html/gcode/tool_compensation.html#_tool_length_offsets
[12:31:54] <seb_kuzminsky> REEEN: is your question this: "when i run my tool into my tool sensor and it trips, what should i set the TLO to?"
[12:32:23] <REEEN> Yes :)))))
[12:32:30] <REEEN> Thats it !!
[12:33:33] <seb_kuzminsky> if so, the answer is "the difference between the currently selected coordinate systems's Z (without any tool length offset) and the Z coordinate of the tool sensor's trip point (again in the currently selected coordinate system)"
[12:33:37] <seb_kuzminsky> :-)
[12:34:13] <seb_kuzminsky> i was taught to think of TLOs this way:
[12:34:33] <seb_kuzminsky> dont worry about the absolute TLO of each tool, what matters is the difference in TLO between the tools you're using
[12:34:59] <seb_kuzminsky> this is beause the absolute TLO is easily compensated for by translating the whole coordinate system
[12:35:19] <seb_kuzminsky> so the process for setting TLOs of your tools looks like this:
[12:36:22] <seb_kuzminsky> Tn M6 to your longest tool, touch it to your tool sensor and set TLO to 0
[12:37:10] <seb_kuzminsky> then cycle through all the other tools one by one and touch off to your tool sensor
[12:37:15] <seb_kuzminsky> that's it
[12:37:58] <seb_kuzminsky> when you touch one of the shorter tools to the tool sensor and tell Axis that your Z is now 0, it figures out the TLO needed to make that true and updates the tool table
[12:38:03] <seb_kuzminsky> does that make sense?
[12:39:15] <REEEN> Hmm , can I send you my current routine ?
[12:40:25] <seb_kuzminsky> err, maybe better to paste it someplace public
[12:40:40] <REEEN> Okay wait I change to my pc
[12:41:03] <REEEN> okay Iam back
[12:41:20] <REEEN> when my tool touches of I do this :
[12:41:40] <REEEN> G10 L1 P#<_current_tool> Z#5063
[12:42:10] <REEEN> I set the tooltables Z offset from the curent tool to my current z position
[12:42:27] <REEEN> this is the wrong way I know
[12:44:41] <REEEN> I think I have to use g10 l11 but the description of this code is so bad I don't get it
[12:44:49] <seb_kuzminsky> http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G10-L1_
[12:45:23] <seb_kuzminsky> G10 L1 sets the tool offset to the programmed Z word, which ignores coordinate system offsets, which is almost certainly not what you want in this case
[12:46:33] <seb_kuzminsky> G10 L11 sets the TLO to the specified coordinates *in G59.3*, which also probably not what you want
[12:46:52] <REEEN> yes I think so
[12:46:53] <Tom_itx> is the longest tool a requirement or suggestion? the offsets should reflect any tool order?
[12:47:00] <Tom_itx> i agree the longest is a good idea
[12:47:12] <REEEN> I would use the spindle nose
[12:47:13] <seb_kuzminsky> G10 L10 sets the TLO to the specified coordinate in whatever the selected coordinate system is, that's probably what you want
[12:47:32] <REEEN> so g10 l10 will make it ?
[12:48:02] <cradek> set g59.3's origin near your sensor, and use L11 and your offsets will be small
[12:48:16] <cradek> L11 is exactly for this
[12:48:23] <seb_kuzminsky> he moves his sensor around
[12:48:31] <cradek> ??
[12:48:48] <cradek> around how exactly?
[12:49:02] <seb_kuzminsky> i assume it's something like this:
https://www.stepcraft-systems.com/media/k2/items/cache/78a38d90a5f5af5857b8e93fa4dd5a84_XL.jpg
[12:49:44] <cradek> if you always set that on the table somewhere, that's fine
[12:50:16] <REEEN> Yes thats it I always place it on the same position
[12:50:20] <seb_kuzminsky> oh
[12:50:30] <seb_kuzminsky> then yeah, do what cradek suggested
[12:51:01] <REEEN> i have a specified position on my machine table wehere I place it if i need to measure a new tool
[12:51:10] <REEEN> so g10 l11 ?
[12:51:12] <cradek> set G59.3 such that with TLO 0 a typical/longish tool tip is near the sensor's height at G59.3 Z=0
[12:51:33] <cradek> then just use L11 Z0
[12:51:56] <cradek> so hard to type this on my phone
[12:52:07] <REEEN> But if I change g59.3 later it is messed up right ?
[12:52:20] <cradek> don't do that
[12:52:23] <seb_kuzminsky> no, the tlos will still be right even if you move g59.3
[12:52:37] <cradek> G59.3 is for your measurer
[12:53:04] <REEEN> yes so i have to block this coordinate system for the user
[12:55:07] <REEEN> the way I would do that is using G53 z coordinates. G53 is always exactly the same
[12:55:29] <REEEN> and g53 can't be changed so why not use that ?
[12:56:16] <cradek> because you'll get huge TLOs and that's irritating
[12:56:33] <seb_kuzminsky> REEEN: i see your point, using G53 would have that nice feature in this case
[12:57:15] <cradek> I think it's best to have small negative TLOs
[12:57:17] <seb_kuzminsky> unfortunately the g-code standard treats G53 specially (it's not modal like the other coordinate systems, for example), and isnt usable in this case :-(
[12:58:15] <REEEN> yes :( no gcode param but I have an Idea I can subtract the current coordinates system offset from my current positon so I'm back in g53 ?
[12:58:56] <cradek> you're about to write crashy units-related assumptions and bugs
[12:59:22] <cradek> but yeah you could do math on the #numbers
[12:59:32] <seb_kuzminsky> do you have users who use G59.3 normally? i've never used it myself
[13:00:26] <REEEN> I have a lot users and it is a bit complicated to tell them all not to use g59.3
[13:00:38] <seb_kuzminsky> yeah, i can understand that
[13:00:45] <cradek> notice with L11 Z0 active units don't matter
[13:01:04] <cradek> anyway, be careful
[13:01:06] <seb_kuzminsky> ooh, nice, 0mm == 0inches
[13:01:48] <seb_kuzminsky> there's no way to "lock" a coordinate system
[13:01:48] <REEEN> you know anytime there will be someone using it and then he's going to call my because there is an error :D
[13:02:36] <seb_kuzminsky> you could remove it from the touch-off list in the gui, so the user would have to use MDI G10 L2 or L20 to change it
[13:04:11] <REEEN> hmm how do you mean that ?
[13:04:35] <REEEN> I think I will try out the math thing to use g53 before I do that
[13:04:50] <REEEN> I will let you guys know if it works
[13:05:34] <seb_kuzminsky> i mean, edit axis.py, change the all_systems variable to not include G59.3, that way a user can't use the GUI to change G59.3
[13:06:16] <REEEN> Thanks to all of you :)))
[13:06:40] <REEEN> Iam using gmoccapy, maybe I will tell norbert to remove it :)
[13:07:06] <seb_kuzminsky> no! dont remove it for everyone, just your untrustworthy users! the rest of us want it ;-)
[13:08:02] <REEEN> :D Iam currently building a new gui industrial faced and I think we will put an option to hide it in the settings
[13:08:23] <REEEN> no not iam I mena norbert and i :)
[13:10:04] <REEEN> we were talking about tools and the tooltable, why the hell is the tooltable limited to 56 tools ? 56 tools thats nothing Iam using about 300 tools and I had to use a patch to be able to use them
[13:11:05] <REEEN> does anyone know why ?
[13:12:05] <Tom_itx> that's come up in the past
[13:12:35] <JT-Shop> something about NML message size IIRC
[13:13:40] <REEEN> okay, so why not increase this number ?
[13:14:24] <JT-Shop> I should have said NML message size limits
[13:15:26] <REEEN> but it works using the patch
[13:15:55] <JT-Shop> it's above my pay scale now
[13:16:09] <Tom_itx> submit the patch for review?
[13:17:59] <REEEN> I received the patch from norbert and he received it from seb
[13:35:27] <seb_kuzminsky> nope
[13:38:01] <cradek> you can increase the number of tools with a define in the code and then you have to increase the tool buffer size in your nml file. just set it so it's big enough for your machine.
[13:40:12] <seb_kuzminsky> i'm not opposed to increasing the tool table size in master
[13:40:50] <seb_kuzminsky> it's a common complaint, and easy to fix at low cost to code complexity and runtime resource usage
[13:41:13] <cradek> it probably no longer breaks all the configs to increase it (since they don't have separate nml files anymore)
[13:52:29] <jepler> I wonder how much layering you have to violate to find out the size of the nml buffer and dynamically change the number of tools to match
[13:52:34] <jepler> so that the change would *only* be the nml file
[13:52:43] <jepler> not gonna try to sneak that in for 2.7, no way
[13:53:59] <jepler> #1 = #5381 #2 = #5382 ...
[13:54:15] <jepler> G10 L...
[13:54:22] <jepler> #5381 = #1 #5382 = #2 ...
[13:54:35] <jepler> oh woops, before the G10 line, #5381 = 0 #5382 = 0 ...
[13:55:07] <jepler> basically, you could save the G59.3 coordinate system, stick all zeros in it, do your activity in G53.9, and then put everything back
[13:55:10] <jepler> untested
[13:56:10] <jepler> it's also interesting to wonder whether there could be a "modal G53" (e.g., G53.1)
[14:00:56] <lerman> I haven't seen anything on the mailing lists in about five days. Is it just me or is there something I should know?
[14:01:44] <cradek> http://sourceforge.net/blog/category/sitestatus/
[14:01:58] <lerman> Thanks, KL
[14:02:09] <cradek> lerman: sourceforge put all their data in one shoebox and then it broke
[14:02:15] <jepler> /topic sourceforge broke. status: putting humpty together again
[14:02:23] <jepler> also they put slashdot in the same shoebox
[14:02:40] <jepler> also in a few weeks we'll probably hear that the bad guys have our plaintext passwords and social security numbers
[14:02:40] <cradek> wow
[14:02:59] <cradek> and control of our car brakes
[14:03:44] <lerman> The bad guys already have my SSN (in fact, they generated it.) :-)
[14:03:56] <JT-Shop> lol
[14:16:47] <mozmck> why is there wireless access to cars controls now anyhow?
[14:17:14] <cradek> to make them more like entertainment systems or video games
[14:17:40] <cradek> fwiw,
http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/
[14:17:49] <mozmck> yeah, I saw that. I like my old cars...
[14:18:05] <cradek> also it allows the car companies to sell you subscription services so they get monthly income from you forever
[14:18:29] <mozmck> or they kill your car on the highway. gov likes it too I'm sure.
[14:20:27] <skunkworks_> come on moz - you don't think military training in TX is a precursor to Gov take over - do you?
[14:30:04] <mozmck> Haven't heard much about that. But it seems gov never turns down an opportunity for more control, power, spying etc.
[14:30:47] <cradek> sure it does, when considering regulation of robber-barons
[14:31:10] <mozmck> well, they give money and that's more power :)
[14:31:19] <cradek> yay money
[14:33:54] <skunkworks_> imporved data passsing to cannon buffer so things like feedrate override can work inside subroutines..
[14:34:07] <mozmck> oh well. I'm not anti government. But not always for everything they do.
[14:34:13] <skunkworks_> ^ mach4 changelog..
[14:34:30] <cradek> skunkworks_: always interesting
[14:34:48] <mozmck> huh, need some imporved speling
[14:34:54] <skunkworks_> that was me..
[14:34:56] <skunkworks_> sorry
[14:34:58] <mozmck> :)
[14:35:33] <mozmck> I nevver mispel things.
[14:35:36] <skunkworks> forgot I had irc up here
[14:36:00] <skunkworks> http://www.pmdx.com/Downloads_Mach4/Mach4_Hobby_Releases/Mach4Hobby%20build-release-notes.txt
[14:36:03] <skunkworks> zlog
[14:36:30] <jepler> they port mach to linux yet?
[14:38:48] <skunkworks_> it is on the to-do list
[14:39:05] <cradek> why would you even
[14:39:45] <jepler> working RT with a user interface many people like?
[14:40:01] <cradek> oh right
[14:40:09] <skunkworks_> I don't think they will use any rt... I think the plan is external motion boards.
[14:40:15] <skunkworks_> only
[14:40:50] <cradek> why would you even
[14:42:28] <skunkworks_> heh
[14:43:56] <mozmck> I've heard that you can get a lot faster updates to external hardware with mach4, but I don't know how realtime it is.
[14:44:53] <skunkworks_> it isn't
[14:45:00] <skunkworks_> it is a buffered system.
[14:45:21] <mozmck> So basically the same as mach3 on that side.
[14:45:32] <skunkworks_> the only realtimey part of mach3/mach4 is arts printer port driver
[14:45:38] <skunkworks_> (software wise)
[14:45:46] <skunkworks_> other than external software
[14:45:54] <skunkworks_> *hardware
[14:46:04] <mozmck> For Mach3, believe me, I know.
[14:46:06] <jepler> then what do change items like "Incremental planner for jogging improved to avoid overshoot" mean?
[14:46:38] <skunkworks_> scarys sounding - huh? But it still pretty beta...
[14:46:44] <skunkworks_> if that
[14:47:30] <jepler> hmm maybe we should go back to talking about soviet mind-control airships
[14:48:08] <skunkworks_> oh - the goverment is flying drones around hacking peoples wifi...
[14:58:31] <skunkworks_> http://www.tormach.com/blog/greg-jackson-1952-2015/?utm_source=blog&utm_medium=email&utm_campaign=postnotify&utm_id=6073&utm_title=Greg+Jackson%2C+1952-2015
[15:37:14] <bjmorel_work> PCW are you around?
[15:55:52] <jepler> micges: what was the result of your hostmot2 ethernet testing with 2 devices? If you said anything further I missed it in scrollback.
[15:58:20] <micges> I've got ferrors but can't tell if it's from any bugs or my switch which is 100Mb
[16:07:58] <PCW> Around but I have ~800 boards to ship before end of the month so not much time
[16:09:24] <PCW> freeby.mesanet.com/dual.zip is my config that fails with 2 cards
[16:09:40] <micges> thanks
[16:11:22] <bjmorel_work> PCW: Is the 7i92 flashed before shipping?
[16:11:31] <PCW> ( had run the 7I76e through the switch for about 3 weeks at 3 KHZ without any problems)
[16:12:17] <PCW> yes the 7I92 must be programmed or you have no way to access it
[16:12:48] <bjmorel_work> Sorry, I meant do I have to load an appropriate bit file, and if so where are they located?
[16:13:26] <PCW> you need to load a bitfile appropriate to you use/daughtercards
[16:13:55] <bjmorel_work> ok, thanks.
[16:14:09] <PCW> they are in the 7i92.zip file in configs/hostmot2
[16:16:01] <PCW> you can read the current pinout with
[16:16:02] <PCW> mesaflash --device 7i92 --readhmid
[16:16:04] <PCW> (assuming its set for the default IP address 192.168.1.121)
[16:16:37] <bjmorel_work> Perfect, get to leave work in 7 minutes to go play :)
[16:23:38] <jepler> PCW: OK, I'll grab your config and see if I reproduce the problem with it, or can spot a problem
[16:33:19] <cradek> TIL adding 2-3% lead to tin and other coatings prevents (prevented) whiskers. I wonder what they use today, if anything
[16:36:17] <cradek> http://www.sciencedirect.com/science/article/pii/S0026271413003107
[16:41:07] <mozmck> As far as I know, lead-free solder simply has problems with tin whiskers.
[16:43:19] <mozmck> I've heard that NASA does not allow lead-free solder for at least critical stuff, and that it also is not used or not allowed for avionics?
[16:44:11] <cradek> that would not surprise me
[16:44:52] <cradek> it can make perfect sense to make disposable consumer crap a little less toxic, but not make sense in an airplane
[16:46:34] <mozmck> I wonder how much less toxic it really is? Lead comes out of the ground after all...
[16:47:11] <seb_kuzminsky> it's pretty toxic
[16:47:20] <seb_kuzminsky> uranium and asbestos come from the ground too
[16:48:30] <cradek> removing lead from gasoline in a region causes crime rates there to drop 22 years later
[16:49:33] <cradek> lead really screws up kids
[16:49:45] <mozmck> heh, that would be an extremely weak link. Many things can change in 22 years.
[16:50:01] <cradek> well that's what we have statistics for
[16:51:08] <mozmck> I know lead is toxic, but I wonder how much less toxic is the replacement? Is it %95 as toxic like R134A compared to R12?
[16:51:45] <cradek> citations near the end of the section
https://en.wikipedia.org/wiki/Tetraethyllead#Toxicity
[16:52:51] <cradek> R12 wasn't phased out because it was toxic, it was phased out because it was nuking the ozone layer
[16:53:35] <mozmck> Yes, but from things I read, R134A was only %5 less harmful.
[16:54:52] <cradek> have a citation? google isn't giving me one.
[16:56:25] <mozmck> no, it was a long time ago now I read on that. oh well, I'm cynical of a lot of stuff, especially when it becomes political.
[16:57:18] <cradek> unfortunately everything is politics; even science and facts and math seem to be fair game for opinion-based debate
[16:57:31] <mozmck> yes.
[16:57:42] <cradek> some people don't believe in ... facts
[17:08:24] <cradek> the graph on page 69 of the first citation is pretty amazing. wish there was an updated version of this paper.
[17:19:46] <seb_kuzminsky> i have a couple of non-trivkins machines, and it's making me wish Motion (or someone) switched from Free to Teleop mode automatically after homing
[17:19:59] <seb_kuzminsky> i always rack my gantry once before i remember to hit $ in Axis
[17:24:04] <seb_kuzminsky> seems like the GUI is the wrong place to do it
[17:27:55] <seb_kuzminsky> is there ever any good reason to stay in Free mode when Teleop is available?
[17:29:14] <jepler> I thought there was something deficient about teleop mode jogging, like that one of incremental or continuous jog was unavailable
[17:36:12] <micges> seb_kuzminsky: doing it in GUI is better than not doing it at all, all my gantry machines controls free/teleop from gui and they works fine
[17:36:21] <jepler> huh R-134a is no longer used in new cars in Europe. They're on to something called HFO-1234yf.
[17:37:45] <jepler> .. this one only causes 4x the global warming of CO2, but it *does* catch on fire.
[18:05:24] <seb_kuzminsky> jepler: ah, you're right, no incremental teleop jogging, boo
[18:06:06] <seb_kuzminsky> which is silly, and you can work around it with small mdi moves
[18:11:10] <andypugh> Google doesn’t seem to contain much bleating about Sourceforge mailing lists being down, Is it just us? (is it just me?) Theid blog / twitter seems to say that they think mailing lists are back.
[18:13:03] <seb_kuzminsky> andypugh: where do you see that? the most recent blog post (from yesterday) says they're still working on mailing lists:
http://sourceforge.net/blog/category/sitestatus/
[18:15:48] <andypugh> https://twitter.com/sfnet_ops
[18:16:02] <andypugh> But I might be reading too much into the archives being back.
[18:16:26] <andypugh> a comment on the message about archives asks when the lists are due back.
[18:17:22] <andypugh> I wonder if it is worth harvesting all the emails that have sent a message to the list to say why we have gone silent?
[18:33:31] <seb_kuzminsky> i've gotten personal emails from a couple of people and responded to them individually
[18:33:47] <seb_kuzminsky> there's also been people asking here on irc
[18:47:33] <seb_kuzminsky> ooh, an email on emc-users
[18:47:46] <seb_kuzminsky> it's a candle flickering in the darkness
[19:08:43] <jepler> PCW: compared to your config, I had to disable serial
[19:08:56] <jepler> just because I don't have any
[19:09:35] <jepler> .. and then it ran for me
[19:10:05] <jepler> config differences
http://paste.ubuntu.com/11917280/
[19:11:28] <jepler> so is it sserial?
[19:14:24] <Tom_itx> looks that way
[19:23:38] <jepler> micges: I haven't done the bw calculations, but if you're stuck with 100 megabit at the switch you're testing with, you could try doubling the servo period
[19:24:37] <micges> yeah working on 250Hz here
[19:26:27] <micges> also got many wd bites
[19:27:37] <micges> jepler: on what kernel are you now?
[19:28:34] <jepler> 3.14-0.bpo.2-rt-amd64 #1 SMP PREEMPT RT, core 2 duo, D-Link 5-Port Gigabit Switch (DGS-1005G)
[19:29:27] <jepler> 04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection (pcie 1x)
[19:31:51] <jepler> huh I don't know what git show-branch is, but it sure is colorful
[19:51:16] <PCW> Hmm multiple cards working today...
[19:52:45] <jepler> neat, an automated program was able to find a "new" branchless implementation of abs()
[19:53:09] <jepler> http://blog.regehr.org/ ->
http://blog.regehr.org/extra_files/souper-jul-15.html
[19:54:21] <jepler> if I understand it right, the superoptimizer is told to find a possibly more-efficient way to compute the value that the original code (%0 .. %3) stores in %3
[19:54:31] <jepler> and it comes up with the code in %4 .. %6
[19:54:52] <jepler> which would be written in C as
[19:54:53] <jepler> int abs_nocmp(int x) {
[19:54:53] <jepler> int q = x >> 31;
[19:54:53] <jepler> int r = x ^ q;
[19:54:53] <jepler> return r - q;
[19:54:55] <jepler> }
[19:55:44] <jepler> this method is known to people
http://www.geeksforgeeks.org/compute-the-integer-absolute-value-abs-without-branching/ but souper reasoned it out for itself
[19:55:53] <jepler> PCW: any idea what's different from yesterday to today?
[19:59:57] <PCW> No idea but occasionally I got some "resource not available" errors on startup
[19:59:59] <PCW> running cheerfully now with 2 sserial devices at 1 KHz, I did try 2 KHz yesterday but the 1 KHZ test failed also
[20:01:11] <jepler> I see occasional startup problems too. I have not actually tried to figure out why. I know I shold..
[20:01:14] <jepler> should
[20:04:21] <jepler> hm2_eth: ERROR: 192.168.1.129: Could not retrieve mac address
[20:04:21] <jepler> hm2_eth: rtapi_app_main: Resource temporarily unavailable (-11)
[20:05:12] <jepler> PCW: ^^ is this your startup message?
[20:05:52] <PCW> Not sure, let me try a bunch of starts
[20:07:04] <jepler> that was with a deliberately wrong address
[20:07:10] <jepler> I also got this once in about 20 starts
[20:07:10] <jepler> hm2_eth: ERROR: receiving packet: Resource temporarily unavailable
[20:07:10] <jepler> hm2_eth: Unrecognized ethernet board found: -- port names will be wrong
[20:07:10] <jepler> hm2_eth: discovered
[20:07:10] <jepler> hm2: llio reports invalid number of I/O connectors (0)
[20:07:57] <jepler> that one ends with
[20:07:57] <jepler> hm2_eth: rtapi_app_main: Invalid argument (-22)
[20:09:02] <jepler> actually that seems to be the more common failure
[20:19:06] <jepler> here's a tcpdump of a failure that ends with (-22):
http://paste.debian.net/284671/
[20:19:42] <jepler> hm2_eth: ERROR: used llio->read in realtime task (addr=0x010c)
[20:20:04] <jepler> that time the terminal also logged this, which is weird (I never started a realtime thread)
[20:20:12] <PCW> Yes I just got that error
[20:21:28] <PCW> hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
[20:21:30] <PCW> hm2_eth: 10.10.10.10: Hardware address: 00:60:1b:10:40:13
[20:21:31] <PCW> hm2_eth: 10.10.10.11: Hardware address: 00:60:1b:11:80:44
[20:21:33] <PCW> hm2_eth: ERROR: receiving packet: Resource temporarily unavailable
[20:21:35] <PCW> hm2_eth: Unrecognized ethernet board found: -- port names will be wrong
[20:21:37] <PCW> rtapi_app: caught signal 11 - dumping core
[20:21:39] <PCW> ./hm2-pidstepper_dual.hal:42: waitpid failed /home/pcw/linuxcnc-dev/bin/rtapi_app hm2_eth
[20:21:40] <PCW> ./hm2-pidstepper_dual.hal:42: /home/pcw/linuxcnc-dev/bin/rtapi_app exited without becoming ready
[20:24:00] <PCW> and the joint following errors are back
[20:24:02] <PCW> maybe some initialization fails but it continues
[20:25:01] <jepler> 19:58:44 <PCW> rtapi_app: caught signal 11 - dumping core
[20:25:12] <jepler> the UI still started after the run where you got ^^^ that ?
[20:25:19] <jepler> after that message, all realtime is stopped!
[20:37:46] <PCW> failed to start that time but now when it does start, the joint following errors are back
[20:37:54] <jepler> sendto(6, "\210]\0\0", 4, 0, NULL, 0) = 4
[20:37:54] <jepler> recvfrom(6, 0x7fffc17d7c20, 16, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
[20:37:57] <jepler> write(1, "hm2_eth: ERROR: receiving packet"..., 67) = 67
[20:38:32] <jepler> sometimes at startup it is failing to get back a packet in time
[20:39:12] <jepler> but also I think there are some bugs with the new 'unrecognized card' code; and it falls into that code when the first thing goes wrong because of some missing error handling
[20:42:15] <PCW> Yes its time dependent (it get the joint following error only at 2 KHz, not 1 KHz)
[20:42:17] <PCW> if it ever works at 2 KHz it continues to work
[20:42:29] <jepler> hm2_eth: discovered 7I92
[20:42:29] <jepler> hm2/hm2_7i92.0: out of memory!
[20:42:33] <jepler> well that's a new one
[20:42:35] <PCW> s/it get/I get/
[20:42:59] <PCW> i think it parsing gawbidge
[20:44:44] <PCW> its
[20:44:46] <PCW> bbl dinner
[20:46:50] <jepler> yes, it would log the 'error receiving packet' message and then go on to try to do something with the received package
[20:46:54] <jepler> packet
[20:53:57] <jepler> 1437528484.790617 sendto(6, "\210]\0\0", 4, 0, NULL, 0) = 4
[20:53:57] <jepler> 1437528484.790678 recvfrom(6, 0x7fff3318af70, 16, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
[20:54:02] <jepler> 1437528484.790754 write(1, "hm2_eth: ERROR: receiving packet"..., 67) = 67
[20:55:11] <jepler> this should be going through hm2_eth_read which retries until 200*1000*1000ns pass
[20:55:49] <jepler> so it's very weird that it could get done failing after just 137000ns
[21:11:08] <jepler> oh wait, this one's not going through the retry machinery in the first place
[21:29:09] <jepler> well, I have a series of changes here that collectively have pushed the startup problem down from maybe 1-in-10 to less than 2-in-1000
[21:30:28] <jepler> I'll clean them up and publish them yet tonight. up to 800 successful startups after the latest fix, no failures
[21:37:56] <jepler> .. 2100
[21:37:59] <jepler> I think it might be fixed
[21:42:50] <jepler> .. 4400
[21:44:29] <jepler> 5000+
[21:44:43] <jepler> (boy starting got faster after I took my debugging stuff all back out too)
[21:57:15] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-startup ff37886 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: ensure that the thread-specific key is initialized * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ff37886
[21:57:15] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-startup e63a15d 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: reset errno before socket recv * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e63a15d
[21:57:15] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-startup 36a8145 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: handle socket errors in hm2_eth_probe * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=36a8145
[21:57:20] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-startup 214c71b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: don't use nonblocking socket * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=214c71b
[21:57:24] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-startup f3c9158 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: use a longer timeout during setup * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f3c9158
[21:57:28] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-startup 5bc678a 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: allow time for the probe request packet to come back * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5bc678a
[21:57:35] <jepler> this branch is based on 2.7 and solves several kinds of intermittent startup problems with hm2-eth.
[22:01:29] <jepler> 10000 startups
[22:02:33] <jepler> (these are halrun startups, not linuxcnc startups)
[22:15:40] <pcw_home> I'll have to see if that fixes the joint FE's at 2 KHz. It sort of looks like some initialization silently failed
[22:16:30] <jepler> I also recommend using the read-request functions. doing the split read is not automatic, you have to do it manually with your addfs
[22:16:42] <jepler> put the read-request for each board first, then the read for each board
[22:20:27] <pcw_home> So if only read is called, it does the request/read automatically
[22:32:07] <pcw_home> can you reorder the reads to allow some optimization?
