Back
[00:04:03] -!-
theorbtwo has quit [Ping timeout: 240 seconds]
[00:04:20] theorb is now known as
theorbtwo
[00:26:59] -!-
tom3p [tom3p!~tomp@74-93-88-241-Illinois.hfc.comcastbusiness.net] has joined #emc-devel
[00:29:51] -!-
The_Ball has quit [Ping timeout: 252 seconds]
[01:03:33] -!-
The_Ball has quit [Quit: leaving]
[01:08:00] -!-
The_Ball has quit [Client Quit]
[01:11:41] -!-
adb has quit [Remote host closed the connection]
[01:11:57] -!-
The_Ball has quit [Client Quit]
[01:27:33] -!-
The_Ball has quit [Quit: leaving]
[01:35:15] -!-
The_Ball_ has quit [Client Quit]
[01:36:48] -!-
John_f_ has quit [Quit: Ex-Chat]
[01:47:07] -!-
tom3p [tom3p!~tomp@74-93-88-241-Illinois.hfc.comcastbusiness.net] has parted #emc-devel
[01:48:41] -!-
Calyp has quit [Read error: Operation timed out]
[02:43:41] -!-
chester88 has quit [Ping timeout: 240 seconds]
[02:46:06] -!-
adb [adb!~Moldovean@178-211-232-101.dhcp.voenergies.net] has joined #emc-devel
[03:03:27] -!-
Ze1982 [Ze1982!~Ze1982@ppp255-131.static.internode.on.net] has joined #emc-devel
[03:04:49] -!-
chester88 [chester88!~chris@d64-180-196-97.bchsia.telus.net] has joined #emc-devel
[03:08:26] -!-
psha [psha!~psha@213.208.162.69] has joined #emc-devel
[03:09:22] -!-
West0n has quit [Ping timeout: 252 seconds]
[03:26:06] <CIA-11> EMC: 03cmorley 07v2.5_branch * rfbd67939671d 10/src/emc/usr_intf/touchy/ (touchy.glade touchy.py): Touchy - add ability to choose different gtk theme then system
[03:26:07] <CIA-11> EMC: 03cmorley 07v2.5_branch * r05db0721e36a 10/src/emc/usr_intf/touchy/touchy.py: touchy - add ability to change DRO text color from preference file
[03:26:08] <CIA-11> EMC: 03cmorley 07v2.5_branch * r3beb1a3ed489 10/src/emc/usr_intf/touchy/touchy.py: touchy - fix for theme changes to 'follow system theme'
[03:26:09] <CIA-11> EMC: 03cmorley 07v2.5_branch * r982a1068228a 10/src/hal/user_comps/gladevcp.py: gladevcp - add ability to change GTK theme of panel
[03:26:10] <CIA-11> EMC: 03cmorley 07v2.5_branch * r8b1a5b2ceb1f 10/src/hal/user_comps/gladevcp.py: gladevcp - add option to force panel to maximize
[03:26:11] <CIA-11> EMC: 03cmorley 07v2.5_branch * rc06ef0282ab1 10/src/emc/usr_intf/touchy/touchy.py: touchy - add ability to force maximize after geometry move
[03:26:11] <CIA-11> EMC: 03cmorley 07v2.5_branch * rb8471578ae17 10/src/emc/usr_intf/touchy/touchy.glade: touchy - move theme change button to proper spot
[03:26:13] <CIA-11> EMC: 03cmorley 07v2.5_branch * r8e6089d03a3c 10/src/emc/usr_intf/touchy/touchy.py: touchy - add ability to choose error message text color
[03:53:59] -!-
ries has quit [Quit: ries]
[04:15:10] -!-
psha has quit [Quit: Lost terminal]
[04:16:55] -!-
WayL84Supper has quit [Client Quit]
[04:17:40] -!-
L84Supper has quit [Ping timeout: 252 seconds]
[04:19:08] -!-
WayL84Supper has quit [Client Quit]
[04:41:12] -!-
dgarr [dgarr!~dgarrett@adsl-75-61-69-225.dsl.pltn13.sbcglobal.net] has joined #emc-devel
[04:45:41] -!-
FinboySlick has quit [Quit: Leaving.]
[04:47:52] -!-
mozmck has quit [Quit: Leaving.]
[04:55:25] -!-
mozmck [mozmck!~moses@client-173.225.233.241.dfwtx.partnershipbroadband.com] has joined #emc-devel
[04:58:23] -!-
packrat has quit [Ping timeout: 240 seconds]
[05:01:58] -!-
West0n has quit [Ping timeout: 263 seconds]
[05:08:18] -!-
mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #emc-devel
[05:13:29] -!-
dgarr has quit [Quit: Leaving.]
[05:22:47] -!-
Eartaker has quit [Quit: Not again...]
[05:24:13] -!-
ve7it has quit [Remote host closed the connection]
[06:45:38] -!-
e-ndy [e-ndy!~jkastner@static-84-242-102-36.net.upcbroadband.cz] has joined #emc-devel
[06:51:38] -!-
Eartaker has quit [Quit: What does this button do???]
[07:10:34] -!-
robh__ [robh__!~robert@5ace7086.bb.sky.com] has joined #emc-devel
[07:36:23] -!-
SWPadnos has quit [Read error: Connection reset by peer]
[07:36:24] -!-
SWPadnos_ [SWPadnos_!~Me@74-92-8-214-NewEngland.hfc.comcastbusiness.net] has joined #emc-devel
[07:36:29] SWPadnos_ is now known as
SWPadnos
[08:02:33] -!-
Valen has quit [Ping timeout: 264 seconds]
[08:07:01] -!-
mhaberler has quit [Quit: mhaberler]
[08:08:52] -!-
robh__ has quit [Read error: Connection reset by peer]
[08:09:20] -!-
robh__ [robh__!~robert@5ace7086.bb.sky.com] has joined #emc-devel
[08:14:29] -!-
mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #emc-devel
[08:16:34] -!-
theos has quit [Ping timeout: 250 seconds]
[08:31:04] -!-
robh__ has quit [Quit: Leaving]
[08:42:06] -!-
e-ndy has quit [Quit: Ex-Chat]
[08:42:24] -!-
e-ndy [e-ndy!~jkastner@static-84-242-102-36.net.upcbroadband.cz] has joined #emc-devel
[09:02:12] -!-
psha[work] [psha[work]!~psha@195.135.238.205] has joined #emc-devel
[09:31:31] -!-
Grandixximo has quit [Quit: Leaving]
[09:48:33] -!-
cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #emc-devel
[09:49:57] <cncbasher> using pncconf anyone haveing the z axis config screen grayed out ?
[09:57:47] theorbtwo is now known as
lhs_lovelace
[09:57:51] lhs_lovelace is now known as
theorbtwo
[10:20:09] <cncbasher> solved
[10:20:12] -!-
cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has parted #emc-devel
[10:23:05] -!-
toastyde1th has quit [Ping timeout: 258 seconds]
[10:49:55] -!-
The_Ball has quit [Ping timeout: 258 seconds]
[11:02:52] -!-
nicko has quit [Ping timeout: 258 seconds]
[11:21:48] -!-
robin__ has quit [Ping timeout: 255 seconds]
[11:33:47] -!-
mhaberler has quit [Quit: mhaberler]
[11:40:47] -!-
mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #emc-devel
[12:07:18] -!-
DaViruz has quit [Ping timeout: 246 seconds]
[12:27:56] -!-
skunkworks [skunkworks!447329d2@gateway/web/freenode/ip.68.115.41.210] has joined #emc-devel
[12:28:06] -!-
SWPadnos has quit [Changing host]
[12:28:06] -!-
SWPadnos [SWPadnos!~Me@emc/developer/SWPadnos] has joined #emc-devel
[12:43:50] <CIA-11> EMC: 03jthornton 07v2.4_branch * rf662d0fa42b4 10/src/hal/utils/comp.g: Docs: expand description
[12:46:07] <CIA-11> EMC: 03jthornton 07v2.5_branch * r0dd096cd48e7 10/src/hal/utils/comp.g: Docs: expand description
[12:54:15] -!-
JT-Shop_ [JT-Shop_!~chatzilla@216-41-156-49.semo.net] has joined #emc-devel
[12:56:02] -!-
JT-Shop has quit [Ping timeout: 258 seconds]
[12:56:11] JT-Shop_ is now known as
JT-Shop
[13:11:40] -!-
dgarr [dgarr!~dgarrett@adsl-75-61-69-225.dsl.pltn13.sbcglobal.net] has joined #emc-devel
[13:12:54] <dgarr> for consideration: bugfix patch (v2.5_branch) for ngcgui:
http://www.panix.com/~dgarrett/stuff/0001-ngcgui.tcl-bugfix-for-numbered-params-in-range-31-99.patchfo
[13:13:43] <skunkworks> http://www.panix.com/~dgarrett/stuff/0001-ngcgui.tcl-bugfix-for-numbered-params-in-range-31-99.patch
[13:14:07] -!-
elmo40 has quit [Ping timeout: 244 seconds]
[13:14:16] <psha[work]> skunkworks: irc log readers will thank you :)
[13:14:31] <skunkworks> :)
[13:15:28] <dgarr> skunkworks thanks!
[13:16:45] <CIA-11> EMC: 03cradek 07v2.5_branch * r41929a66e20f 10/tcl/ngcgui.tcl: ngcgui.tcl: bugfix for numbered params in range 31-99 or 3digit
[13:16:51] <cradek> dgarr: thanks for maintenance! :-)
[13:17:59] <dgarr> np
[13:22:21] -!-
Calyp has quit [Ping timeout: 264 seconds]
[13:24:00] -!-
robin__ has quit [Ping timeout: 252 seconds]
[13:34:52] -!-
servos4ever has quit [*.net *.split]
[13:34:52] -!-
sagC has quit [*.net *.split]
[14:09:06] -!-
JT-Work [JT-Work!~chatzilla@216-41-154-151.semo.net] has joined #emc-devel
[14:12:22] -!-
JT-Work has quit [Read error: Connection reset by peer]
[14:12:43] -!-
JT-Work [JT-Work!~chatzilla@216-41-154-151.semo.net] has joined #emc-devel
[14:13:00] -!-
jdhNC has quit [Quit: ^^^ that's fucking funny right there.]
[14:15:46] -!-
Valen has quit [Quit: Leaving.]
[14:15:56] -!-
nullie has quit [Quit: Ex-Chat]
[14:31:16] -!-
psha[work] has quit [Quit: leaving]
[14:40:05] -!-
cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #emc-devel
[14:54:03] -!-
JT-Work has quit [Remote host closed the connection]
[14:54:18] -!-
geo01005 has quit [Ping timeout: 276 seconds]
[15:03:08] -!-
psha [psha!~psha@195.135.237.18] has joined #emc-devel
[15:13:39] -!-
mhaberler has quit [Quit: mhaberler]
[15:19:12] -!-
mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #emc-devel
[15:20:15] -!-
dgarr has quit [Quit: Leaving.]
[15:24:46] -!-
jimbo132 has quit [Ping timeout: 258 seconds]
[15:56:17] -!-
El_Matarife has quit [Quit: Nettalk6 - www.ntalk.de]
[15:59:37] <cncbasher> CIA-11> can pncconf read the pin file or IDROM as PCW suggests to dynamicly read in pinconfigs from either firmware builds or custom
[16:01:08] <mhaberler> how does the rs274 interpreter access tool table data when running under a UI like Axis? tool_table comes from EmcStatus into python stat.tool_table, but then I'm at loss how GET_EXTERNAL_TOOL_TABLE access this data
[16:03:17] <CIA-11> EMC: 03mshaver 07v2.5_branch * rfd856198cecd 10/src/hal/drivers/mesa-hostmot2/sserial.c: Changed NumRegisters and MultipleRegisters to match version 22 bit file.
[16:03:38] -!-
mshaver [mshaver!~mshaver@c-69-255-160-198.hsd1.md.comcast.net] has joined #emc-devel
[16:03:53] <mhaberler> disregard - found it. lib/python/interpret.py get_tool
[16:05:45] <mshaver> I made a commit to v2.5_branch. Will the buildbot make me a new .deb right away, or does it do it at a certain time of day. Can I send it a command to make it do it now? I should probably check the wiki...
[16:06:31] <cradek> I am not sure packages are building successfully right now in 2.5. Seb keeps commenting on something related, but I haven't checked into it
[16:08:22] <mshaver> Well, hope you're keeping your head above water out there Chris! I'll go look at Seb's messages and see what's up.
[16:08:52] <cradek> I'm trying my best, anyway
[16:09:06] <cradek> I expect more time/normalcy in a month or two.
[16:13:02] <mshaver> According to this
http://buildbot.linuxcnc.org/buildbot/waterfall have triggered a build in about a half hour. I'll check back & see whether I get a new 2.5 deb!
[16:13:25] <cradek> cool - maybe it's master that's not working...?
[16:14:00] <mshaver> I'll see what develops and let you know!
[16:14:39] <cradek> thanks
[16:16:09] -!-
isssy has quit [Client Quit]
[16:23:21] -!-
geo01005 has quit [Ping timeout: 276 seconds]
[16:28:58] <mhaberler> manual says: G10 L1 reloads the tool table
[16:29:12] <mhaberler> axis says: P value out of range with G10 L1 or G10 L10 when doing 'G10 L1'
[16:29:32] <mhaberler> looks like it needs G10 L1 Px with x > 0
[16:29:44] <mhaberler> I can fix the manual or the code.. what's better?
[16:30:00] <cradek> G10 L1 ... reWRITES the tool table
[16:30:14] <cradek> it's how you change an entry
[16:30:52] <mhaberler> fine, but the manual says.. Program a G10 L1 to set a tool table entry from a program or the MDI window. G10 L1 reloads the tool table.
[16:32:21] <mhaberler> I get this on master
[16:32:36] <cradek> I think "rewrites" was meant where it says "reloads"
[16:32:40] <cradek> reloads is the wrong word
[16:32:57] <mhaberler> try out 'G10 L1' in your favorite UI, please
[16:33:14] <mhaberler> and look at stderr
[16:33:59] <cradek> "G10 L1" is not a valid command because it doesn't say what tool to alter and what setting of the tool to alter
[16:34:30] <KimK> mhaberler: Would you mind if I fixed it so I don't have to merge? Is this in the main g-code reference in the user manual?
[16:34:46] <mhaberler> http://emc.mah.priv.at/docs/html/gcode/main.html#_g10_l1_set_tool_table_a_id_sec_g10_l1_set_tool_table_a
[16:34:57] <mhaberler> g-code reference
[16:35:03] <mhaberler> thanks!
[16:35:16] <KimK> Thank you.
[16:35:27] <cradek> mhaberler: I don't think we're communicating effectively
[16:35:45] <cradek> the docs have the wrong word. where it says reloads, it should say rewrites
[16:35:55] <mhaberler> ok
[16:36:02] <cradek> it should also say that it's an error if P is unspecified
[16:36:08] <mhaberler> yes
[16:36:18] <mhaberler> that's all - I was just wondering
[16:36:21] <KimK> cradek: I'll add that too.
[16:36:38] <cradek> possibly also should be an error (in docs and interp) if G10 L1 Px but no other words, because it would have no effect
[16:37:45] <mhaberler> oh, I see .. it was meant to mean 'a successful G10 L1 <foo> <bar>' command rewrites the tool table'
[16:38:18] <mhaberler> I read this as 'a standalone "G10 L1" rewrites the tool table' (whatever sense that makes ;)
[16:38:34] <cradek> yes the first one you said is my understanding
[16:38:48] <cradek> standalone G10 L1 is rightfully an error because it would have no effect
[16:39:00] <cradek> I don't see why rewriting the unchanged tool table would be a useful feature
[16:39:10] <mhaberler> I violently agree
[16:39:13] <cradek> the idea is that it gets written immediately after every change
[16:39:29] <cradek> ok yay, just a doc bug then
[16:39:36] <mhaberler> yes
[16:44:05] <mhaberler> sorry about being a pain - I'm trying to excise toolTable from emcStatus, which is why I need to understand every wart
[16:44:38] <cradek> on the contrary, comparing behavior with docs is heroic, not irritating
[16:48:28] -!-
ve7it [ve7it!~LawrenceG@S0106009027972e37.pk.shawcable.net] has joined #emc-devel
[16:52:42] <psha> heh, cmorley uses mailer that a) is not compatible with gmane thread detection b) has nearly 100% hit ration in my spam filters :)
[16:54:33] <cradek> hotmail with html multipart/alternative
[16:55:05] <cradek> -users is configured to squash that crap into text/plain but we -dev isn't
[16:55:23] <cradek> s/we//
[17:08:33] -!-
mhaberler has quit [Quit: mhaberler]
[17:15:42] -!-
skunkworks has quit [Ping timeout: 252 seconds]
[17:43:57] -!-
mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #emc-devel
[17:45:22] -!-
IchGuckLive has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.17/20110422054454]]
[17:46:51] -!-
nullie has quit [Quit: Ex-Chat]
[17:49:34] -!-
JT-Work [JT-Work!~chatzilla@216-41-154-151.semo.net] has joined #emc-devel
[17:50:21] <mhaberler> cradek: ok?
http://git.mah.priv.at/gitweb/emc2-dev.git/commitdiff/fae1f3a309bb41ef01d56cf374df984ad92bf2cc
[17:52:15] <mhaberler> or 2.5
[17:52:35] -!-
skunkworks [skunkworks!447329d2@gateway/web/freenode/ip.68.115.41.210] has joined #emc-devel
[17:54:10] -!-
geo01005 has quit [Ping timeout: 240 seconds]
[17:56:33] -!-
Loetmichel has quit [Ping timeout: 264 seconds]
[17:56:54] <mshaver> So, I never got my new .deb file from the buildbot :( According to the end of this page:
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/391/steps/shell_4/logs/stdio the problem was. "cp: cannot create regular file `/usr/bin/ngcgui': Permission denied". Fixable?
[17:57:51] <mhaberler> KimK: are you pushing your doc changes to 2.5 or to master?
[17:58:08] <mshaver> In fact, a new 2.5 deb hasn't been made since about a month ago...
[17:58:27] <KimK> mhaberler: to 2.5 as soon as I get my ducks in a row.
[17:58:33] <KimK> mshaver: Hi Matt
[17:58:40] <mshaver> Hey!
[17:58:57] <mhaberler> ok, then I'll apply this 2.5 as well
[17:58:57] <skunkworks> hey matt did you make it to the cnc fest?
[17:59:05] <mshaver> yes
[17:59:14] <skunkworks> how was it?
[17:59:19] <KimK> How was it?
[17:59:23] <KimK> Ha!
[17:59:26] <skunkworks> me first!
[17:59:46] <mshaver> not much to say really. no emc crew to speak of.
[18:00:09] <KimK> Wasn't Ray Henry there?
[18:01:32] <mshaver> Yes. I guess it was him, me & Jon Elson on the emc side and everybody else with Mach. Actually, the fellow with the Emco PC-50 was there too!
[18:02:03] <skunkworks> was he showing off his video system?
[18:02:13] <skunkworks> (emco guy)
[18:02:45] <mshaver> Gotta go tinker with the air conditioner, back in a little while!
[18:03:02] <mshaver> skunkworks: Yes, I think so.
[18:03:53] <KimK> How was the attendance at Ray's classes?
[18:04:40] <KimK> skunkworks: What video system is this? For lathe tool setting?
[18:05:24] <mshaver> pretty good I think, I didn't go. but I taught a class right after him one day and he had at least 10 people I think
[18:06:06] <KimK> OK, sounds good, even if half of them were just curious.
[18:08:36] <skunkworks> KimK: a plugin for axis that adds a video tab with cross hair for aligning parts
[18:09:24] <KimK> Like psha's camera stuff?
[18:11:13] <skunkworks> exactly
[18:11:25] <skunkworks> (it is psha's stuff he used)
[18:11:53] <KimK> skunkworks: I was pretty impressed by this idea:
http://www.youtube.com/watch?v=zb0IQPHbU0g (using a closeup camera to set lathe tools)
[18:13:33] <skunkworks> That is pretty cool - I bet something like that could be used the same way in emc21
[18:13:36] <skunkworks> or emc2
[18:14:01] <skunkworks> (sorry - been working on the super secret beta of emc21)
[18:16:51] <KimK> Is that the one with the 11-dimensional quantum tunneling?
[18:18:32] <skunkworks> pfha - whatever. we all know there are only 10 dimensions
[18:18:55] <KimK> The 11th one is for comments.
[18:24:08] <CIA-11> EMC: 03mhaberler 07v2.5_branch * r07b4b8277ab7 10/src/emc/rs274ngc/interp_convert.cc: interp: report error on G10 L1 Px without offsets
[18:26:55] <cradek> mhaberler: it should be allowed to program just radius/orientation with G10 L1
[18:28:39] -!-
vladimirek [vladimirek!~vladimire@adsl-dyn24.78-98-14.t-com.sk] has joined #emc-devel
[18:30:05] <mhaberler> duh. will fix.
[18:31:10] <cradek> thanks
[18:32:15] <mhaberler> so its at least one of XYZABCUVWRQ
[18:37:50] <cradek> yes I think that's it
[18:38:01] -!-
danimal_garage has quit [Ping timeout: 246 seconds]
[18:39:12] -!-
tris has quit [Ping timeout: 255 seconds]
[18:40:11] <mhaberler> is there a 'never amend a patch on git.linuxcn.corg' rule?
[18:40:37] <mhaberler> like push with -f
[18:41:51] <cradek> you would certainly never want to do that to fix a minor error like this
[18:42:13] <mhaberler> ok
[18:42:14] <cradek> we have done it maybe twice, to fix very grave mistakes
[18:42:35] <cradek> I think once someone put all of master's changes onto a release branch accidentally
[18:43:04] <CIA-11> EMC: 03mhaberler 07v2.5_branch * r9f5146e2300e 10/src/emc/rs274ngc/interp_convert.cc: interp: report error on G10 L1 Px without offsets, radius and orientation
[18:43:23] <cradek> I should probably set the config option that forbids it (to be removed in an emergency)
[18:48:03] -!-
JT-Work has quit [Quit: ChatZilla 0.9.87 [Firefox 5.0/20110615151330]]
[18:51:36] <cradek> anyone have any thoughts about that?
[18:51:48] <mhaberler> fine with me
[18:56:50] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust1037.basl.cable.virginmedia.com] has joined #emc-devel
[18:59:02] <andypugh> What would be the "EMC-way" to handle a problem that has just come up with Smart Serial? If you look in sserial.c line 337 there is an error message that, if the user sets the servo thread too fast, can print to the error log 10,000 times per second or more, and apparently eventually fills the whole hard drive.
[18:59:37] <cradek> I don't know if there's an "emc way" but seems like you should just print the error once
[18:59:50] <andypugh> If it happens every seldom, it's sort-of OK. But it needs to be flagged at one level, and if it is bad enough it probably ought to stop the driver.
[19:00:51] <andypugh> The way we do it in the car ECUs is an on-error increment, and on-success decrement, and a threshold which triggers an error/limphome/MIL lamp
[19:07:30] -!-
Xolotl4 has quit [Quit: Leaving]
[19:09:21] -!-
SWPadnos has quit [Ping timeout: 255 seconds]
[19:09:48] -!-
vladimirek has quit [Remote host closed the connection]
[19:11:33] <mhaberler> personally I think a error counter array would be good idea; for instance the Linux Ip stack counters are very useful in diagnosing problems and fairly cheap
[19:12:54] <mhaberler> why dont you makle them HAL pins?
[19:12:55] <andypugh> Arguably that belongs in rtapi_print_err rather than my code.
[19:14:23] <mhaberler> I'm not sure if 'printing' is the best abstraction in a high-speed environment
[19:15:33] <mhaberler> it's the cause of the 'filling problem'
[19:15:41] <andypugh> Doing anything clever is a job for a proper programmer. I just take what exists and extend it to suit other hardware.
[19:16:53] <mhaberler> HAL pins would be unclever unough methinks
[19:18:12] <andypugh> You mean an error counter pin
[19:18:15] <andypugh> ?
[19:18:24] <mhaberler> yes
[19:18:44] <andypugh> Folk would just leave it unconnected. (I know I would)
[19:19:23] <mhaberler> doesnt matter - you can easily view it with onboard tools if you need to - no debugging, diving for files
[19:19:30] <andypugh> But there is a lot to be said for the increment/decrement counter with the threshold as a parameter.
[19:19:32] -!-
sumpfralle has quit [Read error: Connection reset by peer]
[19:21:01] <mhaberler> I dont quite get it -. lets say that starts with 0. sucess makes -1, failure makes it 0 again. then a series of successes - it bumps into -MAXINT?
[19:21:41] <mhaberler> actually there are quite a few debugging pins in rt code
[19:22:58] <cpresser> andypugh: thats only usefull if every error is only counted once. at least that is the way i am guessing the car-onboard-error-stuff works
[19:24:21] <cpresser> printing errors to syslog is the default linux-way. repeating errors wont get printed. instead syslog tells you that the last message appeared 10000times
[19:26:53] <andypugh> cpresser: I have assumed that RT code has to use the RTAI error messager
[19:29:03] <andypugh> mhaberler: I would probabaly initialise to -20 with an on-error increment of 5 and an on-success decrement of 1. Success only decrements to zero. Errors only get printed if the value is <0.
[19:29:24] <mhaberler> ah I see
[19:29:29] -!-
JT-Shop has quit [Ping timeout: 240 seconds]
[19:29:59] <mhaberler> if value > threshold you mean
[19:30:21] -!-
jthornton has quit [Ping timeout: 258 seconds]
[19:30:47] <mhaberler> does the 'error print' reset?
[19:32:07] <mhaberler> that's ok for occasional non-fatal errors I guess
[19:34:54] <andypugh> Well, the idea is that it prints 4 errors, then stops. And if there are >threshold errors, then it bails.
[19:35:31] <andypugh> But it will carry on indefinitely if the timeouts only happen one time in 5.
[19:36:42] <mhaberler> I'd suggest to split that into 'counting' and 'interpreting counts' which is a different thing IMO
[19:37:03] <mhaberler> maybe even a HAL component
[19:37:42] <mhaberler> never fudge at the source
[19:47:10] -!-
toastydeath has quit [Ping timeout: 260 seconds]
[19:55:50] -!-
psha has quit [Quit: Lost terminal]
[19:56:50] <andypugh> Well, the immediate question is what I do to prevent the problem of a too-fast servo thread and the sserial driver. I don't see an external HAL component as the solution.
[19:57:55] -!-
Techrat has quit [Quit: Leaving]
[19:58:45] <mhaberler> no, do the HAL pins *in* the driver; have a a python script access them and report if something bad happens - like with psha's emc-notify
[20:01:33] <andypugh> That makes my driver fundamentally different to all the other drivers, then.
[20:02:12] <andypugh> And means that it doesn't report any faults at all unless the users load up the python.
[20:02:54] <mhaberler> use another pin for reporting thresholds & clearing?
[20:03:35] <mhaberler> print it on first error, the just bump the counter?
[20:03:40] <andypugh> I am not necessarily saying that all the other HAL components are right, but if I make mine different, then I am either going to have to change ever other component, or defend my difference.
[20:04:25] <andypugh> So, you are proposing never raisign a hard error?
[20:04:55] -!-
e-ndy has quit [Quit: Ex-Chat]
[20:05:11] <mhaberler> the original problem was printing overflow
[20:06:27] <andypugh> Yes. True. But on reflection, and after use by a user, I realise that there is an unhandled problem.
[20:06:58] <mhaberler> can you recover, or cant you?
[20:07:55] <mhaberler> you are in good company: grep motion.debug src/emc/motion/*c
[20:08:45] <mhaberler> watching a pin and using emc-notify doesnt stuff the disk
[20:09:00] <andypugh> I reckon if it is an occasional problem it is OK. The problem is of the smart-serial buffer being still full from the previous thread iteration. Currently the driver writes to the buffer regardless, making the problem more serious.
[20:09:47] <andypugh> The first thing to do is to break before the write. But then we could easily end up only updating every other thread (or worse) and not actually knowing.
[20:09:50] <mhaberler> is there a backpressure mechanism? can you 'reschedule for later if busy'=
[20:10:13] <andypugh> Well, you can write next thread.
[20:10:14] <mhaberler> then count the skips
[20:10:56] <andypugh> That's the idea, count the skips and if they are more than one time in N, then eventually the driver really ought to give up completely.
[20:11:17] <mhaberler> determine if HW busy, if yes bump skip count and reschedule; if skip count too high - shit hit the fan
[20:11:42] <mhaberler> reset skip count on HW found idle
[20:12:37] <andypugh> The servo thread runs at the rate it runs at. "Rescheduling" means waiting a full servo period.
[20:13:00] <mhaberler> yes
[20:13:23] <mhaberler> too late?
[20:13:34] <andypugh> My increment/decrement does achieve that behaviour, I think.
[20:14:17] <mhaberler> oh I seen, the hw is still busy after say 1msec?
[20:14:49] <mhaberler> smart serial = SSI interface, right?
[20:15:08] <andypugh> No, it's a Mesa proprietary protocol.
[20:15:15] <mhaberler> uh
[20:15:55] -!-
acemi has quit [Quit: WeeChat 0.3.2]
[20:16:43] <andypugh> Well, the protocol is RS422 I think, but the data is Mesa's own.
[20:17:20] <mhaberler> will the hw always eventually recover, or does it wedge out once in a while?
[20:18:18] <andypugh> The problem comes if the user tries a servo update rate faster than the amount of data the card needs to transfer.
[20:18:35] <andypugh> So, yes, the hardware will always catch up, if the driver stops writing.
[20:18:38] <mhaberler> is there an upper bound on the time?
[20:18:57] <mhaberler> oh, its a flow control problem
[20:19:13] <andypugh> Yeah.
[20:19:15] <mhaberler> you need a backpressure mechanism to prevent flooding
[20:19:36] <mhaberler> who's wrting? can she queue?
[20:20:06] <andypugh> Can't be done within the framwework. "Realtime" means "write now, every time"
[20:20:34] <mhaberler> that only works with hard upper bounds
[20:20:44] <andypugh> The data being written is direct from the motion controller, initially.
[20:21:25] <mhaberler> you're going to kill me for this.. the protocol is unsuited for hard RT
[20:21:41] <andypugh> I think we can afford the odd over-run, but if it is consistent we really need to say "no, stop, you ned to reconfigure this system"
[20:22:14] <mhaberler> are you willing to queue *om your driver* and b) dpes this actually help?
[20:22:36] <mhaberler> are you losing position or just time?
[20:22:38] <andypugh> No, it doesn't help.
[20:24:30] <mhaberler> well, the turing question is - has that !!%§%!&§$ protocol a hard upper time bound for transfer, or does it not
[20:24:39] <andypugh> As the data is actually rotor angle and current data it is better to skip a turn, and write the next position next turn. If the motor is running at constant speed the only effect will be a momentary lower torque as the lead-angle shrinks.
[20:25:15] <mhaberler> oh, ist it part of the bldc project?
[20:25:15] <andypugh> Upper bound time depends on how many devices are connected.
[20:25:38] <andypugh> Not directly, it is the 8i20 driver.
[20:26:49] <andypugh> But you could easily run a 500Hz thread and a 5kHz thread with different hardware in each, so the driver would struggle to calculate the max throughput.
[20:26:53] <mhaberler> so the upper bound is fixed with the # of devices; can you calculate at setup time wether you're doomed or not?
[20:32:10] -!-
willburrrr2003 has quit [Quit: Friends help you move. Real friends help you move bodies.]
[20:32:11] <mhaberler> if multiple threads, you might be able to determo
[20:32:43] <mhaberler> you could use a hal pin to drive behaviour like skip/force log/dont log
[20:33:05] <mhaberler> and always bean-count;-)
[20:34:19] <andypugh> I think I will have error-count as a pin, increment, decrement and threshold as parameters. And allow users to totally ignore all of them.
[20:35:07] <mhaberler> I mean what's the point - imo a) know something happened b) determine severity c) provied several ways to deal with it; cant think of much more
[20:37:19] <andypugh> What I mean is, that the parameters can be left as-is and the pin can be unwired, and the driver will still behave sensibly. However, if the user wants to over-ride the error-checking by setting the error increment to zero, then they are quite at liberty to do so.
[20:37:47] <mhaberler> yes -- provide rope to hang themselves ;-)
[20:44:46] -!-
cassmodiah_ has quit [Remote host closed the connection]
[20:47:15] -!-
Tom_itx has quit [Ping timeout: 260 seconds]
[20:48:41] <mshaver>
[20:52:42] <mshaver> andypugh: Just got back and read back a bit. 1. There's a mechanism that is used when there are repetitive occurrences of the "unexpected real time delay" error. Beyond the first few messages, writes to /var/log/messages are suppressed.
[20:56:10] <mshaver> 2. You're right that there needs to be a user settable threshold for successive errors beyond which unrecoverable failure is declared and a mechanism (hal pin?) to display the current error value, or perhaps the peak error value.
[20:59:32] <mshaver> 3. The error rate vs. success rate scheme is nice too.
[21:11:26] -!-
mhaberler has quit [Ping timeout: 252 seconds]
[21:13:11] -!-
FinboySlick has quit [Quit: Leaving.]
[21:18:15] -!-
cjdavis has quit [Quit: Leaving.]
[21:34:39] -!-
mhaberler [mhaberler!~mhaberler@extern-181.stiwoll.mah.priv.at] has joined #emc-devel
[21:47:24] -!-
skunkworks has quit [Ping timeout: 252 seconds]
[21:54:12] -!-
Fox_Muldr has quit [Ping timeout: 276 seconds]
[22:15:02] -!-
jthornton [jthornton!~chatzilla@216-41-156-49.semo.net] has joined #emc-devel
[22:24:38] -!-
cassmodiah has quit [Remote host closed the connection]
[22:32:38] -!-
elmo401 has quit [Read error: Connection reset by peer]
[22:35:24] -!-
KimK has quit [Read error: Operation timed out]
[22:45:37] -!-
elmo40 has quit [Client Quit]
[22:47:24] -!-
cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has parted #emc-devel
[22:49:53] -!-
KimK [KimK!~Kim__@ip174-71-95-176.om.om.cox.net] has joined #emc-devel
[22:58:51] -!-
sumpfralle has quit [Ping timeout: 255 seconds]
[23:04:00] -!-
ries has quit [Quit: ries]
[23:09:50] -!-
mhaberler has quit [Quit: mhaberler]
[23:26:48] -!-
Calyp has quit [Ping timeout: 240 seconds]
[23:35:38] -!-
andypugh has quit [Quit: andypugh]
[23:44:58] -!-
mhaberler [mhaberler!~mhaberler@extern-181.stiwoll.mah.priv.at] has joined #emc-devel
[23:54:25] -!-
dgarr [dgarr!~dgarrett@adsl-75-61-69-225.dsl.pltn13.sbcglobal.net] has joined #emc-devel
[23:56:12] -!-
pjm has quit [Ping timeout: 276 seconds]