jmk-away is now known as jmkasunich
SWPadnos_ is now known as SWPadnos
cc1plus: error: unrecognized option `-funit-at-a-time'
make: *** [depends/libnml/rcs/rcs_print.d] Error 1
this is on BDI-4.51, after an apparently successull run of ./configure --enable-run-in-place --with-realtime=/usr/realtime-22.214.171.124-rtai --with-pytho=/usr/bin/python2.4
its late, will investigate later
./src/Makefile:OPT := -O2 $(call cc-option, -funit-at-a-time) $(call cc-option,-fno-strict-aliasing)
jmkasunich: this code is supposed to find out whether the compiler supports -funit-at-a-time, and enable it if it is supported
what values did you get for CC and CXX? Are they different versions of the C compiler?
er, "different versions of GCC" I suppose I should say
Ed Nisley has posted a halscope screenshot
here's mine: http://emergent.unpy.net/files/sandbox/halscope-stepgen-bug.png
jepler: (stating the obvious) you where able to repeat it?
I used the 2.0.4 stepper/inch.ini and got that trace from my first jog towards -X
jepler: in your picture - are the top two traces step gen dir and step? or is it at the printer port pins?
skunkworks: it's the signals connected to the stepgen component
I looked at the stepgen.0.dir and could not get it to do it. stepperinch.ini using axis as the front end - in both 2.0.4.and head as of yesterday (or the day befor)
(jogging in the -x direction.)
for me it only happened on the very first jog
tkemc with the jog speed set to 1 inch per minute
jmk is very gracious
I got it to do it on 2.0.4 - but so far only at 1 ipm - odd
what behavior did you see? I saw a single step in the wrong direction.
[21:11:34] <skunkworks> http://www.electronicsam.com/images/KandT/oops.png
direction drops for a second and it seems like there is an extra step
'second' = really short time period
I also cannot see it happen except after the first start up. Although I didn't jog too long
that looks like my graph -- but in my png, look at the bottom two traces
the red is the commanded position and the green is feedback
they do stay "together", there's just that weird 1-step reversal
ok - I was just graphing the ouput of stepgen and the printer port pin.
those will always be the same
because they are connected to the same signal
I know - I was just making sure and playing with halscope. which I will say again - damn cool
you were trying HEAD at first and never saw it happen there?
I can try it again - like I said.. I only see it with the jog set at 1ipm. 10 doesnt do it neither does lower speeds.. so far anyways
let me see
is there a way to kill whatever is running? I can't seem to go between head and 2.0.4 without a reboot
what error do you get?
One of em isn't dragging the kernel modules out.
n/m - my stupidity
what error did you get?
I had picked the 2.0.4 condig by mistake.
I ask because we recently had a user reporting that he couldn't compile HEAD on his system with 2.0.4 -- he got some error every time he started HEAD. "shared memory mismatch"
er, he could compile it, but couldn't use it
if you got that message I wanted to know how you fixed it
rtapi version mismatch iirc
it does it in head also
I still haven't seen it in HEAD
but I believe you
I did a g1x-.01f1 and got it also - in a differnt spot
it's good to know you get it with coordinated motion too
sure points to stepgen
[21:35:39] <skunkworks> http://www.electronicsam.com/images/KandT/headjog.png
[21:36:06] <skunkworks> http://www.electronicsam.com/images/KandT/headcom.png
yep, I got it that way in HEAD too
top one is head jogged and the bottom one is the mdi commanded motion
single shot mode, with g1x-.01f1 as my MDI command
only the first time
right. so far.
seems really low speed makes it worse
like I said before - I have only seen it at 1ipm so far.
have not seen it slower or faster yet
this glitch, combined with a drive that needs setup or hold time on direction, *could* lead to loss of opsition
that is what I was thinking - the change in dir isn't when the step is - normally
could cause a stall?
usually when you reverse you have lots of time, but not with this bug
I don't remember what version I had when I cut that circuit board. probably 2.0.3. no issues on my machine. that was a pretty intense file.
I have run a lot of long files too without problem, but I agree with jepler that this could be a serious bug on some setups
the "dirsetup" and other parameters -- those are in periods, not nS or uS, right?
the documentation has them as floats and doesn't specifically say what units they are .. the source code shows them as u32s
I'd have to look at the source too
they were periods in emc1, bet they still are
(FLOAT) stepgen.<chan>.steplen - Length of a step pulse (step type 0 only).
I should ought to fix the docs then
don't just believe me
no, I read the source as "periods"
which, let me just say, sucks
the alternative is to not give the user what he asks for unless he's very lucky
I guess you would ceil to periods
fix for 2.2 I guess
when I use setup and hold times, they seem to be respected .. as nearly as I can tell with halscope, anyway
for what it is worth - increasing the stepgens vel and acc headroom doesn't fix the problem :)
although - lowering the period to 20us makes it go away for 1ipm
so I though going from 50 to 20 is 2.5 increas (don't know if that is right) so I tried a jog at 2.5ipm - still no reversak
could there be a problem with resolution of 50us and the default accelleration / vel of the stepperinch.ini? So that the step gen gets ahead of itself and say 'crap - I need to slow down' and it does so in one period.
* skunkworks is talking out of his ass again
ew - never mind - I got it to do it.
[22:26:27] <skunkworks> http://www.electronicsam.com/images/KandT/20usx-01f10.png
only here for a few minutes
looks like we have two interesting issues going on
at least one, for sure
one that has been around forever I think, and causes a maximum error of 1 step
and another that may be unique to one user and might not even be software
I'd be surprised if it isn't software, considering that the direction issues have shown up in halscope traces for skunkworks and jepler
thats the first one
been around forever, and causes only 1 count of error
oh - you're talking about the overall drift
the "goes a half a turn in the wrong direction" problem is the one thats gonna be hard to reproduce
yeah, unless he's got an FError of +/- 1" or something (which would explain that reasonably well)
even a wide FE wouldn't explain it
if the error starts to get large, the control loop is gonna be trying to correct it
the TP wouldn't try to correct if FE limit is high
it won't just keep getting bigger at the same rate
err - DEADBAND
not the TP
there is a position loop inside stepgen
yes - that's in the update_freqs function, right?
if the fb accurately represents the steps out of the stepgen module, then you'd get a runaway, or a recovey, but _not_ a uniform move for half a turn
the only way to get uniform behavior is if the fb says "we're doing exactly what we're supposed to be doing" and the direction inversion is happening after that
but that loop is in the slower thread, so you'd possibly get a full SERVO_PERIOD of wrong output
a half turn is _many_ servo periods of wrong output
true - should be
in fact, its inpossible for direction to toggle more than once per servo period
update-freq generates a signed frequency command
actually, the make_pulses code may be able to toggle more than once
make-pulses obeys that command, and uses its sign for the dir bit
I'm still looking at it critically, so I'm not sure of that yet
freq is used to compute addval, (which is proportional to frequency, no reciprocals or anything)
I haven't looked at all the code that controls the dir pin, so I'm not sure yet - I've probably just missed the mechanism by which it would be prevented
and addval is ramped if needed in makepulses
but 31 of the ramped addval is used to drive dir
ramping addval could cause a problem in some cases (possibly)
since addval can't cross zero twice in a servo period, you can't have two dir changes in a servo period
how would ramping hurt?
dunno yet - in this conversation, you're the expert and I'm just figuring it out :)
Ive donned my stupid hat, and am taking nothing for granted so far
sometimes the guy who isn't the "expert" is the one who sees the problem the expert has overlooked
yep - hence the stupid hat I keep in my wardrobe ;)
my plan of attack for the first problem (the one step wrong problem) will be to add a couple params so I can see key internal vars
like the ramped addval
actually, addval is computed by update_freq, then may be changed by makepulses based on a ramp, no?
the other problem I doubt I'll be able to duplicate - so I'll have to work with the guy who's having it happen
there are two I think
lemme open the source file
don't worry about it if you're about to head out the door - I'm sure I'll have more intelligent (or at least less stupid) comments later
struct field newaddval is the one that update-freq should be setting, and addval is the ramped one
and the ramp value is calculated in update_freq?
deltalim you mean?
err - could be ;)
note - the ramping in make-pulses is very rudimentary
I'm not looking at it right now - IRC and EMC are on separate computers at the moment :)
and should be irrelevant to the situation jeff saw
newaddvel steps from one servo period to the next, but those steps should never exceed the max accel rate
the ramping in make pulses just interpolates the servo rate stesls