mhaberler: Yes, canon is still terra-ingcognita. I am slowly pulling the thread of wool and seeing what unravells
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
a tangled ball of yarn?
slightly improved version: git describe --match='v2*' --contains dcc5a94e64d03a754acc3cb2451e97ba58d85ee6
should only match v2.x tags
'released version' meaning 'has tag'?
ah and here's one that will tell you *all* the remote branches that contain a commit: git branch -r --contains dcc5a94e64d03a754acc3cb2451e97ba58d85ee6
list can be long
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]
nope, still not relevant to the web interface.
anyway I'll stop spouting off about git commandline stuff and let you guys get back to it
not sure I actually prefer that
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]
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
hahah guts and bolts
Sounds right to me
[00:08:13] -!- lyzidiamond has quit [Quit: lyzidiamond]
Who was last in there? It's looking like the Code that OO forgot.
ok, so g5x and g92 values live in emccanon.cc, plus rotation. arg.
G5x is currently ouside the scope of toolstore (but looks like a really natural fit)
there are canon cmds to pass current g5x and g92 downstream,queued as soon as set
well it's really blunder prevention, so we dont overlook something and create a gaffe
and if offsets are to be persistent.. canon might need to talk to the toolstore too
the offset values might be pulled back into interp for writing to the .var file though
there's nothing like a decent set of layering violations to confuse readers ;)
[00:15:59] -!- dgarr [email@example.com] has joined #linuxcnc-devel
Yeah. How about we start from scratch? ;-)
well offsets are some veritable mess in terms of layer jumping
I see. Chicken!
[00:20:50] -!- andypugh has quit [Quit: andypugh]
there you have it: cleanup job ahead, bang, gone they are.
[00:23:53] -!- cpresser has quit [Quit: Lost terminal]
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]
mhaberler: yes I think so
most of that is not suitable for merging
but a few may be
or cherry-picking more likely
d5096c27619758f8ba510802938b3a48f9894eca 72e6856c6884b9c8761d24bb5f8e77fbb0a3ee76 274f474d6f4f465e45c9fb180f72544c4cb325cc I think are good and right and don't break anything
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
I was unable to measure whether 0bf2e5b64e5b755b9c6ec9979ff86511c5d0ebef actually made a performance difference
and 87c2a6f0d8165ded67ef995ec562f4f9f044d1d1 is a right change too, as std::map is used by that header without explicitly including <map>
[00:32:16] -!- kwallace1 [firstname.lastname@example.org] has joined #linuxcnc-devel
it didn't fix the issue I was actually thinking about, which was a hardy compile error related to that header
I think hardy, one of the old systems anyway
[00:32:41] -!- kwallace has quit [Ping timeout: 256 seconds]
rtapi_get_nominal_time etc looks like an alternate to passing actual time in the thread function params as well?
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
but I haven't thought too hard about the overhead of this
two more function calls are more expensive than two more function parameters
but will enough functions consult the information that it's a win overall? no idea at all.
I understand reading the TSC causes a pipeline stall, not sure what this means
these all operate in nsec, so it's doing a clock_gettime syscall in the userspace cases (for the _actual variant)
well I just read it again
it's using extra_task_data, calling clock_gettime just once per thread invocation, not once per function call
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
but yes there are clock_gettime calls at every thread invocation in rt_preempt
and making that an extra param might increase that to one per thread function
[00:38:09] -!- kwallace [email@example.com] has joined #linuxcnc-devel
I'm curious about that actually
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]
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]
but sometimes none of those things is the actual question that would let you get better performance e.g. at closing the servo loop
(heck you probably need to know read time and expected write time both for that)
looking at thread_task: isnt the values from rtapi_get_clocks() what we'd want to know in the thread funct?
I think rtapi_get_time is more convenient, because you know its units (ns)
except that rtapi_get_clocks() is called post the threadfunct, with only the dubious value of determining runtime and maxtime?
rtapi_get_clocks is in TSCs and may have no fixed unit (CPUs with frequency scaling and non-constant tsc as one example)
(note: in our rtai kernels we disable CPU frequency scaling)
right.. I wonder if any code actually uses runtime and maxtime
halcmd show thread lets the user see htem
and sometimes that's useful for debugging, assuming you think you can convert it to ns
right, but thats display output only
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
looks like runtime/maxtime arent used in controlling flow at all
hal_parport's use is simplified by use of rtapi_get_time .. ditto uparport
and then there are the uses in hal_lib you already are looking at
oh and the one in motion/control.c which should be junked
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?
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
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]
clocks is a bad idea, simply pretend it does not exist
ignore the fact that we do use it despite that
ivcsw .. involuntary context switches?
yes as far as I understand it
that's something else that would be a canary for losing realtime
though not impossible if e.g., the fast thread interrupts the slow one
do we have a good definition for 'losing realtime' ?
anyway that series about nominal and actual time was about trying to make latency-test results mean the same thing as cyclictest results
the xenomai SIGXCPU signal indicating domain change definitely is
in rtai, rt_task_wait_period() returns an error from an enum including RTE_TMROVRN and RTE_UNBLKD
I would have to refresh myself on what those mean
but the former value is the one which we take to be "Unexpected realtime delay on task %d"
.. which is just a rtapi_print_msg
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)
if it's unrecoverable (xenomai userspace) then it probably increases forever from that moment on
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
right, I was thinking about a hard condition to cause an estop
I wish that could be done without exposing the thread flavor to hal configs and make them depend on it
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..
if nominal > actual + period clearly you missed a deadline
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)
zultron is Captain Hook
[01:02:54] <mhaberler> http://i.dailymail.co.uk/i/pix/2012/10/12/article-2216530-023F6EB9000004B0-499_634x541.jpg
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]
oh, speaking of which.. Mursi was just removed by the army in egypt
was he the one sitting across from you at the desk by the front mhaberler?
John Morris? the tallest of all the guys
i'm not so good with remembering names
he was set up over by charles on a card table, wasn't he?
[01:08:04] * jepler tries to remember
anyway, bbl. life is calling me.
someone should edit some pics and add in names
i've seen 2 sets posted
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
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]
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]
skunkworks: that's right
skunkworks: andypugh said he thought there might be more than one but he was mistaken
but it should still be fine for non-doublestep setups with this latching pin
what does it go by? thi longest pin?
the longest reset time? Shortes?
there is only one reset time
the thing that is at the pin level is whether it is a resetting pin
but they all get the same timeout
I thought you could set the reset time for each pin
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]
so a 20kHz base thread without doublestep will be fine
more than enough. If I am remembering my math right - 10000hz/4000steps/inch= 2.5 in/sec or 150ipm.
(at a20khz base thread)
the dangers of seeing what's on an old linux install:
# On branch v2_3_branch
# Your branch is ahead of 'origin/v2_3_branch' by 2 commits.
[02:01:54] -!- mattiasb has quit [Ping timeout: 264 seconds]
there's even a directory called "emc2.cvs"
jepler@azazel:~/emc2.cvs$ cvs diff
rsh: cvs.linuxcnc.org: Name or service not known
cvs [diff aborted]: end of file from server (consult above messages if any)
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]
it also turns out there's a breezy (5.10) install on this disk
I think I won't check whether it has any unpushed changes
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
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
what did you want to use the random numbers for?
usually I transmit them to the NSA
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: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 [firstname.lastname@example.org] 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 [email@example.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 [firstname.lastname@example.org] has joined #linuxcnc-devel
[05:35:15] -!- mozmck [email@example.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 [firstname.lastname@example.org] has joined #linuxcnc-devel
[06:17:55] -!- FinboySlick has quit [Quit: Leaving.]
[06:23:01] -!- kwallace2 [email@example.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 [firstname.lastname@example.org] has joined #linuxcnc-devel
[08:08:39] -!- maximilian_h has quit [Client Quit]