cradek: is this right? 318fbd9a line 179 x += currentToolOffset.tran.z;
Just quickly, do you reckon that this: http://www.pastebin.org/357227
will be effective at spotting if my kinematics module is sending back NaN?
line 179 emc/task/emccanon.c
certainly not, thank you
it caused a gcode program of mine to hang i think
mozmck: Oh :-( I think Visteurs is using your packages and he gets the problems too.
andypugh, how about isnan()?
oh right, RT
EMC: 03cradek 07master * rab53d7de05de 10/src/emc/task/emccanon.cc: fix stupid cut-n-paste error with tool offset
thanks for finding that!
for consideration: http://www.panix.com/~dgarrett/stuff/0001-halshow-add-menu-options-for-load-save-exit.patch
I am printing out the joint positions and (I think) checking the axis positions for NaN when the come back to control.c from my kinematics module. Here is a sample of output. http://www.pastebin.org/357234
(I only get to run inverse kins as a one-shot, but forward kins runs all the time, so actually printing that is a non-starter.
cdecl> declare p as pointer to array 16 of struct hal_data_u
struct hal_data_u (*p)
EMC: 03seb 07master * r1f39204a0722 10/src/hal/drivers/mesa-hostmot2/stepgen.c: fix a stepgen bug
EMC: 03seb 07v2.4_branch * r02c2e884b5ea 10/src/hal/drivers/mesa-hostmot2/stepgen.c: fix a stepgen bug
seb_kuzminsky: Did the mesa stepgen bug fix have anything to do with a following error fault while jogging?
Dave911: no i dont think it would cause that problem
i made 2 hm2 stepgen bugfixes yesterday
one should prevent the stepgen from moving at all, in some very rare configurations
the other sometimes caused *very* slow creep when it should have been stopped after a move in the negative direction
neither one should have caused occasional following errors on an otherwise working machine
he stepped away
I just wondered if anyone looked into that weird HM2 stepgen bug with base thread that Chris Morley reported
is that bugreport recorded anywhere? was it on irc or on the mailing list?
Just on developers list
I think pncconf leaves a "empty" basethread on step motor configs, the sample HM2 step configs run fine
but the base thread causes trouble somehow
hmm, cmorley's description sounds a bit like the casting/underflow bug i fixed last night
The other manifestation is random following errors in the middle of a move (looks like feedback is lost momentarily)
pcw_home: and this bug is only with a base thread, right? never without a base thread?
do we have any halscope plots that show this happening?
do we have a config that has the problem?
I think any pncconf generated step config will exhibit the bug,
Ill ask customer with troubles to send failing config
there's config files & halscope screenshots in the thread jeff linked: http://thread.gmane.org/gmane.linux.distributions.emc.devel/2607/focus=3233
bummer, all the pastebin files have expired and are gone... :-(
dave911: you might try removing the basethread, seems to fix the problem for everyone so far...
As stepgen.0 was drifting (-fb increasing steadily for no command) for no reason I have been able to work out, I moved that axis to stepgen.6. Now stepgen.1 is drifting....
Is that diagnostic in any way?
Hey Seb it seems if a Base thread is loaded ( even if not used ) it will affect the step generators.
Pncconf always adds a base thread so any config made with pncconf will show this error.
though I'm sure if you add a base thread to any hostmot2 stepper config you will get the same problem.
it follow errors very quickly mostly in one direction.
Which stepgens? Hostmot2 or HAL?
In case there is any confusion, the stepgens I was referring to above are HAL ones.
When you say HAL you actually mean the software steppers. Both steppers use HAL of course :)
Yeah, well, yeah.
Hey John How are you?
good, nice and hot here in the 90's
wow! sunny here but not that hot!
I have almost everything done on the Hardinge :)
sounds like beer drink weather
too hot for beer
do you have more video?
did you see the one cutting the black top hat looking washer?
[17:46:16] <JT-Work> http://www.youtube.com/watch?v=isTD6bDF_LI
that one is cutting some VHMW seal washers for the Hardinge screws that hold the cover plates on
yea, I got the coolant tank and screens cleaned out finally and put fresh coolant in last night
hey did you every try the mux16 with out using the suppress-no-output ?
i'm curious how jumpy the feed changes would have been
yea, it kinda bounces around a bit between positions
yes colant can be really smelly. Do you use soluble oil or synthetic ?
my last thought is we need to make a gray code comp and wire it up for gray code output instead of binary
ok good then supress-no-output was worth while
ya why gray code?
semi-synthetic soluble ValCool VPTech
well there would be no in between areas with gray code
only one bit at a time changes
Argh! I don't want to jump to conclusions, but I think I might have found my Kinematics problems.
well the inbetween areas would come from the switch ? or would the comp ignore changes till they are valid?
the comp would only act on valid inputs
scroll down a bit on this page http://en.wikipedia.org/wiki/Gray_code
Ahh i see. so the feed rates bounce at bit even with suppress-no-input
I think the switch was originally wired up for gray code and that is why it didn't make sense to me at the time
well that should be doable. surprised some one hasn't made a comp yet
I thought about it for a while does that count?
I would even wire that monster switch again to try one out
what was it?
Here's a clue: pos->c = (180/M_PI) * atan2(sin(joints), sin(joints)/cos(joints));
That works :-)
There is no "tan" in rtai_math....
You should write a wiki page about writing kinematics !
The compiler was pulling one out of math.h which isn't RT-safe (and was probably expecting a different number format)
[18:02:12] <JT-Work> http://www.plcdev.com/using_ladder_logic_for_gray_code_conversion
that must have been tough to sort out :/
The kins? Up to 2am every night for a week staring at 100 lines of code type of tough.
And it isn't even for a machine I will ever see, or anyone I even know.
I can barely stay up to 11pm LOL
andypugh: seriously you should write a wiki page
Yeah, I might.
would help the next poor sucker ! feels goos to win though doesn't it.
PCW : any theory why base thread would affect stepgens in hostmot2?
No other than some bug in the driver that causes basethread interrupting servo thread to break some variable in HM2 stepgen
Sebastian could not duplicate it
Di you have the error one more than one card or only the 5I20?
PCW: between calculations and sending result to mesa?
chester88: I found this http://pastebin.ca/1889339
micges yes something like that but its all random speculation, very odd that a basethread that does nothing should cause breakage
I have only tried tested the 5i20 for this bug. The fact the base period had effect was pointed out to me by a user.
but it definitely did make a difference. I will have to do more testing.
micges: do you use a basethread in your stepper configs?
PCW: luckly (sadly) no
Yes, Ricks problem went away when he deleted the basethread
micges: can you add it and try ?
can you give me a link to bug report? I
'm not fully follow
there is no bug report lust mail list ..hold on
starts here: http://news.gmane.org/gmane.linux.distributions.emc.devel
thanks, I can test it on monday if it won't be solved until then
andypugh: do you have a 400K 7I43? (finally getting around to making the SVSS4_8 bitfile)
I do, you were out of stock of what I ordered :-)
Probably a good thing, not sure the config will fit in 200K
JT-Work: I will check those gray-code links out .
gotta go . take it easy guys.
i just spoke with tom, he said removing the base thread did not fix the occasional hm2 stepgen ferror
Maybe he has a real f-error problem?
Though that seems unlikely with a Mesa card stepgen
I have been seeing this with a p-port stepper system, where the axis max speed was way in advance of stepgen-scale x base-thread-period
tom's using steppers in position control mode, with encoders for position feedback to emc
so the hm2 stepgen creep bug i fixed last night could explain his problem
he's going to test 2.4.1-53 from the buildbot, which has the fix, and report back to us
SWPadnos: Did you say that hal_float_t is a different level of precision to double? ie it is encoded in a different way in memory?
./hal/hal.h:#define hal_float_t volatile real_t
./hal/hal.h:typedef double real_t __attribute__((aligned(8)));
I am curious now why a) The compiler was finding tan from math.h but gave an error when I tried to use arctan (math.h was _not_ in the includes) and b) Why using a non-rtapi trig function caused such odd bugs. It wasn't wrong answers, it was out-of-function memory writes and that sort of thing.
matt and i just moved his 6130 lathe with a 3x20 :-)
Hi cradek. It was my kins code after all.
I was using "tan"
why is that bad?
It isn't in rtapi_math.h
So it uses the one from math.h
(Not sure how it finds that, it wasn't an include)
that would be ok in sim... explains it.
It doesn't quite explain why it is quite so very horribly nd randomly bad.
Is there a way to prevent people using "tan" in future?
I don't know
I got a warning about atan not being in the library, but is silently found tan from math.h without a #include
And writing to the wrong bits of memory is a lot worse than just getting the wrong answer back.
you should have had a warn,ing if no prototype
sorry, phone kb
Try it :-)