Chris Morley wrote: > > Chris: can you try setting max_velocity to .8 so theres no chance the > > trajectory planner can outrun the stepgenerator? I think all bets are > off > > without this. > > > > I will try this later hopefully tonight. > Interestingly the reason I was using 100 inches per minute (1.667 ips)... > Pncconf has a 'tune test' that sets the hostmot2 stepgen's > max velocity and max acceleration. It would let me move at > aprox 150 inches per minute. It does not keep track of following error > though. So I detuned it to 100 ipm and ran EMC. I'm not sure how > hostmot2's stepgens decide on whether it can or cannot move at a > specific drive timings and max speed etc.
I take this to mean that your "tune test" changes hm2 stepgen.position-cmd at a rate of 150 ipm without checking if position-fb if keeping up. I think if you check, you'll find position-fb moving at only 53.6 ipm (0.893 ips as derived earlier), because that's the fastest your timings (and leadscrew pitch) allow it to go. There are two things that affect what the hm2 stepgen max speed is. The first is the four timing parameters, which provides a kind of physical max, an absolute upper bound on the frequency of the output signal. The other is the .maxvel parameter, which may optionally specify a more restrictive limit. The hal file you posted has .maxvel set to 0, which is the secret handshake for "go as fast as the timing parameters allow". > But all that aside I still don't see why moving negative and positive > is so dramatically different - but then again I know nothing about > stepgenning and trajectory planning :) I think Jeff's analysis of the firmware source code can explain a big difference. When the hm2 stepgen is stopped (when position_cmd = position_fb), it relaxes to Dir being zero. If the first step is in the Dir=0 direction (positive on your machine, i think), it can step right away. But if the first step is in the Dir=1 direction, it has to switch the Dir line before it can take the first step. Your .ini file specifies a 200 microsecond delay every time the Direction pin changes, before starting stepping. So if it's starting from a stand-still, and going in the negative (Dir=1) direction, then it falls 200 microseconds behind the trajectory planner before it even starts moving. Then, since the TP runs away from the stepgen in this config (it's allowed to move faster than the stepgen is), stepgen never catches up, and it ferrors. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
