Back
[01:27:09] <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.
[02:16:58] <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
[02:16:58] <the_wench> will tell kwallace when he/she joins next
[02:20:10] <archivist> !later kwallace a software one is built in
http://linuxcnc.org/docs/html/man/man9/debounce.9.html
[02:20:10] <the_wench> will tell kwallace when he/she joins next
[08:50:10] <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?
[08:50:26] <cradek> where "correct" is the speed I described earlier
[08:51:02] <archivist> he is doing a fine second move
[08:51:15] <cradek> yeah
[08:51:20] <cradek> maybe wayyy too slowly
[08:52:01] <archivist> interesting that renishaw call it a vibration delay rather than debounce
[08:52:52] <cradek> theirs are so sensitive that I bet just moving the probe around would trigger it
[08:53:06] <skunkworks> on shuttles of the k&t sometimes the probe will trigger...
[08:53:07] <cradek> if you touch it, it triggers, but you don't feel any motion
[08:53:28] <archivist> manual I have is for the arm mounted one they use for lathe tool setting
[08:53:58] <archivist> TSA universal motorised arm
[08:54:04] <cradek> I bet if attached to a nonmoving part of a lathe you'd get a lot less trouble
[08:54:10] <archivist> I want one!
[08:54:17] <cradek> yeah wouldn't that be great
[08:54:45] <cradek> I tried to buy one on ebay but their stuff is made up of so many different parts
[08:54:57] <cradek> who knows what even goes together
[08:55:46] <archivist> when I went to collect the manuals, the seller had an empty renishaw box
[09:58:05] <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
[09:58:05] <the_wench> kwallace: archivist said a software one is built in
http://linuxcnc.org/docs/html/man/man9/debounce.9.html
[10:00:49] <kwallace> the_wench, thank you for the information.
[10:39:06] <cradek> kwallace3: we talked about your question quite a bit while you were gone
[10:52:42] <kwallace3> Is the_wench a person?
[10:58:25] <cradek> kwallace3: no, it's a bot
[11:02:37] <archivist> kwallace3, !later nickname message is what I did, it records it and watches for your return
[11:03:37] <kwallace3> Oops, I responded to a bot.
[11:03:53] <cradek> you are the first one to do that ever
[11:05:45] <the_wench> I am flattered though :)
[11:45:56] <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
[11:46:42] <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.
[11:51:22] <cradek> I don't think RO of 2.0 will ever do anything
[11:51:41] <skunkworks> screenshot!
[11:51:47] <cradek> should the range be 0..1?
[11:56:41] <mozmck> hmm, I thought the override is the same as the one in Axis? Let me check again...
[11:58:19] <mozmck> ok, looks like you're right (of course!)
[11:58:51] <cradek> haha I was about to run AXIS to see if it's crazy
[11:59:34] <mozmck> I'll change that and commit if everything else looks right.
[12:00:55] <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?)
[12:02:15] <cradek> hmm is there a _inc mode you also need to do?
[12:02:28] <mozmck> Well, I'm only using it in my UI which is a custom skin.
[12:02:58] <mozmck> I checked that and it looked like it was not used IRC. I'll look at that again.
[12:03:16] <cradek> sure but if you're adding support for RO to the backend you should add all the methods that the other overrides support
[12:08:26] <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
[12:08:41] <mozmck> which is why I did not do it.
[12:09:42] <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
[12:09:48] <cradek> ok obviously I need to look at more than just your patch
[12:10:30] <mozmck> but I'm not 100% sure about that
[12:11:41] <cradek> I see what you mean
[12:11:48] <cradek> I have no idea how this works
[12:12:37] <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.
[12:12:45] <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
[12:13:00] <mozmck> yes
[12:13:09] <cradek> ok I'll let a gscreen expert handle it :-)
[12:14:14] <mozmck> I see there is a button_rapid_override, but it seems to have to do with the max velocity :(
[12:14:31] * cradek backs away slowly
[12:14:43] <mozmck> heh! :)
[12:56:07] <kwallace3> Do one of these cause the probe to stop?
[12:56:11] <kwallace3> emcmotStatus->probedPos = emcmotStatus->carte_pos_fb;
[12:56:11] <kwallace3> /* stop! */
[12:56:11] <kwallace3> emcmotStatus->probing = 0;
[12:56:11] <kwallace3> emcmotStatus->probeTripped = 1;
[12:56:11] <kwallace3> tpAbort(&emcmotDebug->tp);
[12:56:26] <kwallace3> This is in control.c
[12:56:46] <cradek> surely tpAbort stops the move
[12:57:07] <kwallace3> I thought it might just be a message.
[13:08:04] <cradek> did you see the conversation about probing speed?
[13:13:37] <kwallace3> I think so. It just seems that getting the speed just right is a bit of a hack.
[13:14:36] <kwallace3> Ideally, probe should work at any reasonable speed.
[13:14:43] <cradek> yep
[13:16:03] <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.
[13:16:43] <cradek> well guess it's not that slow: 0.3 ipm
[13:17:07] <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.
[13:17:42] <cradek> I think you are mistaken. it decelerates in a controlled fashion to a stop past the trip point.
[13:18:08] <cradek> I guess if you are going extremely slow it could stop in 1-2 servo cycles
[13:18:11] <cradek> how slow are you going?
[13:18:26] <cradek> (if it stops right away it's a new-tp bug)
[13:18:47] <kwallace3> .03 IPM
[13:18:56] <cradek> you can compare probed position to current position after the stop
[13:19:06] <cradek> what's the machine step resolution?
[13:19:18] <archivist> does it record the trip point, if yes you really dont care how far it overruns
[13:19:44] <cradek> archivist: it does record it, and yes you care very much because overtravel breaks the probe
[13:20:10] <archivist> at that speed !
[13:20:11] <cradek> probes have a small allowable overtravel
[13:20:44] <cradek> no, not at that speed of course
[13:21:07] <archivist> I know about allowable travel and the fuse added to a good probe
[13:21:21] <kwallace3> It doesn't seem to overrun with very slow probes. It seems to sit in place and dithers.
[13:21:34] <cradek> kwallace3: what's your machine resolution? steps per inch?
[13:23:17] <kwallace3> I'd have to look it up. (Tormach 770 mill), easily .0001" per step.
[13:24:09] <pcw_home> skunkworks: what wireless chip do you have in your laptop? It looks like the .config I used has Atheros turned off
[13:25:03] <kwallace3> SCALE = 10160.0
[13:25:43] <cradek> ok then probing at less than 5.9 ipm gives you no benefit and only these problems
[13:25:55] <cradek> because that's one step per millisecond
[13:27:11] <cradek> at .01 you are issuing a step pulse and then reading the probe input 60 times and then issuing another step pulse
[13:27:30] <cradek> (is my math right?)
[13:27:33] <skunkworks> pcw_atheros.. :)
[13:29:50] <pcw_home> Jason Penn had the same issue, I dont have any Atheros hardware but it looks
[13:29:52] <pcw_home> like running xconfig and adding the Atheros wiresless option adds right looking stuff to .config
[13:31:04] <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.
[13:31:29] <cradek> kwallace3: sometimes people have wrong expectations and explaining is called for
[13:31:56] <cradek> kwallace3: and it's often better than a software hack :-P
[13:32:26] <pcw_home> grep CONFIG_ATH .config
[13:32:26] <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"
[13:33:01] <cradek> er it's 600x haha
[13:37:38] <skunkworks> sit in place and dither?
[13:37:52] <cradek> sometimes I do that when I'm hungry
[13:38:27] <skunkworks> heh
[13:38:28] <skunkworks> <kwallace3> It doesn't seem to overrun with very slow probes. It seems to sit in place and dithers.
[13:39:01] <cradek> I wonder if that's the machine's vibration, or really what the probe does
[13:39:34] <cradek> it would be interesting to set it up with a micrometer screw poking it and see if it really does dither in place
[13:40:07] <kwallace3> http://wallacecompany.com/tmp/Screenshot-probe_bounce-1a.png
[13:41:02] <skunkworks> Heh - I guess I don't understand the conversation..
[13:41:21] <cradek> skunkworks: tormach's probe is noisy right at the trip point
[13:41:44] <kwallace3> I think I'm wrong with the "Pushing In" bit. I think the probe stops on the first rising edge.
[13:41:46] <cradek> skunkworks: kwallace3 is trying to figure out what to do about it, with the limitation that he can't fix the hardware
[13:42:59] <cradek> kwallace3: I wonder if your particular probe is a representative sample (maybe some are better and some are worse)
[13:43:31] <kwallace3> I really think that G38's stopping exactly on trigger is the problem.
[13:44:16] <kwallace3> But, using reasonable probe rates avoids it.
[13:44:32] <cradek> well I can sure see that argument too
[13:44:59] <cradek> at first I was having trouble seeing "stop asap" as anything but a feature
[13:46:29] <cradek> but I guess I still think every solution except "just probe faster" (debounce, overtravel) makes something worse
[13:47:44] <cradek> (this makes me realize I have never tested probing with new-tp)
[13:50:31] <cradek> kwallace3: in your picture, it *does* go past the trip point enough to make it stop bouncing, right?
[13:53:00] <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.
[13:53:15] <cradek> that would be cool to see
[13:53:49] <kwallace3> I'll work on it a little later.
[13:53:52] <skunkworks> and triggering on the first rising is bad?
[13:54:39] <kwallace3> No it's good. It's the later edges that are bad.
[13:55:36] <skunkworks> oh - you nean triggers that are not during a G38 move... Is there logic in pathpilot that triggers an estop?
[13:55:59] <cradek> hmm what is the actual error you get?
[13:56:37] <skunkworks> you get a 'probe tripped something something' if it happens outside a probing command
[13:56:58] <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.
[13:57:19] <cradek> ah that one
[13:57:30] <kwallace3> Then the subroutine aborts and put manual mode in a twist.
[13:57:40] <cradek> what kind of twist?
[13:58:25] <kwallace3> Really just, F = .03 IPM but it's annoying.
[13:59:34] <cradek> wait you mean it changes the jog speed?
[14:00:23] * cradek squints
[14:00:58] <kwallace3> Normal speed for rough probing then slow for second finish probe.
[14:00:58] <cradek> it's always possible we have real bugs here...
[14:01:33] <cradek> I'm asking about "manual mode in a twist" after you get an error that aborts the program
[14:01:36] <cradek> what do you mean by that?
[14:01:51] <kwallace3> At the end of the routine I restore the original speed, unless it errors out early.
[14:02:14] <cradek> how does that affect manual mode?
[14:04:56] <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.
[14:05:28] <cradek> oh, weird
[14:29:19] <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?
[14:30:09] <mozmck> meaning a new branch in the linuxcnc git - just for while I'm working on that.
[14:30:34] <cradek> definitely fine
[14:31:07] <cradek> if it's mostly for you, it's our custom to make the branch named something like mozmck/rapid-override
[14:31:26] <cradek> or maybe it's mozmck/gscreen? whatever is fine
[14:31:38] <andypugh> it seems you can’t use the dpkg -getbulddeps doge with uspace
[14:31:59] <andypugh> err getbuilddeps and dodge respectively
[14:32:43] <cradek> ~/emc$ dpkg-checkbuilddeps
[14:32:43] <cradek> dpkg-checkbuilddeps: Unmet build dependencies: inkscape
[14:32:49] <cradek> wfm?
[14:33:03] <andypugh> I am currently iterating trhough ./configure iteratively one package at a time
[14:33:21] <cradek> are you just spelling dpkg-checkbuilddeps wrong?
[14:33:46] <andypugh> The ./configure -a stage fails without a realtime kernel
[14:33:53] <cradek> ./configure uspace
[14:34:07] <andypugh> Ah
[14:34:14] <cradek> I just typed ./configure and got (surprisingly) good help
[14:34:25] <skunkworks> ./configure --with-realtime=uspace I thought
[14:34:35] <cradek> skunkworks: the other configure - there are two
[14:34:48] <skunkworks> huh
[14:34:49] <jepler> debian/configure
[14:37:01] <mozmck> cradek: ok, thanks.
[14:37:04] <andypugh> skunkworks: You imbecile! That is exactly what I tried, but you should know better ;-)
[14:38:17] <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.
[14:38:33] <skunkworks> :)
[14:38:35] <mozmck> handy to get a new system set up
[14:39:12] <cradek> cool
[14:45:37] <mozmck> zlog:
[14:47:23] <andypugh> inkscape seems a bizarre new dependency…
[14:48:07] <pcw_home> Inkscape?
[14:48:12] <jepler> cradek: mk-build-deps (install devscripts and equivs)
[14:48:55] <andypugh> pcw_home: So dpgk-checkbuilddeps said
[14:49:47] <andypugh> Hmm, and ruby too
[14:54:54] <cradek> andypugh: I think the docs support svg etc now
[14:55:00] <cradek> ugh ruby?
[14:55:02] <cradek> who knows
[14:55:37] <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
[14:56:04] <cradek> sweet
[14:57:10] <cradek> perfectly done, making it off 2.7; it can be merged either way then
[14:57:53] <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
[14:58:27] <mozmck> thanks.
[14:59:15] <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
[14:59:56] <andypugh> (And currently my single shared git repo is being used by another platform)
[15:02:44] <cradek> andypugh: is it this one?
http://www.linuxcnc.org/docs/devel/html/examples/spindle.html
[15:02:56] <cradek> Hardware Examples/Spindle Control Example
[15:10:27] <andypugh> Possibly, I did a make-clean so it’s gone for the moment
[15:13:24] <andypugh> Interestingly the checkbuilddeps didn’t catch tclx or libtk-img
[15:13:46] <jepler> that's considered a feature.
[15:14:58] <andypugh> running “make’ now
[15:15:20] <jepler> to reduce the number of packages required to *build* linuxcnc, we invented (src/)./configure --disable-check-runtime-deps
[15:15:28] <jepler> which doesn't check for certain packages only needed at runtime
[15:15:52] <jepler> this erodes the value of checking *just the build dependencies* as a way to install what you need to *build and run linuxcnc*
[15:16:12] <andypugh> Hmm, but ./configure refused to work without them.
[15:23:42] <jepler> (src/)./configure checks for them by default, but not if --disable-check-runtime-deps is passed in
[15:24:07] <jepler> if you're confused, I don't blame you for feeling that way
[15:27:05] <andypugh> Hmm, so I could in theory have compiled without them, but then the compile binary woudn’t have run?
[15:27:32] <andypugh> Talking of compiled binaries, where do the rip files actually end up?
[15:28:01] <jepler> here and there, but only inside the git clone
[15:28:28] <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. :-)
[15:28:45] <jepler> that's a curious thing to do
[15:29:43] <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.
[15:30:25] <andypugh> I probably need to start again with a —prefix=
[16:53:25] <kwallace_T770> cradek, here are is a halscope of another probe move that failed:
[16:53:28] <kwallace_T770> http://wallacecompany.com/tmp/Screenshot-probe_y_minus-1a.png
[16:53:42] <kwallace_T770> http://wallacecompany.com/tmp/Screenshot-probe_y_minus-1b.png
[16:57:06] <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.
[17:00:39] <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.
[17:02:00] <kwallace_T770> Unless, probe has the retract built in, maybe. I need to give this more thought.
[17:10:53] <kwallace_T770> Here is the same probe motion without an error:
http://wallacecompany.com/tmp/Screenshot-probe_y_minus-1c.png
[17:49:16] <cradek> wow you're still getting several bounces at 5ipm?
[17:50:53] <cradek> can't tell for sure how many, but way more than one
[17:52:23] <cradek> I guess at 5ipm you're still a bit under 1 step per servo cycle
[17:52:43] <cradek> depending on your acceleration, it might only be going a couple steps before stopping
[17:55:28] <cradek> huh at 50ipm it'll still be checking the probe faster than every .001"
[17:56:55] <cradek> I don't know what the answer is :-/
[17:57:25] <cradek> you could add a ton of debounce and then probe really slow, but does that actually fix anything?
[23:59:54] <cmorley> mozmck: gscreen.glade does not need to be loaded in background when using a custom screen. Gscreen has lots of code that make assumptions about what widgets are available and what they are called. In most cases if they are missing warnings will be shown but nothing bad happens. It also depends on what things are initialized at start up. They long term goal is to generalize common routines and move all specific-to-screen function i
