Hello Guest it is July 17, 2019, 09:35:05 AM

Author Topic: G53 oddity  (Read 9355 times)

0 Members and 1 Guest are viewing this topic.

Re: G53 oddity
« Reply #30 on: January 06, 2011, 11:44:04 AM »
G53 has always been rock solid here too.  Sounds almost like the axes are not referenced prior to the G53.  I know if I don't reference the machine prior to a G53 I get some unexpected results. 

Offline ger21

*
  • *
  •  6,288 6,288
    • View Profile
    • The CNC Woodworker
Re: G53 oddity
« Reply #31 on: January 06, 2011, 12:10:23 PM »
When you do anything in VB that causes DRO's to change values, you need to give them time to actually update. Sleep(250) 1/4second should be enough.
Gerry

2010 Screenset
http://www.thecncwoodworker.com/2010.html

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html

Offline tmead

*
  •  62 62
    • View Profile
Re: G53 oddity
« Reply #32 on: January 06, 2011, 12:53:50 PM »
The application we are running is for cutting shapes from a bulk material in a produciton environment using a specially design ed cylindrical blade, and is not a not a normal CNC machineing application. The script calculates variables that are then used to position G81 drilling cycles. This is done based on the operator requested combination of the four sizes of bores, and any combination must be available to the operator. This means there is no way round issueing GCode commands from the VB. None of the canned drilling commands that are constructed using VB scripts have been a problem at all, it's all been in the setup and recovery routines, where I know now I'd have been much better loading a small gcode file !

The machine refernces all axes to switches at the beginning of a run, and the operator will not be able to proceed until this is compelete.

Adding a sleep 500 after the G59 command has made the G0 G53 totally reliable now. I did not expect to have to worry about the synch when issueing GCode setup commands like this - now I know better !

Tim

Offline tmead

*
  •  62 62
    • View Profile
Re: G53 oddity
« Reply #33 on: January 06, 2011, 05:52:23 PM »
the screen set forces a sequence of actions from the operator.
* Page 1 only has one option to reference all axes and make a small move. DROs are not updated or changed except as a result of axis moves.
* Page 2 is displayed, where all the fun began. This only has two buttons, and only one does anything if the script is not running.
* The main button script starts by trying to make a couple of preparatory moves, based on history with a previous machine running an older version of Mach3. These were G53 moves as the previous machine seemed to object to moving in fixture coordinates away from machine zero after reference all. These now work, after adding a G59 P13 and a sleep 500 before the g53 moves.

Tim

Offline BR549

*
  •  6,874 6,874
    • View Profile
Re: G53 oddity
« Reply #34 on: January 06, 2011, 07:23:13 PM »
SOUNDS like you need to develope a Plugin for mach instead of the VB approach.

(;-) TP