Hello Guest it is March 28, 2024, 08:56:31 AM

Author Topic: DRO anomoly with g68  (Read 5160 times)

0 Members and 1 Guest are viewing this topic.

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: DRO anomoly with g68
« Reply #10 on: December 04, 2011, 04:00:44 PM »
YEP strange indeed. IF you bump the look ahead up to 200 you will never see the rotated DROs they just stay black all the time. I thought teh Look ahead was only for CV. DID not know it would effect this as well

That is a new one to add to the Mach3, stranger than true book.

(;-) TP

Offline rcaffin

*
  •  1,052 1,052
    • View Profile
Re: DRO anomoly with g68
« Reply #11 on: December 04, 2011, 04:49:04 PM »
Hi TP

Actually, I think i understand almost exactly what is going on here. Fixing it would require a change to a fairly fundamental data structure - the data buffer, and that's why I suggested it would require Mach4 rather than just an update to Mach3.

The data buffer holds 'steps' of movement. Each step has certain data in it: X, Y, Z, A, B, C, time and maybe (don't know) one or two other things as well. The graphics display uses this data to update the on-screen display - usually correctly. It has the time variable to help it, as does the SmoothStepper.

However, to update the DROs requires at least one other bit of information, and that is rotation applicable to each step of data. That information is NOT in the step data buffer. Instead the DRO display routine uses the current rotation angle, and as we now know that can be wrong if the system is calculating many steps ahead. Cut down the look-ahead to somehting like 2 steps and the system usually does have access to the right rotation value.

To fix this problem would require that the data structure for the buffer be expanded to include rotation, and that would have many implications for the whole program. In principle it should be fairly easy to do, IF and ONLY IF, the software has been written in a modular or parametric manner. If it hasn't ... then a complete rewrite of some parts is indicated.

But then, the whole problem with subroutine nesting suggests that a complete rewrite of some parts of the code is required anyhow. Hum-tiddy-um.

Sorry about the techie details, but in another life I designed and wrote that sort of system software, for Real-Time systems and robots etc.. (Yes, they all worked.)

Cheers

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: DRO anomoly with g68
« Reply #12 on: December 04, 2011, 05:40:12 PM »
I really like the INFO please keep the lectures coming. Kinda reminds me of some of Arts lectures we got from time to time.

(;-)TP

Offline rcaffin

*
  •  1,052 1,052
    • View Profile
Re: DRO anomoly with g68
« Reply #13 on: December 04, 2011, 07:00:01 PM »
I really like the INFO please keep the lectures coming.
Yeah, sorry about that! I don't mean to lecture, but email/forum is so limiting in conversation.

Cheers
Roger

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: DRO anomoly with g68
« Reply #14 on: December 04, 2011, 07:37:20 PM »
ROger Not to worry Lectures are allowed here(;-) it is a good thing

(;-) TP