Back
[02:49:00] <KGB-linuxcnc> 03Chris Morley 05master ece8c30 06linuxcnc 10share/gscreen/skins/gaxis/gaxis.glade 10share/gscreen/skins/gaxis/gaxis_handler.py gaxis -add some gremlin plot controls * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ece8c30
[02:49:00] <KGB-linuxcnc> 03Chris Morley 05master ce61d11 06linuxcnc 10lib/python/gladevcp/hal_actions.py gladevcp -hal_actions home, unhome, MDI should be sensitive to states * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ce61d11
[02:49:00] <KGB-linuxcnc> 03Chris Morley 05master 30e1a9d 06linuxcnc 10lib/python/gladevcp/hal_actions.py gladevcp -have hal_actions (eg MDI) check for is_all_homed state * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=30e1a9d
[02:49:03] <KGB-linuxcnc> 03Chris Morley 05master dc54291 06linuxcnc 10lib/python/gladevcp/hal_mdihistory.py gladevcp -have hal_mdihistory widget check for machine states * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dc54291
[06:33:49] <skunkworks> logger[psha],
[06:33:54] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2013-12-17.html
[07:45:20] <jepler> two other ways to insert some text after a given line number of a file (here, I insert "..." after the 2nd line of output produced by the "seq" command)
[07:45:24] <jepler> seq 4 | awk '{print; if(FNR == 2) print "...";}'
[07:45:26] <jepler> seq 4 | sed '3i...'
[07:45:44] <jepler> Tom_itx: ^^^ dunno if you were interested in these other suggestions
[07:46:59] <jepler> and of course I shouldn't neglect perl: seq 4 | perl -pe 'print "...\n" if $. == 3;'
[08:50:23] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 6cb84b7 06linuxcnc 10src/hal/components/stepgen.c fix a kernel-mode compile warning * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6cb84b7
[08:50:36] <KGB-linuxcnc> 05stepgen-warning-fix 5a62fbd 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5a62fbd
[10:49:30] <skunkworks> is there another name for average? Is there an averaging componant in hal?
[10:50:48] <archivist> filter to some extent
[10:51:33] <pcw_home> lowpass
[10:52:26] <pcw_home> (digital R/C filter)
[10:52:55] <pcw_home> running average
[10:55:19] <skunkworks> pcw_home, with your encoders read step/dir?
[10:55:26] <pcw_home> Yes
[10:55:42] <pcw_home> count mode 1
[10:55:59] <skunkworks> really... Hmmm - that might be a cool experiment..
[10:56:25] <pcw_home> Ive used them that way for debugging the stepgen
[10:56:27] <skunkworks> I would really like to read what is coming out of mach - and look at the peak acceleration...
[10:57:16] <skunkworks> I think I could use this setup.. And it would backplot also..
[10:57:17] <skunkworks> http://imagebin.org/282646
[10:57:42] <pcw_home> yeah that one way to check whats really going on (you _will_ have to low pass filter the accel)
[10:58:10] <skunkworks> It would be an experiment with rt-preempt..
[10:58:13] <skunkworks> also
[10:58:14] <skunkworks> :)
[10:58:59] <skunkworks> pcw_home, there isn't any right now and it seems to be working correctly.. (bunch of ddt's)
[10:59:43] <skunkworks> because it is sampling over the servo period?
[11:00:02] <skunkworks> it would be the same with if I was counting I woud think...
[11:01:39] <pcw_home> Just that software stepgens have very high noise at small accel measurement intervals due to the base thread quantitization
[11:02:48] <pcw_home> but at say 1KHz and dv/dt from encoder velocity it might be ok
[11:03:39] <pcw_home> (better to use encoder velocity since it will remove the measuring systems servo thread jitter)
[11:04:04] <skunkworks> I will look
[11:05:20] <skunkworks> I was trying to figure out how I would count step/dir in hal and it would require updown + some logic to work.. The 7i80 solves that problem :)
[11:09:08] <skunkworks> this way I can scale it and everything
[11:23:43] <cradek> mhaberler: on my mini mill I'm using REMAP=M6 modalgroup=6 ngc=manual_change for tool length probing.
[11:23:47] <cradek> It's simple to do and works well.
[11:23:56] <mhaberler> oh, good to hear
[11:24:24] <mhaberler> so you switched to master?
[11:24:44] <cradek> yeah I'm running buildbot master debs on it now
[11:24:58] <cradek> my VMC is still 2.5 (uh or maybe it's 2.4?)
[11:25:06] <cradek> surely it's 2.5
[11:25:08] <cradek> ha
[11:25:30] <mhaberler> I'll do a pass over the remap docs later 'this year', let me know if you have any suggestions or examples
[11:26:11] <mhaberler> I think everything is in place to do custom cycles by now, too
[11:26:21] <cradek> assuming my use case is the most commonly-wanted one [of course programmers always assume this and they're usually wrong] my setup might be a good example
[11:26:29] <mhaberler> including sticky support
[11:26:43] <mhaberler> well just go ahead and insert it
[11:27:00] <cradek> a very good and useful exercise would be to try to replace G84 with G33.1-type moves
[11:27:16] <cradek> it would be great to have step/repeat with the rigid tap cycle
[11:27:55] <cradek> OR make g84 work with a particular reversing tapping head (they can have different reversing ratios)
[11:28:37] <mhaberler> I gave that a stab a long time ago; the only hard change I needed was to suppress wait-for-atspeed on reversal, that needed a canon+downstream change
[11:28:47] <cradek> I didn't intend to give you work, I only meant to say it was working and it's good
[11:29:46] <skunkworks> cradek, I think I have found more overages in master...
[11:30:00] <cradek> sorry which exercise are you talking about where you wanted to suppress wait-for-atspeed?
[11:30:01] <mhaberler> oh, I happily comply.. gluing together other stuff these days
[11:30:29] <mhaberler> let me find that branch and re-understand it; it was based on a discussion with robh
[11:31:24] <mhaberler> that was the rationale:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=commitdiff;h=7923b8525b6963bafb2088c696c7aeacc0901bf2
[11:32:03] <mhaberler> I stopped working on this branch (g84-dev) and turned to implementing cycle support in embedded python instead
[11:32:15] <cradek> ah T/C, a third case other than the two I suggested
[11:33:15] <cradek> robh was working on the case where he had no spindle feedback and wanted to use a T/C tapping head? (because you could use the rigid tap cycle with a T/C just great)
[11:33:33] <mhaberler> I think that was the issue, yes
[11:35:03] <mhaberler> hm, the recent config reorg.. wonder where remap went
[11:35:43] <mhaberler> ah, sim/axis/remap
[11:37:11] <cradek> remap/manual-toolchange-with-tool-length-switch is MUCH more complicated than what I ended up with
[11:38:20] <mhaberler> this example uses the remap cycle support:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=tree;f=configs/sim/axis/remap/cycle;h=e161c25192bfbc86ca9ff27e5a5499087048e1a0;hb=6cb84b76e6b8832b380bb52ee46d5e789c274ffb
[11:38:35] <mhaberler> well if you come up with something simpler that'd be great
[11:41:13] <cradek> it would take a lot of doc-reading for me to understand that more advanced remap
[11:41:41] <cradek> just curious - can you override the existing G84 instead of making new ones?
[11:45:35] <mhaberler> let me see
[11:48:30] <mhaberler> not currently; what it would need is a test like in 3367 to override the call in 3370:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/rs274ngc/interp_convert.cc;h=f8c0f871951f51851d335556d133b532cc1c2da6;hb=6cb84b76e6b8832b380bb52ee46d5e789c274ffb#l3367
[11:48:58] <skunkworks> cradek,
http://imagebin.org/282753
[11:49:19] <skunkworks> I will isolate it.. This program causes it quite often for some reason
[11:49:21] <mhaberler> overriding existing codes is a per-code test; using new, unallocated ones works without touching the code
[11:49:26] <cradek> skunkworks: yargh
[11:49:35] <skunkworks> heh - sorry
[11:49:44] <cradek> mhaberler: got it (m6 you already handled apparently)
[11:49:58] <mhaberler> yes, and quite a few others
[11:50:09] <mhaberler> sort of as a use case appeared
[11:51:25] <mhaberler> m6 is around 2293 same file
[11:51:59] <mhaberler> that has the 'recursion' feature - you can use an m6 in a remap, in which case it will use the builtin sequence
[11:53:47] <cradek> yes I use that
[11:54:41] <cradek> and M73
[11:55:06] <mhaberler> ah, it's you - I thought somebody might ;)
[11:55:55] <cradek> the tool change does motion and probing, so it darn well better set the units first, and you'd sure not want to change units on the caller
[11:56:08] <cradek> and I should test all of that :-)
[12:15:25] <skunkworks> cradek,
http://electronicsam.com/images/KandT/testing/circblendlatest/
[12:15:37] <skunkworks> the LHchips3error.ngc
[12:15:46] <skunkworks> is one example
[12:17:14] <cradek> thanks, I'll try to look at it later today
[12:17:19] <cradek> ha F9991200.0
[12:18:02] <skunkworks> Find replace F > F999
[12:19:30] <andypugh> What's going on there?
[12:19:51] <pcw_home> thats a fairly high feedrate
[12:19:59] <skunkworks> I am just running programs as fast as they will go...
[12:20:02] <andypugh> I guess the K&T isn't _quite_ that fast?
[12:20:16] <skunkworks> not quite.. ;)
[12:20:17] <cradek> yeah I understand and there's nothing wrong with it; it just looks silly
[12:20:41] <skunkworks> so the limit is the TP - not the feed
[12:21:41] <cradek> sure
[12:21:50] <cradek> same as changing to all G0 (except there is no such thing as a rapid arc)
[12:21:57] <skunkworks> right
[12:22:39] <pcw_home> is it possible that that high a feedrate triggers some corner condition not normally seen?
[12:22:51] <cradek> very doubtful
[12:23:09] <cradek> (in my planner anyway - I don't know much about robert's)
[12:23:27] <skunkworks> robers runs through without an overage... ;)
[12:23:32] <skunkworks> today anyway
[12:23:39] <cradek> yay that's great :-)
[12:23:56] <cradek> if I understand right though, his depends on mine working right
[12:23:57] <skunkworks> he has fixed a bunch of issues over the last few days
[12:24:21] <skunkworks> sure - but I think he has tweeked yours..
[12:24:27] <cradek> bbl
[12:25:01] <pcw_home> Looks like real progress on the new TP
[12:27:19] <skunkworks> old tp
[12:27:20] <skunkworks> http://imagebin.org/282644
[12:27:36] <skunkworks> new tp
[12:27:37] <skunkworks> http://imagebin.org/282645
[12:28:21] <pcw_home> almost twice as fast!
[12:28:28] <skunkworks> the more line segments vs arcs the better... (right now the readahead works if there are line segments, tangent line-arc and arc-arcs
[12:29:13] <skunkworks> tangent arc-arcs
[12:29:15] <pcw_home> high speed profiling CAM output will mostly be short line segments
[12:29:20] <skunkworks> right
[12:29:33] <skunkworks> and that was his inital focus
[12:30:07] <skunkworks> and falls back to parabolic blends (current tp) for unhandled cases.. which is pretty cool
[12:30:55] <pcw_home> so if this works with everything else it removes one of the main complaint I hear about LinuXCNC for profiling and high speed routers
[12:31:00] <andypugh> Why are both tool paths incomplete?
[12:31:00] <skunkworks> in the last picture - you can see the yellow vs red - yellow is parabolic blending
[12:31:46] <skunkworks> andypugh, the tool path disapears after so many lines to save memory
[12:31:56] <skunkworks> you onley see it on long programs
[12:32:11] <andypugh> I am rather concerned about the extent of blending on the rapids, I can't help feeling that those might hit the work.
[12:32:14] <skunkworks> pcw_home, that is what I am excited about.
[12:32:48] <skunkworks> andypugh, that is normal path.. if you don't want that - you do a G64Px.xx
[12:33:14] <skunkworks> (g64 is - go as fast as you can while touching every segmetn)
[12:33:22] <andypugh> Still, it's a bit unnerving to see
[12:33:51] <skunkworks> yes - and that is extreme - high feed and sort of low acceleration (30in/sec^2)
[12:34:18] <skunkworks> 500ipm
[12:37:14] <andypugh> Ah, OK, so not a realistic set of parameters, really.
[12:37:22] <pcw_home> Ive been testing the stepgen for latency sensitivity (Ethernet) at 300 In/sec^2 1800IPM
[12:37:43] <andypugh> What is the speed-up like with a better accel match?
[12:38:27] <pcw_home> 10x would be about 80 In/sec^2
[12:38:51] <pcw_home> (100 ms to full speed)
[12:41:36] <mozmck> actually, those parameters are not un-realistic for some work I think.
[12:42:30] <mozmck> at least not too far out. We run plasma cutting at 225+ ipm and 35in/s^2 accel
[12:44:44] <skunkworks> mozmck, do you have any programs with short line segments I could play with?
[12:45:03] <skunkworks> or andypugh
[12:45:06] <mozmck> I might, I'd have to look.
[12:45:40] <andypugh> skunkworks: No, I mainly machine with MDI commands :-)
[12:45:46] <skunkworks> it seems to run programs maxed out about twice as fast..
[12:47:35] <skunkworks> I was looking for a nice router program to make a guitar - but have not found any (Gcode already done anyway) :)
[12:52:00] <mozmck> I presume you are referring to the stick-on-a-board screeching electric noisemaker?
[12:52:11] <skunkworks> yes ;)
[12:52:28] <mozmck> ah, I don't have anything for that :)
[13:55:29] <skunkworks> http://youtu.be/oUajH5BCOUQ
[14:02:11] <KGB-linuxcnc> 03Norbert Schechner 05master 462d4e0 06linuxcnc 10(5 files in 2 dirs) gmoccapy_0_9_9_6_3 - plasma design adapted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=462d4e0
[14:35:50] <jepler> has anyone suggested to norbert that he not put a version number in his commit messages?
[14:37:13] <seb_kuzminsky> jepler: cradek did
[14:37:56] <cradek> twice
[14:38:01] <jepler> OK
[14:38:03] <jepler> well whatever
[14:38:52] <seb_kuzminsky> i should quietly remove the version numbers in the hostmot2 driver before anyone notices
[14:38:59] <cradek> he tried to come up with a different system, where the user could see the git ref easily on the screen, and although I don't think that's an important feature, it was important to him and he couldn't get it to work easily. if you have strong feelings maybe you could help him do that.
[14:40:11] <jepler> I offered a patch to put the git ref in linuxcnc.version so he could display it
[14:40:50] <cradek> thanks, I think that's a good approach
[14:41:08] <seb_kuzminsky> we have scripts/get-version-from-git that the buildbot uses to (ugh) overwrite VERSION, and that goes into Axis and the debian version number and into the docs
[14:42:14] <jepler> also I don't understand what relationship this has to putting version numbers in commit messages
[14:42:48] <jepler> get the string 0_9_9_6_3 from the about dialog and plug it in to google and see where you end up on gitweb?
[14:43:27] <cradek> he wants people on the forum who are building from source to be able to report problems to him easily
[14:43:49] <cradek> I think if they are building from source, they can use git describe, but he prefers something on-screen
[14:44:08] <cradek> I suppose people might send him screenshots or something - I don't know the culture of bugreporting on the forum
[14:44:43] <jepler> the fight I'm fighting at the moment is not about the string 0_9_9_6_3 which I assume he puts in his source file
[14:44:54] <jepler> though that's bad too and it would be next on the list to do something about
[14:45:12] <jepler> well anyway I'm sorry I brought it up
[15:04:10] <mhaberler> once ubc3 is merged, that is taken care of; the git tags are available in C and Python as needed
[15:04:44] <cradek> but the social part is harder than the technical part :-/
[15:05:20] <mhaberler> still no need to reinvent the tech part; Norbert will get around to it
[15:05:27] <mhaberler> Dec 17 21:40:28 wheezy msgd:0: startup instance=inst0 pid=13729 flavor=rt-preempt rtlevel=5 usrlevel=5 halsize=512000 shm=Posix gcc=4.8.2 git=v2.6.0~pre~remote-hal-ui~f733fb0
[15:06:03] <cradek> very useful
[15:07:05] <mhaberler> it's generated during configure, is in config.h, and linuxcncconfig.py as linuxcncconfig.GIT_VERSION
[15:15:21] <memleak> someone pinged me when i was out of town but my scrollback doesn't go back far enough to see what the comment was...
[15:16:10] <cradek> 14:06 < cradek> good work memleak and seb_kuzminsky and everyone else! it's going to work.
[15:16:13] <cradek> 16:26 < cradek> wow I have 1854ns latency with isolcpus on memleak's kernel
[15:16:23] <cradek> these are the only things containing your name since you talked last
[15:16:34] <memleak> thanks cradek!
[15:16:35] <cradek> for the context you'll have to dig in the logs :-)
[15:17:24] <memleak> glad my RTAI stuff works well for you!
[15:17:26] <memleak> +
[15:17:55] <memleak> i put the keyboard down and accidentally type in a + sign.. sorry about that
[16:39:53] <alex_joni> logger[psha]: bookmark
[16:39:53] <logger[psha]> alex_joni: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2013-12-17.html
[18:17:27] <andypugh> Is there any chance that step 4 here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_On_Ubuntu_Precise has messed up my ssh keys?
[18:18:01] <andypugh> git pull is asking for a password, which is a bit of a problem.