Back
[02:59:31] <archivist> to save time log here
http://camlog.archivist.info/
[03:00:24] <psyko_> Hello. Can anyone explain to me how the G54 ... G59 are transformed into canonical instructions ? Is it just a SET_ORIGIN_OFFSETS with the memorized axis offset ?
[03:00:48] <psyko_> thx archivist
[07:31:24] * jthornton has discovered the gscreen document and is working on cleaning it up for prime time
[12:34:03] <mozmck1> I don't know if I'm missing something or what. My setup was working for probing, and I don't think I changed anything except upgraded to the latest 2.7, but now it starts a probe move, goes until the probe makes contact and then tells me, "Probe is already tripped when starting G38.2 or G38.3 move"
[12:38:37] <skunkworks> is the probe logic the correct direction?
[12:39:08] <mozmck1> Nope, tried that and it correctly gave the error before it started the probe move.
[12:39:30] <archivist> any filtering in circuit to hide contact noise
[12:39:34] <mozmck1> I mean yes, the logic direction is correct.
[12:40:26] <mozmck1> It does the probe move for about .5 inch (12mm archivist :) ), makes contact, and then gives that error.
[12:40:37] <mozmck1> That seems to me a bug no matter how you look at it.
[12:41:02] <archivist> yes a signe of contact bounce
[12:41:44] <archivist> a mechanical bug that can be solved with a filter or a software delay
[12:44:15] <skunkworks> did anything else change? more noise? oh - higher accelleration of 2.7 tripping probe?
[12:44:52] <mozmck1> I've been using 2.7 pre this whole time, but it has been a little bit since I ran it.
[12:45:22] <skunkworks> huh. probably not acceleration then
[12:45:44] <mozmck1> archivist: why would noise cause a false error like that? worst case I would think is that the move would end prematurely.
[12:47:30] <archivist> halscope it and it should be obvious
[12:47:53] <mozmck1> I'm trying to figure out how to do that now. Not sure how to set it up
[12:49:58] <archivist> someone else had a similar problem, he cleaned his contacts :)
[12:52:44] <mozmck1> I'm not sure you understand my point yet. Anyhow, I'm not sure what to look at in halscope. I can look at motion.probe-input, and I assume I want it in single mode?
[12:57:42] <archivist> kwallace, was having trouble around the end of march this year with a probe
[12:58:32] <archivist> http://wallacecompany.com/tmp/Screenshot-probe_y_minus-1a.png
[12:59:15] <mozmck1> I just caught the probe-input in halscope - had to set it to roll, and then quickly click stop before it rolled off the screen.
[12:59:24] <mozmck1> It looks perfectly clean.
[13:00:10] <skunkworks> see if you get a probe trigger when you are not actually probing.
[13:00:12] <mozmck1> And I still maintain that a noise spike should not give *that* error *after* a half inch of probing motion.
[13:01:02] <mozmck1> by probe trigger I presume you mean a spike on motion.probe-input in halscope?
[13:01:48] <skunkworks> yes
[13:01:50] <mozmck1> My code makes a G0 move before the probe move, and there was no spike during that.
[13:02:16] <mozmck1> Nothing until it touched the metal. Then instead of ending the probe move, it gives me that error.
[13:03:50] <archivist> it opens then closes and opens again the routine is seeing that second change to it is seeing two trips
[13:04:52] <archivist> so it is seeing a real mechanical error, you expect it to ignore secondary changes, why
[13:05:43] <mozmck1> Well, I don't see anything like that in halscope. motion.probe-input is low, then goes high with no sign of noise.
[13:06:23] <skunkworks> the other thought is to go back to a previous version of 2.7 just to make sure it isn't something in linuxcnc.
[13:06:40] <mozmck1> hmm, I could try that.
[13:07:53] <archivist> go to a version before march :)
[13:08:18] <mozmck1> archivist: I would expect a different error in that case if it is going to error. Something like the one when jogging and the probe input goes active.
[13:08:26] <mozmck1> why before march?
[13:09:26] <archivist> because I am looking at the log of in here when two were looking at probing
[13:19:09] <cradek> probing interacts intimately with the TP, and the TP is all new
[13:19:41] <cradek> if something about probing works in 2.6 but not 2.7 we should find a sim setup that reproduces it
[13:20:04] <mozmck> My problem is between 2.7 a month or so ago, and now.
[13:20:18] <mozmck> There were TP changes in between
[13:20:19] <cradek> ok, that's still the same answer
[13:21:44] <cradek> sphereprobe.comp might be useful (it's a pretend sphere you can probe)
[13:22:27] <cradek> if you know what ref worked right, you could bisect it
[13:23:28] <mozmck> I'm going back trying to figure it out better, and I'll probably build linuxcnc from that time and test it.
[13:23:39] <cradek> cool
[13:24:25] <cradek> I recommend sphereprobe to eliminate any questions about your hardware
[13:24:53] <mozmck> How about just starting a move and using a button on screen to toggle motion.probe-input?
[13:25:36] <mozmck> I guess I should look at sphereprobe and see how it works...
[13:25:38] <cradek> that might work but the results wouldn't be as reproducable
[13:26:05] <skunkworks> shpereprobe is a config right?
[13:26:07] <cradek> it takes current coordinates as input and turns on the output if you're inside the specified sphere
[13:26:15] <cradek> skunkworks: hmm not sure. it's a comp
[13:26:41] <cradek> ./sim/servo_sim.hal:addf sphereprobe base-thread 2
[13:26:52] <cradek> yes it's already in servo_sim
[13:27:10] <cradek> ./sim/servo_sim.hal:net probe-out sphereprobe.probe-out => motion.probe-input
[13:28:30] <skunkworks> hmm not seeing that config.
[13:28:33] <mozmck> me neither
[13:28:43] <cradek> ./sim/tklinuxcnc/servo_sim.ini:HALFILE = servo_sim.hal
[13:28:45] <cradek> ugh
[13:28:56] <cradek> maybe a starting point anyway
[13:30:50] <mozmck> pretty!
[13:31:03] <skunkworks> find it?
[13:31:15] <mozmck> in the tklinuxcnc section.
[13:31:19] <mozmck> hurts my eyes!
[13:31:22] <archivist> looks a useful comp to verify a a probe with a real datum sphere
[13:31:23] <skunkworks> duh - didn't see that
[13:34:29] <cradek> I found it probing downward, at 0,0,-.167833
[13:34:45] <mozmck> found what?
[13:34:56] <cradek> the sphere
[13:35:01] <cradek> ooh
[13:35:11] <cradek> first probe worked, second one gave "Probe tripped during non-probe MDI command."
[13:35:18] <cradek> that ain't right
[13:35:25] <mozmck> hah!
[13:35:34] <cradek> is that what you're getting?
[13:35:47] <mozmck> "Probe is already tripped when starting G38.2 or G38.3 move"
[13:36:04] <cradek> third and fourth probes worked right
[13:36:06] <mozmck> That is after it moves about .5", and just when it contacts the metal
[13:36:13] <cradek> mozmck: is that in mdi or in gcode?
[13:36:20] <mozmck> gcode
[13:37:00] <cradek> joint 2 following error
[13:37:04] <mozmck> I don't see any noise in halscope on motion.probe-input, and I maintain that /that/ error is false even if noise is the problem.
[13:38:00] <cradek> yeah seems there's some troubles 'round here
[13:38:45] <mozmck> Shouldn't noise just cause a premature end to a probe move anyway?
[13:39:18] <cradek> this time I got "Probe tripped during non-probe MDI command" when moving upward which I know can't "trip" because I'm in sim
[13:40:20] <cradek> well not knowing of any outstanding bugs in 2.7 was good while it lasted
[13:40:27] <cradek> I wish this was more consistent
[13:41:05] <mozmck> I'm going to build 3622d00e06f64 which is just before the latest TP changes from Rob and test that.
[13:41:07] <cradek> tklinuxcnc constantly prints "can't open none" to stdout
[13:41:11] <cradek> mozmck: cool
[13:41:24] <cradek> mozmck: I'll try making a cleaner sim config for easy testing
[14:21:18] <cradek> the only problem I'm reliably seeing is "G38.2 move finished without making contact" when hitting ESC to abort
[14:29:55] <mozmck1> I'm still getting the error with 3622d00e06f64
[14:30:24] <mozmck1> Guess I'll figure out how to hook up a debounce component on that input.
[14:35:58] <skunkworks_> so is there an issue?
[14:36:11] <mozmck1> debounce man page is not too helpful
[14:36:24] <mozmck1> is there better docs on it somewhere?
[14:36:47] <cradek> what question does it not answer for you?
[14:37:08] <cradek> (if you don't see bounce in halscope I doubt debounce will help you)
[14:37:41] <skunkworks_> but you say that previous versions of 2.7 worked..
[14:38:02] <mozmck1> no definition of units for delay
[14:38:21] <mozmck1> no indication if G and F are 0 based or start at 1?
[14:39:17] <mozmck1> skunkworks: Yes, I can try back further even I guess.
[14:39:40] <cradek> I agree the G,F are baffling
[14:40:11] <cradek> there is no unit for delay, it just runs every time you run it
[14:40:33] <cradek> so I guess you could say delay is in thread periods (whatever thread you run it from)
[14:40:46] <cradek> it's a sampler, not a timer
[14:41:02] <mozmck1> ok, that's what I was assuming
[14:43:37] <KGB-linuxcnc> 03Chris Radek 05cradek/probetest 68a7d38 06linuxcnc 10configs/sim/axis/axis.ini 10lib/hallib/simulated_home.hal 03nc_files/crazyprobe.ngc Sim config for testing mozmck's probing bugs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=68a7d38
[14:43:55] <cradek> ^ this might help you
[14:43:55] <mozmck1> thanks!
[14:43:58] <cradek> welcome
[14:44:23] <cradek> it probes an imaginary plane at z=0
[14:44:31] <mozmck1> I'm using my machine right now. crashed my plasma tip pretty good trying to figure out this debounce comp
[14:44:50] <mozmck1> I load debounce like this: loadrt debounce cfg=1,1
[14:45:19] <mozmck1> and halshow shows this
[14:45:24] <cradek> I did it here
[14:45:38] <cradek> to just get one, I guess you use cfg=1
[14:45:44] <mozmck1> Owner Type Dir Value Name
[14:45:44] <mozmck1> 28 bit IN FALSE debounce.0.0.in <== home-z
[14:45:45] <mozmck1> 28 bit OUT FALSE debounce.0.0.out ==> probein
[14:45:45] <mozmck1> 28 s32 OUT 0 debounce.0.time
[14:45:45] <mozmck1> 28 bit IN FALSE debounce.1.0.in
[14:45:45] <mozmck1> 28 bit OUT FALSE debounce.1.0.out
[14:45:45] <mozmck1> 28 s32 OUT 0 debounce.1.time
[14:45:47] <cradek> then you get only .0.0.
[14:45:58] <mozmck1> hmm
[14:46:27] <cradek> then you get 1 block (#0) since you only specified one number, and it only has one element in it (#0) because that number is 1
[14:46:49] <cradek> this was overengineered
[14:46:55] <mozmck1> heh
[14:47:06] <cradek> the author probably thought you'd want sets of similarly-timed debounces
[14:47:26] <cradek> like 3 for the limit switches, 6 for the jog buttons, etc etc
[14:47:29] <mozmck1> I can see that being useful for some things.
[14:48:52] <mozmck1> do you have to addf debounce to the servo thread?
[14:49:05] <mozmck1> (or some thread?)
[14:49:35] <cradek> yes whichever thread you want
[14:49:41] <mozmck1> ohh, looks like I would addf debounce.0
[14:56:04] <mozmck1> Yep, debounce did not help.
[14:56:34] <mozmck1> But I did find out I can do a probe move in MDI and it works fine, but in my gcode it does not?
[14:57:14] <cradek> it would be great if you could make the wrong thing happen in the sim config
[14:57:49] <mozmck1> I will try! back to the house...
[14:58:08] <cradek> if you can, go ahead and push the test case to that branch
[15:11:17] <skunkworks> are there any probing tests in the test suite?
[15:29:49] <mozmck> It would be nice to have an option to not build the docs when you build deb packages.
[15:30:05] <mozmck> That takes a lot of extra time if you're just testing stuff.
[16:51:42] <mozmck> Hmm, I *think* have more clues. I haven't used your sim config yet cradek, been working on the real machine.
[16:53:07] <mozmck> I loaded a file I cut before and it works. New files do not.
[16:53:23] <mozmck> If my probe routine looks like this
[16:53:23] <mozmck> G0 Z0.5
[16:53:23] <mozmck> G38.2 Z-0.5 F20.0 ( Probe Touch-Off )
[16:53:23] <mozmck> G92 Z0.0
[16:53:23] <mozmck> Z0.150
[16:53:23] <mozmck> M3 S100
[16:53:35] <mozmck> I get the probe error.
[16:54:13] <mozmck> oh, I just figured it out - duh!
[17:11:13] <mozmck> turned out it was an error in my sheetcam post - it was not putting a G0 in the z move after the probe move.
[17:15:10] <cradek> oh interesting
[17:16:39] <skunkworks> so.. we are ok?
[17:17:06] <skunkworks> well.. I am ok..
[17:25:44] <cradek> I think the abort thing is a bug
[17:25:54] <cradek> and it all sure seemed weird when I was MDIing
[17:26:26] <cradek> I (or someone) needs to be more methodical and try that again
[17:27:11] <skunkworks> g38.2 is modal?
[17:27:44] <cradek> yeah surely so
[17:28:06] <skunkworks> wow.. I am really starting to get calls on win10 computers...
[17:28:07] <cradek> so mozmck's code was doing a second probe, upward, with the probe still in contact at the start
[17:28:15] <skunkworks> right
[17:28:30] <skunkworks> makes sense now
[17:34:28] <mozmck> Yep, I just cut a couple of parts, they whole bug was in my gcode
[17:34:51] <mozmck> thanks you all for your patience!
