Back
[01:21:45] <steve_stallings> steve_stallings is now known as steves_logging
[04:06:52] <ries_> ries_ is now known as ries
[13:20:03] <alex_joni> aaaargh
[13:20:37] <alex_joni> how can an email message lose one bit?
[13:20:53] <alex_joni> err.. gain one bit
[13:21:21] <alex_joni> sent a picture as an attachment to me
[13:21:38] <alex_joni> the image was base64 encoded, and the encoding differs by one bit
[13:21:59] <alex_joni> sent **** 5A ****
[13:22:07] <alex_joni> and it arrived as **** DA ****
[13:22:57] <alex_joni> **** are about 1230 other chars, which are fine
[13:23:53] <micges_work> email account in romania?
[13:24:04] <alex_joni> no, US
[13:24:21] <micges_work> weird
[13:29:21] <cradek> do you mean the ascii character 5 changed into the ascii character D, or do you mean a byte with the value of 0x5a changed into the byte 0xda?
[13:30:52] <alex_joni> an ASCII char of Z (0x5D) changed into U' (0xAD)
[13:42:01] <jepler> "The TCP checksum is a weak check by modern standards."
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Error_detection
[13:42:49] <cradek> as anyone who downloads ISOs knows
[13:56:24] <alex_joni> bleah
[14:00:54] <jepler> "Traces of Internet packets from the last two years show that between 1 packet in 1,100 and 1 packet in 32,000 fails the TCP checksum, even on links where link-level CRCs should catch all but 1 in 4 billion errors" --
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.7021&rep=rep1&type=pdf
[14:07:57] <jepler> hmph, the machine-readable pin description is 14% as big as the BIT file and 6.5x as big as the text version
[14:09:48] <jepler> oh well, they're still not large packages, and their addition only adds about 40k to download and 100k to Installed-Size (for hostmot2-firmware-4i65, which I selected at random)
[18:24:54] <micges> jepler: hi
[18:25:05] <jepler> hi micges
[18:25:07] <jepler> what's up?
[18:25:09] <micges> how 2.4.0 release is going?
[18:25:41] <micges> I know you have lost week but..
[18:26:39] <jepler> I think Chris is looking at this G92 issue, I'm looking at a numpy vs numarray issue for image-to-gcode, and I'd like to understand what the impact is of reverting that commit that caused the bad motion on abort.
[18:26:49] <jepler> maybe you can tell me more about that
[18:28:25] <micges> I don't see any impact of reverting my commit
[18:28:54] <micges> it was added to resend blending value to motion after abort nothing else
[18:33:38] <micges> bad motion on abort was from some bad things from read ahead code, I think problem was when canon flush() was called in code I've added to interp::synch()
[18:34:38] <jepler> but in your opinion the loss of the blending value on abort is not important enough to hold the release?
[18:36:02] <micges> I've handled with it so long so I'll wait until proper solution will be made
[18:38:05] <micges> for now I've made soultion that after any error I can only run program from begining so G64 P0.01 will be interpreted
[18:39:29] <cradek> to say I'm working on G92 is a big exaggeration
[18:39:46] <jepler> cradek: hm, ok
[18:41:11] <cradek> I've been trying to find time to do it. Do you think it's worth holding 2.4?
[18:41:26] <jepler> is the behavior you *do* get something that any user might grow to love and depend on?
[18:41:39] <jepler> or will all users uniformly react with revulsion, and learn never to use G92 and rotation together?
[18:41:58] <cradek> probably the revulsion one
[18:42:24] <cradek> the biggest problem is I'm not sure how it should work
[18:43:28] <cradek> G92 moves all the systems, but they can have different rotations
[18:44:17] <cradek> but even ignoring that and considering one system - you rotate a system then use G92 XY. the coordinates change to what you specify. now you rotate it again. what happens to the g92 offset?
[18:44:48] <jepler> the numbers stored in the parameters don't change and the new coordinate system becomes whatever the numbers indicate
[18:45:05] <micges> we have few other bugs that can revulsive
[18:45:14] <cradek> what do you mean by the second part?
[18:47:01] <jepler> you need to define what it means to have certain numbers in the G92 offset's parameters and certain numbers in the active fixture offset's parameters
[18:47:03] <cradek> micges: ??
[18:47:24] <jepler> when you've done that, you've defined what happens when you switch the active fixture offset
[18:47:40] <jepler> (and g92 offsets are applied and nonzero)
[18:48:18] <jepler> (please tell me it's not possible to write G53 G92 ...)
[18:50:39] <cradek> it's not
[18:51:10] <micges> cradek: see sf bug tracker
[18:52:33] <cradek> I'm pretty sure that when you run G92 the dro should change to what you say. but I think you're right that it is not sufficient to say that. The things stored in the variables could be rotated, or could not, for instance.
[18:54:36] <cradek> IMO the most *useful* (but surely not the easiest) is for G92 offsets to be applied to each of the *rotated* systems, and the vars are the undoctored numbers specified by the G92 command.
[18:55:31] <cradek> maybe another useful implementation is to have G92 move all the origins, ignoring rotation
[18:56:06] <cradek> (but I think that violates the first thing I said - that the dro should change to what you say)
[21:17:27] <skunkworks> skunkworks is now known as someone
[21:17:39] <someone> someone is now known as skunkworks
[21:52:17] <micges> what is desired interp messages place? define interp_return.hh or inline in source?
[21:54:52] <jepler> define inline in source
[21:55:09] <micges> thanks
[21:55:13] <jepler> do not: #define THIS_IS_A_VERY_TEDIOUS_ERROR_CONDITION "this error condition is very tedious"
[21:55:25] <jepler> even if you add the _() to make it "right"
[21:55:53] <micges> ok
[22:18:45] <CIA-2> EMC: 03micges 07v2.4_branch * r91e4cd96fa23 10/src/emc/rs274ngc/ (interp_check.cc interp_convert.cc): Remove unneeded checkings in G43.1 gcode
[22:18:46] <CIA-2> EMC: 03micges 07v2.4_branch * r1b8758034a91 10/src/emc/rs274ngc/interp_check.cc: Fix small typo
[22:18:47] <CIA-2> EMC: 03micges 07v2.4_branch * r73a1bfc49ae7 10/src/po/pl.po: Another part of Polish translations
[22:23:01] <robh__> hi had any one got chance to look at the G83 R problem?
[22:24:02] <micges> robh__: can you remember it?
[22:24:36] <robh__> if u have Z100, and then G83 with R2, frist peck is from 2 value, but then all pecks onwards return to the Z hight
[22:25:15] <robh__> which also makes chaning R value with in G83 very odd behave if u have multi hights of drilling etc
[22:25:52] <robh__> i also have a new odd problem i could not see why it did it, maybe someone can help
[22:26:05] <robh__> if i do, G91 G28 Z0 M09 M05
[22:26:13] <robh__> G91 G28 X0 Y0
[22:26:29] <robh__> G01 G90 G54 A0 F2000 i get no motion and no error
[22:27:53] <robh__> if u MDI it in that order works fine
[22:28:13] <robh__> i have the program if u care to see and try it
[22:28:22] <micges> yes
[22:28:31] <robh__> quite long tho full program
[22:28:44] <micges> pastebin.com it
[22:28:58] <robh__> http://pastebin.com/m8fmFKAF
[22:29:22] <robh__> its the last 4 lines of program, if u do run from here it also does it,
[22:30:09] <robh__> if u do a run from here on Line 528, X & Z will move to some odd place then go back to home as program asks, i dont know if that is a run from here bug tho
[22:30:43] <robh__> i am runing this on 2.3.5
[22:31:09] <micges> ok thanks for report, I'll take a look
[22:32:26] <robh__> no problem it does the G90 G01 A F ok in program ahead but not at the end
[22:33:17] <micges> can you write g83 line that is buggy for you?
[22:33:41] <robh__> 1 sec
[22:35:45] <robh__> http://pastebin.com/V9S4vukH
[22:37:22] <robh__> its in the motion, u will see it on the pecks only, as if it returns to Z clearnce not R clearnce
[22:38:11] <robh__> thanks for looking into it
[22:39:37] <micges> robh__: you know meanings of G98 and G99 codes?
http://www.linuxcnc.org/docview/devel/html//gcode_main.html#sub:G98,-G99:-Set
[22:39:49] <robh__> yes
[22:40:24] <micges> ok
[22:40:31] <robh__> its when it pecks the hole, comes out to Z100 then back into hole, not to Z2 as R asks
[22:40:42] <robh__> G99 G98 works fine
[22:48:33] <micges> can you paste screenshot of buggy g83 ?
[22:54:29] <robh__> not sure how i can show it, if u sim it, u should see when it retracts on peck .should see the Z value retracts to before doing next peck on hole
[22:55:22] <micges> here on g83 z returns to z=2.0 on each retract
[22:55:45] <robh__> v2.4?
[22:56:00] <micges> v2.3.5
[22:57:28] <robh__> it was only when on pecks, going to next hole was ok it would hold down on R value just peck lifts
[22:59:01] <robh__> in morning i will try document it abit better to try and show you problem part
[22:59:10] <micges> I tested again and it retract to z=2
[22:59:55] <micges> are doing something more in sim instead of load file and run?
[23:02:38] <micges> in your gcode file (larger) are drills on same z level?
[23:03:22] <robh__> yes
[23:04:08] <micges> ok so I see buggy preview
[23:04:19] <micges> in v2.4
[23:04:21] <robh__> was just i had Z50 before G83 other day, so i could clear some casting walls and notice the peck went back to z50 not zrvalue
[23:07:35] <micges> hmm
[23:07:57] <micges> I see you're using G43.1
[23:08:18] <micges> I mean g43
[23:09:27] <micges> if you'll not use g43 preview will be correct?
[23:12:03] <robh__> micges, try this one this is one i know has bug
[23:12:03] <robh__> http://pastebin.com/93V5Tffb
[23:13:12] <robh__> on line 12, if u turn down velocity u should see pecks return to Z25 and not the Z2 as id exspect from the R2 defined
[23:18:14] <robh__> aah seems it does it on G98 but not on G99
[23:20:31] <micges> I see
[23:20:33] <micges> it
[23:21:15] <robh__> grate
[23:23:33] <micges> i line 12 you have g98
[23:23:42] <robh__> yes
[23:24:00] <micges> so it should retract to last z before cycle
[23:24:23] <robh__> it does, its when it comes out of hole for peack brake, then back into same hole with in cycle
[23:24:48] <robh__> it lifts right to Z25 and not Z2 which i wuld exspect to see from R2
[23:25:08] <robh__> peck
[23:26:06] <micges> but you have g98 so r is ignored and last z before cycle is used
[23:26:43] <micges> it works here as expected
[23:27:01] <robh__> seems alittle wrong to me that why travel all that way from hole before reentering the hole
[23:27:28] <micges> use g99 in that line
[23:27:34] <micges> will be ok then
[23:27:48] <robh__> every other control i used only lifts back to R on G99 & G98 you see untill it has finished drill that hole and moving to the next then it obays the G99 G98 rule
[23:28:20] <robh__> but it will hold down to next hole which i didt want todo you see, i need the lift out and over when finished
[23:29:58] <micges> I don't understand
[23:31:14] <robh__> its not the retract of G99 G98 im not talking of, its the pecking of the hole, when it does a peck it comes out of the hole to Z25 then backinto hole to do next peck, and so on
[23:32:13] <robh__> what id exspect to see if, pecking to come out of hole to Z2 (from R value) then back into hole, no need to go right upto Z25 on pecks, only go to Z25 when finished drill that hole as G98 or G99 asks for.
[23:33:22] <micges> I don't use cycles
[23:34:02] <robh__> thts why when i did this change,
http://pastebin.com/qh0GeC5C it worked as exspected
[23:34:02] <micges> I've told you that g83 with g98/g99 works according to docs
[23:34:09] <robh__> yes it does
[23:34:13] <robh__> i agree
[23:35:15] <robh__> im talking how it chip brakes to Z values
[23:36:30] <robh__> i have to go now , but thanks for your time micges apreshiate it
[23:37:00] <micges> no problem
[23:37:36] <micges> you should ask others about that change
[23:37:46] <micges> good night all