What you are seeing is one reason WHY I never recomend using a MACRO over just running Plain Gcode .  The macro WILL depend on the computer running it as to IF it will run acturately (not jumping out of sync and skipping codes).

Normally I would see it on FAST cpu PCs.  

You Code seems correct, You may want to try it this way, adding in a few more wait states. (;-) Also corrected a few GO instead of G0 issues. (;-)

PierceHeight =GetUserDRO(1000)
While IsMoving( )
Sleep(20)
Wend
CutHeight= GetUserDRo(1001)
While IsMoving( )
Sleep(20)
Wend
PierceTime=GetUserDRO(1002)
While IsMoving( )
Sleep(20)
Wend
Zoffset=GetUserDRO(1003)
While IsMoving( )
Sleep(20)
Wend
Code “G28.1Z0”
While IsMoving( )
Sleep(20)
Wend
Code”G92 Z0”          '(set z to 0)
While IsMoving( )
Sleep(20)
Wend
Code”G0 Z”&Zoffset '( Retract to top of material)
While IsMoving( )
Sleep(20)
Wend
Code”G92 Z0”          '(set z to 0)
While IsMoving( )
Sleep(20)
Wend
Code”G0 Z”&PierceHeight
While IsMoving( )
Sleep(20)
Wend
DoSpinCW( )             '(Turn torch on)
While IsMoving( )
Sleep(20)
Wend
Code”G4P”&Pierce Time    ' (Pierce delay)
While IsMoving( )
Sleep(20)
Wend
Code”G0Z” &CutHeight      '(Go to cut height)
While IsMoving( )
Sleep(20)
Wend
End

Thanks for the tips. The Go G0 was a typo and I will try the extra sleep commands .I do not have a specific Cam for plasma yet but use Vectric for most of my wood work. Rather than calling the m3 macro is it possible to automatically insert the raw g code at the start of each cut file?
Thanks

WIth a CAM you can modify the POST to insert the Gcode sequence BEFORE each M3.

(;-) TP

Heh He - I know Terry has a thing about wait states but to suggest this is why the original code you posted "doesn't work" is frankly pushing things a bit.

