Hello Guest it is June 25, 2019, 08:54:33 PM

Author Topic: G31 Probe problem  (Read 36410 times)

0 Members and 1 Guest are viewing this topic.

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: G31 Probe problem
« Reply #60 on: August 03, 2011, 01:13:35 PM »
I was staying off the sleep thing to try to avoid getting too heavy with the principle of the semaphore thing.

That said sleep does NOT return control back to Mach per se. What it does is say to the (windoze) scheduler, "nothing to see here - please move on". So if you imagine the scheduler splitting time between all the windows processes, when it comes to the CB thread it effectively skips it and moves on to the next process in the list (and even in a "bare" system there are a lot more processes vying for the CPU than just Mach). Without it, the CB thread would accept it's "turn" and waste CPU cycles doing several iterations of a loop.

So.... what value should we give to sleep? Well it's an eductated sort of guess. If the REQUEST we've made is something like code "G1 X10" then we can bet it's going to take more time than (say) setOEMDRO. So in the former we might choose a sleep 100, whereas for the latter we might choose sleep 10 or even sleep 1 - it's a game of compromise. The name of the game is to try to save CPU cycles without causing too long a wait AFTER the semaphore has been set by Mach. Note that this does NOT change the logic of the program. We're only trying to be nice to the CPU.

If Art DID build a sleep into isMoving then I would humbly suggest that it was a mistake and not documenting the fact a further mistake. But that would just be MHO if in fact he did.

Ian
« Last Edit: August 03, 2011, 01:35:24 PM by stirling »

Offline BR549

*
  •  6,873 6,873
    • View Profile
Re: G31 Probe problem
« Reply #61 on: August 03, 2011, 03:01:30 PM »
I think we need a CB /Gcode traffic cop (;-)

I don' t think it was ART as the while Ismoving would hog the CPU without a sleep(). I may be wrong and it was only a test version that had the built in sleep() . I have years of trouble notes in several volumes of books. The longer I stay away from them the fuzzier they get.

I was looking at the Cubloc PLC system and they seem to have  figured out the integration between their ladder logic and their basic language. It stays in thread sync with each other. Otherwise havic would be the results.

(;-) TP
« Last Edit: August 03, 2011, 03:05:10 PM by BR549 »

Offline BR549

*
  •  6,873 6,873
    • View Profile
Re: G31 Probe problem
« Reply #62 on: August 03, 2011, 03:15:17 PM »
I think it was this Version update.

January 29/2009
Release 3.042.021
-- Bug fix to some Arcs feedrate..
-- Installer was missing a file, making a false error message popup
-- CPU usage lowered on Macros that fill Mach3's buffers
-- Macro's can no longer overrun the buffer when adding moves
-- Feedhold fixed to pause motion coming from the script buffer
-- Ismoving() script call no longer will tax the CPU

My other point has always been IF mach3 had condition Gocde most of this would be a moot/mute? point as most would not need the CB side for machine work. You will notice that Fanuc MacroB is a VERY useful macro language for Gcode and it HAS access to all the system parameter/var 's.

Then the CB would be basically for system enhancements.  (my opinion (;-) )

(;-) TP
« Last Edit: August 03, 2011, 03:21:58 PM by BR549 »

Offline Tweakie.CNC

*
  • *
  •  7,817 7,817
  • Super Kitty
    • View Profile
    • Tweakie.CNC
Re: G31 Probe problem
« Reply #63 on: August 04, 2011, 02:30:40 AM »
Hi Guys,

So, should we be using the Sleep() command within the while...wend or not ??

Tweakie.
Success consists of going from failure to failure without loss of enthusiasm.  Winston Churchill.

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: G31 Probe problem
« Reply #64 on: August 04, 2011, 04:45:50 AM »
Hi Tweakie

Yes. - and be creative with the value.

Just for fun - here's an alternative view of how you can use it. Suppose we guess or by experience know or perhaps even work out, that some "code" request is going to take for arguments sake in the order of 10 milliseconds. How about the following?

code "something"
sleep 9
while isMoving()
  sleep 1
wend

This attempts to "rest" the CPU optimally whilst giving the fastest response. Is it worthwhile or anal?  ;D - you decide.

Ian

Offline Tweakie.CNC

*
  • *
  •  7,817 7,817
  • Super Kitty
    • View Profile
    • Tweakie.CNC
Re: G31 Probe problem
« Reply #65 on: August 04, 2011, 09:00:47 AM »
Thanks Ian.

Tweakie.
Success consists of going from failure to failure without loss of enthusiasm.  Winston Churchill.

Offline BR549

*
  •  6,873 6,873
    • View Profile
Re: G31 Probe problem
« Reply #66 on: August 04, 2011, 09:53:48 AM »
my rule of thumb is USE Sleep() when there is an update to a VAR or DRO or LED to take place and something has to take place based on  those updates.

The Gcode seems to be stacked into a Que and seems to stay in order most of the time the CB updates and calls are all over the place and need supervision(;-)

I would be nice if someone were to actually MAP out the process so we would KNOW how the process really works. CB all by itself works well. It is when you mix it with Gcode that most problems occur.  Perhaps a GATE can be created to keep the process stable?????   I know it works to keep goats in the barnyard(;-)

(;-) TP
« Last Edit: August 04, 2011, 09:58:07 AM by BR549 »

Offline BR549

*
  •  6,873 6,873
    • View Profile
Re: G31 Probe problem
« Reply #67 on: August 04, 2011, 10:06:25 AM »
SIDE BAR:  Has anyone ever tried a G31 with an arc?

(;-) TP
Re: G31 Probe problem
« Reply #68 on: August 04, 2011, 12:23:34 PM »
geez, i have been jinxed! never had a problem with the g31 until i read this thread. headed out to the machine to cut and what happened? mach  ignores the g31 at the start of the m3 macro and just fires the plasma torch. changed the g 31 to g28.1 and still happened. put the g28.1 into the gcode and works flawlessly. using the g28.1 also got rid of the ramping problems of the z axis probing. with the g31 could only probe at  40 ipm reliably. with g28.1 probing at 100 ipm.thanks for the info Br549.

Offline BR549

*
  •  6,873 6,873
    • View Profile
Re: G31 Probe problem
« Reply #69 on: August 04, 2011, 12:43:04 PM »
HIYA Triple, You were not jinxed you were enlightened(;-) THe stars aligned properly and you saw the light.

(;-) TP