Back
[02:36:41] <CIA-18> 03jepler 07v2_2_branch * 10emc2/src/configure: rebuild with proper version number
[08:00:16] <alex_joni> VERSION has gotten a bit out of hand..
[08:00:46] <alex_joni> we have VERSION (the file), then configure stuff, then there's a version in emc.hh (I checked that a couple days ago, so it's fine),...
[08:00:54] <alex_joni> and there's version in the manuals
[12:58:23] <alex_joni> bon jour tissf
[13:43:32] <skunkworks471> skunkworks471 is now known as skunkworks_
[13:52:16] <fenn_> fenn_ is now known as fenn
[15:48:42] <tissf_> tissf_ is now known as tissf
[16:02:53] <CIA-18> 03cradek 07TRUNK * 10emc2/src/emc/motion/control.c: probe protection: if the probe trips while we're not probing, stop.
[16:07:09] <SWPadnos> is that a good idea in all cases?
[16:07:56] <alex_joni> SWPadnos: yup
[16:08:10] <SWPadnos> even if I have a home switch and the probe input on the same pin?
[16:08:11] <alex_joni> if you don't like it you can dehook it in hal, or physicly
[16:08:54] <SWPadnos> unhooking is a bad idea, noise could cause the machine to stop (randomly)
[16:09:01] <cradek> SWPadnos: I didn't think of that case...
[16:09:26] <SWPadnos> I agree that protecting a probe is a good idea, but I'm not sure if it should be an automatic abort input
[16:11:20] <alex_joni> maybe an probe-tripped output from motion?
[16:11:28] <alex_joni> and one can then and that with machine.probing
[16:11:30] <cradek> I don't think you could/should hook home and probe together. you could not probe near the end of travel for instance
[16:11:56] <alex_joni> and the output goes to machine.abort
[16:12:03] <SWPadnos> It's amazing the silly things pweople do when they're trying to add features to a machine using only a single parallel port ;)
[16:12:16] <alex_joni> yup, and we let them :)
[16:12:29] <SWPadnos> that's the idea
[16:12:29] <cradek> that silly person could use axis.*.homing to inhibit the probe input
[16:12:43] <cradek> (I think)
[16:12:48] <SWPadnos> sure - a home switch was just the first thing that popped into mind
[16:13:24] <SWPadnos> the thing is that the probe input becomes an additional abort input, which may not be the intended feature
[16:14:22] <alex_joni> SWPadnos: btw, this did start as a feature request
[16:14:42] <alex_joni> how about having a *-probing output from the motion controller?
[16:14:44] <SWPadnos> ok. so it's not "our fault" ;)
[16:15:03] <alex_joni> then it's easy to combine that with the probe input, and feed that into abort
[16:15:09] <SWPadnos> that should work
[16:26:59] <cradek> SWPadnos: I don't think I understand your objection. it's not an abort input, it's an input that you hook to your probe
[16:27:33] <cradek> when probing, a rising edge does a special thing. when not probing, a rising edge is an error condition
[16:31:13] <SWPadnos> I don't know that I agree that the probe activating while not probing is an error
[16:32:18] <cradek> ok I understand the base issue now
[16:33:09] <SWPadnos> it certainly could be an error, so ther eshould be some means of making that happen, like Alex's suggestion of a "probing" output from motion
[16:33:45] <alex_joni> or a param (setp motion.abort-on-probe 1)
[16:33:52] <cradek> I'm not sure how a user would use that to cleanly abort
[16:34:28] <cradek> setp motion.allow-probe-destruction true
[16:34:32] <SWPadnos> run probing (or not_probing) and probe_input into an and, with the output into an abort / estop input
[16:34:32] <alex_joni> cradek: that only adds one if around your latest probe-diff
[16:34:36] <cradek> that would be much easier
[16:34:40] <cradek> right
[16:35:00] <cradek> is there a realtime abort (not halui)?
[16:35:13] <SWPadnos> there's feedhold and estop
[16:35:21] <alex_joni> and axis.*.abort I think
[16:35:25] <SWPadnos> dunno about anything else
[16:35:29] <alex_joni> or some other name
[16:35:33] <alex_joni> but it's a amp-fault
[16:35:39] <alex_joni> and it stops it immediately
[16:36:00] <alex_joni> cradek: only if you call it 'setp motion.allow-probe-annihilation true'
[16:36:24] <cradek> I don't think this needs to cause a loss of position (like estop, machine off)
[16:36:33] <cradek> I would like there to be a way that it doesn't
[16:36:49] <cradek> alex's suggestion (wrap what I wrote with an if) allows that
[16:47:25] <skunkworks_> Hi guys - great job on the 2.2 release
[17:05:25] <fenn> feed hold and then non-realtime abort?
[17:59:14] <CIA-18> 03tissf 07TRUNK * 10emc2/docs/src/hal/intro_fr.lyx: French translation (HAL intro)
[17:59:56] <CIA-18> 03tissf 07TRUNK * 10emc2/docs/src/ (Submakefile index_fr.tmpl): French translation
[18:01:21] <CIA-18> 03tissf 07TRUNK * 10emc2/docs/src/Master_HAL_fr.lyx: French translation
[19:37:33] <cradek> I'm sure sorry to see that we broke old standard_pinouts
[19:39:40] <SWPadnos> referring to the list mail going from BDI-4xx to EMC2?
[19:40:37] <CIA-18> 03fenn 07TRUNK * 10emc2/src/hal/utils/halcmd_commands.c: clear up ambiguous error messages
[19:43:47] <cradek> no, gene____'s problem
[19:44:21] <SWPadnos> hmmm. I didn't see a pinout change
[19:44:26] <SWPadnos> or are you referring to the tool-prep stuff
[19:44:58] <cradek> we (I guess) made linkpp an error
[19:45:13] <cradek> so, people who have flogged along old configs are all going to have problems
[19:45:46] <SWPadnos> ah, true
[19:46:06] <SWPadnos> I thought it was just deprecated, not an error (or was that in the 2.1.x cycle?)
[19:46:22] <cradek> I think so
[19:52:17] <cradek> axis_manualtoolchange.hal:6: Warning: linkpp command is deprecated, use 'net'
[19:52:22] <cradek> I lied. it's still a warning.
[19:52:41] <SWPadnos> ok - wasthat in 2.1?
[19:53:39] <SWPadnos> you know, it would be very nice to have a "default" option for some of these files
[19:53:51] <SWPadnos> I'm not sure how that would work with permissions and stuff though
[19:54:07] <SWPadnos> liek "var file = default", and it just grabs the current var file
[19:54:19] <SWPadnos> (from the deb, not the home dir)
[20:06:39] <alex_joni> SWPadnos: grabs?
[20:06:47] <alex_joni> remember you need write acces to it
[20:07:12] <SWPadnos> gets
[20:07:20] <alex_joni> yeah, still .. nothing solved
[20:07:24] <SWPadnos> yes, hence the permissions question
[20:07:27] <alex_joni> next time you upgrade.. what happens?
[20:07:32] <SWPadnos> you get the default
[20:07:37] <alex_joni> overwriting your data?
[20:07:41] <SWPadnos> all that does in the case of the var file is reset your offsets
[20:07:43] <alex_joni> like stored offsets?
[20:07:55] <alex_joni> yeah.. might be a lot to lose for some
[20:08:03] <SWPadnos> you just changed the control software, it may be reasonable to have the offsets get reset
[20:08:18] <alex_joni> I don't see that :)
[20:08:46] <alex_joni> whenever I update *insert software name*, I don't expect it to default to some settings
[20:09:04] <SWPadnos> I would expect some things to change
[20:09:33] <SWPadnos> especially when the format of the settings file has documented changes
[20:10:00] <alex_joni> still.. in those cases I (personally) prefer it to not work at all
[20:10:12] <alex_joni> then for it to try to automagically be smart about it
[20:10:34] <SWPadnos> yeah, trying to get smart software right for everyone is a losing proposition
[20:19:21] <CIA-18> 03cradek 07TRUNK * 10emc2/src/emc/canterp/canterp.cc:
[20:19:21] <CIA-18> setup for advanced probing: ability to move until the probe clears, and
[20:19:21] <CIA-18> ability to suppress the failure error and read it in a gcode variable
[20:19:21] <CIA-18> instead. the actual brains in motion are not there yet.
[20:19:27] <cradek> duck
[20:19:27] <CIA-18> 03cradek 07TRUNK * 10emc2/src/emc/motion/ (command.c control.c motion.h):
[20:19:27] <CIA-18> setup for advanced probing: ability to move until the probe clears, and
[20:19:27] <CIA-18> ability to suppress the failure error and read it in a gcode variable
[20:19:27] <CIA-18> instead. the actual brains in motion are not there yet.
[20:19:36] <CIA-18> 03cradek 07TRUNK * 10emc2/src/emc/task/ (emccanon.cc emctaskmain.cc taskintf.cc):
[20:19:36] <CIA-18> setup for advanced probing: ability to move until the probe clears, and
[20:19:36] <CIA-18> ability to suppress the failure error and read it in a gcode variable
[20:19:36] <CIA-18> instead. the actual brains in motion are not there yet.
[20:19:38] <CIA-18> 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (5 files):
[20:19:40] <CIA-18> setup for advanced probing: ability to move until the probe clears, and
[20:19:42] <CIA-18> ability to suppress the failure error and read it in a gcode variable
[20:19:45] <CIA-18> instead. the actual brains in motion are not there yet.
[20:19:47] <CIA-18> 03cradek 07TRUNK * 10emc2/src/emc/nml_intf/ (canon.hh emc.cc emc.hh emc_nml.hh):
[20:19:49] <CIA-18> setup for advanced probing: ability to move until the probe clears, and
[20:19:50] <CIA-18> ability to suppress the failure error and read it in a gcode variable
[20:19:52] <CIA-18> instead. the actual brains in motion are not there yet.
[20:19:55] <CIA-18> 03cradek 07TRUNK * 10emc2/src/emc/sai/saicanon.cc:
[20:19:57] <CIA-18> setup for advanced probing: ability to move until the probe clears, and
[20:20:21] <alex_joni> cradek: did you get a probe?
[20:20:25] <CIA-18> ability to suppress the failure error and read it in a gcode variable
[20:20:25] <CIA-18> instead. the actual brains in motion are not there yet.
[20:20:38] <cradek> always had one - we found it a while back
[20:21:15] <cradek> with these new operations I think you can creep intelligently over the part, instead of guessing how high you have to go to clear it
[20:21:50] <cradek> if you can read the "error" (got to the end of the move without the probe tripping) in gcode, you can loop, creeping up and over the part, until you get to the next grid point
[20:22:40] <alex_joni> sounds nice
[20:23:03] <cradek> because when you have cleared the part and gotten to the destination, you'll get the "error"
[20:23:19] <cradek> I didn't think about how to control when the point gets written to the probefile though - that's another piece of the puzzle
[20:24:38] <cradek> (but that's all I wanted to do right now - so I committed it)
[20:25:00] <fenn> shouldnt it do that since you're just doing a normal probe move?
[20:25:46] <fenn> or do you only want to record probes coming from a certain direction (z axis for instance)
[20:26:18] <cradek> sorry, do which?
[20:26:54] <fenn> say you're probing a sphere, you go up and over and then down, right?
[20:27:07] <cradek> sure, that's one way
[20:27:17] <cradek> but I could go in a circle too
[20:27:49] <fenn> but when you are probing at below the radius, when moving in x/y your probe shank (held in the spindle) runs into the sphere
[20:28:00] <cradek> yep
[20:28:13] <fenn> so.. nevermind i guess
[20:28:41] <SWPadnos> you could approach it from the side, and then step up/over until you get to the peak
[20:28:43] <cradek> anyway, the user ought to be able to control which points are the "good" probes to be written out
[20:28:54] <SWPadnos> or you could start at the "center" and step down / over until you get to the edge
[20:29:25] <cradek> yeah I'm only making primitives here, there are many algorithms you can do in gcode with these primitives
[20:29:30] <SWPadnos> in each case, you still use probe moves to go "toward" the piece, and "clearing" moves to step over/up
[20:29:33] <SWPadnos> right
[20:29:34] <cradek> (at least I hope)
[20:29:35] <SWPadnos> looks grerat to me
[20:29:48] <alex_joni> cradek: maybe we could add some analog-probe interface primitives
[20:29:56] <alex_joni> like go to x/y, measure distance
[20:30:00] <alex_joni> move over, measure
[20:30:00] <alex_joni> etc
[20:30:04] <fenn> that would be neat
[20:30:11] <alex_joni> (with a laser distance scanner for example)
[20:30:18] <fenn> capacitive probe
[20:30:22] <SWPadnos> yep
[20:30:32] <cradek> double GET_EXTERNAL_PROBE_VALUE()
[20:30:36] <alex_joni> fenn: only works for metals.. but the actual process is irrelevant
[20:30:36] <cradek> return 0.0;
[20:30:41] <alex_joni> cradek: yeah that :P
[20:31:12] <alex_joni> * alex_joni remembers wait for analog
[20:31:23] <alex_joni> guess you can do the same with M<mumble>
[20:31:29] <cradek> brb
[20:31:38] <alex_joni> go to x/y, read the value from analogue input
[20:31:40] <SWPadnos> return {x,y,z offsets}
[20:31:43] <SWPadnos> ;)
[20:32:01] <alex_joni> #Z=#123
[20:38:21] <alex_joni> SWPadnos: seen the samsung 223bw ?
[20:50:48] <SWPadnos> hmmm. let me se eif that's the model I got for my wife :)
[20:51:33] <SWPadnos> oh - duh. hers is an Acer
[20:55:23] <alex_joni> heh :)
[20:55:38] <SWPadnos> similar though, the X222W - mostly the same specs
[20:58:16] <cradek> jepler:
[20:58:17] <cradek> Subject: Execution of '/home/jepler/bin/emc-cvs-mkdeb' failed with code 2
[20:58:20] <cradek> Reason: Message body is too big: 140314 bytes with a limit of 24 KB
[21:00:06] <jepler> cradek: yeah I see that
[21:00:48] <cradek> ok, I didn't know whether you get them
[21:00:56] <jepler> I guess I'll have to come up with something else to notify the lists about packaging failures..
[21:01:17] <cradek> put the results on teh farm page?
[21:01:22] <cradek> then post a url
[21:01:25] <jepler> yeah something like that
[21:04:27] <alex_joni> increase the list size?
[21:04:44] <cradek> noooo!
[21:04:59] <alex_joni> run it through top?
[21:04:59] <cradek> 140k is way too big for a mailing list
[21:05:08] <cradek> slap it on pastebin :-)
[21:05:37] <alex_joni> * alex_joni thinks cradek doesn't get a lot of windows emails
[21:06:04] <alex_joni> the other day I got an order (roughly 10 lines of text), would have been about 800 bytes as text format
[21:06:23] <alex_joni> but noo, they had to place it into a word document with company logo, so the whole thing was close to 2 MB
[21:07:59] <cradek> sadly, ooffice has made it so I can no longer pretend not to be able to read those emails
[21:08:11] <alex_joni> haha.. sadly :D
[21:08:22] <cradek> I used to read them with 'strings'
[21:10:42] <alex_joni> I read them with text viewers a lot
[21:10:55] <alex_joni> especially when grep'ing, or searchign for something
[21:19:53] <SWPadnos> I read them with shit-filtering goggles
[21:20:10] <alex_joni> http://youtube.com/watch?v=4Y1sZxAV7bo
[21:20:19] <alex_joni> sorry .. wrong channel :)