Back
[00:09:31] <seb_kuzminsky> linuxcnc-build: force build --branch=master 0000.checkin
[00:09:32] <linuxcnc-build> build #3181 forced
[00:09:33] <linuxcnc-build> I'll give a shout when the build finishes
[00:59:12] <linuxcnc-build> Hey! build 0000.checkin #3181 is complete: Success [3build successful]
[00:59:12] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3181
[07:08:29] <skunkworks_> zlog
[10:22:03] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 c277688 06linuxcnc 10docs/src/remap/structure.txt docs: remove a stray tab in the middle of a word * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c277688
[10:32:12] <seb_kuzminsky> i think i know why task hangs at startup if there's an m61 in RS274NGC_STARTUP_CODE
[10:32:40] <seb_kuzminsky> task runs emcTaskPlanInit() at startup, which handles that ini variable:
[10:32:42] <seb_kuzminsky> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/task/emctask.cc;h=9156555185ced5fb2f1cc35001dcb946bd7b27d7;hb=refs/heads/2.6#l408
[10:33:20] <seb_kuzminsky> down on line 435 it feeds the startup codes to interp
[10:33:47] <seb_kuzminsky> if interp returns INTERP_EXECUTE_FINISH, i think that means it wants task to drain the interp queue, but task does not
[10:36:20] <seb_kuzminsky> so i think you can't do queue busters in RS274NGC_STARTUP_CODE currently
[10:36:22] <seb_kuzminsky> bbl
[10:38:06] <brlcad> seb_kuzminsky: was any progress made with the two students, discussing a half-project?
[10:38:26] <seb_kuzminsky> very slow progress
[10:38:47] <brlcad> one seems to be recoiling, didn't feel he was qualified to work on it (which I doubt)
[10:39:15] <brlcad> think it's more a matter of identifyingsimple incremental goals, not having grandios expectations :)
[10:39:26] <brlcad> (on both sides)
[10:39:27] <seb_kuzminsky> brlcad: cmorley1 has been helping guruwinder
[10:39:36] <seb_kuzminsky> lots of handholding, little forward progress
[10:39:42] <seb_kuzminsky> i got to run, back in about 2 hours
[10:39:48] <brlcad> right, I think he's the one recoiling?
[10:39:54] <brlcad> cmorley1: thoughts?
[10:39:56] <brlcad> cya seb_kuzminsky
[10:40:14] <cradek> it appeared to me that cmorley did more work explaining the project in simple detailed steps than he would have done by doing the improvement himself
[10:40:42] <cradek> and it sounds like that still wasn't enough
[10:41:26] <cradek> oh, I see he's here today, I shouldn't talk for him
[11:17:30] <pcw_home> Is there a generic way to defer a portion of hal command processing until say a particular hal pin is true?
[11:20:17] <cradek> pcw_home: not really. you'd have to poll it and then run a new halcmd
[11:22:42] <pcw_home> Oh well no "If ExtHardwareRunning { HALCMDS }" iguess
[11:29:32] <cradek> loadusr has the stuff where it waits for the component to become ready...
[11:29:36] <cradek> not sure if that could help
[11:35:50] <pcw_home> This would be for RT drivers, for example where Estop removes all control power
[11:35:51] <pcw_home> but uses hm2-eth (powered down at estop) and have the GUI start but be able to
[11:35:53] <pcw_home> say the remote hardware is not up (and gracefully enter,leave the Estop/no comms state)
[11:37:52] <pcw_home> maybe this is not a reasonable situation (but its a current customers setup)
[11:43:11] <mozmck> pcw_home: you can do a lot with haltcl
[11:43:42] <pcw_home> Yeah I keep meaning to try that out
[11:43:56] <mozmck> I'm working on doing something like that with our setup
[11:46:00] <seb_kuzminsky> we dont have examples, and it's not well tested, but i think you can also do some halcmd-like things from python
[11:46:32] <pcw_home> I wonder if hm2_eth should have the same thing as sserial ( a run pin )
[11:48:22] <pcw_home> ( that gets set false if comms are bolluxed and can be manually set false/true to bring the interface up/down )
[11:48:27] <cradek> it sounds like you have a component that calls hal_ready before it's ready. can you fix that?
[11:48:58] <cradek> I think you can take all the time you want at load time
[11:49:43] <cradek> although I don't know if you can ultimately fail
[11:49:54] <pcw_home> but doesn't that hang the rest of the startup?
[11:50:23] <mozmck> Here's a tcl sample that checks for a pin existence. As far as polling and then connecting pins later, I bet you could do that in python pretty easily.
[11:50:25] <mozmck> http://pastie.org/10223580
[11:51:05] <seb_kuzminsky> cradek: pcw_home is trying to solve a problem that happens after startup, if i understand
[11:51:25] <seb_kuzminsky> the user powers down the fpga during estop
[11:51:49] <seb_kuzminsky> pcw_home: how are things going with encoder dpll? that's the second-to-last blocker for 2.7.0
[11:51:56] <pcw_home> yes or at startup (start a partially operational system so you have GUI and status at least)
[11:52:08] <seb_kuzminsky> yeah
[11:52:29] <seb_kuzminsky> it's the same as the "power off the spindle-vfd at estop" problem that jmk and i were talking about earlier
[11:52:49] <pcw_home> Yep same type of issue
[11:53:09] <seb_kuzminsky> i think each driver just needs to handle comms outages gracefully, there's really no way around it
[11:53:37] <seb_kuzminsky> i have one of those usb jog dongles that disconnects every once in a while, same problem
[11:54:03] <pcw_home> mozmck: that looks like what I was thinking and maybe the way to deal with this issue
[11:55:20] <mozmck> pcw_home: That works for startup, but I don't know about afterwards.
[11:55:49] <mozmck> I plan to also add code to catch if a component does not start properly and give a user-friendly error message.
[11:56:01] <pcw_home> if the comms outage is at startup and you dont have any hardware pins yet, its more of dynamic hal modification issue
[11:56:03] <pcw_home> rather than a driver issue at least the way I'm thinking (which may be wrong)
[11:56:44] <mozmck> hm2_eth is one that I was going to check that way, because it could just not be powered on, but you get a full dump of un-readable error (to most users).
[11:57:12] <mozmck> I think hm2_eth should still load even if it can't talk to the board.
[11:57:24] <pcw_home> I though micges was going to work on the encoder dpll stuff but I guess he's too busy
[11:58:07] <mozmck> At least that's how I'm doing with our hardware, and when it can communicate then it sets a "connected" pin and starting working.
[11:58:35] <pcw_home> probably at this point it should just be deferred to the next release (if absolutely needed it can be done with raw-write)
[11:59:48] <pcw_home> Yeah hm2-eth could just ping the card before getting too deep in setup
[12:03:35] <seb_kuzminsky> if hm2_eth loads while the fpga is powererd down, you can't query the smart-serial daughters, right? so you dont know what pins to create, so you can't call hal_ready(), so you can't come out of estop
[12:04:31] <seb_kuzminsky> pcw_home: ok, i'll stop thinking of encoder dpll as a blocker, and release when the tp bug is fixed (#424)
[12:04:58] <seb_kuzminsky> if encoder dpll makes it in before, it's welcome in 2.7, if not, then lets talk about wheter it belongs in 2.7 or master (2.8)
[12:05:52] <pcw_home> probably 2.7 since its backwards compatible with non-DPLL configs
[12:06:15] <mozmck> You can put it in the release notes as a known bug :)
[12:06:25] <mozmck> I see that often enough.
[12:07:17] <pcw_home> I could duplicate the TP bug but only at lower accelerations than my test rig was set for
[12:10:15] <pcw_home> I think what was desired is this: start linuxcnc with hardware off/broken/whatever
[12:10:16] <pcw_home> and GUI comes up but of course wont come out of estop state and says why
[12:11:01] <mozmck> That's basically what I plan to do also
[12:12:57] <pcw_home> More friendly for appliance type usage
[12:24:58] <seb_kuzminsky> yeah, that sounds desirable
[12:25:08] <pcw_home> I did have to resort to trig but have convinced myself that for normal machines the chord errors
[12:25:10] <pcw_home> at a 1 KHz servo thread are not important and even 500 hz is ok for a lot of step/dir usage
[12:25:11] <pcw_home> meaning Preemt-RT and Ethernet should work for even pretty lousy Hosts
[12:25:33] <seb_kuzminsky> but i think we need all the comps to call hal_ready() before we start hal
[12:25:47] <seb_kuzminsky> all the non-user comps at least, no?
[12:26:01] <pcw_home> Yeah
[12:26:59] <mozmck> seb_kuzminsky: I'm still interested in helping with the next release to learn. Any other volunteers for release manager?
[12:27:06] <seb_kuzminsky> so that would require a fairly major restructuring of the hm2 driver system
[12:27:31] <seb_kuzminsky> mozmck: i assumed you were since you hadn't un-volunteered yourself ;-) i've heard of no one else who's stepped up
[12:27:50] <mozmck> ok :)
[12:28:38] <seb_kuzminsky> there's 2 bug fixes in 2.6 since 2.6.8, maybe that's worth another release
[12:29:14] <pcw_home> ( chord errors meaning max deviation of actual polygonal path cause by velocity only stepgen from arc )
[12:29:56] <seb_kuzminsky> hm, and several fixes in 2.7, maybe time for another prerelease there
[12:30:10] <seb_kuzminsky> i'd been hoping to make the next one 2.7.0, but it doesn't look like that's happening :-(
[12:30:22] <mozmck> do you find the fixes just looking at commit logs?
[12:30:28] <seb_kuzminsky> yeah
[12:30:42] <seb_kuzminsky> i just ran this: git log --oneline v2.6.8..origin/2.6
[12:31:12] <seb_kuzminsky> that's usually enough to jog my memory, then i take out the --oneline (and maybe add -p) to see more detail
[12:31:18] <mozmck> nice
[12:31:23] <seb_kuzminsky> or you can use a more interactive tool like tig or gitk
[12:31:50] <mozmck> I usually run gitg - easy command to remember and a nice graphical display.
[17:02:04] <JT-Shop> mozmck, having expanding collapsing menu that stays can't be done with a local copy
[17:02:31] <mozmck> JT-Shop: that's a bummer!
[17:03:14] <mozmck> pdf is still pretty nice.
[17:04:59] <JT-Shop> we can have expanding collapsing on the main html page
[17:05:40] <JT-Shop> and have unlimited links in the documents :)
[17:06:30] <seb_kuzminsky> links between the different parts of the docs is really nice to have
[17:07:12] <JT-Shop> yea get rid of all the " see xx document for more info" and just have a link
[17:07:35] <seb_kuzminsky> i've always liked how we have different documents for different audiences, but maybe the better links are worth more than that separation
[17:08:12] <JT-Shop> after a few years to me it seems that there is no difference between the user and builder 95% of the time
[17:08:40] <JT-Shop> only in places like commercial shops would there be user and integrator
[17:09:04] <seb_kuzminsky> there are a lot more cnc users than cnc builders in my local hackspace
[17:10:12] <Tom_itx> links are good until they're broke
[17:10:33] <seb_kuzminsky> the links in our docs are verified on every build now, and a broken link causes a build failure
[17:10:45] <Tom_itx> oh that's nice :)
[17:10:49] <seb_kuzminsky> (internal links only)
[17:10:55] <Tom_itx> right
[17:11:05] <Tom_itx> well they really shouldn't chnage
[17:11:10] <Tom_itx> * sp
[17:27:44] <JT-Shop> yea a hackerspace is like a shop and has mostly users, I was referring to the 59,000 posts on the forum and the millions of posts on the mailing list from builders who use the machines
[17:28:18] <seb_kuzminsky> i agree
[17:40:39] <JT-Shop> maybe 1 1/2 million on the mailing list, I lost count lol
[17:42:23] <cmorley1> bricad: I thought I had spelled out an easy starter feature. I haven't seen any code so can't say what's up good or bad. It's hard to say because i have been deep in linuxcnc for many years so one forgets how steep the learning curve is.
[19:16:53] <brlcad> cmorley: unless you have outstanding documentation and relevant examples, "most" students tend to have a pretty hard time getting acclimated
[19:18:14] <brlcad> cmorley: if you have a really simple (perhaps tediouisly time consuming) project they could work on, it might be better to get them started there and see how things go
[19:19:33] <brlcad> it could be something as simple as a code quality task like turning on a bunch of compiler warnings or running a static analyzer and fixing everything or writing unit tests to help verify expected behavior
[19:19:35] <cmorley> yes I understand. my only contact has been through the list - I am not aware of any particular problem - I think I answered all questions.
[19:19:59] <brlcad> I talked to the student a couple days ago and he sounded pretty defeated is why I mentino it
[19:20:44] <brlcad> yet I know he's capable given the work he's already done for us
[19:21:50] <brlcad> almost certainly just a lot of unfamilarity or too much detail to wade through under a pressured timeframe
[19:23:20] <cmorley> hmm I did get the idea he was making it more then it was. I was trying to help - I maintain the program he choose to work on. That was the simplest thing i could think of. I'm afraid i'm more of a hacker then a programmer :)
[19:24:46] <cmorley> meaning i hack things together...till it works
[19:24:53] <brlcad> :)
[19:25:26] <cmorley> i will see if I can contact him directly and help...
[19:25:41] <brlcad> okay thanks
[19:25:52] <brlcad> what about the testing idea?
[19:26:14] <brlcad> that's often a good way to get to know a code, test it, prove it works one way or the other
[19:32:22] <cmorley> you mean automated testing?
[19:37:31] <brlcad> sure, unit testing, regression testing, integration testing .. something worth automating to ensure behavior is actually correct, stays correct, or cooperates with something else
[19:38:39] <brlcad> I have to imagine unit testing would be important to a code that sits between the user and hardware
[19:41:55] <Tom_itx> what's the bare minimum ini / hal to test mesa io pins using a justio file?
[19:42:20] <Tom_itx> can it be an empty file with just the hostmot2 driver?
[19:57:23] <Tom_itx> nm i got it..
[20:10:50] <skunkworks> zlog
[20:58:54] <Tom_itx> pcw_home you around?
[21:00:26] <Gurwinder_> cmorley: Hi, want to discuss about GSoC and Linuxcnc
[21:00:53] <Gurwinder_> brlcad: Hi, want to discuss with you too.
[22:04:12] <brlcad> Gurwinder_: hi! what's up?
[22:04:47] <Gurwinder_> brlcad: Good
[22:04:53] <Gurwinder_> about you :P
[22:05:33] <Gurwinder_> I want to discuss about after mid term time period of GSoC
[22:14:02] <Gurwinder_> I figure out some more primitives of BRL-CAD which I can export if I am going with BRL-CAD for after mid-term time period.
[22:25:47] <brlcad> Gurwinder_: cmorley wanted to talk more about a potential project and I think that will be overall still worth pursuing if something is possible ... unless you're outright giving up, I think it'd be greatly worthwhile to find something collaborative that helps bridge our communities
[22:27:27] <brlcad> it is ultimately your decision as your proposal is what was accepted and you can stick to it if that's your desire, but this is an important consideration if a "half-project" can be envisioned
[22:44:03] <Gurwinder_> brlcad: Ok, I will take further decision after talking to cmorley
[22:44:59] <Gurwinder_> For ell export, I have drawn a ellipse. I type "l myellipsename"
[22:46:13] <Gurwinder_> I gaves, A rotation angle 90, B rotation angle 180, C rotation angle 0. Does it means these angle are along with x, y, z axis?
[22:47:09] <Gurwinder_> I want these rotation angles for ellipse to export ellipse for POV-Ray
[23:12:10] <brlcad> Gurwinder: lets take that line of questioning to #brlcad