it's likely that a gtk program exercises code paths in the X server that Tk doesn't
for instance, gtk is using the render extension for fonts, while Tk uses X core fonts
on the other hand, the panel has things rendering with gtk, so that makes it seem less likely
* jepler doesn't have a good theory
there was an ubuntu kernel update last week or so; I'll probably install it tonight or tomorrow, now that I'm back from my trip. This will make the cvs server unreachable for the short time. I'll give another note on IRC right before the downtime.
(hm, I guess it was longer ago than that -- march 16? well, this is the first I saw it)
jepler: what's wrong?
cradek: that report of good latency test results, but chunky behavior while running stepconf
(assuming it's correct that the cause is bad latency, I suppose)
[02:55:29] <jepler> http://www.linuxcnc.org/component/option,com_kunena/Itemid,0/func,view/catid,16/id,75/lang,en/#75
hmm. is there a way to get irssi to show "tabs" for open windows?
or to change windows/tabs without using the "/window #" command
SWPLinux: alt-1, alt-2 etc
hmm. I guess that would work if I weren't in a gnome-terminal
now to figure out how to make rxvt show me a usable font :)
I'm sure you can fix gnome-terminal somehow
something about meta vs escape
ok, esc-# does work
does anyone remember why the indrescnt>3 test is in the ppmc driver?
is that the number if registers in a "hole" that doesn't need to be read?
no, it's in the index sensing
has to be at least three? servo cycles since you requested an index for it to be called valid
that makes no sense to me (while I'm not looking at the code ...)
this is so complicated I don't trust it
and the integrated commenting / screwing up of bracket indenting makes it a lot clearer
I'm sure that does something in vi
emacs (properly indent this whole function)
alt-T C does it in Kate (after you select the function or other text to fix up)
sesms if this was wrong you might get a count reset without an index-enable reset
the user reports the opposite problem
or you would ignore an index reset if it took less than 3 servo cycles to happen
which would be really really unlikely at any speed, since the PPMC can't count that fast
err, since no motor is likely to spin that fast
no, you just have to be suitably close to the upcoming index when you assert index-enable
it wouldn't be hard to hit
but as long as the firmware matches, this is ok I think
it's scary if they don't agree
yeah. it's also a bit hard to follow how the indrescnt gets reset (or not)
like I said though, I think you'd get the opposite wrong behavior
I think it gets reset the first cycle when index-enable is true, then counts up after that
it seems to get incremented all the time in read_encoders, reset sometimes in write_encoders, and checked other times later in read_encoders
yes, I'd bet that's true
that seems to be the intent anyway
the user might not recognize a sign extension problem (count changes to some nonzero value)
I bet jon e has only ever tested this with the encoder spinning one direction
JonE should see that sooner, since he has higher resolution encoders
I'm pretty sure I tested it in both directions, but I may not have gone to over/underflow
(I ported the encoder code to HAL)
maybe didn't do such a great job of it though :)
I remember being confused by his logic, but I think I decided to keep it, under the assumption that it was proven correct
I know there's still a bug but it might be in firmware - I always look in this source and hope to find a smoking gun, but am always left with only an uneasy feeling.
yeah. there's smoke but no identifiable fire in there
yeah, I don't spot a problem. I think it's firmware or a subtle interaction between driver and firmware (like this count-to-3 thing, whatever it means)
I hope we get plots. "delta" and "index" might be telling. they are wrapped in fewer conditionals and might be a clue.
that count-to-3 thing might not be a problem if the hardware index flag still gets reset (but not the software index)
it would then just wait for the next one (I think)
but you'd get a reset count
they must match
yeah, I didn't see code to do this right :)
since the reset happens in hardware, not here
well, keep the hardware looking, but ignore it if count<3
so the hardware resets twice - big deal, the count is still correct relative to the latest index event
if it did it that way
for a while hm2 set i-e false and reset its count on different but adjacent servo cycles - this was not good :-)
true but you got a following error on the first reset when i-e didn't clear
or maybe I'm not understanding what you're saying
no, more likely I'm not understanding the full situation
ack, I should go to bed
goodnight, thanks for helping me puzzle about it
sure, I like puzzling
SWPadnos_ is now known as SWPadnos
[Global Notice] Good morning, it would appear we're experiencing some connectivity issues this morning. We're looking into it. Apologies for the inconvenience and have a good day!
naive cam detector can be turned off with G64P0.01 remains turn on?
micges: that didn't make much sense
is all cam detector implemented in emccanon.cc ?
after improving it in 2.3 I have huge problems resuming gcode properly :|
I'll move resuming code to task soon becouse I have no other option
alex_joni: I'm just complaining :)
have a nice day :)
micges: yeah, I think it's all in emcccanon.cc
alex_joni: sure it does -- it would hypothetically enable tolerance mode in the realtime motion planner, but have task not modify the motions it's presented.
jepler: I mean I didn't understand the sentence
but I understand your description
basicly turning off naive cam detection, but leaving tolerance mode on in the TP
alex_joni: Originally, G64P- modified just the RT planner so that it would follow the programmed path to within P- of the endpoints
yes, I understood now
later I added on the naive cam stuff, and used the same code to turn it on and off
maybe we can use G64.1 or so, to specifically turn off the naive cam detection if needed
or maybe G64 P- Q- to specify the RT tolerance and the naive cam tolerance separately
I'd consider such a patch, but if it turns out to be complicated I won't want to do it on the 2.3 branch
(it may be; I think it involves adding or changing canon calls..)
yes, main problem is that task modify path
(13:43:25) jepler: alex_joni: sure it does -- it would hypothetically enable tolerance mode in the realtime motion planner, but have task not modify the motions it's presented.
I think jepler meant the canon part that is linked into task..
err exactly :P
EMC: 03bigjohnt 07v2_3_branch * 10emc2/docs/src/hal/ (basic_hal.lyx pyvcp.lyx): add a link to the hal commands section
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/ (basic_hal.lyx pyvcp.lyx): add a link to the hal commands section
hello every body
I am happy to meet you all!
i read through emc tp.c these days
feel confused by the motion blend math,is there any clear document for this?
yes there is a comment and a corresponding xfig diagram that explains it
zhangj: good morning
hi cradek,i have saw the xfig diagram today,but where is the comment?
comments in the source code
oh,thank you,i have not read it carfully
another question is I want to watch the program running step by step,what kind of debug tool should i used?the command line GDB is now easy
you can use gdb on all parts of emc if you compile with --enable-simulator. All the "real time" code runs in the process called rtapi_app.
[13:09:59] <jepler> http://mid.gmane.org/20090120172418.GA11149@unpythonic.net
EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: unpack the unused joints.
EMC: 03cradek 07v2_3_branch * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: unpack the unused joints.
unpack? sounds like your just got back from a trip.
then it would be "unpack the abused joints"
I wish there was a search on this page: http://www.linuxcnc.org/docs/devel/html/
* cradek is giddy about a 2.3.0 release
the overall site search would find things there, though I agree, it would be nice to have a "docs search" function there
seb_kuzminsky: a long long time ago - I saw the issue with stepgen before it was figured out that the stepgen needed accel headroom. It would go too far and reverse afew degrees
[15:17:04] <seb_kuzminsky> http://highlab.com/~seb/emc2/stepgen/config/broken-5i20.ini
[TRAJ]MAX_ACCEL is higher than [AXIS_?]MAX_ACCEL
they're in the same units, right? so that indicates lack of headroom?
[TRAJ]MAX_VELOCITY is higher than [AXIS_?]MAX_VELOCITY, too
how is the max accelleration in the mesa stepgens set?
it's in the driver, the fpga doesnt know about accel
so in the servo loop, the driver commands the vel for the following servo period, and the fpga steps at that rate until the driver changes the command
seb_kuzminsky: do you have the rest of that config?
setp hm2_[HOSTMOT2](BOARD).0.stepgen.01.maxaccel [AXIS_1]MAX_ACCELERATION
setp hm2_[HOSTMOT2](BOARD).0.stepgen.01.maxvel [AXIS_1]MAX_VELOCITY
so the TRAJ setting is irrelevant
headroom is the difference between the TP limit (AXIS_N or TRAJ setting) and the HAL driver setting
but it seems like maybe the hm2 stepgen should have some headroom over the axis constraints
which is zero in this case
what is zero?
that seems bad
stick some *1.05 in the hm2 driver?
amazing what a little bit of phase lag can do to you, isn't it?
ok 1.02 then
what's the alternative? I think the user shouldn't have to deal with this.
as we saw with stepconf, if you do something automatically, the user will be surprised when things aren't the way they expect
such as when the actual vel limit is 0.95* what they entered
or if the machine actually moves faster than they entered (or stalls, because the number they used has something added to it)
it won't be commanded any faster than that
I agree that the user shouldn't have to deal with it, but there are surprises any way you look at it
true, it shouldn't be
nah, I disagree that there is a surprise
the surprise is that two limits set exactly the same fight with one another
we know which one has to be a tad higher
or a tad lower
we know the relationship, but not which needs to change
I also disagree with that
the limit may be a mechanical one, so you don't want to command anything faster
they can probably be so close that it doesn't matter.
the real issue is that if the user tells us the machine can go "this fast" we can't set the TP limits that fast due to a problem with the way EMC deals with stepper machines
so the TP limit should be lower
This conversation sounds vaguely familiar.. ;)
which yields the surprise of "I told it 400 IPM, and I only get 380"
right, so you raise the other one enough that it can keep up, which is only a tiny bit
it still moves 400 +- numeric precision rounding crap
except that the user who actually enters the real machine limit will be screwed
(if such a user exists :) )
only by +- N.P.R.C
I don't think anyone is that accurite.
yeah, that's only the usual screwage.
I don't believe anyone can know their real machine limit to within 2% and actually runs it there
that's probably true
changing the HAL component is "icky" though. it assumes that the hardware is being driven by the EMC2 TP, which has this little problem ...
they come to the limits emperically and if the real motion is 1% over the number they command, it makes no difference because they will end up with an appropriate setting after testing by ear or dry-run
the real error is in the way EMC2 deals with stepper systems
incidentally, does the USC exhibit this problem?
I dislike when some sense of puritanism causes the user to have to deal with crap they don't actually need to
oh, no it doesn't - it's a rate generator, not a positioner
I can agree with that
I'm not arguing that there is no problem, or that it shouldn't be fixed
sure, arguing about the best fix is fine :-)
yep - I thought I was doing that. sorry if I didn't make that clear :)
as long as we agree that the best fix isn't making the user set two numbers 1% apart
we'll call that option zero ;)
if hal could let you say 1.01*[FOO]ACCEL it'd be less bad
I had that thought too
(in a hal 'setp' where a number is expected)
Stepwizard does this automatically already... ;)
let's get cmorley to incorporate that into pncconf, and we'll be done! :)
so the fix is in the hm2 driver i should set stepgen max_vel and max_accel to (1+epsilon) times what the user requested?
1.01 or 1.02 maybe?
that's one possible fix
didn't we discuss having a "headroom" param at one point? (for software stepgen I think)
that's another one - have a param that defaults to 0.02 or 0.05 or something, but someone who knows what they want can set it to zero
seb_kuzminsky: are you pretty sure this is the actual problem?
i have no idea if that's the problem
i can't reproduce it
you can't run that config without motors and look at the feedback position?
or you do, but the problem doesn't manifest?
jepler: i do that, and the problem doesnt manifest
is it possible this guy has old firmwares with the high step rate problem?
although (i just realized) i only tried X, and in this config the different axes have different maxvel & maxaccel...
jepler: possible, but i dont think that firmware bug would cause this problem
that bug resulted in slower-than-commanded speed and very large ferrors
the position feedback in the driver corrected for this during the decel phase
accel was unaffected
Is it possible they have steplen-stepspace set near the velocity limit?
These should really be set to the electrical limits
which should be much > the mechanical limits
steplen+stepspace is 6 us
INPUT_SCALE is 320, biggest MAX_VELOCITY is 80
so that's 25600 steps/second, which is 39 us/step
so that should be ok
that would result in the stepgen not keeping up over the move, not necessarily in overshooting at the end
pcw: did you see the accel headroom discussion above?
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-04-14.txt
Just guessing about why you cant reproduce the problem
(5I20 uses PCI clock for stepgen and it can vary from system to system)
I got the THC hooked up to the 5i20 last weekend
works real slick
got a good start on the THC component too...
* BJT-Work is off to lunch
Did you ever get the software counting to work?
no, not past about 3 volts
At the slowest rate (1/128) you would need a 16 KHz base thread to count the max frq
I don't remember what that config was running at
(I blame SWP)
yep, my fault
he _assured_ me that 8KHz was not too fast
what are you talking about though?
I graphed the voltage/freq with the 5i20 and it is straight from 0 vdc to 10vdc input
The V-F should be linear to 12 bits or so
I checked 1/128 and 1/64 and they were perfect as far as I could tell
I did have a lab power supply to feed the input so it should be close
Yes thats Sebs good work on HM2s velocity output
I didnt think the lower rates would work as well
is this an adc for m5i20?
I went with a full PID in the THC comp
I still need to check the 1/32 and 1/1
voltage to freq board cradek
pcw: i was thinking about hacking on hm2/spi at fest (mid may)
Its a V-F converted being fed into the encoder input and using the velocity out
mostly for the reprap folks
as the Analog
* BJT-Work is heading to lunch
SPI is big unforch
talk to you guys later
so the point is to have adc - just v-f is the way to accomplish it?
would be fun to play with edm using that
Its a AD7740 V-F with one of ADs isolator+power
So its got 2500V common mode range :-)
(and only ~2 pf input output capacitance)
wonder if I could use my lathe for sinker edm. wonder if the spindle rotation and cutting oil circulation would work for flushing.
nah - surely if that worked, someone would have done it already
cradek: You dont want the EDM return current going through your spindle bearing!
well that's definitely true
Seb: do you want a 7I65 to use as a SPI guinea pig?
cradek: ever seen pictures of ball bearings "EDMed" by 60 cycle leakage current?
the 7i65 and the 7i64 are the two boards that have SPI on them, and the 7i64 is all digital right?
wow, that's twice the 7i33 on one plug?
Yes 7I64 is 24out and 24 in isolated I/O
7I65 is 8 axis servo interface (with 16 bit SPI DACs)
pcw: the 7i65 has some SPI ADCs too, right? that's what the reprap guys want
might have been useful for john too
Yes one 8 channel 12 bit ADC
ok cool, yes please send me one of those and i'll take a look at it at fest
I can't keep up with your cool new products.
The V-F is probably more suitable for noisy THC type applications
the spi doesnt need any special cables, it just runs over the 50-pin ribbon, right?
Yes 50 pin (Ive tried 15 feet)
cradek: thanks for fixing that unpack duh
seb_kuzminsky: still around?
can you put the halscope.cfg somewhere online?
the one you used for tracking the stepgen issue
alex_joni: the computer i have it on is powered off at home, i'm at work
i can dig it up this evening
alex_joni: i finally noticed that his configs are different for the different axes, and i only tested X
do you know which axis/axes he's having the overshooting problem on?
one other thing I noticed. I don't know if his information is more specific, but "55% FO" could mean 55% of normal, or 155% of normal
what a lousy bug report
I can imagine some issue at > 1.5x speed much easier than I can imagine it at >0,5x
well, that's a summary I think
a summarized translation even :)
regardless of the FO setting emc will never command motion above the ini settings
sure. I'm just imagining bugs in the free planner (that's used for jogs, right?) being more likely at >1x FO rather than <1x
i tested "g0" moves with F set to 60*MAX_VEL, that worked fine
I thought the bug report was about jogging ?
jepler: it is - i didnt realize at the time that jogging and traversing used different planners :-/
i'm not sure if it's a planner issue or a hostmot2 issue
oh, also i didnt know it was a jogging-only bug until i told the reporter i couldnt reproduce it...
it's been... frustrating
seb_kuzminsky: I'll try to drag him in here ;)
might be easier, or send your email to him
i dont speak any german :-(
he doesn't have the issue with 2.2.8 though
swedish or english would work
I hope he can speak a bit of english :)
i'll be here for another 1.5 hrs about, then again in about 5 or 6 hrs
it's after midnight here, and after 11pm in germany
so probably tomorrow
thanks for being the middle man
sure thing, too bad I can't be a better one ;)
I haven't finshed reading yet, but the idea of a HAL driver multiplying something you give it by 1.05 makes me see read
a component should do what it says it will do, the guy who puts them together is responsible for making sure they play well together
I think I'm in agreement there
if motion has a problem with stepgens, then it should fix itself or leave the fixing to the integrator