Hello Guest it is July 14, 2020, 07:37:54 PM

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

0 Members and 1 Guest are viewing this topic.

Offline rcaffin

*
  •  1,029 1,029
    • View Profile
VarCheck Monitor unreliable?
« 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

Offline BR549

*
  •  6,932 6,932
    • View Profile
Re: VarCheck Monitor unreliable?
« Reply #1 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

Offline rcaffin

*
  •  1,029 1,029
    • View Profile
Re: VarCheck Monitor unreliable?
« Reply #2 on: November 21, 2011, 04:12:53 PM »
Hi TP

See attached. Works for  me.

Note - subroutine nesting again - may be involved.

Offline BR549

*
  •  6,932 6,932
    • View Profile
Re: VarCheck Monitor unreliable?
« Reply #3 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

Offline rcaffin

*
  •  1,029 1,029
    • View Profile
Re: VarCheck Monitor unreliable?
« Reply #4 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.

Offline BR549

*
  •  6,932 6,932
    • View Profile
Re: VarCheck Monitor unreliable?
« Reply #5 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

Offline rcaffin

*
  •  1,029 1,029
    • View Profile
Re: VarCheck Monitor unreliable?
« Reply #6 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

Offline BR549

*
  •  6,932 6,932
    • View Profile
Re: VarCheck Monitor unreliable?
« Reply #7 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

Offline rcaffin

*
  •  1,029 1,029
    • View Profile
Re: VarCheck Monitor unreliable?
« Reply #8 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

Offline BR549

*
  •  6,932 6,932
    • View Profile
Re: VarCheck Monitor unreliable?
« Reply #9 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
« Last Edit: November 21, 2011, 09:16:31 PM by BR549 »