Back
[06:10:26] <KGB-linuxcnc> 03John Thornton 05master 2e05cff 06linuxcnc 03src/hal/components/thcud.comp Component: thcud is a torch height control that uses up/down inputs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2e05cff
[06:12:49] <archivist> there seems to be a bug in the stepcond config, if one selects a pyvcp panel and then goes on to select the pins there is no spindle-at-speed in the selections
[06:14:45] <archivist> when you attempt to start it fails with the missing pin, this is in 2.5.0 and after update 2.53, I just commented the pin out in the postgui to continue playing
[08:20:25] <seb_kuzminsky> archivist: could you open a bug for that at
http://sf.net/p/emc/bugs
[08:22:25] <archivist> does that mean I have to remember my sf password :)
[08:26:54] <archivist> and, what can I say about picking a metric config and sensible defaults and the default demo
[08:34:06] <cradek> I had always scoffed at the idea of having the upper Z limit above zero on sim configs, because I'd rather they have a normal setup as an example. But we can have that AND have the demo program run, just by shipping a var file with G54 set right. (although, the inch and mm configs will have to run from separate var files if they don't already)
[08:45:52] <seb_kuzminsky> ooh, i like that idea
[08:46:56] <seb_kuzminsky> JT-Shop: thanks!
[08:51:22] <JT-Shop> that makes sense to have the var file ready to run the sim
[10:04:23] <jepler> tracking a var file in git will stink, because running linuxcnc will modify it, then people will blindly commit the modified version
[10:04:47] <jepler> so if you do this, I think it's better to make the var file be created by the build process
[10:05:09] <seb_kuzminsky> good point, i hadnt thought of that
[10:05:31] <archivist> should it be built by the stepconf or whatever
[10:06:19] <seb_kuzminsky> having the build process create it introduces a new source of bugs if we change the var file format (which i guess is unlikely)
[10:06:24] <seb_kuzminsky> bbl
[10:32:06] <cradek> oh var is currently generated by the first run, isn't it
[10:32:37] <cradek> then yeah, generated by the build, I guess
[10:32:47] <cradek> kind of ugly
[10:58:40] <skunkworks_> cradek, This is from master pulled a few weeks ago. 266894
[10:58:44] <skunkworks_> heh
[10:58:50] <skunkworks_> http://imagebin.org/280348
[10:59:11] <skunkworks_> The mahcine is set to 30in/sec^2
[11:01:27] <cradek> also on Z?
[11:01:33] <skunkworks_> yes
[11:01:39] <cradek> hmm
[11:01:47] <skunkworks_> I will run it again and see
[11:02:03] <cradek> if you use halscope triggering you can capture the line number of the violation
[11:02:14] <skunkworks_> I will do that.
[11:02:27] <cradek> then you can make a very small program that shows the trouble case
[11:02:34] <skunkworks_> right
[11:02:36] <skunkworks_> will do
[11:26:05] <seb_kuzminsky> linuxcnc-build: force build docs
[11:26:06] <linuxcnc-build> build #1181 forced
[11:26:06] <linuxcnc-build> I'll give a shout when the build finishes
[11:29:41] <skunkworks_> cradek,
http://electronicsam.com/images/KandT/testing/circblendlatest/
[11:30:02] <skunkworks_> that is the config and a short stellabeeerror.ngc
[11:31:07] <cradek> cool
[11:31:08] <skunkworks_> when I run it the first time it is fine (has to jog over to the location of the segments) then when you run it again - the acc hits 34
[11:31:18] <cradek> which blend does it?
[11:31:20] <skunkworks_> on z
[11:31:44] <skunkworks_> not exactly sure - I could tell you what line - give me a second
[11:32:04] <cradek> I bet the arc is involved :-/
[11:32:09] <norbert> Hallo, I just pulled from master, and tried to merge with the old master, but I get the message: error: Untracked working tree file 'share/linuxcnc/gremlin_view.ui' would be overwritten by merge. Aborting Updating 1d81cfd..2e05cff - What can I do to get the latest master ?
[11:32:26] <cradek> is that your file?
[11:32:39] <norbert> No
[11:32:56] <norbert> it is from a previous master I beleave
[11:33:25] <cradek> I get that too
[11:33:29] <cradek> do you have any other changes?
[11:33:35] <norbert> No
[11:33:41] <cradek> git clean -f -x -d
[11:33:42] <skunkworks_> line 18
[11:33:43] <cradek> git pull
[11:34:20] <cradek> yeah, the arc, yuck
[11:34:21] <skunkworks_> well if I counted right - it is the arc
[11:34:54] <skunkworks_> well - the new tp doesn't do it.. :) (at that point)
[11:34:58] <cradek> yay!
[11:35:26] <kwallace2> OT: I have a PC that says I have commits that are ahead of master, or rather, diverged. Any hints on just pulling the remote master and trashing my local commits which I don't want?
[11:35:27] <skunkworks_> But I am a little perplexed. I ran the stella program new and old and the new took longer.
[11:35:43] <norbert> cradek: thanks it worked!
[11:35:59] <cradek> kwallace2: git reset --hard origin/master; git pull
[11:36:35] <skunkworks_> I need to play a little more. Something like the spiral run almost 400 ipm and screams - (compared to the current tp that runs around 100ipm
[11:37:46] <kwallace2> cradek: Okay, that's similar to what StackOverflow said too. Thanks.
[11:38:40] <skunkworks_> cradek, I have been ignoring axis crashing on large files when you open them more than once..
[11:38:54] <seb_kuzminsky> kwallace2: that will remove your local commits from your branch, make sure you don't want them before you do that
[11:38:55] <cradek> ugh
[11:39:07] <skunkworks_> one thing at a time ;)
[11:39:43] <cradek> seb_kuzminsky: he did explicitly ask for that...
[11:40:08] <seb_kuzminsky> for sure
[11:40:14] <cradek> but future readers of the irc log, beware!
[11:40:46] <linuxcnc-build> Hey! build docs #1181 is complete: Warnings [8warnings compile]
[11:40:47] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/docs/builds/1181
[11:43:26] <seb_kuzminsky> i can't reproduce the 'make -j docs' build problem in master zultron mentioned on the list
[11:43:28] <skunkworks_> cradek,
http://pastebin.com/BMVgpxXK
[11:43:49] <seb_kuzminsky> it works for me both on a single-processor VM and on my 8-processor dev machine
[11:43:51] <dgarr> norbert: commit bc1bc54 eliminated some unneeded copying of files but necessitates removing some files, it is mentioned in the commit message. the files can be manually removed or with _git clean_
[11:44:08] <cradek> skunkworks_: ulimit -c unlimited; reproduce it; gdb /usr/bin/python [the core file], (gdb) bt
[11:45:42] <skunkworks_> ok.. let me see if I can do that - can I do that all in the same terminal?
[11:46:11] <cradek> yes
[11:46:45] <kwallace2> This is what I got with "git reset --hard ; git pull":
http://wallacecompany.com/tmp/git_refresh.txt
[11:47:10] <cradek> AXIS's core file will end up in your config directory I think
[11:47:48] <cradek> kwallace2: git reset --hard origin/master; git pull
[11:48:09] <kwallace2> I guess leaving origin/master off was not getting my toes in far enough.
[11:53:21] <kwallace2> "fatal: Cannot do hard reset with paths."
[11:53:27] <skunkworks_> cradek, confused about the gdb /usr/bin/python [the core file]
[11:53:37] <skunkworks_> where is the core file?
[11:53:44] <cradek> AXIS's core file will end up in your config directory I think
[11:57:53] <skunkworks_> cradek, this help?
[11:57:53] <skunkworks_> http://pastebin.com/7P1NczqY
[11:57:58] <kwallace2> I did "git reset origin/master; git pull", which doesn't complain, but added a bunch of files. I'll try checkout.
[11:58:38] <norbert> dgarr: Thanks
[11:59:01] <cradek> skunkworks_: very much so
[12:00:04] <cradek> skunkworks_: not that I know how to fix it, but it's an interpreter bug involving named parameters
[12:00:22] <cradek> skunkworks_: would be interesting to see if you can reproduce it by processing your file with the standalone interpreter
[12:00:45] <skunkworks_> odd
[12:00:53] <cradek> although I bet it won't have the same lifecycle issues because it always exits
[12:01:03] <skunkworks_> right
[12:01:45] <cradek> can you make a bugreport and attach this backtrace output and also your gcode that triggers it? it looks important.
[12:02:28] <cradek> (because I'm not sure who's the right one to fix it)
[12:03:51] <seb_kuzminsky> is this bug in 2.5 or master?
[12:06:16] <cradek> he's certainly been testing master lately
[12:09:17] <seb_kuzminsky> aha
[12:11:04] <norbert> after making git clean -f -x -d and git pull I just compiled everythik, now ther is an new file docs/man/man9/thcud.9 So I can not push anythink, because otherwise I would push that file too. What now? Sorry, for my stupid questions, but I am a beginner in git and I do not wnat to destroy thinks.
[12:11:39] <cradek> the immediate remedy is to just not add that file to any of your commits
[12:12:18] <cradek> jthornton just forgot to add that to the manpage excludes; he (or you) can fix it with an additional commit
[12:13:11] <norbert> I do not know how to fix that, except adding it to the ignore list.
[12:13:51] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master a0cd7a8 06linuxcnc 10docs/man/.gitignore teach gitignore about thcud * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a0cd7a8
[12:14:15] <seb_kuzminsky> oops, didn't mean to step on your toes norbert :-/
[12:14:20] <cradek> thanks
[12:14:47] <seb_kuzminsky> i think he should have called it 'torch height up/down': thud
[12:15:34] <seb_kuzminsky> oh speaking of thud, the pid thump-on-index thing from a while back could have been avoided by feeding pid with the motor rather than joint signals, right? to completely avoid the discontinuity on home
[12:16:29] <seb_kuzminsky> wow the new kgb is so much better
[12:16:34] <cradek> heck I dunno
[12:16:37] <cradek> (yeah it sure is)
[12:17:29] <norbert> sep_kuzminski: No problem, I am just afraid to do somethinnk stupid, instead of repairing a problem.
[12:17:58] <seb_kuzminsky> breaking stuff is a good way to learn things, and we can always travel backwards in time (using git) to before the problem
[12:18:12] <seb_kuzminsky> so, ask for help, and dont be afraid to try things and break things :-)
[12:18:41] <norbert> OK, then please don't should on my in that case ;-)
[12:19:57] <seb_kuzminsky> heh ok
[12:48:11] <skunkworks_> cradek, is there a way you could test that program for constraint viloations on your end?
[13:04:05] <jthornton> seb_kuzminsky, thanks
[13:06:38] <cradek> skunkworks_: I also get a slight violation here
[13:08:32] <skunkworks_> ok - do you want me to do a bug report on that also?
[13:08:53] <cradek> wow that's a weird helix
[13:08:53] <skunkworks_> would that also be in the current release also?
[13:08:59] <cradek> what generated this?
[13:09:18] <skunkworks_> heh - image to gcode in axis
[13:09:29] <cradek> remarkable
[13:13:28] <cradek> it's a helix with radius .0086 and height 4.6
[13:13:47] <cradek> apparently not a well tested case :-)
[13:14:16] <cradek> I'm shocked that i2g generates helixes at all
[13:17:01] <cradek> oh wait this program is underspecified
[13:17:33] <cradek> there is no Y value before the helix, that's why the preview is weirdly 4.6" tall
[13:18:38] <cradek> guessing it's probably not even a helix
[13:20:13] <cradek> and the path in the gcode file doesn't trigger the bug -- only the NCD-adjusted path does
[13:20:40] <cradek> (I added y4.586 to line 13)
[13:21:37] <cradek> p.003 triggers it; p.002 does not
[13:31:39] <cradek> http://pastebin.com/raw.php?i=GBA0QEVa
[13:31:52] <cradek> skunkworks_: here's one that does it without using NCD
[13:34:39] <cradek> actually the last move is not needed
[13:35:57] <cradek> I bet accels along arcs are too high by a factor of sqrt2 (and helixes by sqrt3)
[13:37:29] <cradek> yep I think they really are
[13:45:51] <skunkworks_> so - no one has noticed that?
[13:45:59] <cradek> nope
[13:46:12] <jepler> it is surprising to me that tort.ngc didn't hit this case -- it has lots of helices.
[13:46:14] <cradek> I have a simple but approximate fix
[13:54:54] <KGB-linuxcnc> 03Chris Radek 05v2.5_branch bfb837e 06linuxcnc 10src/emc/task/emccanon.cc Fix arc acceleration constraint * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bfb837e
[13:59:19] <skunkworks_> Yay!
[13:59:30] <cradek> grumble grumble
[14:00:15] <skunkworks_> grumble?
[14:00:22] <cradek> arcs are hard
[14:00:33] <cradek> the accel is now a lot more conservative to handle the worst possible cases
[14:00:47] <cradek> it takes a lot of smarts (that I don't have, and neither does our code) to figure out when it's actually needed
[14:02:22] <cradek> but the whole TP is conservative about accels in order to make the worst cases work right, and this is just more of that
[14:03:15] <cradek> so, yay, I guess
[14:03:19] <cradek> skunkworks_: thanks for finding that
[14:03:30] <cradek> it was an important bug
[14:05:04] <skunkworks_> Great! Aww.. ;)
[14:05:39] <skunkworks_> Like I say - I am good at breaking things...
[14:06:35] <skunkworks_> it suprised me.. I looked at the screen and though - did I run the wrong build?
[14:06:47] <skunkworks_> thought
[14:06:51] <cradek> I appreciate your ill-placed confidence in me
[14:08:02] <skunkworks_> heh - well - I bet that for the most part - that issue didn't ever cause any problems as everyone under sets their acelleratoin
[14:08:32] <cradek> yes, I bet it was rare, and when it happened, the violation was pretty small
[14:08:40] <skunkworks_> right
[14:13:47] <skunkworks_> heh
http://imagebin.org/280366
[14:14:00] <skunkworks_> that line number almost makes me think int issue ;)
[14:14:17] <skunkworks_> almost
[14:14:34] <cradek> heh funny picture
[14:14:50] <cradek> it looks nice and smooth up to where it goes all wrong
[14:15:13] <cradek> this isn't my planner is it??
[14:16:23] <cradek> (wonder if anyone will see the bug in my bugfix)
[14:17:24] <skunkworks_> No.. It is where it does the position jump e^100
[14:17:48] <cradek> ah
[14:18:51] <skunkworks_> like
http://imagebin.org/279547
[14:19:24] <cradek> Exceeded everything soft limit on everywhere!
[14:20:18] <cradek> did you make a bugreport for your crashycrashy? I don't see it.
[14:20:29] <skunkworks_> not yet. Work :)
[14:20:40] <cradek> gets in the way of a lot.
[14:20:54] <skunkworks_> yes - my wife wonders why I even have to be here..
[14:21:02] <skunkworks_> ;)
[14:56:35] <skunkworks_> cradek, look sane?
https://sourceforge.net/p/emc/bugs/343/
[15:04:58] <cradek> yes, thank you
[15:05:10] <cradek> I'm amazed it didn't mangle your backtrace beyond recognition
[15:12:47] <jepler> that file has no "#" in it, I wonder why it's down in store_named_param...
[15:13:33] <jepler> what git ref are you testing at? please add this information to the bug report. Unless "beta-5" indicates a tag and I'm just that out of the loop
[15:14:26] <skunkworks_> No - how do I get the git ref?
[15:14:32] <jepler> "git describe"
[15:14:55] <jepler> start sim/axis/axis - load stellabee - hit ctrl-r to reload it?
[15:16:04] <jepler> (that sequence isn't crashing here at a recent master branch ref, nor is it even entering the function Interp::store_named_param according to gdb)
[15:16:25] <jepler> err actually I'm on v2.5_branch
[15:16:32] <skunkworks_> jeff - does this make sense?
[15:16:33] <skunkworks_> samco@samco-desktop:~/linuxcnc-orig$ git describe
[15:16:33] <skunkworks_> v2.5.3-2348-g4fb1d4c
[15:16:34] <jepler> v2.5.3-72-g29fada5
[15:17:36] <skunkworks_> it should be recent within the last month.. (I think)
[15:17:40] <jepler> OK
[15:17:56] <skunkworks_> I tried it on the installed 2.5.3 and it doesn't crash
[15:18:01] <jepler> OK
[15:18:30] <skunkworks_> but yes - all you ahve to do is re-load it and the bar goes a little bit across then axis closes
[15:51:17] <jepler> I'm able to get a crash similar to the one skunkworks posted. It looks like _setup.named_parameter_occurrence can be uninitialized:
[15:51:20] <jepler> http://pastebin.com/mPTJ5Ajv
[15:52:42] <kwallace2> Let's say I am using 2.6.0~pre and I have an active tool 1 with 0 tool length. I move to G53 G0 X0 Y0 Z0 which happens to be the top left rear corner of the machine space:
http://wallacecompany.com/tmp/tlo-0.png
[15:52:53] <kwallace2> Then I change the tool length using G10 L1 P1 Z1 and G43 H1 and get this:
http://wallacecompany.com/tmp/tlo-1.png
[15:53:06] <kwallace2> It seems to me the machine space ouline should shift with the tool length change. Am I missing something?
[15:55:57] <KGB-linuxcnc> 03Michael Haberler 05master 57e44d0 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc interp/setup_struct: fix missing initalisation of named_parameter_occurence * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=57e44d0
[15:58:06] <seb_kuzminsky> awesome!
[16:01:35] <jepler> thanks mah
[16:02:28] <jepler> with that ref pulled in I don't see the crash anymore
[16:13:38] <jepler> kwallace2: it might be nice if it did, but I don't know that it ever was written to do that. It's not clear whether you're suggesting an improvement or noting something that works different than it used to
[16:17:20] <cradek> if we think of the red lines as "places the controlled point can go" then I agree it should move -- but I'm not sure that's what the red lines really represent
[16:19:23] <cradek> I can imagine a tool so long (large positive or negative length) that you can't reach any of the program anymore, and the program would be outside the box and all those limits warning boxes would come on
[16:19:34] <cradek> that does make some intuitive sense
[16:30:45] <kwallace2> cradek: It just seemed to me that the red outlines would describe the control point or soft limit space. I thought I may have messed up my version of Gremlin so I checked to see how AXIS did it as a reference and the two agree. It seems like something I might try to fix if I can support the notion that it is broken.
[16:33:39] <kwallace2> The fact that the tool looks like it is hanging down into the red box makes me think I can raise the tool up more but is actually at the Z limit.
[16:41:17] <kwallace2> Opps, I meant to address jepler above too.
[16:44:59] <seb_kuzminsky> there are really two boxes, but we only show one, and i guess i'm not sure what the thing we show is
[16:45:41] <seb_kuzminsky> the two boxes are the limits in g53 space, and the limits of the controlled points in its currentcoordinate system (which may be translated and rotated relative to g53)
[16:46:45] <seb_kuzminsky> it would be illuminating to people who know what's going on if we showed both things clearly, but it'd probably be confusing to noobs
[16:47:17] <seb_kuzminsky> i think the simplest, most helpful thing to show would be the limits of the controlled point in its current coordinate system
[16:48:02] <seb_kuzminsky> i dont know how that would interact with cutter comp, which sort of changes the controlled point depending on the current velocity vector
[20:19:08] <skunkworks> logger[mah]:
[20:19:09] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-12-04.html
[20:20:11] <skunkworks> cool - thanks mah
