AXIS 1.4a0 & EMC2 2.0.4 (stock iso + all updates) This story takes a while to set up...
While cutting out a cam that involves lots of fiddly motions, my (mostly stock) Sherline mill gradually forgot its origin position and would have, had I not popped the Esc key, gnawed its way right through the fixture. I set up another blank and, dang, the same sort of thing happened. A bit different positions, but equally bad. So I took everything apart, cleaned & lubed & tweaked, made a great improvement in the overall mechanical goodness, chucked up another blank, and -blap- same story. I hate it when that happens. The failures are similar, but not identical: the XY position gradually drifts in off into the +X/-Y quadrant and the Z position drifts downward. The final G0 move away from the (ruined) blank should be vertically upward, but typically goes vertically downward and thunks the fixture. The AXIS preview looks fine, so the g-code is correct. Admittedly, it took a while to get there, but it's OK. After fiddling with numerous dead ends, I reinstalled the whole Ubuntu/EMC thing from scratch. Starting from the stepper_xyza base, I set the velocity & acceleration values to drive the mill at well under its ratings: 0.25 ips max velocity, 1 in/sec^2 max acceleration. This is achingly slow, but it eliminates motor dynamics from the problem: I can -watch- the motors ramp up to their peak nose-picking speed! This is on a Dell Dimension 4550, 2.4 GHz P4, 1 GB RAM, so I set the base period = 25 us. I then added steplen / stepspace / dirsetup / dirhold statements to the HAL file to put 4 ticks between each edge going to the controller box. That eliminates noise and pulse speed from the problem. With a minimum pulse length of 4 ticks, the maximum motor step rate should be 8 ticks = 200 us. That's well under actual rate required by the max velocity, so it's not producing following errors even with the slow pulses. Now, under manual control with the "jog speed" dialed back to 1 ipm, I have a solid failure. Tapping PgUp and PgDn (or the other axes, as well) generally does what I'd expect. However, -sometimes- the motors turn (slowly!) the wrong way; start correctly, jerk backwards, then run backwards; run correctly for a short time and then stall; and so forth. I attached a digital 'scope to the Z axis step & direction signals. They're clean digital pulses, good amplitudes, no noise worth mentioning. The step signal shows the expected ramping-up and ramping-down frequencies at about the right rates. However, the direction signal misbehaves! Erratically, occasionally, but reproduceably (if I'm patient), the direction signal changes while the step signal is pulsing. For example, it will change from 1 to 0 to 1 (high - low - high) while I'm holding down the PgUp key (not calling for a direction change). The other axis behave similarly. The changes seem to be in the tens-to-hundreds of millisecond range and generally occur at the leading or trailing ends of the motion, not in the middle, but that may just be my observations so far. While the direction signal "glitches", the step pulses continue to ramp up or down, so it seems as though something is losing track of which the motion direction for a while . The resulting transients whack the motors pretty hard; they're obviously not carefully planned direction changes! Note that the parallel port is disconnected from the driver box, the spindle motor is off, and this is pure software from the PC. Nothing mechanical at all! This is the most complex part I've made, so the mill was running longer and doing more motions than ever before, which would cause the misbehavior to add up. However, I -think- it's the first part I've done since the most recent EMC updates, although I'm ashamed to admit I haven't been logging what I've been doing against those changes. It -definitely- didn't misbehave like this back in the BDI days. I -think- the first few EMC2 versions were OK, but I can't be sure because it's intermittent enough that I might have not noticed slight errors on the simpler parts. It's not like I'm doing really high-precision stuff here... I did manage to make one good cam before the latest updates, so it -did- work correctly a week or so ago. Anyhow, I think I've eliminated all the things that could cause the problem outside of the EMC2 code itself, but if there's any other information I can provide or debugging I can do, I'm willing, because it flat out doesn't work for me right now! Thanks... -- 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