1) As pointed out you were using the letter "O" instead of a zero in several places.
2) It may be an artifact of how the forum translated the code text you posted but the quotes ("") are not syntactically correct as far as the interpreter is concerned. Please post code using the #code tags in future - this will help a lot in debugging.
3)  Code”G92 Z0” (set z to 0) is incorrect syntax. You're using GCODE style comments in CB. This will cause the CB interpreter to fail. Either use Code "G92 Z0 (set z to zero)" (look where the closing quote is) OR preferably use CB comments i.e. Code "G92 Z0" 'set z to sero.
4) Code”G4P”&Pierce Time (Pierce delay) is a syntax error (the space between Pierce and Time. (as well as the reason in 3) above. (The missing spaces are also syntax errors but may again be an artifact of you posting the code on the forum without #code tags.

If you did indeed run the code you posted step by step then there is NO WAY it ran OK - impossible.

As far as putting wait states after a FUNCTION call like PierceHeight=GetUserDRO(1000). This is completely pointless. Unlike a SUB call from CB to Mach which can be ASYNCHRONOUS, a FUNCTION call by its very nature is always SYNCHRONOUS.

Ian

Hi Ian
The bracketed comments in my post are my understanding of what the code does, not part of the code. I didn’t realise you could attach code in reply section so thanks for that tip
The actual code is:-
PierceHeight=GetUserDRO(1000)
CutHeight=GetUserDRO(1001)
PierceTime= GetUserDRO(1002)
zoffset=GetUserDRO(1003)
If GetOEMLed(836)=0 Then
Code "G28.1z0"
While IsMoving()
Wend
Code "G92 z0"'set z 0
While IsMoving()
Wend
Code"G0z"&zoffset' move to surface,inc switch free play
While IsMoving()
Wend
Code"G92z0"'set z 0
While IsMoving()
Wend
Code "G0 z"&PierceHeight' move to pierce height
While IsMoving()
Wend
Code "G4P" &PierceTime'pierce delay
While IsMoving()
Wend
DoSpinCW()' Turn torch on
While IsMoving()
Wend
Code "G0z" &CutHeight'move to cut height
While IsMoving()
Wend
Else
MsgBox "Torch on surface"
End If
         
I have it in as a m3 macro at the start of a cut file but it doesn’t always run consistently. If I run it step by step in the VB editor it runs OK.
I just wanted the code checked for any errors and suggestions

Tony

OK I've re-formatted your code so we can read it a tad easier (There's no charge for spaces - feel free to use them )

Plus this is what I meant by #code tags (see the # button on the regular reply screen - not the quick reply)

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

If GetOEMLed(836) Then
  MsgBox "Torch on surface"
Else
  Code "G28.1 z0"
  While IsMoving()
  Wend

  Code "G92 z0" 'set z 0
  While IsMoving()
  Wend

  Code "G0 z" & zoffset' move to surface,inc switch free play
  While IsMoving()
  Wend

  Code "G92 z0" 'set z 0
  While IsMoving()
  Wend

  Code "G0 z" & PierceHeight' move to pierce height
  While IsMoving()
  Wend

  Code "G4P" & PierceTime'pierce delay
  While IsMoving()
  Wend

  DoSpinCW()' Turn torch on
  While IsMoving()
  Wend

  Code "G0 z" & CutHeight'move to cut height
  While IsMoving()
  Wend
End If


Now then....

What do you mean by...

I have it in as a m3 macro at the start of a cut file but it doesn’t always run consistently. If I run it step by step in the VB editor it runs OK.

i.e. what EXACTLY does it NOT do that you'd like it to do and what EXACTLY does it DO that you DON'T want it to do? - I'm a tad down on my psychic capabilities at the moment 

Ian

Thanks for the re –formatted code and the free spaces-  sorry to hear about your failing psychic capabilities so here are some details-

I have been running the test code on a live machine and expect to see the torch:-

1 Travel down to the surface of the material
2 Take up the free play of the floating head
3 Retract back to the surface (which should now be z 0)
4 Go to pierce height
5 Torch on
6 Pierce delay
7 Go to cut height
8 Start cutting.

The free play between the torch touching the material and the limit triggered is measured at 3.6mm. (This becomes my zoffset parameter in the code-UserDRO (1003))

The first problem is my mistake in that the Torch on command should be before the Pierce delay command in the code-easy fix.

The second problem is if I use the zoffset (3.6mm), pierce height of 2mm and cut height of 1mm and run the code the actual pierce height on the machine is high and subsequently the cut height is high, although the measured difference between the two is 1mm as expected.

I can get the correct pierce height-cut height by reducing the zoffset figure but I must have something wrong!

 I have rechecked the zoffset measurement and the z axis calibration and both are correct. Could the problem be associated with the G28.1 command? I notice that the z axis backs off from the switch at the end of the homeing sequence and so I have the z axis home set to auto 0 but is this conflicting with the G92z0 in the macro and resulting in an incorrect offset?

 Tony

What you think the offset should be and what it ends up being can be 2 different things. The way I get teh correct offset is trial by error. Run the routine and have it stop before the M3 and MEASURE the set height IF it is NOT correct change the offset value untill it is correct.

The real question IS will it repeat itself every time ending at the same value ? 

WHile some may tell you too many wait states spoils the pie I have found them required many times over many machines and PCs to keep from breaking things(;-). As a rule I only use as many as it takes to make it run reliably. and not a mili secound longer BUT that may not run on your machine.

I do have a PC here that requires little to NONE on wait states but it is a old slow machine @ 1.2ghz. The faster one 3ghz you never know where the code will blow up.

BUT that is just my story your milage may vary due to local conditions (;-) LOLOLOL

(;-) TP

Could the problem be associated with the G28.1 command?

Well I've just spent a while scoping G28.1's behaviour and I'm not sure if you'd call it a problem or just the way it is but G28.1 appears to behave a little weird depending on WHERE you start from,  where the commanded point is and where the switch is made ACTIVE. If you make sure the commanded point is always ABOVE where the switch will go ACTIVE then you're ok. Otherwise it can be - well let's say - "inconsistant". I can do the details if you want but generally if the switch goes ACTIVE at or above the commanded point then G28.1 behaves quite differently.

Another quick point: Just because the home LED is on doesn't mean your ACTUALLY "Torch on surface" - it may be slightly above it depending on HOW you homed.

@Terry - Hi Terry

I'm not disputing that wait states are sometimes required and that WHERE they're needed appears to be version and perhaps system hardware dependant. All I was saying above is that this was NOT the fundamental reason why the first code posted didn't work and also I stand by what I said that there is ZERO point in putting them after a FUNCTION call.

Ian

EDIT: Hmmmm - Seems G28.1 doesn't do what it says on the tin as far as the speed to the commanded point either. According to the blurb it travels at current feedrate - nope - it travels at rapid rate!

hIYA Ian I was just pulling your leg(;-).

The G28.1 method uses a % of rapid as defined in Config/homing. It IS adjustable.

Also with the G28.1 function there IS a waypoint feature. With this you can direct the Z to move to the way point at rapid then finish the function at home speed.  With Plasma you are rarely anywhere but a  0.100 " or so off the top of material at any time. So I just do

G28.1 Z.500   That sends the Z UP to .500 at rapid as a SAFEZ and then resumes the Home function at the preset speed I have defined.

I use SafeZ as .500 as it is not safe to go zooming around the thin guage material as it warps and there may be kickups hidding that will tear the torch right off the head IF you are just skimming the top of the material.

BUT the G28.1 method does NOT allow you to use the G68 function(EXTREMELY USEFULL IN PLASMA) as the Z homing routine will not run in rotated XY space. Yes I know it does not make sense NOT to be able to HOME the" Z".   XY I understand as that is what is rotated BUT it is what it is.

(;-) TP