Re: EMC Bug List

[Paul <paul.corner-at-tesco.net>]

Hi Matt

With the number of RH6.x/RTL3.0 (BDI) installs around the globe, is there 
much to be gained in continued support of RH5.2 and RTL0.9J systems ?

A few comments mixed in below -

On Thursday 18 Jul 2002 5:18 am, Matt Shaver wrote:
> Actually, what I meant was, "Is there any reason to keep using
> RH5.2/RTL0.9J over RH6.2/RTL3.0 ?".

> Bug #2 - Angular axes move slow/don't work

I think John Guenther might be on the right track when he suggested it might 
be a granularity issue - The commanded moves are scaled by INPUT_SCALE just 
before the values are passed to the pulse generator (or DACs) which I believe 
might be the cause of the problem.


> Bug #3 - "Units" handling is inconsistent

Switching between G70 and G71 with an angular axis results in the displayed 
position being subject to a conversion factor of 25.4

> Bug #4 - TkEMC comes up in "robot mode" (with steppermod)

This is down to differences between the freqmod and steppermod sources. One 
of the dangers of having multiple sources for what is basically the same 
module results in some changes not being propagated across.


> Bug #5 - Annoying nonsensical errors

> Bug#6 - Joel's Homing Bug

I *think* I have found the offending line where backlash is added during a 
homing cycle. Need to set up a test machine to verify this before a change is 
committed that could possibly replace it with another bug.

> Bug #6 - Joel's Software Limits Bug
> Bug #7 - M1 Bug
> Bug #8 - G-code Init Bug
> Bug #9 - .var File Bug
> Bug #9 - Coordinate Offsets Not Initialized

Not sure if I have heard anything about Bugs 6 to 9 - Quite a bit has changed 
since the original BDI-2.04 was released.

> Bug #10 - Too many ifdefs
> Need a good housecleaning, switch to autoconf/automake, etc.

Not too sure an autoconf would help here - Most of the platform specific 
stuff is handled by the $PLAT.def files in rcslib/etc. Most of the #ifdefs 
surround various #includes. The bulk of these could be placed in to dedicated 
$PLAT.h files without too much trouble. Reading through the sources, there 
isn't too much code that is subject to ifdefs - In the places where it is, it 
is because the same source is used in both realtime and nonrealtime. Having 
seperate sources would put us back in the situation where bug fixes or 
improvements don't get propagated across.

Regards, Paul.