Back
[00:50:53] -!- jrf [jrf!~john@cpe-72-128-90-199.wi.res.rr.com] has joined #linuxcnc-devel
[00:51:35] -!- rob_h has quit [Ping timeout: 258 seconds]
[01:47:48] -!- jrf has quit [Quit: Leaving]
[03:05:07] <mozmck> Here is my fix for the file-loaded event from hal_glib
https://github.com/mozmck/linuxcnc-mirror/commit/8cec4d3ec3fa51e7691e7f639ddd942ec4736451
[03:06:22] <mozmck> If someone can think of a better way to do this, or sees a problem with the way I did it, please let me know. If it looks good, should it go on 2.7 as a bugfix?
[03:12:45] -!- JT-Shop has quit [Read error: Connection reset by peer]
[03:12:45] -!- jthornton has quit [Read error: Connection reset by peer]
[03:13:41] -!- jthornton [jthornton!~john@198.45.191.246] has joined #linuxcnc-devel
[03:13:41] -!- JT-Shop [JT-Shop!~john@198.45.191.246] has joined #linuxcnc-devel
[03:29:03] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[04:09:24] -!- Miner_48er has quit [Read error: Connection reset by peer]
[04:21:01] -!- kwallace [kwallace!~kwallace@162.222.30.254] has parted #linuxcnc-devel
[04:59:34] -!- Mathnerd314 has quit [Ping timeout: 240 seconds]
[04:59:38] -!- ve7it has quit [Remote host closed the connection]
[05:13:34] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[05:48:40] -!- kingarmadillo has quit [Ping timeout: 258 seconds]
[06:28:28] -!- mk0 [mk0!~Orr@fiztech.basnet.by] has joined #linuxcnc-devel
[06:33:02] -!- rob_h [rob_h!~robh@2a02:c7f:5603:bc00:2909:aa13:24e2:740b] has joined #linuxcnc-devel
[06:56:31] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[06:57:03] -!- teepee has quit [Ping timeout: 244 seconds]
[06:57:09] teepee_ is now known as teepee
[07:44:15] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[07:57:21] -!- ktchk [ktchk!~eddie6929@n219079250034.netvigator.com] has joined #linuxcnc-devel
[08:16:21] -!- ktchk has quit [Ping timeout: 240 seconds]
[08:53:12] -!- mk0 has quit [Read error: Connection reset by peer]
[08:53:19] -!- b_b has quit [Changing host]
[08:53:31] -!- mk0 [mk0!~Orr@fiztech.basnet.by] has joined #linuxcnc-devel
[09:29:41] -!- ktchk [ktchk!~eddie6929@n219079250034.netvigator.com] has joined #linuxcnc-devel
[09:46:03] -!- mk0 has quit [Quit: Leaving]
[10:31:41] -!- mkrz has quit [Ping timeout: 240 seconds]
[10:40:55] -!- emc [emc!~emc@198.45.191.246] has joined #linuxcnc-devel
[11:05:28] -!- emc has quit [Quit: Leaving]
[11:11:13] -!- emc [emc!~emc@198.45.191.246] has joined #linuxcnc-devel
[11:11:20] -!- emc has quit [Remote host closed the connection]
[11:15:34] -!- remstw has quit [Ping timeout: 240 seconds]
[11:44:13] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:48:21] -!- kingarmadillo has quit [Ping timeout: 240 seconds]
[11:51:42] -!- zlog has quit [Ping timeout: 272 seconds]
[11:51:42] -!- Tom_itx has quit [Ping timeout: 260 seconds]
[11:53:43] -!- zlog [zlog!~zlog@ip68-102-196-26.ks.ok.cox.net] has joined #linuxcnc-devel
[11:58:36] -!- emc [emc!~emc@198.45.191.246] has joined #linuxcnc-devel
[11:59:09] -!- emc has quit [Remote host closed the connection]
[12:10:53] -!- micges [micges!~micges@adcc137.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[12:12:05] -!- micges has quit [Client Quit]
[12:13:45] -!- Tom_itx [Tom_itx!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[12:21:46] -!- emc [emc!~emc@198.45.191.246] has joined #linuxcnc-devel
[12:21:49] -!- emc has quit [Remote host closed the connection]
[12:55:23] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:32:17] <skunkworks> This seems to work pretty good so far.
[13:32:18] <skunkworks> http://www.scorchworks.com/Fengrave/fengrave.html
[13:32:35] <skunkworks> I have used it for vcarving so far.
[13:33:30] <skunkworks> they make a comment about using it as an input filter in linuxcnc
[13:38:32] <mozmck> thanks for the link - one more thing I'll have to try someday
[13:48:04] -!- b_b has quit [Read error: Connection reset by peer]
[13:48:35] -!- b_b has quit [Changing host]
[13:49:39] -!- mkrz has quit [Remote host closed the connection]
[13:49:51] <mozmck> seb_kuzminsky: any thoughts on putting this as a bugfix in 2.7?
https://github.com/mozmck/linuxcnc-mirror/commit/8cec4d3ec3fa51e7691e7f639ddd942ec4736451
[13:57:55] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[13:59:27] -!- mkrz has quit [Ping timeout: 260 seconds]
[14:03:54] <skunkworks> http://electronicsam.com/images/house/freinds.JPG
[14:04:15] <skunkworks> that was just a black/white logo
[14:05:17] <mozmck> nice! The text is raised?
[14:05:47] <skunkworks> no - cut with a 60deg cutter
[14:06:16] <mozmck> I guess it's an optical illusion - sure looks like it's raised and the background is sunken
[14:06:46] <skunkworks> Heh - I can see that
[14:11:16] -!- b_b has quit [Read error: Connection reset by peer]
[14:16:50] <KGB-linuxcnc> 03Dewey Garrett 052.7 bbfb9fb 06linuxcnc 10src/emc/rs274ngc/rs274ngc_pre.cc rs274ngc_pre.cc msg for INTERP_FILE_NOT_OPEN * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bbfb9fb
[14:17:57] -!- skunkworks_ has quit [Ping timeout: 250 seconds]
[14:25:42] -!- b_b has quit [Changing host]
[14:28:44] -!- Daerist has quit [Remote host closed the connection]
[14:35:54] -!- ktchk [ktchk!~eddie6929@n219079250034.netvigator.com] has parted #linuxcnc-devel
[14:42:09] <seb_kuzminsky> thanks dgarr!
[14:43:13] <seb_kuzminsky> if you say "closes #63" in the commit message, it'll automatically close the issue (there are some other keywords for it too:
https://help.github.com/articles/closing-issues-via-commit-messages/)
[14:43:17] <seb_kuzminsky> mozmck: looking...
[14:46:11] -!- kingarmadillo has quit [Read error: Connection reset by peer]
[14:55:29] <seb_kuzminsky> mozmck: it's a nice coincidence that i was just in that exact code that you're fixing, while chasing the stat buffer g5x bug zultron reported
[14:55:33] <seb_kuzminsky> https://github.com/LinuxCNC/linuxcnc/tree/seb/2.6/statbuffer-g5x-abort
[14:56:01] <seb_kuzminsky> so your patch looks mostly good to me
[14:56:26] <seb_kuzminsky> you cleanly added a new field to the stat buffer, that's obviously useful to the UIs above Task
[14:56:38] <seb_kuzminsky> my only question/suggestion is:
[14:57:31] <seb_kuzminsky> are you sure you don't want to move the setting of task.callLevel=0 into emcTaskAbort()?
[14:58:47] <seb_kuzminsky> it seems like all the places where you set it to 0 are in the same code block that calls emcTaskAbort(), plus there are many other places where that function is called, but task.callLevel does *not* get set to 0
[14:59:02] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal 5476119 06linuxcnc 10.gitignore 04configs/sim/FastSeal/Kopie von lathe.tbl 10configs/sim/FastSeal/pendant.hal Internal changes to check for ignore limits * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5476119
[14:59:02] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal 0031f4f 06linuxcnc 10src/emc/usr_intf/FastSeal/FastSeal.py 10src/emc/usr_intf/FastSeal/release_notes.txt EU_Surplus_FastSeal 0.8.0 - hal pin to clear and reload preview * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0031f4f
[15:00:08] <seb_kuzminsky> the internal structure of Task is really messy - lots of message passing, queueing of messages, state management, etc etc. it's a swampy jungle
[15:01:41] <seb_kuzminsky> skunkworks: that sign looks great
[15:02:10] <skunkworks> seb_kuzminsky, thanks! first time 'v-carving'
[15:03:32] <seb_kuzminsky> i've seen people v-carve with expensive closed-source CAM software, but never with open-source code based on our wiki's example code
[15:03:33] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[15:03:42] <seb_kuzminsky> that's really interesting
[15:03:57] <cradek> sure is
[15:04:27] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal 618e358 06linuxcnc 10src/emc/usr_intf/FastSeal/FastSeal.py 10src/emc/usr_intf/FastSeal/release_notes.txt EU_Surplus_FastSeal - 0.8.1 - deleted unneeded print commands * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=618e358
[15:04:30] -!- remstw has quit [Ping timeout: 258 seconds]
[15:04:42] <cradek> I would have used that instead of scanlines for
http://timeguy.com/cradek/01408982148
[15:04:42] <seb_kuzminsky> wow, the fengrave website is full of awesome-looking results
[15:04:57] <seb_kuzminsky> oh, yeah
[15:05:06] <mozmck> seb_kuzminsky: thanks for the comments!
[15:05:12] <seb_kuzminsky> well the scanlines came out looking pretty good too
[15:05:27] <seb_kuzminsky> i wonder if v-carving would be faster? less rasterization for sure
[15:05:40] <cradek> yeah, especially after she poked it with a sharpie to darken the inside parts
[15:06:18] <cradek> today I would have used mumble sulphmumble which is the thing that real jewelers who really know what they're doing use to darken silver
[15:07:09] <mozmck> My method was simply to set task.callLevel wherever task.currentLine got set, but that may not be the best.
[15:09:30] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[15:10:13] <mozmck> seb_kuzminsky: speaking of task being messy, did you see this call graph of Interp::execute()?
http://www.mcknight-instruments.com/images/classInterp_execute_cgraph.png
[15:11:47] <cradek> wow.
[15:12:28] <mozmck> I used doxygen to generate those - pretty neat - and somewhat helpful.
[15:12:55] <cradek> I'm surprised to hear it was helpful
[15:13:24] <skunkworks> it was much much faster than engraving
[15:13:57] <mozmck> cradek: Not all of the graphs are that large - and it can give a quick picture of where things are going in the code.
[15:14:18] <cradek> oh I see - not this one in particular
[15:14:44] <mozmck> Yeah, I did the whole source tree.
[15:15:43] <mozmck> Doxygen comments could be useful to add. Code comments that are there already could be given doxygen tags.
[15:17:25] <skunkworks> the rotozip finally died.. I guess we used it quite a bit. (circuit board making and such)
[15:17:36] <skunkworks> the brushes where 1/6"
[15:17:40] <skunkworks> 1/16"
[15:17:45] <skunkworks> left
[15:18:29] <skunkworks> put a router back in. (the runout on the router was too much for circuit board making - why we were using the rotozip...)
[15:21:45] <cradek> I'm surprised to learn that M1.2-0.25 is a standardish size that's closeish to .047-90 that I made recently
[15:23:12] <skunkworks> so you could have just bought them?
[15:23:52] <cradek> hmmmmm ebay.com/itm/281902543081
[15:23:53] <skunkworks> ;)
[15:24:19] <cradek> bet these are not particularly great...
[15:25:20] <cradek> also I'm nervous that they don't say what the pitch is
[15:25:43] <cradek> eh it's just $16
[15:28:03] <skunkworks> love all the pictures
[15:28:48] <cradek> yes, very useful
[15:31:22] <skunkworks> Get off my lawn!!
[15:31:30] <skunkworks> (sorry - gene again)
[15:40:37] <seb_kuzminsky> mozmck: i think it'd be nice to have better comments inside Task, and i dont mind doxygen syntax in there, though i've personally not found webpages of code comments all that helpful generally
[15:40:56] <seb_kuzminsky> if it'd be help to others i'd welcome it
[15:41:40] <seb_kuzminsky> on the topic of callLevel, setting it wherever currentLine gets set seems like a reasonable way to do it
[15:42:13] <seb_kuzminsky> i wonder if currentLine has stale data if you take another Abort path through Task
[15:42:34] <seb_kuzminsky> i bet it'd be easy to change the statbuffer-g5x-abort test to test that
[15:45:13] <mozmck> I'll add a callLevel = 0 in emcTaskAbort() - it can't hurt anything. I would add currentLine, but I'm not sure if that would hurt something. Could be something is depending on it being stale at times?
[15:48:40] <seb_kuzminsky> if so we have 2 bugs! ;-)
[15:51:10] <mozmck> heh!
[15:52:13] <seb_kuzminsky> mozmck: sounds good. as you can see with your doxygen-fu, emcTaskAbort ends up calling interp.close() which unwinds the interpreter call stack, so putting it there will never be wrong
[15:52:56] <mozmck> as far as doxygen goes, some of the existing code comments are really pretty good, and having them in a cross-linked html doc tree is a lot faster than browsing through the code.
[15:53:17] <seb_kuzminsky> with vim & cscope it's pretty quick ;-)
[15:54:05] <mozmck> seb_kuzminsky: true, unless someone decides to implement the resume mentioned in the comment in emcTaskAbout()
[15:54:26] <mozmck> well, vim & cscope may be fast once you learn them well :-)
[15:54:51] <seb_kuzminsky> i'll channel jepler and say "step 1: have 20 years of experience"
[15:55:10] <mozmck> I use eclipse, and it is fast, but for simply learning the code, something like doxygen can really help if done well.
[15:56:13] <seb_kuzminsky> yay for different tools for different people
[15:56:37] <seb_kuzminsky> oh hey speaking of jepler:
[15:56:38] <seb_kuzminsky> adaed5af (Jeff Epler 2007-06-24 15:05:18 +0000 199) // without emcTaskPlanClose(), a new run command resumes at
[15:56:41] <seb_kuzminsky> adaed5af (Jeff Epler 2007-06-24 15:05:18 +0000 200) // aborted line-- feature that may be considered later
[15:57:04] <mozmck> I recently discovered that I can do a C++ search in eclipse for something like EMC_TASK_STAT::file and it will find every occurance of every variable of that type in the project.
[15:57:37] <seb_kuzminsky> that's a good power to have
[16:13:21] <seb_kuzminsky> oh, mozmck, also dont forget to sign off your commit
[16:13:33] <mozmck> oops, thanks for the reminder
[16:13:39] <seb_kuzminsky> and if you send me a link to a branch instead of a commit on github, i can pull it more easily
[16:14:57] <mozmck> I can push to glo, but I figured I ask for comments first
[16:15:04] <mozmck> can it go on 2.7?
[16:15:33] <seb_kuzminsky> always a good idea to get more eyes on things first, i just meant a branch on github is easier to pull than a commit on github
[16:16:05] <seb_kuzminsky> do you want me to look at the emcTaskAbort change first? i trust you to get it right, and if you're confident please push to 2.7 on glo
[16:16:25] <mozmck> Oh, I see. It looks like there is a link right under the commit message to the branch
[16:16:52] <mozmck> I'm just adding one line emcStatus->task.callLevel = 0; so I don't *think* I'll mess that up!
[16:20:36] <mozmck> huh, I guess that link is not to the branch, but some comparison. github loses the branch you are on any time you click on anything it seems.
[16:20:50] <mozmck> seb_kuzminsky: here's the update:
https://github.com/mozmck/linuxcnc-mirror/commits/mozmck-2.7
[16:38:49] -!- ivansanchez has quit []
[16:41:46] -!- amiri_ has quit [Remote host closed the connection]
[16:42:22] <seb_kuzminsky> thanks!
[16:43:25] <seb_kuzminsky> oh, now that you set callLevel=0 in emcTaskAbort, i think you should *not* set it in the code paths that call emcTaskAbort, in the interest of keeping things organized and simple
[16:44:25] <seb_kuzminsky> the setting of currentLine=0 should probably be in emcTaskAbort too, but that shouldn't be part of this commit you're working on
[16:44:57] <seb_kuzminsky> (and just to be clear, i dont expect you to take on that janitorial task as part of the feature you're adding, though i hope one of us remembers to do it later in master)
[16:49:06] <mozmck> Hmm, that makes sense - I'll look at that some more.
[16:57:01] <mozmck> ok, fixed that - thanks for the help. I had not checked to see if each place I set it was in a place that called emcTaskAbort(), but it was. much cleaner now.
[16:57:47] <mozmck> There really could be some cleanup in several places there in task - I will probably do that on master.
[17:05:26] <KGB-linuxcnc> 03Moses McKnight 052.7 6b90e14 06linuxcnc 10(7 files in 4 dirs) Added callLevel to EMC_TASK_STAT class, to fix hal_glib file-loaded bug. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6b90e14
[17:09:55] <seb_kuzminsky> that looks great mozmck
[17:10:05] <mozmck> thanks
[17:11:04] <mozmck> seb_kuzminsky: I saw your two notes on my simple-run-from-line branch, but I'm not sure it's worth the effort to try and redo my commits for that?
[17:11:25] <seb_kuzminsky> nah, they're nitpicks, fix if it's easy and ignore if not ;-)
[17:11:30] -!- beawesomeinstead has quit [Read error: Connection reset by peer]
[17:11:37] <mozmck> ok :-)
[17:12:01] <mozmck> I'll try and do some documentation, but other than that, are there any objections to pushing it to master?
[17:12:38] <seb_kuzminsky> speaking of task abort stuff, i've made some progress on the statbuffer/g5x/abort bug zultron reported, and i have questions on what the right behavior on abort is
[17:14:24] <seb_kuzminsky> mozmck: i haven't read that one as carefully yet
[17:14:27] <seb_kuzminsky> what is a skipp arse?
[17:15:24] <seb_kuzminsky> i'd suggest squashing those two commits together, since the first one isn't useful on its own right?
[17:15:41] <seb_kuzminsky> that would make reviewand future debugging easier
[17:16:36] <seb_kuzminsky> on the abort issue: normal program termination happens with M2 or M30, which does a whole bunch of environment restoring inside Interp and out in Task's Canon.
[17:17:08] <seb_kuzminsky> on Abort we don't do those things. Interp closes, but the Canon state is not carefully/completely restored, that's the root of the g5x bug zultron reported
[17:17:44] <seb_kuzminsky> my guess is to pull the M2/M30 cleanup code out to a function, and call it both from M2/M30 and from Abort
[17:17:59] <seb_kuzminsky> am i missing anything? is there state that shouldn't be restored on Abort?
[17:20:02] <mozmck> seb_kuzminsky: skipparse is a flag to tell Interp::read() to skip parsing the line it reads. otherwise you get errors as you skip through the code to get to the actual start line.
[17:20:26] <mozmck> yes, squashing the two commits would be best I'm sure.
[17:20:34] <seb_kuzminsky> ;-)
[17:21:21] <seb_kuzminsky> one thing i really like about git is how you can do your development piecemeal and stream-of-consciousness, and then clean it up into something that's comprehensible to others in postprocessing
[17:21:46] <mozmck> I don't know of state that should not be restored on abort offhand, but I'm a bit green :-)
[17:22:22] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[17:24:12] -!- teepee has quit [Ping timeout: 272 seconds]
[17:24:12] teepee_ is now known as teepee
[17:24:38] <mozmck> where is M3/M30 handled?
[17:25:00] <seb_kuzminsky> interp_convert.cc
[17:25:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/statbuffer-g5x-abort 7c8b4a8 06linuxcnc 10(6 files) add a test to reproduce the preview-strangeness reported by Zultron * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7c8b4a8
[17:25:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/statbuffer-g5x-abort 3515a3c 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc 10src/emc/rs274ngc/rs274ngc_pre.cc 10src/emc/task/emctaskmain.cc debugging junk * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3515a3c
[17:25:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/statbuffer-g5x-abort 8b476f1 06linuxcnc 10tests/statbuffer-g5x-abort/test.ini debug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8b476f1
[17:25:05] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/statbuffer-g5x-abort 2c4a4ca 06linuxcnc 10src/emc/iotask/ioControl.cc debug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2c4a4ca
[17:25:09] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/statbuffer-g5x-abort 58b1aa2 06linuxcnc 10src/rtapi/sim_common.h rtapi (sim): flush stdout/stderr after rtapi_print() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=58b1aa2
[17:25:13] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/statbuffer-g5x-abort a0c54f3 06linuxcnc 10tests/statbuffer-g5x-abort/preview-strangeness.ngc 10tests/statbuffer-g5x-abort/test-ui.py statbuffer-g5x-abort test: show (poorly) that flood coolant is correctly shut off on abort * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a0c54f3
[17:25:18] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/statbuffer-g5x-abort 664fa6d 06linuxcnc 10src/emc/task/iotaskintf.cc 10src/emc/task/taskclass.cc task: don't call emcAbortCleanup() in emcIoAbort() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=664fa6d
[17:25:22] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/statbuffer-g5x-abort b80852b 06linuxcnc 10tests/statbuffer-g5x-abort/test-ui.py debugging * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b80852b
[17:25:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/statbuffer-g5x-abort 5a84454 06linuxcnc 10src/emc/rs274ngc/rs274ngc_pre.cc interp: reset g5x index, g5x offset, and rotation on abort * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5a84454
[17:25:31] <seb_kuzminsky> mozmck: convert_stop()
[17:25:40] <mozmck> thanks
[17:25:59] <seb_kuzminsky> there's my un-cleaned-up stream-of-consciousness work-in-progress statbuffer-abort branch
[17:26:14] <linuxcnc-build> build #1944 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1944 blamelist: Norbert Schechner <nieson@web.de>
[17:26:34] <seb_kuzminsky> just airing my dirty laundry
[17:26:54] <seb_kuzminsky> BBL
[17:41:04] <linuxcnc-build> build #3372 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/3372 blamelist: Norbert Schechner <nieson@web.de>
[17:45:05] <linuxcnc-build> build #1940 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/1940 blamelist: Norbert Schechner <nieson@web.de>
[17:46:03] <linuxcnc-build> build #3372 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/3372 blamelist: Norbert Schechner <nieson@web.de>
[17:47:53] <linuxcnc-build> build #2200 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/2200 blamelist: Norbert Schechner <nieson@web.de>
[17:51:05] <linuxcnc-build> build #1274 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/1274 blamelist: Norbert Schechner <nieson@web.de>
[17:51:38] <linuxcnc-build> build #362 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/362 blamelist: Norbert Schechner <nieson@web.de>
[18:00:57] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[18:04:45] <linuxcnc-build> build #1239 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/1239 blamelist: Norbert Schechner <nieson@web.de>
[18:08:30] <cradek> seb_kuzminsky: I don't believe jepler wrote those comments. I think they are as old as the dinosaurs.
[18:11:28] <cradek> heh yeah - he removed that from one file and put it into two other files
[18:18:03] <linuxcnc-build> build #1632 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/1632 blamelist: Norbert Schechner <nieson@web.de>
[18:18:41] <linuxcnc-build> build #612 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/612 blamelist: Norbert Schechner <nieson@web.de>
[18:21:48] -!- md-2 has quit [Quit: Leaving...]
[18:22:46] <linuxcnc-build> build #611 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/611 blamelist: Norbert Schechner <nieson@web.de>
[18:23:00] <linuxcnc-build> build #541 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/541 blamelist: Norbert Schechner <nieson@web.de>
[18:25:55] <linuxcnc-build> build #542 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/542 blamelist: Norbert Schechner <nieson@web.de>
[18:34:28] -!- kalxas has quit [Quit: Goodbye]
[18:44:53] -!- kwallace [kwallace!~kwallace@162.222.30.254] has joined #linuxcnc-devel
[18:46:21] -!- Komzzpa has quit [Ping timeout: 240 seconds]
[18:55:24] -!- rob_h has quit [Ping timeout: 272 seconds]
[18:55:28] -!- b_b has quit [Remote host closed the connection]
[18:55:45] -!- rob_h [rob_h!~robh@97e42a64.skybroadband.com] has joined #linuxcnc-devel
[19:02:01] <seb_kuzminsky> sb end
[19:02:16] <seb_kuzminsky> oops
[19:23:37] <skunkworks> steve steve steve....
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/150818
[19:23:42] <skunkworks> :)
[19:24:08] <skunkworks> treading requires windows 10... ;)
[19:24:14] <skunkworks> threading
[19:25:05] <seb_kuzminsky> i'd like to get programs like f-engrave into the hands of more linuxcnc users, to strengthen the ecosystem
[19:25:18] <seb_kuzminsky> skunkworks: did you run it on linux or windows?
[19:26:07] <skunkworks> I am running it on linux
[19:26:12] <seb_kuzminsky> cool
[19:26:40] <skunkworks> I had to install the 2 extra things he talks about in the install directions
[19:26:46] <seb_kuzminsky> right
[19:26:58] <skunkworks> one was an apt-get install and the other was a make install
[19:27:18] <seb_kuzminsky> the make install was TTF2CXF_STREAM, in his zip file?
[19:27:25] <seb_kuzminsky> his(?)
[19:27:30] <skunkworks> I 'think' jepler had brief contact with this guy - on the mailing list maybe?
[19:27:33] <skunkworks> yes
[19:27:45] <seb_kuzminsky> i should sometimes read my email, i might learn things
[19:28:57] <skunkworks> The potrace was an apt-get install - I didn't find the libpotrace - but it didn't seem to keep it from working
[19:29:12] <skunkworks> I assume it was installed with the apt-get
[19:29:17] <skunkworks> this is on debian jessie
[19:29:26] <seb_kuzminsky> jessie ftw
[19:29:44] <seb_kuzminsky> potrace.deb pulls in libpotrace0
[19:33:47] <skunkworks> Jessie has been great
[19:33:49] <skunkworks> no issues
[19:33:59] <skunkworks> I am running rt 4.4.9
[19:34:48] <skunkworks> I wish a working rtai kernal was available.
[19:34:55] <seb_kuzminsky> me too
[19:35:03] <skunkworks> another project. :)
[19:35:10] <seb_kuzminsky> i'm bummed the 5.0-test1 rtai kernels failed so badly in the buildbot VMs
[19:35:30] <seb_kuzminsky> i never ran into any trouble on baremetal (but i didn't run it that much)
[19:36:06] <seb_kuzminsky> and rtai.org removed support for the 3.16 kernel i was targetting :-(
[19:39:53] <skunkworks> why? old?
[19:40:00] * skunkworks doesn't know his kernels
[19:45:26] <seb_kuzminsky> i dont know why they removed the patch for that kernel
[19:51:34] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[19:51:56] <CaptHindsight> the mysteries of Paulo
[19:52:32] <CaptHindsight> memleak has 3.16 on his RTAI tree if you want support
[19:54:03] <CaptHindsight> https://github.com/NTULINUX/RTAI
[19:54:29] <CaptHindsight> https://github.com/NTULINUX/RTAI/tree/master/base/arch/x86/patches
[20:00:21] <skunkworks> pcw_home,
[20:00:23] <skunkworks> http://www.cnczone.com/forums/tormach-personal-cnc-mill/309278-pcnc770-4th-axis-clear-path-servo-pathpilot.html
[20:00:48] <skunkworks> seems like the stepgen is falling behind.
[20:01:21] <skunkworks> maybe pathpilot doesn't show an error if the stepgen settings are not achievable?
[20:05:34] <cradek> well you'd get ferrors, right?
[20:07:25] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:08:28] <linuxcnc-build> build #2340 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2340 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[20:08:46] <linuxcnc-build> build #2340 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/2340 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[20:12:12] -!- skunkworks_ has quit [Ping timeout: 246 seconds]
[20:12:31] <linuxcnc-build> build #2006 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/2006 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[20:19:10] <linuxcnc-build> build #4179 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/4179 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[20:24:28] <linuxcnc-build> build #4181 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4181 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[20:25:32] <linuxcnc-build> build #3390 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3390 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[20:29:41] <linuxcnc-build> build #4181 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/4181 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[20:34:24] <linuxcnc-build> build #808 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/808 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[20:34:37] <cradek> that doesn't look like a stepgen problem
[20:35:22] <cradek> but he has an ferror limit of 15 degrees
[20:37:38] <cradek> fwiw, some random master build I tested works fine
[20:40:26] <cradek> I don't even know whether his display shows feedback or command
[20:40:38] <cradek> think he's going to have to ask his pathpilot vendor for help...
[20:41:11] <linuxcnc-build> build #4181 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/4181 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[20:43:37] <cradek> also I wonder if his stepgen is in velocity mode
[20:44:38] <cradek> if they're really using those pid values, if it's falling behind during the long move, when the move ends the FF1 contribution immediately goes to zero, leaving you relying on P only for final positioning - I can imagine this causing the creep at the end.
[20:44:53] <linuxcnc-build> build #808 of 1500.rip-jessie-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/808 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[20:45:55] <cradek> wonder what the rest of the pid values are (the ones not coming from the ini)
[20:46:12] <cradek> wonder if they left halscope in their distribution
[20:46:17] * cradek shrugs
[20:47:26] <linuxcnc-build> build #4189 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/4189 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[20:47:27] <linuxcnc-build> build #4193 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4193 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[21:00:06] -!- jthornton has quit [Read error: Connection reset by peer]
[21:00:30] -!- JT-Shop has quit [Read error: Connection reset by peer]
[21:01:48] -!- jthornton [jthornton!~john@198.45.191.246] has joined #linuxcnc-devel
[21:07:01] -!- jthornton has quit [Ping timeout: 250 seconds]
[21:09:50] -!- jthornton [jthornton!~john@198.45.191.246] has joined #linuxcnc-devel
[21:12:40] -!- jthornton has quit [Read error: Connection reset by peer]
[21:12:44] -!- chillly has quit []
[21:13:11] -!- jthornton [jthornton!~john@198.45.191.246] has joined #linuxcnc-devel
[21:26:40] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[21:27:07] -!- teepee has quit [Ping timeout: 244 seconds]
[21:27:08] teepee_ is now known as teepee
[21:43:39] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[22:00:51] -!- jrf [jrf!~john@cpe-72-128-90-199.wi.res.rr.com] has joined #linuxcnc-devel
[22:27:28] <seb_kuzminsky> debian packaging for f-engrave:
https://github.com/SebKuzminsky/f-engrave
[22:27:48] <PCW> cradek: Pretty sure its because of the small max_error value (a scaling issue with rotary axis)
[22:27:59] <seb_kuzminsky> it'd be easy to add to the same build system that builds mesaflash etc, and publish on wlo
[22:28:21] -!- kingarmadillo has quit [Ping timeout: 246 seconds]
[22:28:25] <PCW> f-engrave looks really nice
[22:29:29] <seb_kuzminsky> yeah
[22:29:37] <seb_kuzminsky> here's a pre-built deb for jessie/amd64:
http://highlab.com/~seb/linuxcnc/f-engrave_1.58-1_amd64.deb
[22:35:07] -!- gaute_ has quit [Quit: Page closed]
[22:35:10] -!- dnaleromj has quit [Ping timeout: 272 seconds]
[23:00:08] -!- JT-Shop [JT-Shop!~john@198.45.191.246] has joined #linuxcnc-devel
[23:01:47] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[23:08:05] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[23:08:30] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has parted #linuxcnc-devel
[23:39:19] -!- rob_h has quit [Ping timeout: 258 seconds]
[23:39:42] <cradek> PCW: what's MAX_ERROR?
[23:40:15] <PCW> the PID loops maximum error bound
[23:41:01] <cradek> oh you think it hooks to pid.N.maxerror?
[23:41:08] <PCW> yes
[23:41:13] <cradek> and it was set to 0? that would disable the P gain
[23:41:25] <PCW> no 0 means no bound
[23:41:26] <cradek> (if I'm reading the manpage right)
[23:41:35] <cradek> oh
[23:41:46] <cradek> then I don't see how that would change it? what am I missing?
[23:42:18] <PCW> it was set to .0005 as an attempt to reduce the effect of latency spikes on the high gain PID loop
[23:42:51] <cradek> oh I see it now
[23:43:00] <cradek> I misremembered it as 0, but that's MAX_OUTPUT
[23:43:04] <PCW> .0005 inches words pretty well .0005 degrees not so well
[23:43:10] <cradek> yeah, bet so
[23:43:26] <PCW> its a scaling issue
[23:43:42] <cradek> yeah degrees are a lot "smaller" than inches
[23:44:28] <cradek> so if he had a reasonable ferror limit, he *would* have seen ferrors
[23:45:02] <cradek> it's better if misconfiguration causes ferrors than ruined parts
[23:45:20] <PCW> their .0005/125 degrees per second is smaller than the timebase differences between the hardware stepgen and the servo thread
[23:45:40] <PCW> yes crazy ferror settings
[23:47:26] <PCW> of course random ferrors can cause ruined parts as well if set too tight
[23:47:57] <PCW> but 15 degrees is nuts
