Machsupport Forum

Mach Discussion => General Mach Discussion => Topic started by: rcaffin on December 03, 2011, 05:02:48 PM

Title: DRO anomoly with g68
Post by: rcaffin on December 03, 2011, 05:02:48 PM
Continuing my efforts to find ways to misuse Mach and subroutines (yeah, I know).

I was milling three slots at 120 degrees, with multiple Z passes. It seemed much the easiest to work out how to mill one slot the way I wanted, then to make that into a subroutine and call it three times with a g68 a0 b0 r(angle) command for each subroutine. So far so good, and the slots were all milled properly.

But I nearly had a fit when I looked at the DROs!

What I was expecting to see were the X & Y DROs showing the coordinates for the slot: X varying over the slot length and Y fixed at plus and minus values giving the slot width. Well, for the slot at 0 degrees that is exactly what I got. For the slot at 120 degrees I got the same numbers but in red, signifying a rotation. Again, so far so good. But then, before the machine finished milling that slot, the numbers went black and gave very different values. A bit of thought showed that the DROs were quite correct: the values being displayed in black were the unrotated XY values. This was repeated for the 240 degree slot of sourse.

Now I do understand (thank you TP) that Mach calculates ahead and uses a data buffer to queue stuff out. But why does it lose track of the rotation? It is almost as though the data in the queue is missing the relevant rotation value so that Mach uses the value from the current look-ahead calculations - which at some stage is going to be wrong for the display. Most disconcerting when watching the DROs!

Cheers
Title: Re: DRO anomoly with g68
Post by: BR549 on December 03, 2011, 06:06:18 PM
SURPRISE (;-)

There are many things deep in Mach3 that were never really finished, some of the toolpath displays are one of them. The dros are another in deep G68 arrays that invlove SUBs.

I noticed that you see that SUBS seem to be the common denominator in most of our discussions (;-).

I take it that the program did cut correctly ??? Just looked scary on the display?

(;-) TP

Title: Re: DRO anomoly with g68
Post by: BR549 on December 03, 2011, 06:33:59 PM
IF you program the cuts to use the G68 but not the subs does it do the same thing with the DROs?

Currious, (;-) TP
Title: Re: DRO anomoly with g68
Post by: rcaffin on December 03, 2011, 07:03:55 PM
> I noticed that you see that SUBS seem to be the common denominator in most of our discussions (;-).
Actually, I don't think the subroutines are important in this case. I think it is just the length of the queue which is causing the problem.

Yes, the program did cut correctly. It also displayed correctly in the graphic windows. Just the DROs were 'off'.

The attached condensed version has but one level of subroutine and displays the same problem, although to slightly more alarming degree. I kept one level as a means of generating enough data to fill out the queue buffer, but I am sure the behaviour would be the same if that layer was unrolled as well. Should anyone wish to play with it, feel free.

Cheers


Title: Re: DRO anomoly with g68
Post by: BR549 on December 03, 2011, 08:58:35 PM
OK did some testing just for the kicks AND it was not the G68 it was not the parametrics, it was not the size of the buffered data.

It was the way you wrote the subs.

I redid the sub a differrent way where and it displayed fine and the dros were fine.

Once you start with subs Mach can do funny things.

(;-) TP
Title: Re: DRO anomoly with g68
Post by: BR549 on December 03, 2011, 09:28:00 PM
OK Had to find the root cause so a little more testing.

It was not so much the structure of the sub BUT the use of the G69 in between to reset the rotatoion to zero. It was not really needed and proved to be the cause of the problem.

Remove all the G69s from the program then add one JUST BEFORE the M30 call to end the program. That will set the rotation back to Zero at program end.

It runs fine here without the abnormal DRO switching.

Just had to find out, (;-) TP
Title: Re: DRO anomoly with g68
Post by: rcaffin on December 03, 2011, 09:48:00 PM
Remove all the G69s from the program then add one JUST BEFORE the M30 call to end the program. That will set the rotation back to Zero at program end.
It runs fine here without the abnormal DRO switching.

OK, tried that, removed two g69 commands leaving the last one in place at the end of the program. I still got the abnormal DRO readings.
If you did something to prevent the abnormal behaviour, could you post your code please so I can see what it was?

<soapbox>
But having three g69 commands in place is perfectly legal and, some might argue, good programming practice. Cancel any rotations before going on to the next block of code. So I contend the abnormal DRO behaviour is still something which should not be.
That Mach has a few quirks - no argument!
</soapbox>
Title: Re: DRO anomoly with g68
Post by: BR549 on December 04, 2011, 11:14:15 AM
Switching back and forth with the G69 is not needed in this case. You are stilll in the same plane you could also add to the rotation as a inc move.

But switching back and forth with subs is triggering the quirk Inside one of the subs. It did NOT do this when testing the same routine without subs

I ended up testing your routine as is  but just removed all the G69s except for the last one placed just before the M30. That way the machine is rotated Back to normal as the program ends. It worked here that way.

The original code will still cause the quirk.

You may want to turn this over to Andrew/ Brian for fixing.

"I " agree it SHOULD NOT DO THIS, but you are preaching to the choir (;-)

(;-) TP

Title: Re: DRO anomoly with g68
Post by: BR549 on December 04, 2011, 11:31:22 AM
Here is the test sample I used based on your code. Please let me know what YOU find testing it.

What is your look ahead setting???

It works here without the Quirk  V.020.

(;-) TP
Title: Re: DRO anomoly with g68
Post by: rcaffin on December 04, 2011, 03:17:08 PM
Hi choir :-)

Your V3 looks identical to my V2 with two exceptions: you have a switch to metric at the start and I have a g69 at the start. I'll stick my neck out and claim that neither is significant.

Yes, your V3 still has the anomolous DRO behaviour on my simulation set-up (in my office). That figures, after all.

So ... I checked on my look-ahead depth. It is as-delivered and set to 20 (lines). Hum ... interesting.
So I changed that to 2 lines, and tried my heavily nested V1, my simplified V2, and your v3.
Your v3: no problem
Simplified V2: no problem
Heavily nested V1: no problem

I have not got around to trying out a steadily increasing level of look-ahead to see where the problem starts, but I do not think we have to look any further that that. I was thinking that 'look-ahead' meant just that, LOOK, but apparently it really means 'calculate ahead'.
Since the heavily nested V1 runs cleanly, I suggest that we can dismiss subroutine nesting from consideration here.

Yep, an issue for Mach4 I think.

Cheers
Title: Re: DRO anomoly with g68
Post by: BR549 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

Title: Re: DRO anomoly with g68
Post by: rcaffin 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
Title: Re: DRO anomoly with g68
Post by: BR549 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
Title: Re: DRO anomoly with g68
Post by: rcaffin 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
Title: Re: DRO anomoly with g68
Post by: BR549 on December 04, 2011, 07:37:20 PM
ROger Not to worry Lectures are allowed here(;-) it is a good thing

(;-) TP