Machsupport Forum

Mach Discussion => General Mach Discussion => Topic started by: rcaffin on November 21, 2011, 02:38:54 AM

Title: VarCheck Monitor unreliable?
Post by: rcaffin on November 21, 2011, 02:38:54 AM
I was debugging a parametric program today (genuine spiral surfacing), and as usual things were not-quite-right. You know?
So I brought up the VarCheck diagnostic monitor so i could watch the critical parameters as the control point swept around the expanding spiral.
After much anguish, I finally realised that the displayed values bore absolutely no relationship to the path being traced.
Oh yes - the path as shown on the screen is correct, but the displayed values for the #n parameters used in calculating the path were simply ridiculous.

Is this just me again  ???, or has anyone else noticed that the display is sometimes wrong?

cheeers
Title: Re: VarCheck Monitor unreliable?
Post by: BR549 on November 21, 2011, 10:08:14 AM
I have never know them to be wrong so far, But ??????????


Can you give an example file where it will show wrong?

(;-) TP
Title: Re: VarCheck Monitor unreliable?
Post by: rcaffin on November 21, 2011, 04:12:53 PM
Hi TP

See attached. Works for  me.

Note - subroutine nesting again - may be involved.
Title: Re: VarCheck Monitor unreliable?
Post by: BR549 on November 21, 2011, 04:21:22 PM
Remember Back when I said That ART had eluded that it is possible in nested subs for the Vars to go weird. It is how Art programed the Var monitor and WHEN mach3 calculates the values as the Gcodede program runs and gets stacked into the que.

This looks to be one of those cases where the math is either outrunning the var monitor or is LAgging behind it.

Try running it in single step mode to see IF the Var Monitor runs correctly.

(;-) TP

Title: Re: VarCheck Monitor unreliable?
Post by: rcaffin on November 21, 2011, 04:57:23 PM
Remember Back when I said That ART had eluded that it is possible in nested subs for the Vars to go weird. It is how Art programed the Var monitor and WHEN mach3 calculates the values as the Gcodede program runs and gets stacked into the que.

This looks to be one of those cases where the math is either outrunning the var monitor or is LAgging behind it.
Watching it, that was the impression I got. I think the calculations and the VarCheck monitor are getting way ahead of the actual data output. I can see the radius variable getting to 20 (the final value) long before the display gets there. In this case, I don't think the nested subs actually have anything to do with the 'problem'.

Quote
Try running it in single step mode to see IF the Var Monitor runs correctly.
Yep, correct display.

Hum - solving that problem is not easy if Mach is going to calculate ahead like that and stack up the output data to be streamed. Hum ... It may be necessary to add a little text message to the Monitor screen advising that dynamically changing results may not be valid except in single step.

Can/should Mach calculate ahead like that, and queue up the output data to be sent at the clock rate? With a low-powered processor from a decade ago, the answer would have to be yes. With a modern very fast processor it is unlikely to be needed, but changing Mach to be in very fast single-step mode all the time might be a serious effort and of questionable value most of the time. Mach has to be able to do the look-ahead at corners as well. Hum ... interesting.

Cheers
Roger
PS 'Art had alluded ...'   To elude is to avoid or escape from. Sorry - pedantic spelling enthusiast.

Title: Re: VarCheck Monitor unreliable?
Post by: BR549 on November 21, 2011, 06:43:26 PM
When you are running a buffered system and doing parametric GCODE I would EXPECT it to be ahead of the buffer. That is one of the reasons that we don't have conditional (;-) it would be very hard to be able to calculate things that have not happend yet.

A good example is when you start extracting Axis positional values into your formulas.

One way of stalling the buffer load is to inject G4P0 into the code at strategic places the G4P0 will cause no delay BUT it delays the bufferload until the last minute and MAY make the Var monitor read better .

(;-) IF you are looking for a spelling scholar you are in the WRONG forum (;-) LOLOLOLOL

Title: Re: VarCheck Monitor unreliable?
Post by: rcaffin on November 21, 2011, 07:13:04 PM
Hi TP

