Back
[08:58:45] <skunkworks> This seems to work pretty good so far.
[08:58:47] <skunkworks> http://www.scorchworks.com/Fengrave/fengrave.html
[08:59:03] <skunkworks> I have used it for vcarving so far.
[08:59:58] <skunkworks> they make a comment about using it as an input filter in linuxcnc
[09:05:00] <mozmck> thanks for the link - one more thing I'll have to try someday
[09:16:19] <mozmck> seb_kuzminsky: any thoughts on putting this as a bugfix in 2.7?
https://github.com/mozmck/linuxcnc-mirror/commit/8cec4d3ec3fa51e7691e7f639ddd942ec4736451
[09:30:22] <skunkworks> http://electronicsam.com/images/house/freinds.JPG
[09:30:44] <skunkworks> that was just a black/white logo
[09:31:46] <mozmck> nice! The text is raised?
[09:32:15] <skunkworks> no - cut with a 60deg cutter
[09:32:45] <mozmck> I guess it's an optical illusion - sure looks like it's raised and the background is sunken
[09:33:15] <skunkworks> Heh - I can see that
[09:43:18] <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
[10:08:37] <seb_kuzminsky> thanks dgarr!
[10:09:41] <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/)
[10:09:45] <seb_kuzminsky> mozmck: looking...
[10:21:57] <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
[10:22:01] <seb_kuzminsky> https://github.com/LinuxCNC/linuxcnc/tree/seb/2.6/statbuffer-g5x-abort
[10:22:29] <seb_kuzminsky> so your patch looks mostly good to me
[10:22:54] <seb_kuzminsky> you cleanly added a new field to the stat buffer, that's obviously useful to the UIs above Task
[10:23:06] <seb_kuzminsky> my only question/suggestion is:
[10:23:59] <seb_kuzminsky> are you sure you don't want to move the setting of task.callLevel=0 into emcTaskAbort()?
[10:25:15] <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
[10:25:30] <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
[10:25:30] <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
[10:26:36] <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
[10:28:09] <seb_kuzminsky> skunkworks: that sign looks great
[10:28:38] <skunkworks> seb_kuzminsky, thanks! first time 'v-carving'
[10:30:00] <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
[10:30:10] <seb_kuzminsky> that's really interesting
[10:30:26] <cradek> sure is
[10:30:55] <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
[10:31:10] <cradek> I would have used that instead of scanlines for
http://timeguy.com/cradek/01408982148
[10:31:11] <seb_kuzminsky> wow, the fengrave website is full of awesome-looking results
[10:31:25] <seb_kuzminsky> oh, yeah
[10:31:34] <mozmck> seb_kuzminsky: thanks for the comments!
[10:31:40] <seb_kuzminsky> well the scanlines came out looking pretty good too
[10:31:56] <seb_kuzminsky> i wonder if v-carving would be faster? less rasterization for sure
[10:32:08] <cradek> yeah, especially after she poked it with a sharpie to darken the inside parts
[10:32:47] <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
[10:33:37] <mozmck> My method was simply to set task.callLevel wherever task.currentLine got set, but that may not be the best.
[10:36:41] <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
[10:38:15] <cradek> wow.
[10:38:56] <mozmck> I used doxygen to generate those - pretty neat - and somewhat helpful.
[10:39:23] <cradek> I'm surprised to hear it was helpful
[10:39:52] <skunkworks> it was much much faster than engraving
[10:40:26] <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.
[10:40:46] <cradek> oh I see - not this one in particular
[10:41:12] <mozmck> Yeah, I did the whole source tree.
[10:42:11] <mozmck> Doxygen comments could be useful to add. Code comments that are there already could be given doxygen tags.
[10:43:53] <skunkworks> the rotozip finally died.. I guess we used it quite a bit. (circuit board making and such)
[10:44:04] <skunkworks> the brushes where 1/6"
[10:44:08] <skunkworks> 1/16"
[10:44:13] <skunkworks> left
[10:44:57] <skunkworks> put a router back in. (the runout on the router was too much for circuit board making - why we were using the rotozip...)
[10:48:14] <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
[10:49:40] <skunkworks> so you could have just bought them?
[10:50:20] <cradek> hmmmmm ebay.com/itm/281902543081
[10:50:21] <skunkworks> ;)
[10:50:48] <cradek> bet these are not particularly great...
[10:51:48] <cradek> also I'm nervous that they don't say what the pitch is
[10:52:11] <cradek> eh it's just $16
[10:54:31] <skunkworks> love all the pictures
[10:55:16] <cradek> yes, very useful
[10:57:50] <skunkworks> Get off my lawn!!
[10:57:58] <skunkworks> (sorry - gene again)
[11:07:05] <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
[11:07:24] <seb_kuzminsky> if it'd be help to others i'd welcome it
[11:08:08] <seb_kuzminsky> on the topic of callLevel, setting it wherever currentLine gets set seems like a reasonable way to do it
[11:08:41] <seb_kuzminsky> i wonder if currentLine has stale data if you take another Abort path through Task
[11:09:02] <seb_kuzminsky> i bet it'd be easy to change the statbuffer-g5x-abort test to test that
[11:11:41] <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?
[11:15:08] <seb_kuzminsky> if so we have 2 bugs! ;-)
[11:17:38] <mozmck> heh!
[11:18:41] <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
[11:19:25] <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.
[11:19:46] <seb_kuzminsky> with vim & cscope it's pretty quick ;-)
[11:20:33] <mozmck> seb_kuzminsky: true, unless someone decides to implement the resume mentioned in the comment in emcTaskAbout()
[11:20:54] <mozmck> well, vim & cscope may be fast once you learn them well :-)
[11:21:19] <seb_kuzminsky> i'll channel jepler and say "step 1: have 20 years of experience"
[11:21:38] <mozmck> I use eclipse, and it is fast, but for simply learning the code, something like doxygen can really help if done well.
[11:22:42] <seb_kuzminsky> yay for different tools for different people
[11:23:05] <seb_kuzminsky> oh hey speaking of jepler:
[11:23:06] <seb_kuzminsky> adaed5af (Jeff Epler 2007-06-24 15:05:18 +0000 199) // without emcTaskPlanClose(), a new run command resumes at
[11:23:09] <seb_kuzminsky> adaed5af (Jeff Epler 2007-06-24 15:05:18 +0000 200) // aborted line-- feature that may be considered later
[11:23:33] <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.
[11:24:05] <seb_kuzminsky> that's a good power to have
[11:39:49] <seb_kuzminsky> oh, mozmck, also dont forget to sign off your commit
[11:40:01] <mozmck> oops, thanks for the reminder
[11:40:08] <seb_kuzminsky> and if you send me a link to a branch instead of a commit on github, i can pull it more easily
[11:41:25] <mozmck> I can push to glo, but I figured I ask for comments first
[11:41:32] <mozmck> can it go on 2.7?
[11:42:01] <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
[11:42:33] <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
[11:42:53] <mozmck> Oh, I see. It looks like there is a link right under the commit message to the branch
[11:43:20] <mozmck> I'm just adding one line emcStatus->task.callLevel = 0; so I don't *think* I'll mess that up!
[11:47:04] <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.
[11:47:18] <mozmck> seb_kuzminsky: here's the update:
https://github.com/mozmck/linuxcnc-mirror/commits/mozmck-2.7
[12:08:50] <seb_kuzminsky> thanks!
[12:09:53] <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
[12:10:53] <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
[12:11:26] <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)
[12:15:34] <mozmck> Hmm, that makes sense - I'll look at that some more.
[12:23:29] <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.
[12:24:15] <mozmck> There really could be some cleanup in several places there in task - I will probably do that on master.
[12:31:54] <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
[12:36:23] <seb_kuzminsky> that looks great mozmck
[12:36:33] <mozmck> thanks
[12:37:32] <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?
[12:37:53] <seb_kuzminsky> nah, they're nitpicks, fix if it's easy and ignore if not ;-)
[12:38:05] <mozmck> ok :-)
[12:38:30] <mozmck> I'll try and do some documentation, but other than that, are there any objections to pushing it to master?
[12:39:06] <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
[12:40:52] <seb_kuzminsky> mozmck: i haven't read that one as carefully yet
[12:40:56] <seb_kuzminsky> what is a skipp arse?
[12:41:52] <seb_kuzminsky> i'd suggest squashing those two commits together, since the first one isn't useful on its own right?
[12:42:15] <seb_kuzminsky> that would make reviewand future debugging easier
[12:43:04] <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.
[12:43:37] <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
[12:44:12] <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
[12:44:27] <seb_kuzminsky> am i missing anything? is there state that shouldn't be restored on Abort?
[12:46:30] <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.
[12:46:55] <mozmck> yes, squashing the two commits would be best I'm sure.
[12:47:02] <seb_kuzminsky> ;-)
[12:47:49] <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
[12:48:14] <mozmck> I don't know of state that should not be restored on abort offhand, but I'm a bit green :-)
[12:51:07] <mozmck> where is M3/M30 handled?
[12:51:29] <seb_kuzminsky> interp_convert.cc
[12:51:30] <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
[12:51:30] <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
[12:51:30] <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
[12:51:33] <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
[12:51:37] <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
[12:51:41] <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
[12:51:46] <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
[12:51:51] <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
[12:51:54] <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
[12:51:59] <seb_kuzminsky> mozmck: convert_stop()
[12:52:08] <mozmck> thanks
[12:52:28] <seb_kuzminsky> there's my un-cleaned-up stream-of-consciousness work-in-progress statbuffer-abort branch
[12:52:42] <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>
[12:53:02] <seb_kuzminsky> just airing my dirty laundry
[12:53:23] <seb_kuzminsky> BBL
[13:07:32] <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>
[13:11:33] <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>
[13:12:31] <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>
[13:14:21] <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>
[13:17:33] <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>
[13:18:06] <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>
[13:31:13] <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>
[13:34:59] <cradek> seb_kuzminsky: I don't believe jepler wrote those comments. I think they are as old as the dinosaurs.
[13:37:56] <cradek> heh yeah - he removed that from one file and put it into two other files
[13:44:31] <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>
[13:45:09] <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>
[13:49:14] <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>
[13:49:28] <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>
[13:52:23] <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>
[14:28:29] <seb_kuzminsky> sb end
[14:28:44] <seb_kuzminsky> oops
[14:50:05] <skunkworks> steve steve steve....
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/150818
[14:50:10] <skunkworks> :)
[14:50:36] <skunkworks> treading requires windows 10... ;)
[14:50:42] <skunkworks> threading
[14:51:33] <seb_kuzminsky> i'd like to get programs like f-engrave into the hands of more linuxcnc users, to strengthen the ecosystem
[14:51:47] <seb_kuzminsky> skunkworks: did you run it on linux or windows?
[14:52:35] <skunkworks> I am running it on linux
[14:52:41] <seb_kuzminsky> cool
[14:53:08] <skunkworks> I had to install the 2 extra things he talks about in the install directions
[14:53:14] <seb_kuzminsky> right
[14:53:26] <skunkworks> one was an apt-get install and the other was a make install
[14:53:46] <seb_kuzminsky> the make install was TTF2CXF_STREAM, in his zip file?
[14:53:53] <seb_kuzminsky> his(?)
[14:53:58] <skunkworks> I 'think' jepler had brief contact with this guy - on the mailing list maybe?
[14:54:01] <skunkworks> yes
[14:54:13] <seb_kuzminsky> i should sometimes read my email, i might learn things
[14:55:25] <skunkworks> The potrace was an apt-get install - I didn't find the libpotrace - but it didn't seem to keep it from working
[14:55:40] <skunkworks> I assume it was installed with the apt-get
[14:55:45] <skunkworks> this is on debian jessie
[14:55:54] <seb_kuzminsky> jessie ftw
[14:56:12] <seb_kuzminsky> potrace.deb pulls in libpotrace0
[15:00:15] <skunkworks> Jessie has been great
[15:00:17] <skunkworks> no issues
[15:00:28] <skunkworks> I am running rt 4.4.9
[15:01:16] <skunkworks> I wish a working rtai kernal was available.
[15:01:23] <seb_kuzminsky> me too
[15:01:32] <skunkworks> another project. :)
[15:01:39] <seb_kuzminsky> i'm bummed the 5.0-test1 rtai kernels failed so badly in the buildbot VMs
[15:01:58] <seb_kuzminsky> i never ran into any trouble on baremetal (but i didn't run it that much)
[15:02:34] <seb_kuzminsky> and rtai.org removed support for the 3.16 kernel i was targetting :-(
[15:06:21] <skunkworks> why? old?
[15:06:28] * skunkworks doesn't know his kernels
[15:11:54] <seb_kuzminsky> i dont know why they removed the patch for that kernel
[15:18:24] <CaptHindsight> the mysteries of Paulo
[15:19:00] <CaptHindsight> memleak has 3.16 on his RTAI tree if you want support
[15:20:32] <CaptHindsight> https://github.com/NTULINUX/RTAI
[15:20:58] <CaptHindsight> https://github.com/NTULINUX/RTAI/tree/master/base/arch/x86/patches
[15:26:49] <skunkworks> pcw_home,
[15:26:51] <skunkworks> http://www.cnczone.com/forums/tormach-personal-cnc-mill/309278-pcnc770-4th-axis-clear-path-servo-pathpilot.html
[15:27:16] <skunkworks> seems like the stepgen is falling behind.
[15:27:49] <skunkworks> maybe pathpilot doesn't show an error if the stepgen settings are not achievable?
[15:32:03] <cradek> well you'd get ferrors, right?
[15:34:57] <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>
[15:35:15] <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>
[15:38:59] <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>
[15:45:38] <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>
[15:50:56] <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>
[15:52:00] <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>
[15:56:10] <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>
[16:00:52] <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>
[16:01:06] <cradek> that doesn't look like a stepgen problem
[16:01:51] <cradek> but he has an ferror limit of 15 degrees
[16:04:06] <cradek> fwiw, some random master build I tested works fine
[16:06:54] <cradek> I don't even know whether his display shows feedback or command
[16:07:06] <cradek> think he's going to have to ask his pathpilot vendor for help...
[16:07:40] <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>
[16:10:06] <cradek> also I wonder if his stepgen is in velocity mode
[16:11:06] <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.
[16:11:22] <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>
[16:12:24] <cradek> wonder what the rest of the pid values are (the ones not coming from the ini)
[16:12:41] <cradek> wonder if they left halscope in their distribution
[16:12:46] * cradek shrugs
[16:13:54] <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>
[16:13:55] <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>
[17:53:56] <seb_kuzminsky> debian packaging for f-engrave:
https://github.com/SebKuzminsky/f-engrave
[17:54:17] <PCW> cradek: Pretty sure its because of the small max_error value (a scaling issue with rotary axis)
[17:54:28] <seb_kuzminsky> it'd be easy to add to the same build system that builds mesaflash etc, and publish on wlo
[17:54:53] <PCW> f-engrave looks really nice
[17:55:57] <seb_kuzminsky> yeah
[17:56:06] <seb_kuzminsky> here's a pre-built deb for jessie/amd64:
http://highlab.com/~seb/linuxcnc/f-engrave_1.58-1_amd64.deb
[19:06:10] <cradek> PCW: what's MAX_ERROR?
[19:06:44] <PCW> the PID loops maximum error bound
[19:07:30] <cradek> oh you think it hooks to pid.N.maxerror?
[19:07:37] <PCW> yes
[19:07:41] <cradek> and it was set to 0? that would disable the P gain
[19:07:54] <PCW> no 0 means no bound
[19:07:55] <cradek> (if I'm reading the manpage right)
[19:08:04] <cradek> oh
[19:08:15] <cradek> then I don't see how that would change it? what am I missing?
[19:08:47] <PCW> it was set to .0005 as an attempt to reduce the effect of latency spikes on the high gain PID loop
[19:09:19] <cradek> oh I see it now
[19:09:29] <cradek> I misremembered it as 0, but that's MAX_OUTPUT
[19:09:33] <PCW> .0005 inches words pretty well .0005 degrees not so well
[19:09:39] <cradek> yeah, bet so
[19:09:54] <PCW> its a scaling issue
[19:10:11] <cradek> yeah degrees are a lot "smaller" than inches
[19:10:57] <cradek> so if he had a reasonable ferror limit, he *would* have seen ferrors
[19:11:30] <cradek> it's better if misconfiguration causes ferrors than ruined parts
[19:11:49] <PCW> their .0005/125 degrees per second is smaller than the timebase differences between the hardware stepgen and the servo thread
[19:12:08] <PCW> yes crazy ferror settings
[19:13:54] <PCW> of course random ferrors can cause ruined parts as well if set too tight
[19:14:26] <PCW> but 15 degrees is nuts
[21:15:04] <skunkworks_> zlog
[21:33:39] <skunkworks_> seb_kuzminsky, awesome!
[21:48:12] <cradek> wow, that IS awesome
[21:48:43] <cradek> if it eventually ends up on the CNC menu on all our (future) installs that would be the greatest thing
[21:49:40] <cradek> hm, github doesn't want to load for me tonight
[21:50:49] <skunkworks_> cradek, it can be used as an input filter in axis
[21:50:58] <skunkworks_> (I have not tried it yet)
[21:51:06] <cradek> sweet
