Messages

1

General Mach Discussion / Re: Advanced G Code Programming - Advise or Alternatives Needed

« on: March 02, 2013, 05:05:20 PM »

Thanks for the replies.  I like both of these ideas quite a bit.  The way I look at it now, I will probably use a little of both of those tricks.  In order to get the L parameter to work as I want, I need the subprogram to not execute if I turn it off (ie. if the toggle variable  = 0).

Thanks to bobeson and his thread (link below), I was able to setup an equation to set any non-zero value to 1, and 0 always equates to 0. 
Link:http://www.machsupport.com/forum/index.php?topic=13329.0

#1=1 (hole1 toggle)
#2=1 (slot toggle)

 (Cut Hole)
#11=#1
#11=[ 1- [ 1 xor #11 ]]
M98 P1 L[ #11 ]

(Cut Slot)
#11=#2
#11=[ 1- [ 1 xor #11 ]]
M98 (slot.nc) L[ #11 ]

M30

O1
g1 x3 F100
x0
M99

Amazingly that code works!! Now I'm wondering how will a slightly modified version of that equation will work if I tie it in with HimyKabibble's suggestion of using variables for the z depth.... some very interesting stuff could be done with this.

I'll have to play around with it a little more to figure out which will work better for my situation. Maybe there's an even simpler method still, but this gives me something to think about.

2

General Mach Discussion / Advanced G Code Programming - Advise or Alternatives Needed

« on: March 02, 2013, 01:58:16 PM »

Hi everyone,  I am looking for advise on how to go about programming some files to make them easy to change at the machine. My parts typically have 1-4 holes in them and a slot (this is extremely simplified, but will serve well for the example). Each piece is usually custom so I end up having to make a separate file for, 1 hole and a slot, 3 holes and a slot, 2 holes and no slot, etc... This gets tedious when you have 30+ similar parts that all need multiple configurations.  I could program a file for exery permutation, but would love to have a single file capable of making any configuration of that part.

Essentially, I would like to be able to have a provision to individually enable/disable hole 1, hole 2, 3,  4 and the slot. I was originally planning on using GOTO or IF/THEN statements in the G Code, but then found out Mach3 cant do that.  

I was thinking I could set variables at the start of the code that I can edit to be 1 or 0 (on/off). Then write a macro that calls a variable, checks if true or false and enables/disables block delete to turn off the next bit of code.  I would run the macro before each hole or slot.  

Here is a basic eaxmple of that:

#120=1  (hole 1 toggle)
#121=0  (hole 2 toggle)
#122=1 (slot toggle)

(Cut Profile)
... gcode...
... more gcode...

(DRILL HOLE 1)
#200=#120 (set blockskip toggle for next subprogram call)
M26 (call blockskip macro)
/ G0 X1.5 Y2. (move to hole location)
/ G1 Z0.
/ G2 I-.25
/ G1 Z1.

(DRILL HOLE 2)
#200=#121 (set blockskip toggle  for next subprogram call)
M26 (call blockskip macro)
/ G0 X1.5 Y3. (move to hole location)
/ G1 Z0.
/ G2 I-.25
/ G1 Z1.

(CUT SLOT)
#200=#122 (set blockskip toggle for next subprogram call)
M26 (call blockskip macro)
/ G0 X.5 Y1. (move to location)
/ G98 (slot.nc)

M30

Corresponding Macro:

trigger = GetVar (200)   'block skip enable disable variable

IF [trigger = 1]  then turn off blockskip  <-- I know this is not the right command...  have not figured it out yet.
End IF

I tested this out this morning (well not the macro, only the code by manually toggling Block Delete at M0 stops) and found out that I cant enable/disable block skip delete in the middle of a file. It can only be toggled before you start running the code.  So this method seems like it wont work like i had hoped.  

Does anyone have any other ideas on how to individually toggle or skip past different portions of the code in a way that is easily modifiable from the machine? In the above example, I used holes and slots, but the portion I want to toggle could just as easily be a chamfer or a 3d contour.

Maybe I need to go a totally different route, but I am running out of ideas...   Any suggestions would be greatly appreciated.


Regards,
rbjem

Please note that I am not a gcode expert by any means, I know just enough to be dangerous.

3

General Mach Discussion / Re: Macro generated GCode hesitation

« on: January 11, 2013, 10:56:20 AM »

Thanks for the replies.  This is the first time I've written a macro that generates gcode, so I wasnt sure if the stuttering was fixable or not. 

Anyways, I'll make a new version using arc moves, I'm confident that will work better. 

4

General Mach Discussion / Re: Macro generated GCode hesitation

« on: January 10, 2013, 06:20:55 PM »

That brings up another question.  Although it should be quite easy to do in what I want using cartesian coordinates, I was wondering yesterday if it is possible to do a circular move (like a G2 or G3) while in polar coordinates.

5

General Mach Discussion / Re: Macro generated GCode hesitation

« on: January 10, 2013, 06:17:24 PM »

I agree about the inefficiency. I thought about G2/G3 and didnt initially think of a way to do it easily in Gcode. I guess now that Im writing a macro, that should be more doable.  I'll think about it more tonight.

6

General Mach Discussion / Re: Macro generated GCode hesitation

« on: January 10, 2013, 06:14:33 PM »

More testing.... same stuttering

I have rewritten the offending part of the macro so now the helix loop has no calculations and does not check to see if the z height is at the max.  I set it so it now uses a FOR loop in incremental coordinates. Now, before the loop, it calculates how much to increase the z per angle increment and how many steps needed to get to the correct height.  There should be a lot less computation going on now since nothing is changing.

This is what that section now looks like:

Z_INCREMENT= (PITCH * ANGLE_INCREMENT / 360)
Steps =  Round((HEIGHT - (2 * FLAT_LENGTH)) / Z_INCREMENT)

        For i=0 to STEPS   'Begin helical interpolation
         CODE "G91 Y" & ANGLE_INCREMENT
         CODE "Z" & Z_INCREMENT
        Next i

7

General Mach Discussion / Macro generated GCode hesitation

« on: January 10, 2013, 05:18:32 PM »

I have made a macro (only after I found out I couldn't do it solely with gcode) to create some gcode, and have an issue with stuttering that I am wondering if anyone could shed some light on. 

First background info...

I am trying to create a helical toolpath so that I can quickly change parameters for different situations.  I have it coded to the macro to: (starting from the bottom of the cut) make a vertical move, helix around at a desired pitch and radius until I reach a certain z height, then exit the cut vertically.  This then repeats after increasing the cut radius by a small stepover. So far I have gotten this all to work.



My issue is that when executing the macro, the machine moves like it is in absolute stop (G61) mode rather than constant velocity.   I am guessing the issue is due to the way the code is calculated for each step, but am unsure if it is due to my code, or if this is a limitation of mach3. When the angle increment is set to a low value motion slows to a crawl. 

Here is the snippit of code that I am having an issue with:
(I made the program in polar coordinates (G16), so Y is equivalent to angle)

        Do   'Begin helical interpolation
           CURRENT_Z_HEIGHT = (CURRENT_Z_HEIGHT +(PITCH * ANGLE_INCREMENT / 360))  'increment height for this move
           CURRENT_ANGLE = (CURRENT_ANGLE + ANGLE_INCREMENT)   'increment angle for this move 

                CODE "G1 Y" & CURRENT_ANGLE & "Z" & CURRENT_Z_HEIGHT
              
   
           If CURRENT_Z_HEIGHT >= (TOTAL_HEIGHT - FLAT_LENGTH) THEN   'stop at top of helix
                 Exit Do
      
           Else
                 End If

        Loop

This portion executes then is looped back up to the top after incrementing the cut radius.  So essentially I am trying to program a loop in a loop.  Maybe there is a method to do this entriely in a gcode file, but so far it has eluded me. 

Any suggestions, insight, or alternative methods would be appreciated.

8

General Mach Discussion / Re: New computer = weird problems

« on: February 02, 2012, 04:37:17 PM »

I got it fixed!!!!

The problem was i did not copy the plugin required by my BOB back into my new install directory, which made it run goofy.  A ton of hassle and testing just to find the super simple solution, but isnt that how it always goes? Its what I get for not re-reading the BOB manual...

Thanks for all your help Hood. 
rbjem

9

General Mach Discussion / Re: New computer = weird problems

« on: February 02, 2012, 03:24:43 PM »

Best way would be a scope if you had one. Is there any way you can connect the LED to the parallel port side of the BOB, that would let you see if the BOB is passing the signal correctly.
Hood

I was thinking a scope would be quite nice as well...   
As far as testing the bob parallel output, I just unplugeed the cable from the pc, and turned on the control box to test with an led on the homeswitch pin (pin11) and the other end to ground.  However, when I turn on the power, the motors start going crazy.   So, I am guessing I need to test the pins while its plugged into the computer which makes it kind of difficult to access the pins. 

Is there another way to test this? 

10

General Mach Discussion / Re: New computer = weird problems

« on: February 02, 2012, 02:06:20 PM »

Ok, I checked the voltage the swicthes are seeing,  15.5V.  They are rated to operate between roughly 5-30V.  

I also tested the signal wire of the X and it is acting sporadic.  So I unplugged the signal lead (my switches have 3 leads; hot, ground, and signal) and put an 3mm led on the signal wire to light up when I put a magnet near my switches.  As far as I can tell, the led is on constantly which indicates to me that the issue is not the control box wiring (which has been working no problem for a month).  

Is there a better test than an led to see if the signal is bouncing high and low? According to thr Mach3 diagnostic screen the switches jump high to low relatively slowly, I would estimate they bounce about every 0.5 seconds, which I would think is well within the response time of an led and a resistor.

Any ideas?