Back
[00:00:16] <andypugh> mhaberler: Yes, canon is still terra-ingcognita. I am slowly pulling the thread of wool and seeing what unravells
[00:00:39] <jepler> if it's not in a tag then it will typically tell you 'fatal: cannot describe...' though it might also point you at a non-version tag
[00:00:42] <Tom_itx> a tangled ball of yarn?
[00:00:48] <jepler> slightly improved version: git describe --match='v2*' --contains dcc5a94e64d03a754acc3cb2451e97ba58d85ee6
[00:00:55] <jepler> should only match v2.x tags
[00:01:14] <mhaberler> 'released version' meaning 'has tag'?
[00:02:07] <jepler> ah and here's one that will tell you *all* the remote branches that contain a commit: git branch -r --contains dcc5a94e64d03a754acc3cb2451e97ba58d85ee6
[00:02:10] <jepler> list can be long
[00:03:23] <andypugh> jepler: Again, thanks, and good info, but not (as far as I can tell) useful from the web interface. Typically I end up looking what code got changed, then looking at the tree. Sadly I find myself bothering less and less frequently.
[00:03:35] -!- mattiasb has quit [Ping timeout: 256 seconds]
[00:04:55] -!- vladimirek has quit [Remote host closed the connection]
[00:05:07] <jepler> nope, still not relevant to the web interface.
[00:05:47] <jepler> anyway I'll stop spouting off about git commandline stuff and let you guys get back to it
[00:05:52] <jepler> to interp
[00:06:08] <mhaberler> not sure I actually prefer that
[00:06:17] <andypugh> You could usefullly opinionate?
[00:07:01] -!- rob_h has quit [Ping timeout: 248 seconds]
[00:07:50] -!- cpresser has quit [Ping timeout: 256 seconds]
[00:07:54] <jepler> I think you guys are both far enough into the guts and bolts that you don't need opinions from someone who hasn't been in that code lately
[00:07:59] <jepler> hahah guts and bolts
[00:08:13] <andypugh> Sounds right to me
[00:08:13] -!- lyzidiamond has quit [Quit: lyzidiamond]
[00:09:04] <andypugh> Who was last in there? It's looking like the Code that OO forgot.
[00:09:42] <mhaberler> ok, so g5x and g92 values live in emccanon.cc, plus rotation. arg.
[00:11:02] <andypugh> G5x is currently ouside the scope of toolstore (but looks like a really natural fit)
[00:11:16] <mhaberler> there are canon cmds to pass current g5x and g92 downstream,queued as soon as set
[00:11:48] <mhaberler> well it's really blunder prevention, so we dont overlook something and create a gaffe
[00:12:35] <mhaberler> and if offsets are to be persistent.. canon might need to talk to the toolstore too
[00:15:09] <mhaberler> the offset values might be pulled back into interp for writing to the .var file though
[00:15:33] <mhaberler> there's nothing like a decent set of layering violations to confuse readers ;)
[00:15:59] -!- dgarr [dgarr!~dgarrett@174-26-249-207.phnx.qwest.net] has joined #linuxcnc-devel
[00:19:59] <andypugh> Yeah. How about we start from scratch? ;-)
[00:20:33] <mhaberler> well offsets are some veritable mess in terms of layer jumping
[00:20:37] <andypugh> Bedtime.
[00:20:46] <mhaberler> I see. Chicken!
[00:20:50] -!- andypugh has quit [Quit: andypugh]
[00:21:17] <mhaberler> there you have it: cleanup job ahead, bang, gone they are.
[00:23:53] -!- cpresser has quit [Quit: Lost terminal]
[00:24:17] <mhaberler> ok, so since andy faded.. jepler: what was that branch again which you referred to (rtapi/hal exception handling)?
[00:25:44] -!- asdfasd has quit [Ping timeout: 252 seconds]
[00:26:51] <mhaberler> jepler/rtos-master-v0-linux_rt ?
[00:28:17] <jepler> mhaberler: yes I think so
[00:28:30] <mhaberler> ah
[00:28:55] <jepler> most of that is not suitable for merging
[00:29:33] <jepler> but a few may be
[00:29:43] <jepler> or cherry-picking more likely
[00:30:12] <jepler> d5096c27619758f8ba510802938b3a48f9894eca 72e6856c6884b9c8761d24bb5f8e77fbb0a3ee76 274f474d6f4f465e45c9fb180f72544c4cb325cc I think are good and right and don't break anything
[00:30:35] <jepler> the rtapi_get_nominal_time stuff may or may not be a good idea but I know it's broken for every rtos but rt_preempt user
[00:30:54] <jepler> I was unable to measure whether 0bf2e5b64e5b755b9c6ec9979ff86511c5d0ebef actually made a performance difference
[00:31:13] <jepler> and 87c2a6f0d8165ded67ef995ec562f4f9f044d1d1 is a right change too, as std::map is used by that header without explicitly including <map>
[00:31:59] <mhaberler> right
[00:32:16] -!- kwallace1 [kwallace1!~kwallace@smb-73.sonnet.com] has joined #linuxcnc-devel
[00:32:18] <jepler> it didn't fix the issue I was actually thinking about, which was a hardy compile error related to that header
[00:32:26] <jepler> I think hardy, one of the old systems anyway
[00:32:41] -!- kwallace has quit [Ping timeout: 256 seconds]
[00:32:47] <mhaberler> rtapi_get_nominal_time etc looks like an alternate to passing actual time in the thread function params as well?
[00:33:22] <jepler> with these two APIs we don't have to change the parameter list of the realtime functions; they can call whichever function gives them the information they want
[00:33:29] <jepler> but I haven't thought too hard about the overhead of this
[00:33:45] <jepler> two more function calls are more expensive than two more function parameters
[00:34:10] <jepler> but will enough functions consult the information that it's a win overall? no idea at all.
[00:34:17] <mhaberler> I understand reading the TSC causes a pipeline stall, not sure what this means
[00:35:05] <jepler> these all operate in nsec, so it's doing a clock_gettime syscall in the userspace cases (for the _actual variant)
[00:35:18] <mhaberler> uh
[00:35:34] <jepler> well I just read it again
[00:35:55] <jepler> it's using extra_task_data, calling clock_gettime just once per thread invocation, not once per function call
[00:36:32] <jepler> using TSCs is a bad idea but we were forced into it by a version of rtai that had a bad performance hit from whatever API was behind rtapi_get_time on rtai kernelspace
[00:36:53] <jepler> but yes there are clock_gettime calls at every thread invocation in rt_preempt
[00:37:34] <mhaberler> and making that an extra param might increase that to one per thread function
[00:38:09] -!- kwallace [kwallace!~kwallace@tmb-242.sonnet.com] has joined #linuxcnc-devel
[00:38:24] <jepler> I'm curious about that actually
[00:38:52] <jepler> it seems like what you sometimes want to know is when data was read, and sometimes you want to know the best estimate of when it was written
[00:39:06] -!- kwallace1 has quit [Ping timeout: 264 seconds]
[00:39:16] <jepler> you can know stuff instead like what time your code is actually running, or when the start of the thread invocation was
[00:39:29] -!- mattiasb has quit [Ping timeout: 248 seconds]
[00:39:38] <jepler> but sometimes none of those things is the actual question that would let you get better performance e.g. at closing the servo loop
[00:39:49] <jepler> (heck you probably need to know read time and expected write time both for that)
[00:41:41] <mhaberler> looking at thread_task: isnt the values from rtapi_get_clocks() what we'd want to know in the thread funct?
[00:43:25] <jepler> I think rtapi_get_time is more convenient, because you know its units (ns)
[00:43:39] <mhaberler> except that rtapi_get_clocks() is called post the threadfunct, with only the dubious value of determining runtime and maxtime?
[00:43:50] <jepler> rtapi_get_clocks is in TSCs and may have no fixed unit (CPUs with frequency scaling and non-constant tsc as one example)
[00:44:03] <jepler> (note: in our rtai kernels we disable CPU frequency scaling)
[00:44:10] <mhaberler> right.. I wonder if any code actually uses runtime and maxtime
[00:44:20] <jepler> halcmd show thread lets the user see htem
[00:44:39] <jepler> and sometimes that's useful for debugging, assuming you think you can convert it to ns
[00:44:41] <mhaberler> right, but thats display output only
[00:45:12] <jepler> rtai was the tail wagging the dog on this one. I can't think of one place we really want TSCs, but we use them because (probably either breezy or dapper vintage) of an rtai problem
[00:45:58] <mhaberler> looks like runtime/maxtime arent used in controlling flow at all
[00:46:01] <jepler> hal_parport's use is simplified by use of rtapi_get_time .. ditto uparport
[00:46:11] <jepler> and then there are the uses in hal_lib you already are looking at
[00:49:00] <jepler> oh and the one in motion/control.c which should be junked
[00:49:27] <mhaberler> standing back a bit: what would be useful is actual invocation period besides assumed period in ns; so is the question: how do we get at current time in ns without much overhead?
[00:50:30] <jepler> oh incidentally I think I alluded to this patch on irc but haven't pushed it anywhere:
http://emergent.unpythonic.net/files/sandbox/0001-hack-minflt-majflt-ivcsw-pins-from-threads-component.patch
[00:50:34] <mhaberler> I am a bit confused in this clocks vs time land, and period vs abs time
[00:50:55] -!- mattiasb has quit [Ping timeout: 260 seconds]
[00:51:21] <jepler> clocks is a bad idea, simply pretend it does not exist
[00:51:36] <jepler> ignore the fact that we do use it despite that
[00:51:43] <mhaberler> ivcsw .. involuntary context switches?
[00:51:56] <jepler> yes as far as I understand it
[00:52:02] <jepler> that's something else that would be a canary for losing realtime
[00:52:22] <jepler> though not impossible if e.g., the fast thread interrupts the slow one
[00:53:07] <mhaberler> do we have a good definition for 'losing realtime' ?
[00:53:21] <jepler> anyway that series about nominal and actual time was about trying to make latency-test results mean the same thing as cyclictest results
[00:53:23] <mhaberler> the xenomai SIGXCPU signal indicating domain change definitely is
[00:54:40] <jepler> in rtai, rt_task_wait_period() returns an error from an enum including RTE_TMROVRN and RTE_UNBLKD
[00:54:45] <jepler> I would have to refresh myself on what those mean
[00:54:59] <jepler> but the former value is the one which we take to be "Unexpected realtime delay on task %d"
[00:55:05] <jepler> .. which is just a rtapi_print_msg
[00:57:11] <jepler> so in my API-centered mind we need an rtapi API for the number of realtime deadlines we think have been missed. when that number increments, it's bad (maybe estop)
[00:57:24] <jepler> if it's unrecoverable (xenomai userspace) then it probably increases forever from that moment on
[00:58:07] <jepler> how you get from API result to estop is having a HAL component that exists just to consult the API and set a pin based on the API's return value .. heartbeat or whatever you like, then it's in hal wiring what it does
[00:58:10] <mhaberler> right, I was thinking about a hard condition to cause an estop
[00:58:55] <mhaberler> I wish that could be done without exposing the thread flavor to hal configs and make them depend on it
[00:59:02] <jepler> in userspace I assume you can figure out for yourself if you missed a deadline by looking at your nominal time, your actual time, and your period..
[00:59:12] <jepler> if nominal > actual + period clearly you missed a deadline
[00:59:55] <jepler> but whatever it is, it simply becomes a requirement for the implementation of rtapi (and an rtapi hook in the current parlance if I am not out of date already)
[01:00:17] <mhaberler> zultron is Captain Hook
[01:01:11] <jepler> hah
[01:02:54] <mhaberler> http://i.dailymail.co.uk/i/pix/2012/10/12/article-2216530-023F6EB9000004B0-499_634x541.jpg
[01:03:43] <jepler> I thought I'd met him in wichita but now I am no longer so sure
[01:04:43] -!- grummund_ has quit [Ping timeout: 245 seconds]
[01:06:29] <mhaberler> oh, speaking of which.. Mursi was just removed by the army in egypt
[01:06:50] <Tom_itx> was he the one sitting across from you at the desk by the front mhaberler?
[01:07:16] <jepler> bbl.
[01:07:21] <mhaberler> John Morris? the tallest of all the guys
[01:07:45] <Tom_itx> i'm not so good with remembering names
[01:07:55] <jepler> he was set up over by charles on a card table, wasn't he?
[01:08:04] * jepler tries to remember
[01:08:10] <jepler> anyway, bbl. life is calling me.
[01:08:11] <mhaberler> right
[01:08:15] <Tom_itx> someone should edit some pics and add in names
[01:08:28] <Tom_itx> i've seen 2 sets posted
[01:08:51] <jepler> mhaberler: I hope some of that was helpful to you, if only the sad history lesson of why we have rtapi_get_clocks at all
[01:09:03] <mhaberler> definitely
[01:09:15] <mhaberler> yes, that one I was unclear why it existed at all
[01:13:37] -!- mattiasb has quit [Ping timeout: 248 seconds]
[01:18:32] -!- PetefromTn has quit [Remote host closed the connection]
[01:21:20] -!- micges has quit [Quit: Leaving]
[01:21:48] -!- mattiasb has quit [Ping timeout: 245 seconds]
[01:28:30] <skunkworks> jepler: I looked at hal_parport.c and my very bad programming reading skills tells me that I don't know what I am looking at. reset_port seems to only wait for deadline which I don't understand. (seems like it only waits for one time)
[01:29:46] -!- mattiasb has quit [Ping timeout: 276 seconds]
[01:34:04] <jepler> skunkworks: that's right
[01:34:16] <jepler> skunkworks: andypugh said he thought there might be more than one but he was mistaken
[01:34:39] <jepler> but it should still be fine for non-doublestep setups with this latching pin
[01:35:36] <skunkworks> what does it go by? thi longest pin?
[01:35:52] <skunkworks> the longest reset time? Shortes?
[01:35:57] <jepler> there is only one reset time
[01:36:05] <skunkworks> oh
[01:36:13] <jepler> the thing that is at the pin level is whether it is a resetting pin
[01:36:20] <jepler> but they all get the same timeout
[01:36:23] <skunkworks> I thought you could set the reset time for each pin
[01:36:28] <skunkworks> ah
[01:41:12] <skunkworks> at the most I need 4000 steps per inch at 30 ipm. so pretty low power
[01:43:03] -!- mattiasb has quit [Ping timeout: 245 seconds]
[01:45:55] -!- amk has quit [Client Quit]
[01:49:18] <jepler> so a 20kHz base thread without doublestep will be fine
[01:49:23] <skunkworks> sure
[01:52:58] <skunkworks> more than enough. If I am remembering my math right - 10000hz/4000steps/inch= 2.5 in/sec or 150ipm.
[01:53:18] <skunkworks> (at a20khz base thread)
[02:00:49] <jepler> the dangers of seeing what's on an old linux install:
[02:00:49] <jepler> # On branch v2_3_branch
[02:00:50] <jepler> # Your branch is ahead of 'origin/v2_3_branch' by 2 commits.
[02:01:54] -!- mattiasb has quit [Ping timeout: 264 seconds]
[02:03:10] <jepler> there's even a directory called "emc2.cvs"
[02:06:25] <jepler> jepler@azazel:~/emc2.cvs$ cvs diff
[02:06:25] <jepler> rsh: cvs.linuxcnc.org: Name or service not known
[02:06:25] <jepler> cvs [diff aborted]: end of file from server (consult above messages if any)
[02:06:29] <jepler> well I hope there were no changes in there :-P
[02:08:03] -!- PCW has quit [Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]]
[02:09:35] -!- mattiasb has quit [Ping timeout: 256 seconds]
[02:19:11] <jepler> it also turns out there's a breezy (5.10) install on this disk
[02:19:19] <jepler> I think I won't check whether it has any unpushed changes
[02:22:07] <jepler> there was one mildly interesting thing in the hardy install: I wrote a hardware RNG (based on the xor of a large number of free-running oscillators iirc) in the hostmot2 architecture; the driver was hiding in one of those old linuxcnc directories
[02:23:18] <jepler> also iirc it did something like 40MB/s of diehard-quality output, limited by the inl() based PCI interface and/or the PLX bridge chip
[02:23:41] <skunkworks> heh
[02:24:44] <skunkworks> what did you want to use the random numbers for?
[02:25:15] <jepler> usually I transmit them to the NSA
[02:25:40] <jepler> physical / "true" random number generators have been an interest of mine without a real purpose
[02:32:28] _BJFreeman is now known as BJfreeman
[02:34:39] <skunkworks> understood
[02:42:11] -!- erictheise_ has quit [Client Quit]
[03:04:49] -!- Loetmichel has quit [Ping timeout: 246 seconds]
[03:06:10] -!- jfire has quit [Quit: Leaving.]
[03:09:17] -!- ve7it has quit [Remote host closed the connection]
[03:19:05] -!- jfire has quit [Client Quit]
[03:22:39] -!- qrp has quit [Ping timeout: 250 seconds]
[03:28:37] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[03:29:35] -!- Laremere has quit [Ping timeout: 260 seconds]
[03:29:38] -!- stevegt has quit [Ping timeout: 246 seconds]
[03:30:22] BJfreeman is now known as Guest17598
[03:30:29] _BJFreeman is now known as BJfreeman
[03:30:52] -!- Guest17598 has quit [Ping timeout: 252 seconds]
[03:34:30] -!- dgarr has quit [Quit: Leaving.]
[03:35:02] -!- mhaberler has quit [Quit: mhaberler]
[03:37:44] -!- eric_unterhausen has quit [Read error: Connection reset by peer]
[03:41:27] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[03:44:19] -!- stevegt__ has quit [Read error: Connection reset by peer]
[03:44:59] -!- Servos4ever has quit [Quit: ChatZilla 0.9.90 [SeaMonkey 2.14.1/20121129191050]]
[03:52:08] -!- BJfreeman has quit [Ping timeout: 252 seconds]
[03:55:18] -!- stevegt has quit [Ping timeout: 264 seconds]
[03:55:54] -!- jfrmilner has quit [Ping timeout: 246 seconds]
[03:57:05] _BJFreeman is now known as BJfreeman
[04:04:41] -!- stevegt__ has quit [Read error: Connection reset by peer]
[04:27:19] -!- AggieMEEN has quit [Client Quit]
[04:36:39] -!- BJfreeman has quit [Quit: had a good time]
[04:54:33] -!- kwallace [kwallace!~kwallace@tmb-242.sonnet.com] has parted #linuxcnc-devel
[05:01:56] -!- Fox_Muldr has quit [Ping timeout: 252 seconds]
[05:14:19] -!- alpha1125 has quit [Ping timeout: 246 seconds]
[05:15:15] -!- AR_ has quit [Ping timeout: 256 seconds]
[05:18:31] -!- hashfail has quit [Ping timeout: 264 seconds]
[05:26:35] -!- mozmck has quit [Ping timeout: 256 seconds]
[05:33:04] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[05:35:15] -!- mozmck [mozmck!~moses@client-204.235.45.143.wcfltx.partnershipbroadband.com] has joined #linuxcnc-devel
[05:53:53] -!- WalterN has quit [Ping timeout: 240 seconds]
[05:58:32] -!- lyzidiamond has quit [Quit: lyzidiamond]
[06:04:10] -!- kwallace2 [kwallace2!~kwallace@smb-237.sonnet.com] has joined #linuxcnc-devel
[06:17:55] -!- FinboySlick has quit [Quit: Leaving.]
[06:23:01] -!- kwallace2 [kwallace2!~kwallace@smb-237.sonnet.com] has parted #linuxcnc-devel
[06:24:06] -!- mozmck has quit [Ping timeout: 256 seconds]
[06:48:49] -!- krolick has quit [Ping timeout: 246 seconds]
[06:58:53] -!- qrp has quit [Ping timeout: 250 seconds]
[06:59:56] -!- stsydow has quit [Remote host closed the connection]
[07:21:58] Cylly is now known as Loetmichel
[07:22:55] s1dev is now known as s1dev|away
[07:29:26] -!- mhaberler has quit [Quit: mhaberler]
[07:32:35] -!- apel has quit [Changing host]
[07:54:29] -!- b_b has quit [Changing host]
[07:56:25] -!- stsydow has quit [Remote host closed the connection]
[08:08:35] -!- maximilian_h [maximilian_h!~bonsai@f052027155.adsl.alicedsl.de] has joined #linuxcnc-devel
[08:08:39] -!- maximilian_h has quit [Client Quit]
