Hello Guest it is November 14, 2019, 11:33:03 AM

Author Topic: gcode variable that can be seen by a 'brain'?  (Read 3095 times)

0 Members and 1 Guest are viewing this topic.

gcode variable that can be seen by a 'brain'?
« on: November 15, 2009, 10:45:46 PM »
I am one of the poor fools stuck trying to find a decent way to control a laser with Mach3.  The laser plugin works 'sometimes', but it crashes unexpectedly and always gives me the 'previous SEQ not completed' statement.  Perhaps I was foolish to throw away the old Chinese driver that came with my laser.  Okay, enough history.

Is there a way for me to write a variable in Gcode that will not be a machine code that pauses the motion?  I was hoping that there was some variable that could be seen by a brain and have the brain turn my laser on and off.  I have spent days playing with Mcodes and slow VB scripts with little success.  I have also tried simply changing the spindle speed parameter and tying my laser to it with a brain, but I see that Mach3 also pauses when it receives the new speed setting (even though all internal delays are set to zero).  I have also done the trick of using the direction bit for the Z axis to fire the laser.  Even with Z depths of -0.001 and super high speed settings for the fake Z motor I am still getting the jerky machine pauses when rastering the X motion.

I would like to create my gcode as before using small Z motions for laser on-off, but then I would use the find and replace feature of a text editor to change Z0.0 and Z-.001 to this new variable that will not be interpreted by a slow VB script but will instead be seen and immediately acted upon by the brain.

Re: gcode variable that can be seen by a 'brain'?
« Reply #1 on: November 16, 2009, 02:18:43 PM »
Still looking for an answer.  I had one more comment to add that might spark a reply.  I notice in Mach 3 that there is a pulldown menu item called Gcode variable viewer.  I can't find anything about this function in the manual, or perhaps I'm looking at the wrong manual.  This function leads me to believe that certain variables can be grabbed from the gcode that are not necessarily motor movements or machine codes.  

I think it is clear to all that you can't turn on a laser during a pause in motion or it will burn deeper and wider than during a normal XX inch/min run.  We need the ability to run the X and Y in constant velocity mode and then turn the laser on and off without any motion delays.  It would be best if the knowledge of the pending laser on/off commands are processed by the trajectory planning section of the software so it can just happen when it sees that the trigger point has been reached in a particular motion pass.   This seems to be what is happening in the laser plugin, but the plugin has some serious problems with crashing and inability to handle rectangular images.  It also never lets us have the actual code to save.  This is an important point because when rastering across an image there might be several minutes worth of small Y movements in which the laser never fires.  It would be nice to cut out these particular sections of code and let the Y axis move quickly to the next valid position where the laser will fire during an X sweep.