When you are running a buffered system and doing parametric GCODE I would EXPECT it to be ahead of the buffer. That is one of the reasons that we don't have conditional (;-) it would be very hard to be able to calculate things that have not happend yet.
Yes to the queing of data, but NO to the general matter of conditionals (IF statements). There is no reason why Mach could not have conditionals per se - most other CNC 'languages' or variants do have them. Provided the IF statement does not try to query a 'current position value' it is perfectly reasonable. Anyhow, one can have 'IF' statements in Mach if one really has to. It's just messy.

Quote
A good example is when you start extracting Axis positional values into your formulas.
Agree - very tricky stuff! But ... software for touch probes manage.

Quote
One way of stalling the buffer load is to inject G4 P0 into the code at strategic places
I just tried that - works quite well! OK - usable for diagnostics for sure.
Thank you very much for this idea, and for pointing out the queuing problem.

Quote
(;-) IF you are looking for a spelling scholar you are in the WRONG forum (;-) LOLOLOLOL
Yeah, forgive me. I mean well, honestly ... :-)

Cheers
Roger
Title: Re: VarCheck Monitor unreliable?
Post by: BR549 on November 21, 2011, 07:39:49 PM
HIAY ROGER, Systems that do conditional are mainly realtime control systems NOT buffered systems and can interact directly with the ouput data stream up to the point the motor moves. In mach3 you cannot and have decent movements. You could set the look ahead to 1 and then only have the basic que as the buffer. I have no idea the size of the que but it is small.

I did ask Art long ago about the conditional siode I will try to look back though the notes to find the reason he gave for it being removed. In its place we got the CB macro language and a gateway to the Gcode side using it.

(;-) TP

Title: Re: VarCheck Monitor unreliable?
Post by: rcaffin on November 21, 2011, 09:02:44 PM
Systems that do conditional are mainly realtime control systems NOT buffered systems and can interact directly with the ouput data stream up to the point the motor moves. In mach3 you cannot and have decent movements. You could set the look ahead to 1 and then only have the basic que as the buffer. I have no idea the size of the que but it is small.
With all due respect to everyone concerned, (and in the spirit of an academic debate), that restriction is just not true.

I had better explain here that I have been creating real-time computer-controlled systems and robotic systems from scratch (HW & SW) for 40+ years. I have debugged OSs, compilers and other SW systems. I have even modified central processors, back in the days when that was possible. (PCBs with TTL.)

For that matter, I have placed conditionals or IF statements in Mach code on a number of occasions. True, I was not using any real-time data from the motors in the conditionals, but they were the equivalent of IF statements. And they worked just fine.

Quote
I did ask Art long ago about the conditional siode I will try to look back though the notes to find the reason he gave for it being removed.

Please - I would be very interested. I am certain the restriction can be removed. After all, disguised conditionals have been used in Mach for many years.

Quote
In its place we got the CB macro language and a gateway to the Gcode side using it.
Wonderful benefits of course. But you can have conditionals in CB. Not a restriction.

I like Mach, and I want to see it develop some more.

Cheers
Roger
Title: Re: VarCheck Monitor unreliable?
Post by: BR549 on November 21, 2011, 09:14:34 PM
AH but when you run it in CB it is a sub system of the Gcode AND it is NOT really synced with the Gcode side. Heck it is NOT synced with itself for that matter.

Art always stated you would never see it in Mach3. If it were possible it would have been FAR easier to use the existing Conditional in the original Base code(EMC) than develope the CB macro system in lue of the condition Gcode.


At least from an old chip sligger perspective, (NOT a programmer (;-) ) and yes I have done conditional Gcode/hybridCB programing  using Macros and Gcode and it AINT Pretty and can be CHOPPY in execution as well.



But it is what it is, (;-) TP
Title: IF program
Post by: rcaffin 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
Title: Re: VarCheck Monitor unreliable?
Post by: BR549 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
Title: Re: VarCheck Monitor unreliable?
Post by: rcaffin 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