Hello Guest it is March 08, 2021, 05:15:32 AM

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

0 Members and 1 Guest are viewing this topic.

Offline rcaffin

*
  •  1,035 1,035
    • View Profile
DRO anomoly with g68
« 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

Offline BR549

*
  •  6,944 6,944
    • View Profile
Re: DRO anomoly with g68
« Reply #1 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

Offline BR549

*
  •  6,944 6,944
    • View Profile
Re: DRO anomoly with g68
« Reply #2 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

Offline rcaffin

*
  •  1,035 1,035
    • View Profile
Re: DRO anomoly with g68
« Reply #3 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


Offline BR549

*
  •  6,944 6,944
    • View Profile
Re: DRO anomoly with g68
« Reply #4 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
« Last Edit: December 03, 2011, 09:05:06 PM by BR549 »

Offline BR549

*
  •  6,944 6,944
    • View Profile
Re: DRO anomoly with g68
« Reply #5 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

Offline rcaffin

*
  •  1,035 1,035
    • View Profile
Re: DRO anomoly with g68
« Reply #6 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>

Offline BR549

*
  •  6,944 6,944
    • View Profile
Re: DRO anomoly with g68
« Reply #7 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

« Last Edit: December 04, 2011, 11:15:51 AM by BR549 »

Offline BR549

*
  •  6,944 6,944
    • View Profile
Re: DRO anomoly with g68
« Reply #8 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

Offline rcaffin

*
  •  1,035 1,035
    • View Profile
Re: DRO anomoly with g68
« Reply #9 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