Back
[07:50:06] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15terkaa commented on issue #210: Fixed tests for these 02
https://github.com/LinuxCNC/linuxcnc/pull/210#issuecomment-261244685
[07:54:39] <terkaa> Ok, tests rewritten. How to run Travis again?
[07:55:00] <jepler> terkaa: if you update the branch in the pull request, it should run again
[07:55:14] <jepler> in fact when I visit that page it shows "Some checks haven't completed yet"
[07:56:25] <terkaa> Yep just had to click "details" to see the run
[07:56:54] <jepler> thanks for sticking with it.
[07:57:03] <jepler> have you contributed to open source projects before?
[07:59:14] <terkaa> Qemu but it was 10 years ago
[07:59:47] <jepler> that's an important piece of software!
[08:08:20] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15terkaa commented on issue #210: Still fixed 2 failing tests... 02
https://github.com/LinuxCNC/linuxcnc/pull/210#issuecomment-261248531
[08:20:18] <terkaa> Hmmm... Running test: /home/travis/build/LinuxCNC/linuxcnc/tests/interp/compile
[08:20:18] <terkaa> *** /home/travis/build/LinuxCNC/linuxcnc/tests/interp/compile: FAIL: test run exited with 1
[08:20:40] <terkaa> Yes I did something to PPC portion
[08:21:55] <terkaa> brb
[08:38:38] <jepler> ah, why didn't we see that one before
[08:38:50] <jepler> you have changed the API/ABI of the interpreter by adding a parameter to that canon call
[08:39:27] <jepler> we don't really have a stability guarantee about the interpreter API so that's fine, but the source file in there will need to be updated
[08:39:34] <jepler> I wonder why we didn't pay attention to that one yesterday.
[09:15:31] <terkaa> Because there Was a lot of other issues..
[09:21:27] <terkaa> I will try to correct this.
[11:43:58] <terkaa> This seems to take care of it:
[11:44:00] <terkaa> https://github.com/terkaa/linuxcnc/commit/015e2aab318459f8bef6de43186896eb3ec190f4
[11:58:06] <terkaa> Ok now Travis says:
[11:58:08] <terkaa> The command "./scripts/travis-build-test.sh" exited with 0.
[12:00:50] <jepler> good!
[12:01:31] <terkaa> jthornon: You did want a message when this gets pulled for updating docs?
[12:02:00] <terkaa> jthornton: You did want a message when this gets pulled for updating docs?
[12:14:23] <terkaa> So what should I try to do next...
[12:17:35] <jepler> terkaa: it is better if the tests all pass at all of your commits. I would personally fix this by using "git rebase -i" to "squash" all of the commits into a single commit that changes the code and the tests at the same time. If you're tired of learning git, I'd be happy to do this for yo..
[12:18:04] <skunkworks> zlog
[12:18:43] <jepler> +u
[12:20:07] <jepler> afk
[12:22:15] <terkaa> jepler: I can take a break with git so feel free
[13:03:20] <jthornton> terkaa: sure, not sure what "this" is at the moment
[13:03:57] <terkaa> jthornton: G84/G74 floating tapping cycles
[13:05:10] <JT-Shop> ah ok
[13:05:29] <JT-Shop> I'm usually out in the shop during the day working
[13:07:28] <terkaa> JT-Shop: Ok.
[13:20:03] <terkaa> I did update g-code.txt and gcode.html
[13:24:10] <JT-Shop> ok thanks
[13:28:42] <jepler> I rebased and now I'm just running the tests one last time before pushing terkaa's contribution to master..
[13:37:48] <andypugh> Anyone know a) Why this chap is automatically trying to compile ndswrapper and b) How to avoid it?
https://forum.linuxcnc.org/9-installing-linuxcnc/29917-linux-mint-with-rtai?start=90#82915
[13:40:25] <cradek> is ndiswrapper a package you can uninstall?
[13:40:48] <cradek> dkms's design is to rebuild everything whenever a hat drops
[13:40:53] <jepler> on debian systems there is ndiswrapper-dkms and ndiswrapper-source
[13:41:12] <andypugh> That’s a thought. He has a working installation of mint, so he could try that
[13:42:19] <jepler> if ndiswrapper doesn't work, or if a particular network adapter doesn't work, user gets to keep all the pieces.
[13:44:18] <andypugh> I found (with google) a patch from 2014 where they replaced srandom wuth prandom
[13:49:57] <jepler> nobody here just knows the answer offhand for this guy, so *shrug*
[13:51:50] <jepler> but yeah the short answer is clearly "that kernel and that ndiswrapper don't work together"
[14:02:06] <terkaa> jepler: Did tests pass?
[14:03:41] <jepler> terkaa: whoops got distracted
[14:07:25] <KGB-linuxcnc> 03Tero Kaarlela 05master 42ff261 06linuxcnc 10(38 files in 14 dirs) Add G74/G84 floating tap cycles * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=42ff261
[14:08:58] <jepler> cradek: during push, it waited a long time and also printed
[14:08:58] <jepler> remote: Transport error: 500 read timeout
[14:08:58] <jepler> remote: Unable to relay message. All servers failed
[14:09:07] <jepler> was that trying to send the -commit list messages probably?
[14:12:05] <cradek> hm, or poking buildbot?
[14:25:42] <terkaa> Ok. Now I can compile current master on actual machine too
[14:26:38] <terkaa> Thank you for helping me to get this working and pushed to master
[14:29:57] <Tom_L> are those to compliment the G33.1 rigid tapping cycle?
[14:30:48] <Tom_L> G84 was listed but not implemented, G74 wasn't listed
[14:31:42] <jepler> terkaa: thank you for writing it. I hope many users benefit.,
[14:31:50] <Tom_L> yeah, thanks
[14:32:04] <jepler> terkaa: I hope we can look forward to more contributions from you.
[14:32:38] <terkaa> jepler: I have an idea but I am not sure how huge/hard it will be to implement
[14:33:04] <terkaa> I will inform few users who were intrested in having these
[14:33:27] <terkaa> Tom_L: These are for the ones who do not have encoder on spindle
[14:33:37] <Tom_L> right
[14:33:59] <Tom_L> requires a spring loaded tap holder?
[14:34:07] <terkaa> Yes
[14:34:59] <terkaa> Like this one
https://www.youtube.com/watch?v=WgO7TlWUDTI
[14:35:05] <terkaa> My first try outs
[14:35:47] <Tom_L> good stuff
[14:35:53] <jepler> does the spindle speed need to be fairly accurate to do this?
[14:36:13] <Tom_L> it needs to be close to the feed and pitch you want
[14:36:20] <Tom_L> or you'll run out of 'spring'
[14:36:40] <terkaa> Example: M03 S100 F125 is for M8 thread that has 1.25mm pitch
[14:36:44] <Tom_L> if anything the spindle should be ahead of the feed slightly
[14:37:08] <terkaa> That is correct
[14:37:11] <Tom_L> that would cause the tap to pull out from the holder slightly
[14:37:17] <Tom_L> as designed
[14:37:47] <terkaa> Basically Speed/feed has to match pitch
[14:43:10] <terkaa> I have been thinking if it would be possible to add "Machine Lock" function to LinuxCNC?
[14:45:44] <jepler> What is "Machine Lock"?
[14:46:01] <Tom_L> like a 2hand lockout
[14:46:08] <Tom_L> safety i presume
[14:46:47] <Tom_L> hands must be clear and on both buttons before machine will proceed
[14:49:06] <terkaa> Nope.
[14:49:52] <terkaa> If you have machine lock button on. You can run programs in simulation. Program is run but no actual movements happen
[14:50:53] <terkaa> It will take in account axis limits, Zero coordinates. So you can test programs before actually running those
[14:52:27] <terkaa> It would also be handy for "start from line no" feature. You could run program "Machine locked" until you get to line you want to start from
[14:52:28] <jepler> I don't know if it works anymore, but before AXIS it was common for the UIs to have this. It was called "Verify"
[14:53:01] <jepler> the button seems to still exist in tklinuxcnc
[14:53:11] <terkaa> Hmmm... I need to check this
[14:53:35] <terkaa> Start from line no does not work like it should
[14:53:38] <jepler> It may not be 100% the same as what you envision, but I believe it would give you a diagnostic if a soft limit would be exceeded.
[14:54:16] <jepler> yes, I know a lot of users are dissatisfied with how run from line works.
[14:54:18] <terkaa> That is something already. And I believe it would also report impossible arcs etc?
[14:54:30] <jepler> yes
[14:54:47] <terkaa> Ok. So it has checks I am after for.
[14:55:38] <terkaa> Do you know if verify goes thru tool changes, like start from line no? Or those are skipped?
[14:55:41] <bpuk> Evening all. I've merged the last G71 patch I've still got, running tests now to see if it breaks anything major ;)
[14:56:56] <jepler> thanks for working on it bpuk
[14:57:29] <bpuk> no problem - once I've confirmed it works as I remember I'll drop a pull request before I start tweaking things
[14:57:51] <jepler> terkaa: looks like the way validate works is by sengin an EMC_TASK_PLAN_RUN command with the line set to -1
[14:57:56] <bpuk> this patch should address at least some of cradek's comments
[14:59:31] <terkaa> Also there was an issue of incorrect DRO readings with "start from line no"
[15:00:11] <terkaa> I would like to try correcting at least these two issues
[15:01:04] <jepler> I'm unfamiliar with that problem. Is it that the DRO reflects a different coordinate system? I can see how that could result from the problems that we have around abort and run-from-line...
[15:02:01] <jepler> so maybe I am familiar with that problem but it wouldn't have occurred to me to call it an "incorrect DRO problem" even though that's just what a user might notice first
[15:02:52] <jepler> right now we are also trying to get a patch called "state tags" ready to be merged, it has to do with fixing the state the machine (task and interpreter) are in after abort; they can be inconsistent with each other and with the expectation of the operator.
[15:03:18] <jepler> I haven't been involved with that much. Out of people who are frequently on IRC, Seb and Cradek have been most involved I think.
[15:05:00] <terkaa> jepler: I did not pay enough attention on what cause incorrect reading. I know that program should of used G54. But I believe DRO was showing machine coordinates on display. Feeds and Speeds were ok and also actual movements
[15:05:49] <terkaa> I am running TKLinuxCNC in verify to see how it works
[15:17:50] <jepler> Tom_L: (a two handed "cycle start" button is probably not hard to do, you could do it in HAL or ladder or even just physically which is probably preferable)
[15:20:15] <bpuk> ok. The G71 patch is up to date on my local machine, I've clearly got a sign reversed somewhere in the code since it's overcutting. Will do the pull request when I've found the typo
[15:27:37] <terkaa> Ok I have to study these to see if this is already implemented but forgotten...
[15:31:13] <terkaa> later
[18:34:47] <andypugh> Would G71 go into Master or a feature branch? I am thinking that it _ought_ to be safe to have a not-100% G-code in there, it wouldn’t be the first time, after all.
[18:36:47] <cradek> it's already in a feature branch
[18:37:16] <cradek> I gave my opinion about when it should be merged on the devel list
[18:45:20] <jepler> didn't even need any force to bend the hinge the first time, the two parts are totally separate
[18:45:51] <jepler> the overhang of the latch is perfect, the closure works, holy cow
[18:53:52] <andypugh> OK, I read all the way back and I have no idea what the context is of the two things that jepler just said
[18:54:36] <cradek> he 3d printed a thing with a hinge on his new 3d printer and it worked
[18:54:56] <andypugh> Ah, right. I remain surprised that I don’t have a 3D printer.
[18:55:17] <cradek> he got a new inexpensive one and it works kinda ok out of the box
[19:24:10] <Tom_L> jepler, i agree... that was just the first thing that came to mind when he said "Machine Lock"
[19:25:35] <jepler> oh I said that in the wrong place
[19:26:00] <jepler> I was talking about this thing fwiw
http://www.thingiverse.com/thing:1692395
[19:27:40] <jepler> and this is the 3d printer
http://www.monoprice.com/product?p_id=15365
[19:27:41] <Tom_L> hanging out in reprap could affect your credibility =)
[19:28:47] <jepler> Tom_L: yeah I should have used a decoy nick
[19:29:02] <jepler> that's why I was *trying* to keep it on the QT
[20:24:28] <skunkworks> lm317 fixed the DRO on the edm
[20:24:58] <Tom_L> nice
[20:26:15] <skunkworks> now we need to come up with a dialetric sump