Back
[00:00:00] -!- adb has quit [Ping timeout: 252 seconds]
[00:00:03] -!- Jymmm has quit [Read error: Connection reset by peer]
[00:00:05] -!- JT-Shop [JT-Shop!~john@184.21.239.59] has joined #linuxcnc-devel
[00:09:30] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.91.1 [Firefox 34.0.5/20141126041045]]
[00:14:40] -!- sumpfralle has quit [Ping timeout: 272 seconds]
[00:14:55] -!- MrHindsight has quit [Ping timeout: 265 seconds]
[00:15:00] -!- Roguish has quit [Quit: ChatZilla 0.9.91.1 [Firefox 36.0.1/20150305021524]]
[00:16:39] -!- kwallace_shop [kwallace_shop!~kwallace@smb-235.sonnet.com] has parted #linuxcnc-devel
[00:17:54] -!- MrHindsight [MrHindsight!~not_sure@adsl-75-57-146-72.dsl.emhril.sbcglobal.net] has joined #linuxcnc-devel
[00:17:54] -!- MrHindsight has quit [Changing host]
[00:17:54] -!- MrHindsight [MrHindsight!~not_sure@unaffiliated/capthindsight] has joined #linuxcnc-devel
[00:25:36] -!- swingley has quit [Remote host closed the connection]
[00:52:19] -!- TTN has quit [Ping timeout: 245 seconds]
[01:01:55] -!- mhaberler has quit [Quit: mhaberler]
[01:02:40] -!- Brunetty has quit [Ping timeout: 255 seconds]
[01:02:47] -!- ibaca has quit [Ping timeout: 245 seconds]
[01:05:05] -!- anth0ny_ has quit [Quit: anth0ny_]
[01:06:02] -!- anth0ny_ has quit [Client Quit]
[01:11:00] -!- anth0ny_ has quit [Client Quit]
[01:27:25] -!- swingley has quit [Ping timeout: 265 seconds]
[01:32:26] -!- Loetmichel has quit [Ping timeout: 246 seconds]
[01:38:40] -!- ibaca has quit [Ping timeout: 264 seconds]
[01:44:28] <kwallace> I have a routine that does a fast rough probe, backs off a little, then a slow fine probe. It looks like the fine probe stops right at the trigger point and cycles the signal and sometimes produces and error.
http://wallacecompany.com/tmp/Screenshot-probe_bounce-1a.png
[01:45:52] -!- Brunetty has quit [Ping timeout: 255 seconds]
[01:46:22] <kwallace> I'm thinking a hal one-shot could be used to hold the signal stable long enough to process the trigger on the first edge, then go on to the retract move.
[01:47:06] <kwallace> Has anyone tried to solve this problem already?
[01:48:12] <kwallace> By the way, the above screenshot did not produce an error, but some do.
[01:52:23] -!- skunkworks [skunkworks!~chatzilla@69.4.98.27] has joined #linuxcnc-devel
[01:54:50] <kwallace> Another thing that comes to mind, it might be nice to have a parameter to adjust how far the probe travels after a trigger event to ensure the new state is stable.
[02:00:03] <cradek> kwallace: my real renishaw has a time constant of several ms and the opto22 input module may add a couple more. definitely the problem is solved before - but in hardware
[02:01:40] <cradek> kwallace: you know the probe is read every ms (or whatever your servo cycle is), so seems like you "just" need to know how far your probe has to move to be sure it's triggered to select the appropriate slow feed rate
[02:02:28] <cradek> if the probe has .004" of noise in it, you should be moving .010/ms and not .001/ms
[02:03:25] -!- asdfasd has quit [Ping timeout: 255 seconds]
[02:10:05] -!- rob_h has quit [Ping timeout: 255 seconds]
[02:13:57] <cradek> yeah renishaw MP7 "enhanced trigger circuit" nominal 7 milliseconds
[02:25:55] -!- KimK_laptop has quit [Remote host closed the connection]
[02:27:47] -!- swingley has quit [Ping timeout: 245 seconds]
[02:45:39] -!- arloG has quit [Quit: Leaving]
[02:53:40] -!- FreezingCold has quit [Ping timeout: 264 seconds]
[03:04:24] -!- fablab has quit [Ping timeout: 272 seconds]
[03:05:31] -!- FreezingAlt has quit [Ping timeout: 255 seconds]
[03:08:44] -!- AR_ has quit [Ping timeout: 246 seconds]
[03:12:58] -!- patrickarlt has quit [Quit: Leaving...]
[03:18:27] -!- Valen has quit [Remote host closed the connection]
[03:18:46] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[03:28:38] -!- swingley has quit [Ping timeout: 252 seconds]
[03:34:19] -!- Brunetty has quit [Ping timeout: 255 seconds]
[03:34:28] -!- ibaca has quit [Ping timeout: 264 seconds]
[03:40:36] -!- Brunetty has quit [Read error: Connection reset by peer]
[03:44:57] -!- adam3999 [adam3999!~adam3999@pool-108-38-17-37.lsanca.fios.verizon.net] has joined #linuxcnc-devel
[03:53:41] <memfrob> Ah i was able to narrow down the kernel crashes to rtai
[03:54:08] <memfrob> not caused by how linuxcnc handles the new ipipe code which is nice
[03:54:52] <memfrob> jepler: nice to see you again!
[03:55:26] <memfrob> i've been absent from rtai and linuxcnc for months and just a few days ago I started getting back into it again
[04:01:24] -!- jvrousseau has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[04:03:34] -!- sumpfralle has quit [Ping timeout: 245 seconds]
[04:07:47] -!- tjtr33 has quit [Ping timeout: 245 seconds]
[04:26:44] -!- swingley has quit [Ping timeout: 246 seconds]
[04:26:47] -!- ve7it has quit [Remote host closed the connection]
[04:56:15] -!- anth0ny_ has quit [Quit: anth0ny_]
[04:56:20] -!- johtso has quit [Quit: Connection closed for inactivity]
[05:17:54] -!- furrywolf has quit [Read error: Connection reset by peer]
[05:28:28] -!- swingley has quit [Ping timeout: 264 seconds]
[05:37:02] -!- karavanjo has quit [Ping timeout: 272 seconds]
[05:42:21] -!- veek has quit [Ping timeout: 272 seconds]
[05:51:12] -!- steve_stallings has quit [Ping timeout: 256 seconds]
[06:06:13] <kwallace> cradek, thank you for your reply, sorry I got called away. I won't be able to fiddle with the hardware, unless I can find a compelling reason. I'll play with the one-shot to see if that helps.
[06:14:52] -!- kwallace [kwallace!~kwallace@smb-235.sonnet.com] has parted #linuxcnc-devel
[06:28:22] -!- swingley has quit [Ping timeout: 240 seconds]
[06:47:31] -!- XXCoder1 has quit [Ping timeout: 250 seconds]
[06:56:02] <archivist> !later kwallace I got a Renishaw manual the other day, they have a couple of settings for the switch noise, a standard of 0ms and 6.9ms filtered for probe vibration(as they call it), you have to know the delay because that means a position offset
[06:56:02] <the_wench> will tell kwallace when he/she joins next
[06:57:03] -!- adam3999 has quit [Ping timeout: 265 seconds]
[06:59:14] <archivist> !later kwallace a software one is built in
http://linuxcnc.org/docs/html/man/man9/debounce.9.html
[06:59:14] <the_wench> will tell kwallace when he/she joins next
[07:04:14] -!- moorbo has quit [Remote host closed the connection]
[07:18:30] -!- Tecan has quit [Changing host]
[07:19:06] -!- TTN has quit [Remote host closed the connection]
[07:24:59] -!- Praesmeodymium has quit [Ping timeout: 252 seconds]
[07:29:10] -!- swingley has quit [Ping timeout: 252 seconds]
[07:37:22] -!- nerdfiles has quit [Ping timeout: 272 seconds]
[07:48:20] -!- Brunetty has quit [Quit: Follow me]
[08:02:47] -!- tjb1 has quit [Ping timeout: 265 seconds]
[08:30:25] -!- swingley has quit [Ping timeout: 264 seconds]
[08:38:22] -!- nerdfiles has quit [Ping timeout: 256 seconds]
[08:43:28] -!- karavanjo has quit [Ping timeout: 255 seconds]
[08:58:19] -!- rob_h [rob_h!~robh@90.212.252.1] has joined #linuxcnc-devel
[08:59:42] -!- karavanjo has quit [Ping timeout: 272 seconds]
[09:06:40] -!- koo6 has quit [Ping timeout: 272 seconds]
[09:07:05] -!- karavanjo has quit [Ping timeout: 246 seconds]
[09:16:23] amnesic_away is now known as amnesic
[09:28:11] -!- karavanjo has quit [Ping timeout: 252 seconds]
[09:30:53] -!- swingley has quit [Ping timeout: 250 seconds]
[09:39:07] -!- nerdfiles has quit [Ping timeout: 250 seconds]
[09:48:25] -!- nerdfiles has quit [Ping timeout: 264 seconds]
[09:49:21] -!- pingufan has quit [Quit: Konversation terminated!]
[10:03:02] -!- karavanjo1 has quit [Ping timeout: 272 seconds]
[10:05:22] -!- [cube] has quit [Ping timeout: 240 seconds]
[10:17:19] -!- karavanjo has quit [Ping timeout: 252 seconds]
[10:31:42] -!- swingley has quit [Ping timeout: 256 seconds]
[10:39:25] -!- skunkworks has quit [Ping timeout: 264 seconds]
[10:48:59] -!- nerdfiles has quit [Ping timeout: 246 seconds]
[10:55:48] -!- karavanjo has quit [Ping timeout: 244 seconds]
[10:57:21] -!- karavanjo1 has quit [Ping timeout: 244 seconds]
[11:11:18] -!- karavanjo has quit [Ping timeout: 244 seconds]
[11:12:46] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:20:14] -!- TTN has quit [Quit: see ya : )]
[11:28:06] amnesic is now known as amnesic_away
[11:32:23] -!- swingley has quit [Ping timeout: 246 seconds]
[11:50:13] -!- nerdfiles has quit [Ping timeout: 264 seconds]
[11:51:34] -!- steves_logging [steves_logging!~Steve@wsip-70-182-2-252.dc.dc.cox.net] has joined #linuxcnc-devel
[12:00:15] amnesic_away is now known as amnesic
[12:03:05] -!- syyl_ has quit [Ping timeout: 256 seconds]
[12:10:20] -!- karavanjo has quit [Ping timeout: 272 seconds]
[12:11:35] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[12:18:08] amnesic is now known as amnesic_away
[12:26:48] -!- Akex [Akex!uid58281@gateway/web/irccloud.com/x-ujdmqdwzncjkepiw] has joined #linuxcnc-devel
[12:32:56] -!- swingley has quit [Ping timeout: 246 seconds]
[12:50:47] -!- nerdfiles has quit [Ping timeout: 246 seconds]
[12:56:52] -!- anth0ny_ has quit [Quit: anth0ny_]
[13:16:17] -!- Nick001 has quit [Ping timeout: 246 seconds]
[13:28:53] -!- karavanjo has quit [Ping timeout: 246 seconds]
[13:29:15] <cradek> archivist: I think selecting the right speed for probing might be the best fix. adding 10ms of debounce and then probing 1/10th the correct speed doesn't gain you anything but slowness does it?
[13:29:30] <cradek> where "correct" is the speed I described earlier
[13:30:06] <archivist> he is doing a fine second move
[13:30:20] <cradek> yeah
[13:30:24] <cradek> maybe wayyy too slowly
[13:31:05] <archivist> interesting that renishaw call it a vibration delay rather than debounce
[13:31:56] <cradek> theirs are so sensitive that I bet just moving the probe around would trigger it
[13:32:11] <skunkworks> on shuttles of the k&t sometimes the probe will trigger...
[13:32:12] <cradek> if you touch it, it triggers, but you don't feel any motion
[13:32:32] <archivist> manual I have is for the arm mounted one they use for lathe tool setting
[13:33:02] <archivist> TSA universal motorised arm
[13:33:08] <cradek> I bet if attached to a nonmoving part of a lathe you'd get a lot less trouble
[13:33:14] <archivist> I want one!
[13:33:22] <cradek> yeah wouldn't that be great
[13:33:49] <cradek> I tried to buy one on ebay but their stuff is made up of so many different parts
[13:33:52] -!- swingley has quit [Ping timeout: 264 seconds]
[13:34:01] <cradek> who knows what even goes together
[13:34:50] <archivist> when I went to collect the manuals, the seller had an empty renishaw box
[13:45:15] -!- b_b has quit [Changing host]
[13:52:10] -!- nerdfiles has quit [Ping timeout: 255 seconds]
[14:03:53] -!- balestrino has quit [Ping timeout: 246 seconds]
[14:29:42] -!- nerdfiles has quit [Ping timeout: 244 seconds]
[14:37:08] -!- kwallace [kwallace!~kwallace@smb-154.sonnet.com] has joined #linuxcnc-devel
[14:37:09] <the_wench> kwallace: archivist said I got a Renishaw manual the other day, they have a couple of settings for the switch noise, a standard of 0ms and 6.9ms filtered for probe vibration(as they call it), you have to know the delay because that means a position offset
[14:37:10] <the_wench> kwallace: archivist said a software one is built in
http://linuxcnc.org/docs/html/man/man9/debounce.9.html
[14:37:44] -!- skunkworks_ [skunkworks_!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[14:39:54] <kwallace> the_wench, thank you for the information.
[14:40:22] -!- swingley has quit [Remote host closed the connection]
[14:50:40] amnesic_away is now known as amnesic
[14:58:04] -!- kwallace3 [kwallace3!~kwallace@smb-125.sonnet.com] has joined #linuxcnc-devel
[14:59:53] -!- kwallace has quit [Ping timeout: 246 seconds]
[15:04:27] amnesic is now known as amnesic_away
[15:13:04] -!- swingley has quit [Read error: Connection reset by peer]
[15:14:38] -!- swingley_ has quit [Read error: Connection reset by peer]
[15:18:10] <cradek> kwallace3: we talked about your question quite a bit while you were gone
[15:20:41] -!- skunkworks_ has quit [Ping timeout: 265 seconds]
[15:21:18] -!- pingufan has quit [Quit: Konversation terminated!]
[15:25:31] -!- yauh has quit [Quit: yauh]
[15:31:46] <kwallace3> Is the_wench a person?
[15:37:29] <cradek> kwallace3: no, it's a bot
[15:41:41] <archivist> kwallace3, !later nickname message is what I did, it records it and watches for your return
[15:42:02] -!- ketul [ketul!7c7d4564@gateway/web/freenode/ip.124.125.69.100] has joined #linuxcnc-devel
[15:42:41] <kwallace3> Oops, I responded to a bot.
[15:42:57] <cradek> you are the first one to do that ever
[15:44:49] <the_wench> I am flattered though :)
[15:54:35] -!- icetan has quit [Quit: WeeChat 0.4.2]
[15:57:04] -!- dan2k3k4 has quit [Ping timeout: 272 seconds]
[16:03:29] -!- icetan has quit [Client Quit]
[16:03:53] -!- dr0w has quit [Remote host closed the connection]
[16:08:59] -!- Akex has quit [Quit: Connection closed for inactivity]
[16:25:00] <mozmck> cmorley: (or anyone else that wants to check it out), see what you think of this patch to add rapid override support to gscreen:
http://pastebin.com/uGJLjyn3
[16:25:35] -!- moorbo has quit [Remote host closed the connection]
[16:25:46] <mozmck> I did not change the default gscreen GUI to add it, but did try it on the custom one I'm working on and it seems to work.
[16:27:08] -!- quiqua has quit [Quit: quiqua]
[16:29:28] -!- SpeedEvil has quit [Read error: Connection reset by peer]
[16:30:26] <cradek> I don't think RO of 2.0 will ever do anything
[16:30:45] <skunkworks> screenshot!
[16:30:51] <cradek> should the range be 0..1?
[16:35:45] <mozmck> hmm, I thought the override is the same as the one in Axis? Let me check again...
[16:36:14] -!- amiri has quit [Read error: Connection reset by peer]
[16:37:23] <mozmck> ok, looks like you're right (of course!)
[16:37:55] <cradek> haha I was about to run AXIS to see if it's crazy
[16:38:39] <mozmck> I'll change that and commit if everything else looks right.
[16:40:00] <cradek> it looks right to me, except I'd recommend checking to make sure it updates correctly if you change it in another UI (not sure how that works - there might be other things needed?)
[16:41:19] <cradek> hmm is there a _inc mode you also need to do?
[16:41:32] <mozmck> Well, I'm only using it in my UI which is a custom skin.
[16:42:02] <mozmck> I checked that and it looked like it was not used IRC. I'll look at that again.
[16:42:20] <cradek> sure but if you're adding support for RO to the backend you should add all the methods that the other overrides support
[16:47:30] <mozmck> So the _inc is used in one place, and I think there has to be a button in the main gscreen.glade file in order for me to add that for rapid-override
[16:47:45] <mozmck> which is why I did not do it.
[16:48:47] <mozmck> I would need "if self.widgets.button_rapid_override.get_active()", but I think it will crash and burn if there is no button_rapid_override widget
[16:48:52] <cradek> ok obviously I need to look at more than just your patch
[16:49:34] <mozmck> but I'm not 100% sure about that
[16:49:50] -!- icetan has quit [Quit: WeeChat 0.4.2]
[16:50:45] <cradek> I see what you mean
[16:50:52] <cradek> I have no idea how this works
[16:51:37] -!- dan2k3k4k5 has quit [Quit: Leaving]
[16:51:41] <mozmck> I *think* that the gscreen.glade must still be loaded in the background when using a custom glade file. I need to ask cmorley and/or dig more.
[16:51:49] <cradek> I thought you were adding support to the backend so your gui can call it, but this code seems like that plus an implementation of a certain gui too
[16:52:04] <mozmck> yes
[16:52:13] <cradek> ok I'll let a gscreen expert handle it :-)
[16:53:18] <mozmck> I see there is a button_rapid_override, but it seems to have to do with the max velocity :(
[16:53:35] * cradek backs away slowly
[16:53:47] <mozmck> heh! :)
[17:00:09] amnesic_away is now known as amnesic
[17:05:16] Loetmichel2 is now known as Loetmichel
[17:19:49] -!- yauh has quit [Quit: yauh]
[17:28:25] amnesic is now known as amnesic_away
[17:35:11] <kwallace3> Do one of these cause the probe to stop?
[17:35:15] <kwallace3> emcmotStatus->probedPos = emcmotStatus->carte_pos_fb;
[17:35:15] <kwallace3> /* stop! */
[17:35:15] <kwallace3> emcmotStatus->probing = 0;
[17:35:15] <kwallace3> emcmotStatus->probeTripped = 1;
[17:35:15] <kwallace3> tpAbort(&emcmotDebug->tp);
[17:35:30] <kwallace3> This is in control.c
[17:35:50] <cradek> surely tpAbort stops the move
[17:36:11] <kwallace3> I thought it might just be a message.
[17:42:37] -!- nerdfiles has quit [Read error: Connection reset by peer]
[17:47:08] <cradek> did you see the conversation about probing speed?
[17:52:41] <kwallace3> I think so. It just seems that getting the speed just right is a bit of a hack.
[17:53:41] <kwallace3> Ideally, probe should work at any reasonable speed.
[17:53:47] <cradek> yep
[17:55:07] <cradek> my vmc has micron resolution (and virtually no backlash) and the probe responds in 7ms. so to get the best result that is VERY slow motion.
[17:55:48] <cradek> well guess it's not that slow: 0.3 ipm
[17:56:12] <kwallace3> I think the problem is that a slow probe stops 'right on the tracks' and I want it to stop just past the tracks.
[17:56:46] <cradek> I think you are mistaken. it decelerates in a controlled fashion to a stop past the trip point.
[17:57:12] <cradek> I guess if you are going extremely slow it could stop in 1-2 servo cycles
[17:57:15] <cradek> how slow are you going?
[17:57:30] <cradek> (if it stops right away it's a new-tp bug)
[17:57:51] <kwallace3> .03 IPM
[17:58:00] <cradek> you can compare probed position to current position after the stop
[17:58:10] <cradek> what's the machine step resolution?
[17:58:22] <archivist> does it record the trip point, if yes you really dont care how far it overruns
[17:58:48] <cradek> archivist: it does record it, and yes you care very much because overtravel breaks the probe
[17:59:14] <archivist> at that speed !
[17:59:15] <cradek> probes have a small allowable overtravel
[17:59:45] -!- BellinganRoy has quit [Quit: Konversation terminated!]
[17:59:48] <cradek> no, not at that speed of course
[18:00:11] <archivist> I know about allowable travel and the fuse added to a good probe
[18:00:26] <kwallace3> It doesn't seem to overrun with very slow probes. It seems to sit in place and dithers.
[18:00:38] <cradek> kwallace3: what's your machine resolution? steps per inch?
[18:02:21] <kwallace3> I'd have to look it up. (Tormach 770 mill), easily .0001" per step.
[18:03:13] <pcw_home> skunkworks: what wireless chip do you have in your laptop? It looks like the .config I used has Atheros turned off
[18:04:07] <kwallace3> SCALE = 10160.0
[18:04:47] <cradek> ok then probing at less than 5.9 ipm gives you no benefit and only these problems
[18:04:59] <cradek> because that's one step per millisecond
[18:06:15] <cradek> at .01 you are issuing a step pulse and then reading the probe input 60 times and then issuing another step pulse
[18:06:34] <cradek> (is my math right?)
[18:06:37] <skunkworks> pcw_atheros.. :)
[18:08:54] <pcw_home> Jason Penn had the same issue, I dont have any Atheros hardware but it looks
[18:08:56] <pcw_home> like running xconfig and adding the Atheros wiresless option adds right looking stuff to .config
[18:10:08] <kwallace3> cradek, that seems fine and saves me some work. Unless, an operator calls for a very slow probe and expects it to work every time, but I'll worry about that later.
[18:10:33] <cradek> kwallace3: sometimes people have wrong expectations and explaining is called for
[18:11:00] <cradek> kwallace3: and it's often better than a software hack :-P
[18:11:30] <pcw_home> grep CONFIG_ATH .config
[18:11:30] <cradek> try this: "no, you can probe 100x faster than you expect, because linuxcnc is cool; I can explain it to you with math if you want"
[18:12:05] <cradek> er it's 600x haha
[18:16:42] <skunkworks> sit in place and dither?
[18:16:56] <cradek> sometimes I do that when I'm hungry
[18:17:31] <skunkworks> heh
[18:17:32] <skunkworks> <kwallace3> It doesn't seem to overrun with very slow probes. It seems to sit in place and dithers.
[18:18:05] <cradek> I wonder if that's the machine's vibration, or really what the probe does
[18:18:38] <cradek> it would be interesting to set it up with a micrometer screw poking it and see if it really does dither in place
[18:19:11] <kwallace3> http://wallacecompany.com/tmp/Screenshot-probe_bounce-1a.png
[18:20:06] <skunkworks> Heh - I guess I don't understand the conversation..
[18:20:25] <cradek> skunkworks: tormach's probe is noisy right at the trip point
[18:20:48] <kwallace3> I think I'm wrong with the "Pushing In" bit. I think the probe stops on the first rising edge.
[18:20:50] <cradek> skunkworks: kwallace3 is trying to figure out what to do about it, with the limitation that he can't fix the hardware
[18:20:58] -!- swingley has quit [Remote host closed the connection]
[18:22:03] <cradek> kwallace3: I wonder if your particular probe is a representative sample (maybe some are better and some are worse)
[18:22:35] <kwallace3> I really think that G38's stopping exactly on trigger is the problem.
[18:23:20] <kwallace3> But, using reasonable probe rates avoids it.
[18:23:37] <cradek> well I can sure see that argument too
[18:24:03] <cradek> at first I was having trouble seeing "stop asap" as anything but a feature
[18:25:34] <cradek> but I guess I still think every solution except "just probe faster" (debounce, overtravel) makes something worse
[18:26:48] <cradek> (this makes me realize I have never tested probing with new-tp)
[18:27:02] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[18:29:35] <cradek> kwallace3: in your picture, it *does* go past the trip point enough to make it stop bouncing, right?
[18:30:30] -!- f1oat3 [f1oat3!~f1oat@AMontsouris-553-1-24-149.w92-151.abo.wanadoo.fr] has joined #linuxcnc-devel
[18:32:04] <kwallace3> I don't think there is any motion between the first rising edge and the last falling edge, but I guess I should have included position on the trace.
[18:32:19] <cradek> that would be cool to see
[18:32:53] <kwallace3> I'll work on it a little later.
[18:32:56] <skunkworks> and triggering on the first rising is bad?
[18:33:43] <kwallace3> No it's good. It's the later edges that are bad.
[18:34:40] <skunkworks> oh - you nean triggers that are not during a G38 move... Is there logic in pathpilot that triggers an estop?
[18:35:03] <cradek> hmm what is the actual error you get?
[18:35:41] <skunkworks> you get a 'probe tripped something something' if it happens outside a probing command
[18:36:02] <kwallace3> If there happens to be a rising edge in the next move we get a probe while in non probe MDI move or some such error.
[18:36:23] <cradek> ah that one
[18:36:35] <kwallace3> Then the subroutine aborts and put manual mode in a twist.
[18:36:44] <cradek> what kind of twist?
[18:37:29] <kwallace3> Really just, F = .03 IPM but it's annoying.
[18:38:38] <cradek> wait you mean it changes the jog speed?
[18:39:27] * cradek squints
[18:40:02] <kwallace3> Normal speed for rough probing then slow for second finish probe.
[18:40:02] <cradek> it's always possible we have real bugs here...
[18:40:35] -!- micges [micges!~micges@elr32.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[18:40:37] <cradek> I'm asking about "manual mode in a twist" after you get an error that aborts the program
[18:40:40] <cradek> what do you mean by that?
[18:40:55] <kwallace3> At the end of the routine I restore the original speed, unless it errors out early.
[18:41:18] <cradek> how does that affect manual mode?
[18:44:00] <kwallace3> This may be PPi UI specific, but if I change F in g-code the new F shows up in the main screen F DRO and is used in manual mode.
[18:44:32] <cradek> oh, weird
[18:48:41] -!- nerdfiles has quit [Read error: Connection reset by peer]
[18:53:06] -!- nerdfiles has quit [Read error: Connection reset by peer]
[18:59:15] -!- unfy has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
[19:00:15] -!- nerdfiles has quit [Read error: Connection reset by peer]
[19:02:10] -!- ramkam2014 has quit [Quit: Colloquy for iPad - http://colloquy.mobi]
[19:08:23] <mozmck> Is it alright if I push my branch with the rapid_override stuff in gscreen to the linuxcnc git? Or should I do a branch on github instead?
[19:09:13] <mozmck> meaning a new branch in the linuxcnc git - just for while I'm working on that.
[19:09:38] <cradek> definitely fine
[19:10:11] <cradek> if it's mostly for you, it's our custom to make the branch named something like mozmck/rapid-override
[19:10:12] -!- andypugh [andypugh!~andy2@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[19:10:30] <cradek> or maybe it's mozmck/gscreen? whatever is fine
[19:10:42] <andypugh> it seems you can’t use the dpkg -getbulddeps doge with uspace
[19:10:52] -!- nerdfiles has quit [Ping timeout: 272 seconds]
[19:11:04] <andypugh> err getbuilddeps and dodge respectively
[19:11:47] <cradek> ~/emc$ dpkg-checkbuilddeps
[19:11:47] <cradek> dpkg-checkbuilddeps: Unmet build dependencies: inkscape
[19:11:53] <cradek> wfm?
[19:12:07] <andypugh> I am currently iterating trhough ./configure iteratively one package at a time
[19:12:25] <cradek> are you just spelling dpkg-checkbuilddeps wrong?
[19:12:50] <andypugh> The ./configure -a stage fails without a realtime kernel
[19:12:57] <cradek> ./configure uspace
[19:13:12] <andypugh> Ah
[19:13:18] <cradek> I just typed ./configure and got (surprisingly) good help
[19:13:29] <skunkworks> ./configure --with-realtime=uspace I thought
[19:13:39] <cradek> skunkworks: the other configure - there are two
[19:13:52] <skunkworks> huh
[19:13:53] <jepler> debian/configure
[19:16:05] <mozmck> cradek: ok, thanks.
[19:16:08] <andypugh> skunkworks: You imbecile! That is exactly what I tried, but you should know better ;-)
[19:17:21] <mozmck> I found a command to build a package that does nothing but install depends - I need to find that again and write it down.
[19:17:37] <skunkworks> :)
[19:17:40] <mozmck> handy to get a new system set up
[19:18:16] <cradek> cool
[19:19:58] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[19:20:21] -!- skunkworks has quit [Read error: Connection reset by peer]
[19:24:12] -!- swingley has quit [Remote host closed the connection]
[19:24:41] <mozmck> zlog:
[19:24:41] <zlog> mozmck: Log stored at
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2015-03-17.html
[19:26:27] <andypugh> inkscape seems a bizarre new dependency…
[19:26:40] -!- ramkam2014 has quit [Quit: Colloquy for iPad - http://colloquy.mobi]
[19:27:12] <pcw_home> Inkscape?
[19:27:16] <jepler> cradek: mk-build-deps (install devscripts and equivs)
[19:27:59] <andypugh> pcw_home: So dpgk-checkbuilddeps said
[19:28:51] <andypugh> Hmm, and ruby too
[19:31:21] -!- karavanjo has quit [Ping timeout: 252 seconds]
[19:33:42] -!- RifRaf has quit [Ping timeout: 252 seconds]
[19:33:58] <cradek> andypugh: I think the docs support svg etc now
[19:34:04] <cradek> ugh ruby?
[19:34:06] <cradek> who knows
[19:34:41] <KGB-linuxcnc> 03Moses McKnight 05mozmck/gscreen-rapid-override 0f4af54 06linuxcnc 10src/emc/usr_intf/gscreen/emc_interface.py 10src/emc/usr_intf/gscreen/gscreen.py added rapid override to gscreen * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0f4af54
[19:35:08] <cradek> sweet
[19:36:14] <cradek> perfectly done, making it off 2.7; it can be merged either way then
[19:36:57] <KGB-linuxcnc> 03Moses McKnight 05mozmck/gscreen-rapid-override c69f410 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py Changed max value for rapid_override, added _inc value. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c69f410
[19:37:31] <mozmck> thanks.
[19:38:19] <andypugh> cradek: I added the spindle orient example, but the PDF just shows the words “orient.svg” and I didn’t find if the spindle examples appear in the html at all
[19:39:00] <andypugh> (And currently my single shared git repo is being used by another platform)
[19:41:48] <cradek> andypugh: is it this one?
http://www.linuxcnc.org/docs/devel/html/examples/spindle.html
[19:42:00] <cradek> Hardware Examples/Spindle Control Example
[19:49:31] <andypugh> Possibly, I did a make-clean so it’s gone for the moment
[19:49:49] -!- nerdfile1 has quit [Read error: Connection reset by peer]
[19:51:34] -!- Akex [Akex!uid58281@gateway/web/irccloud.com/x-vnuthcavdpvenfpv] has joined #linuxcnc-devel
[19:51:40] Praesmeodymium|2 is now known as Praesmeodymium
[19:52:28] <andypugh> Interestingly the checkbuilddeps didn’t catch tclx or libtk-img
[19:52:50] <jepler> that's considered a feature.
[19:54:02] <andypugh> running “make’ now
[19:54:25] <jepler> to reduce the number of packages required to *build* linuxcnc, we invented (src/)./configure --disable-check-runtime-deps
[19:54:32] <jepler> which doesn't check for certain packages only needed at runtime
[19:54:56] <jepler> this erodes the value of checking *just the build dependencies* as a way to install what you need to *build and run linuxcnc*
[19:55:16] <andypugh> Hmm, but ./configure refused to work without them.
[19:59:20] -!- finnpixel has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
[19:59:27] -!- swingley has quit [Ping timeout: 245 seconds]
[20:02:46] <jepler> (src/)./configure checks for them by default, but not if --disable-check-runtime-deps is passed in
[20:02:49] -!- nerdfiles has quit [Ping timeout: 264 seconds]
[20:03:11] <jepler> if you're confused, I don't blame you for feeling that way
[20:05:52] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[20:06:09] <andypugh> Hmm, so I could in theory have compiled without them, but then the compile binary woudn’t have run?
[20:06:13] -!- b_b has quit [Remote host closed the connection]
[20:06:36] <andypugh> Talking of compiled binaries, where do the rip files actually end up?
[20:06:58] -!- dirty_d has quit [Quit: Leaving]
[20:07:05] <jepler> here and there, but only inside the git clone
[20:07:32] <andypugh> I just realised that I am compiling from an nfs-mounted git repo on my Mac, which probably means that the executable files will end up on my Mac, which isn’t really the plan. :-)
[20:07:49] <jepler> that's a curious thing to do
[20:08:47] <andypugh> It means I can edit code on the machine that actualy has a seat, screen and keyboard and compile on other platforms which may have none of those.
[20:09:29] <andypugh> I probably need to start again with a —prefix=
[20:11:16] -!- ketul has quit [Ping timeout: 246 seconds]
[20:19:54] -!- kwallace3 has quit [Ping timeout: 252 seconds]
[20:26:13] -!- uwe_ has quit [Ping timeout: 264 seconds]
[20:26:43] uwe__ is now known as uwe_
[20:34:19] -!- kwallace [kwallace!~kwallace@smb-75.sonnet.com] has joined #linuxcnc-devel
[20:44:20] -!- USER3 has quit [Client Quit]
[20:48:21] -!- DGMurdockIII has quit [Ping timeout: 252 seconds]
[20:52:50] -!- nerdfiles has quit [Ping timeout: 272 seconds]
[21:00:18] -!- swingley has quit [Ping timeout: 244 seconds]
[21:10:35] -!- FinboySlick has quit [Quit: Leaving.]
[21:11:20] -!- gene78 has quit [Read error: No route to host]
[21:28:04] -!- acdha has quit [Quit: Textual IRC Client: www.textualapp.com]
[21:30:06] -!- kwallace_T770 [kwallace_T770!~kwallace@smb-75.sonnet.com] has joined #linuxcnc-devel
[21:31:37] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[21:32:29] <kwallace_T770> cradek, here are is a halscope of another probe move that failed:
[21:32:32] <kwallace_T770> http://wallacecompany.com/tmp/Screenshot-probe_y_minus-1a.png
[21:32:46] <kwallace_T770> http://wallacecompany.com/tmp/Screenshot-probe_y_minus-1b.png
[21:36:10] <kwallace_T770> The rough probe was at 50 IPM with the finish probe at 5 IPM. I made the assumption that the probe motion would ended at the bottom of motion (moving in -Y) and is marked with the yellow line.
[21:39:43] <kwallace_T770> Since the error edge comes up fairly well after probe ends, there doesn't seem to be much probe can do about it.
[21:41:04] <kwallace_T770> Unless, probe has the retract built in, maybe. I need to give this more thought.
[21:45:12] -!- jvrousseau has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[21:49:57] <kwallace_T770> Here is the same probe motion without an error:
http://wallacecompany.com/tmp/Screenshot-probe_y_minus-1c.png
[21:54:24] -!- nerdfiles has quit [Ping timeout: 245 seconds]
[21:54:42] -!- Deejay has quit [Quit: bye]
[21:54:49] -!- f1oat3 has quit [Ping timeout: 245 seconds]
[21:58:44] -!- Connor [Connor!~Connor@24.214.127.194] has parted #linuxcnc-devel
[21:59:13] -!- Connor [Connor!~Connor@24.214.127.194] has joined #linuxcnc-devel
[22:12:00] -!- Aleian has quit [Ping timeout: 265 seconds]
[22:16:44] -!- Mr_Sheesh has quit [Quit: brb rebooting]
[22:17:04] -!- cnc1 has quit [Ping timeout: 272 seconds]
[22:23:13] -!- theorb has quit [Read error: No route to host]
[22:23:18] -!- theorbtwo has quit [Read error: No route to host]
[22:25:18] -!- radish has quit [Ping timeout: 252 seconds]
[22:28:14] -!- adb has quit [Ping timeout: 252 seconds]
[22:28:20] <cradek> wow you're still getting several bounces at 5ipm?
[22:28:28] -!- nerdfiles has quit [Ping timeout: 264 seconds]
[22:29:00] -!- Akex has quit [Quit: Connection closed for inactivity]
[22:29:57] <cradek> can't tell for sure how many, but way more than one
[22:31:27] <cradek> I guess at 5ipm you're still a bit under 1 step per servo cycle
[22:31:47] <cradek> depending on your acceleration, it might only be going a couple steps before stopping
[22:34:32] <cradek> huh at 50ipm it'll still be checking the probe faster than every .001"
[22:35:59] <cradek> I don't know what the answer is :-/
[22:36:29] <cradek> you could add a ton of debounce and then probe really slow, but does that actually fix anything?
[22:40:01] -!- mhaberler has quit [Quit: mhaberler]
[22:40:30] -!- moorbo has quit [Remote host closed the connection]
[22:43:10] -!- swingley has quit [Remote host closed the connection]
[22:47:22] -!- Tom_itx has quit [Ping timeout: 240 seconds]
[22:48:25] -!- zlog has quit [Ping timeout: 264 seconds]
[22:51:33] -!- nerdfiles has quit [Ping timeout: 252 seconds]
[22:51:57] <kwallace_T770> I think the retract slope needs to be greater, so the probe spends less time at the transition during retract. I added a .020" compression move right after G38 to give the retract some room to get to speed before the expected break point.
[22:53:42] <cradek> I bet you're going to end up having to use debounce and slowing everything way down :-(
[22:54:00] <kwallace_T770> I didn't get as much compression as I wanted, then realized I should try to tighten the TP (using default now, very sloppy) or use exact path mode.
[22:54:08] <cradek> it probably doesn't matter if you're just doing a few probes here and there for setup
[22:54:59] -!- zlog [zlog!~zlog@ip68-102-196-57.ks.ok.cox.net] has joined #linuxcnc-devel
[23:01:44] -!- micges has quit [Quit: Ex-Chat]
[23:02:45] <kwallace_T770> Is there any way to disable the new trajectory planner?
[23:03:39] -!- zlog has quit [Ping timeout: 252 seconds]
[23:05:39] <kwallace_T770> Yay, G61
[23:06:08] -!- tocka has quit [Quit: tocka]
[23:11:36] -!- DGMurdockIII has quit [Quit: Leaving]
[23:21:11] <kwallace_T770> Now I have the retract slope about the same for the rough and finish probes:
http://wallacecompany.com/tmp/Screenshot-probe_y_minus-1d.png
[23:21:39] <kwallace_T770> Now to run a bunch to see if any fail.
[23:37:37] -!- maZer`- has quit []
[23:41:00] <memfrob> well apparently there is some hidden magic within RTAI because ever since i merged the new code a have verified there are no differences which should have any affect on the underlying behavior of RTAI from magma, I get kernel crashes.
[23:41:39] <memfrob> something i re-wrote that is unrelated or took out from before is causing problems
[23:45:14] -!- zeeshan|2 [zeeshan|2!~kvirc64@CPE0018e7cea342-CM5039555db2cc.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[23:47:52] -!- zeeshan has quit [Ping timeout: 256 seconds]
[23:57:12] -!- The_Ball has quit [Remote host closed the connection]
