Hello Guest it is March 29, 2024, 06:35:40 AM

Author Topic: Feed hold while script running causing big crashes  (Read 4897 times)

0 Members and 1 Guest are viewing this topic.

Feed hold while script running causing big crashes
« on: January 30, 2013, 05:43:39 PM »
Hi guys,

I have been chipping away at getting my cnc running and things have been going really well. The scripts I built seem to mostly working well and my VB is getting better by the day!

Maybe I was feeling a bit too chuffed with my self that today when I went to pause the cnc mid tool change rather than coming to a controlled stop and waiting for cycle start it stepped onto the next line in the vb script as it was currently in the following while loop:

Call MovePos(OldTool)'Move infront of old tool slot

Code "G53 G00 X" & XPos-ToolIn & "Y" & YPos
While IsMoving()                                                      '  this is where i pressed feed hold
   Sleep(25)
Wend

Code "G53 G00 Z" & ZPos 'Lower to tool insert height  '  This is where it then stepped to. VERY bad as it was mid table but my estop hand was on form so no damage today....
While IsMoving()
   Sleep(25)
Wend

I was lucky that saw this happening and managed to get to my estop before the tool tool into the bed of the cnc.

My first plan was to put lf statements in to make sure it was at the target gcode before stepping over to the next line by checking against a DRO but this will add HUGE amount of coding as each movement will need to check it actually has reached its target.

My next plan was to use a brain to see if a script/macro was running then somehow lock out the feed hold but could not find an output to issue an estop if the feed hold button was pressed while in a script.

Any other idea to help make sure that feed hold acts as expected rather than causing scripts to step onto the next line?

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: Feed hold while script running causing big crashes
« Reply #1 on: February 01, 2013, 08:46:33 AM »
This appears to be another one of several problems with Feedhold. (There's a bit of a history with bugs in Feedhold).

Mach changed at some point and is now able to queue "some number" of Code statements and execute them in order correctly WITHOUT while isMoving. Usually it doesn't matter though if you still put a while isMoving construct after each Code statement EXCEPT as you've found if you want to be able to feedhold. Taking out the while isMoving constructs should solve your problem.

Just to be clear, I am NOT saying you NEVER need a while isMoving, quite the opposite - it's just that a lot more thought has to be given to when to use them. i.e. they should NOT just be sprinkled about with a wing and a prayer.

Hope this helps

Ian
Re: Feed hold while script running causing big crashes
« Reply #2 on: February 01, 2013, 10:46:59 AM »
Hi Ian,

Thanks for your advice, I am new to mach3 and just teaching myself by reading other peoples code. I often see the :

While IsMoving
   Sleep(25)
Wend

loop after a g code movement and just assumed it was always needed to keep mach3 on task till it was done. I have not seen any info that has said before that you dont need this loop, would you mind posting some info about where you can omit it as I am sure one day I am going to blindly press feed hold and crash a script with how I am currently coding....

Would posting the whole tool change macro help?

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: Feed hold while script running causing big crashes
« Reply #3 on: February 01, 2013, 11:55:55 AM »
I have not seen any info that has said before that you dont need this loop, would you mind posting some info about where you can omit it

AFAIK there is no such information. I've just spent a lot of time over the years figuring out MY rules of when to use isMoving and when not to. If you look back at the (many) threads discussing isMoving you'll find there isn't even agreement of what it actually DOES never mind when it should be used. All I know is that when I simulated YOUR problem HERE I got the same results as you, but taking out the "isMoving loops" caused Feedhold to work as expected HERE. I have a vague idea of WHY but I'd like to look at it more before offering my throat up to the wolves ;).

Cheers

Ian

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Feed hold while script running causing big crashes
« Reply #4 on: February 01, 2013, 12:14:41 PM »
I believe that when the Feedhold stops the Gcode the While Ismoving()  signals the CB code to continue on.

I normally group up the Like statements then add in the While Ismoving() at the end of the group.

Code"G0X0Y0"
Code"G1 X10F10"
Code"G0 X0"
While Ismoving()
Wend

Snarl, snarl , HOOOWWWL

Just a thought, (;-) TP


Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Feed hold while script running causing big crashes
« Reply #5 on: February 01, 2013, 12:45:20 PM »
(;-) IF you look on the diagnostic page when running the macro then Feedhold you will see WHY it does as it does. When you press feedhold it dumps the buffer and empties the current QUE.

IF you are running single line code like
Code"G0X10"
While Ismoving()
Wend

It dumps the current que and starts over with teh next line AFTER the While Ismoving().   

IF you use the group method then it ships over all the group on feedhold.

AS it should really, I do not recall ANY OTHER controller allowing feedhold during MACROs or Canned cycles. But in this case it should have just locked out the FH function.

IF you need to STOP in a macro {ESC} is the  key.

Mixing Gcode motion and CB code has ALWAYS been a problem and should be avoided if possible.

Just a thought, (;-) TP

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: Feed hold while script running causing big crashes
« Reply #6 on: February 01, 2013, 12:57:09 PM »
(;-) IF you look on the diagnostic page when running the macro then Feedhold you will see WHY it does as it does. When you press feedhold it dumps the buffer and empties the current QUE.
Yo just beat me to it Terry - atta boy! but I came to the same conclusion by experiment.

AS it should really, I do not recall ANY OTHER controller allowing feedhold during MACROs or Canned cycles. But in this case it should have just locked out the FH function.
Well you've got far more experience of other controllers Terry so I'll bow to you on that one - but I can't see any valid reason WHY that should be the case.

HOWEVER - There's an inconsistency here. Feedhold works fine IN A MACRO - IF you buffer but not if you don't - that's just cra*p logic.

Mixing Gcode motion and CB code has ALWAYS been a problem and should be avoided if possible.
Steady there big fella - you'll have the myth police on yo ass!

Cheers

Ian

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Feed hold while script running causing big crashes
« Reply #7 on: February 01, 2013, 01:21:15 PM »
Hiya Stirling,  To add to the FH problem  IF you single line the motion with a wait you MAY get 1 FH to work but then it just stalls as it seems MAch3 is waiting for a Cycle start BUT it never sees it as the buffere is empty and it thinks the program is over (nothing to FH) as it does NOT look to the macro side to continue the que load but to the Gcode side which is empty.

AND yes it probably could have been made to work BUT it is what it is at this point .

(;-)TP

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: Feed hold while script running causing big crashes
« Reply #8 on: February 01, 2013, 02:57:12 PM »
Hiya BR549, Had a bit of a play....

Try this

Code "G1 X1" (any distance that takes longer than the following sleep)
sleep 1000 (any time that's enough to let you FH before it wakes up)
Code "G1 Y1"

If you FH BEFORE a second it quits the first move, DOESN'T FH and immediately executes the second move.
If you FH AFTER a second it correctly FH the first move. If you then hit cycle start it correctly finishes the first move and then correctly does the second move.

Like I said - this is just plain bad. Like you said - it is what it is.

And I wonder why it's proving darn near impossible to release an ABSOLUTELY RELIABLE dynamic probing routine.

Cheers

Stirling