Hello Guest it is July 08, 2020, 01:24:21 AM

Author Topic: VarCheck Monitor unreliable?  (Read 4235 times)

0 Members and 1 Guest are viewing this topic.

Offline rcaffin

*
  •  1,029 1,029
    • View Profile
IF program
« Reply #10 on: November 21, 2011, 10:38:19 PM »
The attached program demonstrates a very convoluted way of implementing an IF conditional in Mach, without recourse to CB or macros. It's pure g-code.
This method works reliably, and I have used the method several times in functional programs. I am sure others have done the same before me.

To explain: the program draws a 10-petal flower with the petals at equal angles (36 degrees), but two petals are actually skipped. There are gaps where they should be. Which petals are skipped is set by two parameters. The result is shown in the JPG.

My point is that if this works just fine, then putting an IF statement into Mach g-code, like EMC or Fanuc, is entirely possible. The end result would in effect be that the Mach interpreter will be doing almost the same thing inside.

Yes, I am argumentative and obstroplous. But this works.

Cheers

Offline BR549

*
  •  6,932 6,932
    • View Profile
Re: VarCheck Monitor unreliable?
« Reply #11 on: November 22, 2011, 10:21:56 AM »
I have looked at the Or and Xor but never could relate them to anything usefull. I'll give it a study BUT it looks to be very difficult to work into something usefull.

In the example what is the condition that is referenced to drive the function. I see the subs and the G68 CR in use. Just can't wrap my head around the IF conditional (;-)

(;-) TP

Offline rcaffin

*
  •  1,029 1,029
    • View Profile
Re: VarCheck Monitor unreliable?
« Reply #12 on: November 22, 2011, 03:47:54 PM »
I have looked at the Or and Xor but never could relate them to anything usefull. I'll give it a study BUT it looks to be very difficult to work into something usefull.
Yes, it is messy to use, but it DOES provide the IF function. So it CAN be done right now in Mach. Wouldn't it be better if it was done properly in that case?

Quote
In the example what is the condition that is referenced to drive the function. I see the subs and the G68 CR in use. Just can't wrap my head around the IF conditional (;-)
OK, I will try to explain. Let me know if I succeed - or don't. :-)

There's a loop creating equi-spaced petals. #12=10 defines how many petals. #13=[360/#12] gives the angle between each petal.
There's a parameter counting each petal sub. That's #1.
But for some reason or other, I want to miss petals 3 and 6. Maybe there were clamps in those positions (actual use once). Those positions are specified by #10 and #11.

Subroutine o10 is called to create each petal. It does some logic checking and then (maybe) calls subroutine o11 to do the actual drawing. If the counter #1 matches either of the specified positions then the (maybe) turns out to be (does not).

Underlying this are two things.
1) The first is how logical variables are handled in Mach g-code - or many other programming languages. FALSE is always equal to 0, while TRUE is non-zero, often 1. Actually, this derives from the lowest-level machine language interpreted by the CPU in the computer. So if you do some logic, you end up with either 0 or 1.
2) The other thing is the subroutine call m98 p10 L#4. If this call translates to L1 then the subroutine o10 is called, once. But if it translates to L0 then the subroutine is NOT called. So the logic variable #4 (in my case) determines IF the subroutine is called or not.

Much of the logic in the test program is for combining two different cases - petals 3 and 6. If you only have one case the logic is much simpler. It's what's called Boolean Logic, and fundamental to computers. But it is very simple, just 1s and 0s.

The XOR is a substitute for the NOT function - logic inversion. Messy, but it works. I would suggest that the NOT function should be added to Mach - it would not interfere with anything else in Mach. To explain: NOT(1)=>0, and NOT(0)=>1.

Does this work?

Cheers