Messages

1221

General Mach Discussion / Re: G31 Probe problem

« 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?  - you decide.

Ian

1222

General Mach Discussion / Re: G31 Probe problem

« 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

1223

General Mach Discussion / Re: G31 Probe problem

« on: August 03, 2011, 09:51:05 AM »

There really is no big mystery to this - it's standard inter-thread communication - as practiced in a gazillion systems from enterprise data bases to games. There is no need to "sprinkle" waits here and there, just put them where they're needed and not where they arn't. This isn't alchemy. 

When CB does (for example) a setOEMDRO, CB is not setting anything, it's REQUESTING Mach to set the DRO.

More generally, the client thread (CB) REQUESTS that the SERVER thread (Mach) do something. That request sits in a buffer until the SERVING thread (Mach) has time to action it.

IF the client thread in no way depends on that request being actioned then it can just carry on. HOWEVER - If the client thread depends on that REQUEST being actioned before it can successfully continue according to the logic of the program, it MUST wait for the server thread to let it know it's done it.

There is however a second circumstance when the client thread needs to wait on Mach signaling it's completed the request. In some multi-threading apps, it's appropriate that the buffer used is a FIFO queue. This means that several requests can be sent to the SERVER. However, AFAIK, the buffer used in the Mach/CB context is a single - one-shot buffer. This means that if we want to send multiple sequential requests we MUST wait until each one has been completed before we send the next request and so on.

The mechanism that performs all this is that Mach sets a semaphore when it's completed the request and CB can monitor that semaphore until it see's it set - that's what isMoving does. Shame it's called isMoving because it has nothing to do with movement. A better name would perhaps have been MachIsBusyDoingOurRequest. As in...

while MachIsBusyDoingOurRequest() 'or perhaps something shorter maybe!!!
wend

So, using the above code as an example...

Code"G92 Z0.000"   ' Set the Z value +/- to insure the pierce height comes out correct
Code"G0 Z" &PierceHeight

Two things MAY happen here. One is that the G0 request actually corrupts the G92 request. The other is that the G0 request may happen BEFORE the G92 request. It's perhaps unlikely if you have a good fast system, but that is BAD programming.

The other example is even more obvious perhaps.

Code "G4 P" &PierceTime 'Pierce Delay
Code "G0 Z" & GetUserDRO(1001)

Here, we're asking Mach to perform a dwell. You can virtually guarantee that the G0 will be executed BEFORE the dwell is over. You're also risking buffer corruption again. It might - it might not. Who knows.

If you have a fast system and if the request that you're making is a quick one - then you MIGHT get away with it - then again you MIGHT get away with it MOST of the time. But sooner or later it's going to bite you in the **s*.

Sorry - lecture over - hope it helps.

Ian

1224

General Mach Discussion / Re: G31 Probe problem

« on: August 03, 2011, 06:35:46 AM »

Haven't looked at the logic of the code BUT without the indicated "isMovings" the code will be completely un-predictable.

PierceHeight = GetUserDRO(1000)
CutHeight = GetUserDRO(1001)
PierceTime = GetUserDRO(1002)

If GetOEMLed(836) = 0 Then    ' Checks the Home LED if active then goto else
Code "G28.1 Z.500"   ' Set up the Zhome for the correct direction and speed
While IsMoving()
Wend
Code"G92 Z0.000"   ' Set the Z value +/- to insure the pierce height comes out correct

****************** WHILE ISMOVING WEND **************************

                                 ' The correct value depends on the lost motion of the switch assy
Code"G0 Z" &PierceHeight
While IsMoving()
Wend

DoSpinCW()
While Not isActive(Input1)
Wend
Code "G4 P" &PierceTime 'Pierce Delay

****************** WHILE ISMOVING WEND **************************

Code "G0 Z" & GetUserDRO(1001)
While IsMoving()
Wend

Else
Code "(Torch is On Surface Hit STOP and Fix)"
End If

1225

Mach4 General Discussion / Re: New people welcome !! Come in here and introduce your self!

« on: August 02, 2011, 03:31:20 PM »

Hi welcome to the forum

you might want to post this in the general discussion - more people will see it there.

Ian

1226

General Mach Discussion / Re: G31 Probe problem

« on: August 02, 2011, 01:10:35 PM »

Not sure if this is your particular problem or not but whenever you SET a DRO via CB and then do something that depends on the value of that DRO you MUST do a check via isMoving() that Mach HAS actually finished updating the DRO before you continue your script.

Ian

1227

General Mach Discussion / Re: G31 Probe problem

« on: August 02, 2011, 05:14:13 AM »

Just loaded 3.043.022 and tried it and accel follows the correct axis just fine for me.

Ian

EDIT: Now back to 3.042.020 - can't be doing with that slower screenset loading...

1228

General Mach Discussion / Re: G31 Probe problem

« on: August 01, 2011, 05:43:37 AM »

Hi rrc1962 - Just tried this on my R3.042.020 and G31 uses the correct axis accel setting. Is this a version issue maybe?

Ian

1229

General Mach Discussion / Re: G31 Probe problem

« on: July 31, 2011, 12:30:43 PM »

get an isMoving in there after that code "F30" in post #23 - that should put the cat amongst the pigeons - sorry

Cheers

Ian

1230

General Mach Discussion / Re: G31 Probe problem

« on: July 31, 2011, 12:04:38 PM »

As Terry says, I've had times when a "code" has failed. Never did manage to track down why. Just tested one of my fragments from way back in 07 and what failed then now works fine. Can't see anything of note in the change logs though. As a pro software developer of nearly 30 years - I'd say that gave fair cause for doubt. Of course if just because it hasn't happened to you means it doesn't happen at all is your kama then whatever. Bit of a jump though IMHO to say it's exclusively down to bad programming.

Cheers

Ian