On Monday 4 December 2006 11:54, [EMAIL PROTECTED] wrote: > That means you don't actually have any velocity headroom, > and will lead to following errors if you try to run at > 30 ipm.
I figured I'd set it to the max and see what happened. I'll back the top limit off to 20 in/min, which is marginally more sane, with the stepgen values a smidge higher. I've been setting the stepgen values to 10% over the other values, rounded up to the next easy value to type. Part of this is that I'm still trying to figure out how all those mysterious parameters interrelate. Which is why I'm posting these voluminous notes: I'll take all the advice I can get! > Feed override set less than 100%? Nope. I bumped the initial jog speed up to 30 in/min. AXIS (GUI of choice right now) starts at some nose-pickin' jog speed where I can count steps on my fingers. Sheesh... I also set up a little g-code routine that just runs around the square, using G0 or G1 moves with various F settings, and watched those corner radii. Ouch! > I think most people with Sherlines are using values in > the neighborhood of 10-20 for acceleration, And, IIRC, often complain of "losing steps" and suchlike, all of which would be explained by too much acceleration. Values around 10 start up with a -snap- before producing a following error, so that's not right. Mostly, this all (seemed to) work with BDI a while ago, so something has changed. I'd have to do some excavation to find those old INI files and see what I was using for accelerations. ISTR maybe 5 or so... > do the initial tuning with just stepgen and a signal > generator. If you can walk me through that process (or point me to the doc, which I probably missed), I'll give it a go. Signal generators, I got! > (And of course after each change you > need to restart EMC.) Fortunately, the desktop icon I made stays selected, so I just kill the current session, whack Enter twice, and away it goes... > Does the controller sample the step signal at some fixed > rate or does it get an interrupt when the step input > changes? If sampled, what is the rate? When does it > sample the direction input? After it sees a falling edge > on step? Interrupts on the falling edge of Step, samples the Direction input right then, stores both for the next pass through the Main Loop. That's why I set the HAL values the way they are, although all the hold times are far longer than the actual path length through the code. Therefore, the code ignores Direction flobbulations unless there's a Step pulse in the middle, in which case it does whatever the Direction input says to do at the falling edge of Step. I've tested it up beyond 8000 steps/sec (signal generator in, watching the outputs on a 'scope) and the actual rates coming out of the parallel port never get close to that, so I'm pretty sure the firmware isn't topping out. But I have been wrong before... I'm thinking of gimmicking up a counter to mimic a stepper by decoding the winding signals into up and down counts. Then I'd know for sure what was coming out the far end of this software pipe: if the count deviated from the "right" answer, we wouldn't worry so much about physics. Back to packing for my trip. I'd rather play in the shop! -- Ed ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
