steve_stallings is now known as steves_logging
ries_ is now known as ries
how can an email message lose one bit?
err.. gain one bit
sent a picture as an attachment to me
the image was base64 encoded, and the encoding differs by one bit
sent **** 5A ****
and it arrived as **** DA ****
**** are about 1230 other chars, which are fine
email account in romania?
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?
an ASCII char of Z (0x5D) changed into U' (0xAD)
"The TCP checksum is a weak check by modern standards." http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Error_detection
as anyone who downloads ISOs knows
"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
hmph, the machine-readable pin description is 14% as big as the BIT file and 6.5x as big as the text version
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)
how 2.4.0 release is going?
I know you have lost week but..
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.
maybe you can tell me more about that
I don't see any impact of reverting my commit
it was added to resend blending value to motion after abort nothing else
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()
but in your opinion the loss of the blending value on abort is not important enough to hold the release?
I've handled with it so long so I'll wait until proper solution will be made
for now I've made soultion that after any error I can only run program from begining so G64 P0.01 will be interpreted
to say I'm working on G92 is a big exaggeration
cradek: hm, ok
I've been trying to find time to do it. Do you think it's worth holding 2.4?
is the behavior you *do* get something that any user might grow to love and depend on?
or will all users uniformly react with revulsion, and learn never to use G92 and rotation together?
probably the revulsion one
the biggest problem is I'm not sure how it should work
G92 moves all the systems, but they can have different rotations
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?
the numbers stored in the parameters don't change and the new coordinate system becomes whatever the numbers indicate
we have few other bugs that can revulsive
what do you mean by the second part?
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
when you've done that, you've defined what happens when you switch the active fixture offset
(and g92 offsets are applied and nonzero)
(please tell me it's not possible to write G53 G92 ...)
cradek: see sf bug tracker
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.
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.
maybe another useful implementation is to have G92 move all the origins, ignoring rotation
(but I think that violates the first thing I said - that the dro should change to what you say)
skunkworks is now known as someone
someone is now known as skunkworks
what is desired interp messages place? define interp_return.hh or inline in source?
define inline in source
do not: #define THIS_IS_A_VERY_TEDIOUS_ERROR_CONDITION "this error condition is very tedious"
even if you add the _() to make it "right"
EMC: 03micges 07v2.4_branch * r91e4cd96fa23 10/src/emc/rs274ngc/ (interp_check.cc interp_convert.cc): Remove unneeded checkings in G43.1 gcode
EMC: 03micges 07v2.4_branch * r1b8758034a91 10/src/emc/rs274ngc/interp_check.cc: Fix small typo
EMC: 03micges 07v2.4_branch * r73a1bfc49ae7 10/src/po/pl.po: Another part of Polish translations
hi had any one got chance to look at the G83 R problem?
robh__: can you remember it?
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
which also makes chaning R value with in G83 very odd behave if u have multi hights of drilling etc
i also have a new odd problem i could not see why it did it, maybe someone can help
if i do, G91 G28 Z0 M09 M05
G91 G28 X0 Y0
G01 G90 G54 A0 F2000 i get no motion and no error
if u MDI it in that order works fine
i have the program if u care to see and try it
quite long tho full program
[22:28:58] <robh__> http://pastebin.com/m8fmFKAF
its the last 4 lines of program, if u do run from here it also does it,
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
i am runing this on 2.3.5
ok thanks for report, I'll take a look
no problem it does the G90 G01 A F ok in program ahead but not at the end
can you write g83 line that is buggy for you?
[22:35:45] <robh__> http://pastebin.com/V9S4vukH
its in the motion, u will see it on the pecks only, as if it returns to Z clearnce not R clearnce
thanks for looking into it
robh__: you know meanings of G98 and G99 codes? http://www.linuxcnc.org/docview/devel/html//gcode_main.html#sub:G98,-G99:-Set
its when it pecks the hole, comes out to Z100 then back into hole, not to Z2 as R asks
G99 G98 works fine
can you paste screenshot of buggy g83 ?
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
here on g83 z returns to z=2.0 on each retract
it was only when on pecks, going to next hole was ok it would hold down on R value just peck lifts
in morning i will try document it abit better to try and show you problem part
I tested again and it retract to z=2
are doing something more in sim instead of load file and run?
in your gcode file (larger) are drills on same z level?
ok so I see buggy preview
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
I see you're using G43.1
I mean g43
if you'll not use g43 preview will be correct?
micges, try this one this is one i know has bug
[23:12:03] <robh__> http://pastebin.com/93V5Tffb
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
aah seems it does it on G98 but not on G99
i line 12 you have g98
so it should retract to last z before cycle
it does, its when it comes out of hole for peack brake, then back into same hole with in cycle
it lifts right to Z25 and not Z2 which i wuld exspect to see from R2
but you have g98 so r is ignored and last z before cycle is used
it works here as expected
seems alittle wrong to me that why travel all that way from hole before reentering the hole
use g99 in that line
will be ok then
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
but it will hold down to next hole which i didt want todo you see, i need the lift out and over when finished
I don't understand
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
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.
I don't use cycles
thts why when i did this change, http://pastebin.com/qh0GeC5C
it worked as exspected
I've told you that g83 with g98/g99 works according to docs
yes it does
im talking how it chip brakes to Z values
i have to go now , but thanks for your time micges apreshiate it
you should ask others about that change
good night all