today I saw two strange things: once Axis did backplot only when moves was in X+ direction and not in X- direction
and few times after executing M2 flood and mist was enabled
should G53 do the full unwind on a stuart-style rotary, or should it just disregard g5x,g92 offsets and go to the position?
there ought to be a setting
similar to the modulo axes thing that you/Jeff(?) had worked on before
a setting for g53 behavior? or a setting for stuart-style versus old-emc-style?
or a third style? ss vs oes vs pjobis (previous jepler oops bad idea style)?
stuart-style vs old style
yes of course ss vs oes is a setting
or just add a G/M code to reset the axis to whatever it would be in modulo-land
I worked on modulo axes but never put it in because it didn't make anybody happy
these things happen
and with git it's even easier to not put in things that don't make people happy.
local unhappy-making changes are easier to maintain
gah. is there a program that should be used to remove fingerprints from ./ssh/known_hosts?
other than some sed/awk-foo
it's just a text file...
yes, I know
I could swear there was some utility that could remove them by some reference, but I don't remember it
a moduloing gcode is tempting but as far as I know that scheme doesn't exist outside our fevered imaginations
I actually like that the DRO stays in [0,360)
the +/- bit feels a little goofy but it's ok
yeah - and the CNC bible that Steve B quoted doesn't actually have all the information we need regarding modulo/not
as far as I saw, it didn't talk about modulo at all
it described exactly the oes
absent a reason to unwind, I think that g53 should do the least motion to get to the place the user wants
jepler: yay, thanks for answering my question
once we become aware of a reason, we could look at changing it or making it an option
I think that's probably right, too
if there is one, the reason to wind would be purely an "internal" reason (internal to the software)
I think it doesn't represent anything in the real world
I will do that.
ok I have new-g53 working. It uses the sign to determine which way to turn. It goes to the nearest given position in that direction, disregarding the g5x and g92 offsets.
are -0 and +0 distinct?
EMC: 03cradek 07ss-wrapped-rotary * ra8aa3ddced24 10/src/emc/rs274ngc/ (interp_find.cc rs274ngc_interp.hh): fix G53, ss-style
but did you know that -0.0 is not less than 0?
but did you know that -0.0 is not less than 0.0?
of corse; they're equal
I was smart enough to know I had to read lots of man pages before trying to program inside that tar-pit
* cradek exercises his metaphors today
is a bunch of pies in the sky a nebula of pies?
if so, I can say things like "that sounds like very nebulous sky-pies to me"
oh. I should pay my bills
so easy to forget when you only spend 3 or 4 days at home
jepler: seems that there is fmod but not fdiv. what is the right way to do fdiv?
cradek: I don
casting to an integer type has a range problem
't know of a function that always reduces to a range [0,n)
despite how useful that is
that's the opposite of what yo said
no I want the opposite of that
you are right I bet
but that's not hte one that corresponds with fmod() which says it rounds to 0 to find n
that's ok, I think - I'm not using fmod anywhere
EMC: 03cradek 07ss-wrapped-rotary * ree1472b4491f 10/src/emc/rs274ngc/interp_find.cc: fix eventual range problem caused by going through an int
I'd sure appreciate it if you'd check this for floating point related bloopers (or others)
did you saw my screens about Nan on hm2 encoder velocity
EMC: 03cradek 07ss-wrapped-rotary * r6504c7e89e8e 10/src/emc/rs274ngc/ (interp_convert.cc interp_find.cc interp_internal.cc): fix probe result, g28/g30, g28.1/g30.1
micges: i saw it, but i havent looked into the bug yet...
is that with top-of-tree?
did you get a good zoom in on what the encoder counts & position were doing at the time?
I can do that
do you still have it up, or is it easy to repeat?
cradek also mentioned to check how long NAn was on velocity pin
I don't know if its easy to repeat
but I have config to do this
you have a config that reliably produces NaN on hm2.encoder.vel?
I have machine that every time produces nan, very easy to repeat, and I can send you config from that machine, I don't have any rt machine handy to test in sim config
sure, please send me the config from the problematic machine
seb at highlab.com
seb_kuzminsky: thanks, I'll send you later, gotta run
EMC: 03cradek 07master * rff095f6b3d16 10/src/emc/task/emccanon.cc: yuck: fix home / g0a180 / g28 going nowhere
EMC: 03cradek 07ss-wrapped-rotary * r94c478f07639 10/src/emc/task/emccanon.cc: Merge branch 'master' into ss-wrapped-rotary
cradek: wtf ? yuck: fix home / g0a180 / g28 going nowhere
jepler: stupid tiny XYZ moves again. I was getting XYZ values of 1e-8. I thought it was from rotate() but when I printed the values going in and out they were all 0.
I did not find floats anywhere I looked. I don't understand it.