OK what are the acell values for the X and Y (;-) just in case.

Try this as a test. lift the head up to the top. Reset Zero Then do a fast Down and stop with G1

G1 X-3 F150 (Do not let it hit the table)

See IF the slowdown at the end is quick

Next do the same with a G31 Z-3 F150 (do not trip the switch)

See if the slowdown at the end is the same as the G1.

Next do the G31 again only this time trip the switch on the way down and look at the deacell rate.

Next try it with G0 Z-3.

Somehwere inside the testing should be the answer hopefully.

(;-)TP

If you listen to the vid carefully you can HEAR the difference in the G31 and the G0(;-)

If you would like to try the G28.1 in the macro let us know and we can help you if you need it.

(;-) TP

Could you post a quick tutorial on setting up 28.1?
I tried a little last week and I could see it tripping the home led, but it would not stop at the point so I had something set wrong...


Thanks
Dave

Set up the switch as the Z home in Config/ Ports_pins/inputs. Test it by tripping the switch and looking on the diag page to see IF the Zhome led comes on.

 You will need to set up Zhome in Config Homing to setup the correct Zhome direction AND speed. The speed is based on a % of rapid of the Z. MAKE sure there is no offset value for Z home and make sure that the AUTO Zero is checked on.

Check to make sure the function work testing them in the air first as you go. Making sure that the Zhome is going in the right direction(;-)That way there should NOT be any surprises when you start/test the routine.

The motion is as follows. The G28.1 will go to the midpoint as defined by the Call G28.1 Z.500 this is normally a safe position in plasma. Next it will start the home routine and move to the Zhome switch. When it trips it comes to a controlled stop then reverses UNTIL the switch resets(makes contact). Then the Z dro is reset to ZERO ( or the correction value). Next the Z rapids UP to the pierce height and fires the torch. Then the pierce dwell takes place and the torch lowers to cut height and away you go.

IF the switch stays tripped after the routine then then your else statement will take you to the end and post the message to the error bar


NOTE: I would test it first from the CB CODE editor stepping 1 line at a time (F7) to ensure it does what is needed and does work(;-)



This macro should be very close to the same function as your G31 setup. You will notice that the Z will FIRST go to Z.500 on its way to home that is a safety of sorts that we use. the idea is that the Z.500 should be a safe point to start the routine above the Material. IF the torch is below that point it raises first if above it lowers to that point first. You can use it OR not your choice.


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
                                 ' 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
Code "G0 Z" & GetUserDRO(1001)
While IsMoving()
Wend

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


Hope that helps, (;-) TP

                                      

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

Hi Guys,

Mind if I add my 2 cents.

I don't know why we do it but we always seem to keep our broken probe tips, perhaps it is to teach us a lesson or so we don't forget. 

Anyway, i can't remember which Mach revision started it all but since then every Macro / Script needs a "while.....wend" between every write and every check to keep the CE speed  in line with Mach execution. As Ian has said, without it the code will be unpredictable (work just fine on one machine but not on another and even then you can't count on it).

I have a sneaky suspicion that when we all eventually agree on this - Version 4 will come along and change everything. 

Tweakie.

Hiya tweaky,I treat that problem just like I do the depreciated calls in CB they have been going to go away for about 5 years now(;-) but they are still here and going strong (;-).

Yes I agree perhaps we need a few more wait states. BUT the more you add the slower the routine can get. So I try to balance speed and reliability.

Sometimes you even have to add a sleep() here and there.

(;-) TP

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

It's also poor form to use:

While (IsMoving)
Wend

You should instead use

While (IsMoving)
   Sleep (1)
Wend

This turns control back to Mach briefly, so it can do other things, rather than spending 100% of the CPU time in the loop.  This is particularly important when the operation it's waiting for takes a long time (like a long move).

This is covered in the Mach3 Macro Programmers Reference I wrote several years back....

http://www.machsupport.com/docs/Mach3_V3.x_Macro_Prog_Ref.pdf

Regards,
Ray L.

Actually Brian supposedly added in a built in Sleep() to the While Ismoving() a long while back. I have it in the trouble notes somewhere.

ALL of this is WHY I try to do everything that involves Motion totally within the Gcode side IF possible.

Take this routine, it can be done completely from the Gcode side and from there it is as fast as the machine can move. (;-)

BUT we just have to learn to work with what we have to work with.

(;-) TP