Back
[01:03:38] <memfrob> just a few hours ago tpb came back online, full site isn't back yet, just a flag. back-up servers, mirrors and proxies are also crawling back to life.
[01:05:43] <memfrob> proxybay.info earlier today didnt have a single server online, looks like about half of them are already making a comeback
[06:20:35] <jthornton> seb_kuzminsky, can you take a look at a patch from Dewey that adds arc tolerance to the ini file?
http://pastebin.com/ZhrDeGgd
[06:48:33] <jthornton> arceye is adding some sanity checks for the ini entry
[08:35:35] <cradek> I've always been against making this configurable because I fear people will use it to make the program accept arbitrarily wrong arcs (usually because they don't understand arc specification at all, and don't realize, or refuse to listen to someone telling them, that they should fix their gcode).
[08:35:57] <cradek> on the other hand, if the tolerance check is stupid, I'm all for fixing it
[08:36:46] <cradek> I hate for us to forever have to handle arbitrarily-wrong spirally arcs
[08:37:07] <cradek> getting vel/accel/(jerk) constraints right on correct arcs is hard enough
[08:37:37] <cradek> I'll wait and see what arceye comes up with
[08:38:07] <cradek> meanwhile, someone please tell me if I'm wrong
[08:39:25] <cradek> hmmmmm
[08:40:15] <cradek> if we figure out what the right sanity check is, maybe that should be the allowed tolerance, and configurability serves no purpose
[08:42:00] <cradek> I think the new TP has special hackery already to handle spirals (because all arcs are a little bit spirally). I wonder what constraints that code has - it would be nice if we didn't cause it problems
[08:45:10] <JT_Shop> if limits are imposed then stupidly wrong arcs still could not be ran
[08:46:05] <JT_Shop> say for example your making a sign and 0.001" tolerance might make better sense than 0.0005"
[08:46:16] <cradek> if we know that "stupid" limit, why not make that the new fixed tolerance
[08:46:27] <cradek> oops brb
[09:24:01] <cradek> back
[09:51:40] <JT_Shop> my guess is if you want to make sure your generated G code is to a tighter tolerance like the original then you have a choice to do so
[09:53:46] <cradek> so how about if we would set the default to the "stupid" limit, and allow the user to make it tighter?
[09:54:10] <cradek> then people won't have to mess with it, and the "worst" setting will get tested
[09:54:59] <JT_Shop> sounds reasonable to me
[09:55:10] <cradek> I think a bigger limit is probably ok, because most arcs that are programmed wrong turn out to be really wrong
[09:56:04] <cradek> now we have to be clever and decide what the "stupid" limit is, but I think that's unavoidable
[09:59:04] <cradek> CHKS(abs_err > 100*tolerance || (abs_err > tolerance && (rel_err > .001)),
[09:59:40] <cradek> hmm this is an intricate check - not a simple comparison at all
[09:59:43] <seb_kuzminsky> morning
[09:59:53] <cradek> hey
[10:06:31] <cradek> JT_Shop: do you know the actual arc that caused this issue to come up?
[10:06:46] <cradek> I wonder which of these two checks was triggered
[10:22:34] <jthornton> cradek, this one
http://linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28685-limit-switch-troubles-hal-debounce?start=10#54187
[10:23:45] <cradek> haha Limit Switch Troubles - HAL Debounce
[10:27:10] <cradek> oh I think he's seeing the second check, that radii are different by more than .1% (almost .2% in his case)
[10:27:30] <cradek> his arc is .3 mm radius
[10:28:55] <cradek> for very small arcs you can get large proportional errors pretty easily if you don't use a lot of decimal places
[10:29:43] <cradek> think of programming in .01 mm but you want arcs around .1mm radius - your grid of possible center points is very coarse
[10:30:40] <skunkworks> do away with the check and let linuxcnc make spirals?
[10:30:44] <skunkworks> ;)
[10:31:09] <cradek> I think ArcEye is trusting the name of the define and guessing what it does, instead of looking at how it is used
[10:31:53] <cradek> skunkworks: the planner probably doesn't handle (extreme) spirals correctly
[10:32:00] <skunkworks> probably...
[10:32:49] <skunkworks> I remember rob talking about it in his presentation - but I don't remember what he said.
[10:33:31] <cradek> yeah I know he encountered constraint violations because all (most) arcs are a bit spiraley, and he tweaked something accordingly
[10:52:02] <cradek> fwiw, I bet those tolerances were chosen with the assumption that inch gcode is written with 3 decimal places and mm gcode with 2
[10:52:28] <cradek> so in theory, if you round to the nearest 3 (inch) or 2 (mm) decimal places you'd never trigger the error
[11:09:16] <cradek> G3 X0.226 Y0.271 I0.009 J0.002
[11:10:02] <cradek> yeah his very tiny arcs are very quantized at this resolution
[11:27:48] <cradek> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=18962fd6
[11:28:02] <cradek> the current scheme is there because it fixed very large arcs
[11:28:17] <cradek> we might need to do some thinking about very small arcs too
[11:37:01] <seb_kuzminsky> "big" and "small" are relative
[11:37:24] <seb_kuzminsky> we currently make some assumptions about the scale of work people are doing (not just in arcs, but all throughout linuxcnc)
[11:39:54] <cradek> yes that's true
[11:41:02] <cradek> I was wondering if I could figure out the right tests for "accept any arc generated by rounding or truncating to 3 decimal places (if inch) or 2 (if mm)" but those assumptions you're talking about are sure there
[11:41:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 365d95d 06linuxcnc 10docs/src/gcode/gcode.txt docs: fix a whitespace typo in G2/G3 docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=365d95d
[11:41:40] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 a7526e3 06linuxcnc 10docs/src/getting-started/Getting-LinuxCNC.txt docs: better intro in the Getting-LinuxCNC document * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a7526e3
[11:41:48] <cradek> the g64 tolerance is one way we have an exception to that
[11:42:11] <cradek> perhaps we could use that for this too, somehow
[11:42:23] <seb_kuzminsky> yeah
[11:42:50] <seb_kuzminsky> what's the rationale for having both absolute (ie 0.0005 inch) and relative (ie 0.1%) radius discrepancy checks?
[11:44:02] <seb_kuzminsky> is it that we're trying to accept small arcs with large relative discrepancies due to inadequate sigfigs in the gcode? so we check that their absolute error is below some arbitrary threshold?
[11:44:54] <seb_kuzminsky> and accept them anyway in that situation
[11:45:31] <seb_kuzminsky> having absolute tolerance configurable through gcode seems the same as having it configurable through ini variables, no?
[11:46:19] <seb_kuzminsky> i'm not saying it's wrong, i think it's probably right to expose that particular knob to the user
[11:46:20] <cradek> sort of. it will get exercised a lot more.
[11:46:36] <seb_kuzminsky> like we do for lines with the current g64
[11:48:03] <cradek> I think what the author really wanted was a spiralness-proportion-factor check, but what he had was a tolerance setting
[11:52:25] <seb_kuzminsky> OP says here that he's getting the error while trying to engrave tiny letters:
http://linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28685-limit-switch-troubles-hal-debounce?start=10#54163
[11:52:35] <cradek> yeah
[11:52:39] <seb_kuzminsky> is there somewhere else he talks about spirality?
[11:52:56] <cradek> I think he doesn't know that's the issue
[11:53:24] <cradek> his grid (.001) is very coarse considering his arc radii (a few * .001)
[11:54:02] <cradek> I think he doesn't really care what shape he gets, even though his gcode features are unmachinably small
[11:54:30] <cradek> did you find the gcode file? it's a few links down
[11:54:35] <cradek> and you have to log in
[11:56:31] <skunkworks> having it related to G64 sounds like a better solution...
[11:56:37] <seb_kuzminsky> i agree
[11:57:49] <seb_kuzminsky> cradek: i'm looking at jer10b.ngc, it all looks planar to me, what am i missing?
[11:58:37] <cradek> yes it's planar
[12:00:36] <cradek> I'm talking about spiral in the planar sense, r = a + b*theta
[12:00:50] <seb_kuzminsky> oh, right
[12:01:05] <cradek> I'm pretty sure that's what you get out of motion whenever you have an arc with mismatched radii
[12:01:20] <seb_kuzminsky> i hope so!
[12:01:49] <seb_kuzminsky> at the end of the sloppy arc (ie planar spiral) you should be at the endpoint
[12:01:57] <seb_kuzminsky> at the endpoint the user specified in the gcode
[12:02:22] <cradek> right
[12:02:35] <cradek> #define ARC_ABS_ERR 5e-4
[12:02:35] <cradek> #define ARC_REL_ERR 5e-4
[12:02:47] <cradek> the new planner makes some other assumptions
[12:02:57] <cradek> ?? we had probably better understand them
[12:03:12] <cradek> int arcNormalizedSlerp(...
[12:03:17] <seb_kuzminsky> slerp?
[12:03:46] <seb_kuzminsky> OP's error is from interp, not motion, though
[12:03:55] <seb_kuzminsky> (not saying we shouldn't understand motion too...)
[12:04:08] <cradek> sure but if the interp allows slop, the planner needs to handle it
[12:04:54] <seb_kuzminsky> a sloppy arc looks like an arc that's a cutter-comp entry/exit move, right?
[12:05:04] <cradek> no
[12:05:14] <cradek> cutter comp arc entry is still a circular arc
[12:05:32] <cradek> and there's no such thing as an arc cutter comp exit move
[12:07:40] <cradek> //TODO deal with large spiral values, or else detect and fall back?
[12:07:43] <cradek> ^ (tp)
[12:08:24] <cradek> you know, maybe this approach is wrong
[12:08:57] <cradek> given an arc with mismatched radii you can generate a unique circular arc, once you decide whether you want to sacrifice beginning tangency, ending tangency, or center point
[12:09:30] <cradek> cutter comp entry does exactly that
[12:09:31] <seb_kuzminsky> got to go, bbl
[12:09:49] <cradek> er maybe you can only keep one
[12:09:55] <cradek> I'd have to think about it more
[12:10:11] <cradek> ccomp entry keeps ending tangency and sacrifices the other two
[12:10:52] <cradek> anyway, maybe instead of making a spiral we can circularlize the arc and avoid downstream problems
[12:35:58] <skunkworks> you mean do it in 'interp' so it will just work in the trajectory planner?
[12:36:06] <skunkworks> (if I am understanding it right)
[13:56:31] <seb_kuzminsky> d
[13:56:34] <seb_kuzminsky> oops
[16:17:10] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 bbe1811 06linuxcnc 10docs/src/getting-started/Getting-LinuxCNC.txt docs: add some info on alternate install methods * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bbe1811
[17:01:20] <linuxcnc-build_> build #825 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/825 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[18:08:53] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 ded72cc 06linuxcnc 10docs/src/getting-started/Getting-LinuxCNC.txt docs: alternate install method for Debian Wheezy with Preempt-rt * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ded72cc
[18:46:35] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 f4262df 06linuxcnc 10docs/src/getting-started/Getting-LinuxCNC.txt docs: add a "Download the image" section * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f4262df
[18:46:35] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 ccf7c28 06linuxcnc 10docs/src/getting-started/Getting-LinuxCNC.txt docs: add a "Download using zsync" section * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ccf7c28
[21:07:42] <cmorley> pcw_home: I've been experimenting with mesaflah and pncconf. is the firmware name available by reading the cards?
[21:08:35] <cmorley> Could I talk you into adding --readhmid that exports a more machine readable format like XML?
[21:11:09] <cmorley> is there anyway to extract info from the serial cards similar to readhmid is a machine readable format?
[21:11:16] <cmorley> ttyl
[21:24:20] <pcw_home> the firmware name is not in the current IDROM
[21:24:22] <pcw_home> Its probably not a big deal to make mesaflash generate a xml version of a pinout file
[21:25:18] <pcw_home> you can probe sserial devices, the latest mesaflash does a little of this
[21:29:46] <pcw_home> :
[21:29:47] <pcw_home> mesaflash --device 7i76e --addr 10.10.10.10 --sserial
[21:29:49] <pcw_home> SSLBP port 0:
[21:29:50] <pcw_home> interface type: 12
[21:29:52] <pcw_home> interface width: 8
[21:29:53] <pcw_home> SSLBP Version: 1.43
[21:29:55] <pcw_home> SSLBP Channel Start: 112
[21:29:56] <pcw_home> SSLBP Channel Stride: 50
[21:29:58] <pcw_home> SSLBP Processor Type: d8
[21:29:59] <pcw_home> SSLBP Channels: 2
[21:30:01] <pcw_home> SSLBP Baud Rate: 2500000
[21:30:02] <pcw_home> SSLBP Clock: 100 MHz
[21:30:04] <pcw_home> sserial device at channel 0: 7I76 IO (unit 0x12345678, sw revision: 14)
[23:38:27] <cmorley> yes I have that working but that doesn't tell me much about its capabilities.
[23:40:14] <cmorley> on a 7i77 the unit numbers (similar to what you posted above) is that a good way to detect 7i77 ss analog vrs I/0?
[23:40:41] <cmorley> pncconf needs to know which ss channel is the analog and which is the I/O
[23:40:59] <cmorley> currently this is all hardcoded internally