Jump to content

Welcome to eMastercam

Register now to participate in the forums, access the download area, buy Mastercam training materials, post processors and more. This message will be removed once you have signed in.

Use your display name or email address to sign in:

Manofwar

Verified Members
  • Posts

    89
  • Joined

  • Last visited

  • Days Won

    1

Manofwar last won the day on August 12 2018

Manofwar had the most liked content!

About Manofwar

  • Birthday 05/17/1993

Profile Information

  • Gender
    Male
  • Interests
    Machining, of course!

Uncategorized

  • Location
    Fort Collins, CO

Recent Profile Visitors

1,043 profile views

Manofwar's Achievements

Rookie

Rookie (2/14)

  • Dedicated Rare
  • Conversation Starter Rare
  • First Post Rare
  • Collaborator Rare
  • Week One Done Rare

Recent Badges

32

Reputation

  1. For all who were curious. I don't believe passing a 2D array to a Cycle is currently possible. I tried multiple ways implementing this and couldn't get it. The book doesn't list an escape character, or those listed don't work. I also tried to concatenate in a comma using a temporary place holder variable to hold the comma, this also failed. If anyone else comes up with a solution (not that it's need, more out of a fun problem) please post it. Below is how I ended coding it. 1D arrays. PFS would be run before the drill is called (hence the Boolean check at the top for running the sub) and assign values to them. IF _PFS_RAN <> 1 CALL "PFS.SPF" IF RS_Main_Loop <> 0 GOTOF ("OPERATION_"<<RS_Main_Loop) RS_Main_Loop=8 OPERATION_23: ; 04_Port_Drilling CALL "PREP_LINE.SPF" T="MIT_DRILL_3937_2D_140" M6 S970 M3 M73 M7 M161 D1 G60 IF RS_Sub_Loop <> 0 GOTOF ("Port_"<<RS_Sub_Loop) RS_Sub_Loop=2 Port_2: CYCLE800 (0,"TC8",100000,57,-2.03389,-7.33396,-1.4988,43.939,-10.892,0.,_PFS_X[2],_PFS_Y[2],0,-1) CALL "23_04_Port_Drilling_02.SPF" G00 SUPA Z=-.5 RS_Sub_Loop=RS_Sub_Loop+1 Port_3: CYCLE800 (0,"TC8",100000,57,-1.03847,-7.3891,-0.52993,44.72,-5.648,0.,_PFS_X[3],_PFS_Y[3],0,-1) CALL "23_04_Port_Drilling_01.SPF" G00 SUPA Z=-.5 RS_Sub_Loop=RS_Sub_Loop+1 Port_4: CYCLE800 (0,"TC8",100000,57,5.11368,4.60438,-1.19746,-33.788,31.701,109.373,_PFS_X[4],_PFS_Y[4],0,-1) CALL "23_04_Port_Drilling_07.SPF" G00 SUPA Z=-.5 RS_Sub_Loop=RS_Sub_Loop+1 Port_5: CYCLE800 (0,"TC8",100000,57,3.80065,5.85249,-1.10746,-39.986,22.651,180.,_PFS_X[5],_PFS_Y[5],0,-1) CALL "23_04_Port_Drilling_06.SPF" G00 SUPA Z=-.5 RS_Sub_Loop=RS_Sub_Loop+1 Port_6: CYCLE800 (0,"TC8",100000,57,2.22723,6.85471,-1.90209,-43.563,12.621,180.,_PFS_X[6],_PFS_Y[6],0,-1) CALL "23_04_Port_Drilling_05.SPF" G00 SUPA Z=-.5 RS_Sub_Loop=RS_Sub_Loop+1 Port_7: CYCLE800 (0,"TC8",100000,57,-3.67067,6.3578,-0.78282,-40.893,-20.705,180.,_PFS_X[7],_PFS_Y[7],0,-1) CALL "23_04_Port_Drilling_04.SPF" G00 SUPA Z=-.5 RS_Sub_Loop=RS_Sub_Loop+1 Port_8: CYCLE800 (0,"TC8",100000,57,-7.45717,-0.26041,-0.52993,1.999,-44.965,271.413,_PFS_X[8],_PFS_Y[8],0,-1) CALL "23_04_Port_Drilling_03.SPF" G00 SUPA Z=-.5 RS_Sub_Loop=0 G00 SUPA Z0. RS_Main_Loop=24
  2. This video covers the data array tables much better then I can describe it. https://youtu.be/YK8hqu3qukU You can stack CYCLE800, I just don't like that method, as additive mode can be dangerous. By using the built in X1, Y1, Z1 you position shift after calling position and rotation without having to post out multiple CYCLE800 lines or using additive mode. I'm machining 3D printed parts. Because the feature location drift a bit from print to print some features get defined as machine in place. (capture local data and machine locally.) So, I load the part, run a program to probe those feature locations, save that data to an array named _PFS[n,m] (where the array is loaded into a GUD as DEF NCK REAL _PFS[30,2] before hand) it would look like the example below. (Example only) Port 3 location X-.0067 Y.0032 ^ This data is stored from the probe as _OVR[5] for X, and _OVR[6] for Y. I store this data in the array like this: _PFS[3,0] = _OVR[5] (This stores the actual X deviation) _PFS[3,1] = _OVR[6] (This stores the Y deviation) Then later on, in the actual machining program I can call that data from the location as you would call any variable. This causes an issue because of how the data is delimited in both arrays and cycles. The array needs the comma to tell it row, column. The cycle needs it to move to the next field. In the below picture you can see what happens when the control hits the comma in the array. It sees "_PFS[1" sees a comma so it moves to the next field and types "0]" the same would happen for Y1 except it starts in the Z1 and moves outside of the range of CYCLE800's displayed fields. Hopefully this provides a clearer picture of the problem. There are other many other ways to perform this task, I just wanted to see if I could get it this way.
  3. The cycle type is not the issue. I'm using CYCLE800 as an example. The problem is passing a 2D (or 3D) array to any cycle. Cycle800 works fine from the post and on the machine. Currently I don't think this can be done. I believe only 1-dimensional array variables can be passed to cycles. I may rewrite what I'm doing to use that. However, if anyone has a solution for 2D/3D arrays being passed to cycles please post it.
  4. Kinematics are table/table A/C trunnion style, DMU85 FD. _PFS[x,y] is an array variable I've added to the machine using a UGUD (no need to pass it in every time and the data is saved.) You are correct with the Cycle layout. I'm trying to work with <_X1>, <_Y1>. However, when you try to pass, lets say _PFS[1,0], _PFS[1,1] this is what happens. It sees the comma in the field for the X1 value and escapes to the next field, in this case Y. Fills in the remainder of the array variable for X and then hits the delimiter. This error continues outside of the fields shown. In this example _PFS[1,0] should be entirely in the X1 field and _PFS[1,1] should be in the Y1 field. Z1 should be blank.
  5. I'm having an issue with implementing an array on a DMG Mori (Siemens 840d) inside of a cycle. The cycle that gets posted looks like this: CYCLE800 (0,"TC8",100000,57,-1.03847,-7.3891,-0.52993,44.72,-5.648,0.,0,0,0,-1) What I'm looking for is something that looks like this: CYCLE800 (0,"TC8",100000,57,-1.03847,-7.3891,-0.52993,44.72,-5.648,0.,_PFS[1,0],_PFS[1,1],0,-1) However, the comma between the row and the column is escaping the field that it should be filling out. Has anyone faced this issue before, and if so what did you come up with?
  6. I'm sure you already got this one. But I've been using Emuge's Shur-Thread in Inconel 718 with really good success. TSC and have ideal LOC for ports. https://www.emuge.com/products/thread-mills/shur-thread/spiral-unf/gfr351065044
  7. I recently designed a macro program to do face grooves in parts that require a circular finish. I have not yet been able to test it and will keep updating the code here. However, if anybody else ever has a need for it. Here it is. If you do try this code, do so with extreme caution. This program could be incredibly dangerous if operated incorrectly, (think broken part, spindle, tool, etc.) If you do use it, let me know how it goes here. Cheers, Caleb ; PROGRAM DESIGNED TO CUT CIRCULAR FINISH GROOVES THAT ARE NOT ABOUT A ROTATION AXIS ON A PART ; WORK OFFSET SHOULD BE SET TO CENTER AND TOP OF FEATURE DESIRED ; THIS PROGRAM IS VERY DANGEROUS, DO NOT STOP MACHINE DURING CYCLE ; SINGLE BLOCK, FEED HOLD, CYCLE HOLD, FEED OVERRIDE, AND SPINDLE OVERRIDE OVER CAN CAUSE CATASTROPHIC FAILURE ; PROGRAM DESIGNED IN INCH MODE, MAY BE UNSTABLE IN MM ; PROGRAM IS DESIGNED TO CUT FEATURE TO SIZE WITH NO STEPOVER ; ACTUAL SPINDLE POSITION CLOCK POSITION MAY NEED ADJUSTMENT, SEE LINE 60 DEF REAL _F_DIA; FEATURE DIAMETER DEF REAL _Z_DEPTH; DEPTH OF FEATURE DEF REAL _Z_FEED; INFEED OF TOOL, AS LATHE DEF REAL _T_TOOL_OFFSET; B DISTANCE OF TOOL IN SPINDLE, OFFSET OF TOOL FROM CENTER OF SPINDLE DEF REAL _PI; PI CARRIED TO 5TH DECIMAL DEF REAL _H_TRAVEL; ACTUAL DIAMETER TRAVEL, DIAMETER OF FEATURE - RADII OF TOOL*2 DEF REAL _F_RATE; FEEDRATE CALCULATION DEF REAL _LOOP_CUT; CALCULATION FOR LOOP CUTTING DEF REAL _FINAL_Z_CUT; FINAL CUT IN Z DEPTH DEF INT _TOOL; TOOL NUMBER, OR NAME, BEING USED DEF INT _T_HEIGHT; D VALUE BEING USED DEF INT _RPM; RPM OF MILLING SPINDLE ; THESE VARIABLES REQUIRE INPUT BEFORE RUNNING; INPUT OF 0 WILL RESULT IN ALARM ; ***INPUT DATA DESIRED HERE*** _F_DIA=3 _RPM=1 _Z_DEPTH=.050 _Z_FEED=.003 _TOOL=16 _T_HEIGHT=1 STOPRE T=_TOOL D=_T_HEIGHT; TOOL CALL, AND HEIGHT CALL M6 STOPRE _LOOP_CUT=(TRUNC(_Z_DEPTH/_Z_FEED)) _T_TOOL_OFFSET=($P_TOOLL[2]) _PI=(3.14159) STOPRE _H_TRAVEL=(_F_DIA-(_T_TOOL_OFFSET*2)) STOPRE _F_RATE=(_H_TRAVEL*_RPM*_PI) _FINAL_Z_CUT=((_LOOP_CUT*_Z_FEED)-_Z_DEPTH) STOPRE IF _F_RATE>500 GOTOF "MESSAGES_ALARMS_2" IF _F_DIA<=.500 GOTOF "MESSAGES_ALARMS_1" IF _RPM<=0 GOTOF "MESSAGES_ALARMS_1" IF _RPM>=100 GOTOF "MESSAGES_ALARMS_2" IF _Z_DEPTH<=0. GOTOF "MESSAGES_ALARMS_1" IF _Z_FEED<=0. GOTOF "MESSAGES_ALARMS_1" IF _Z_FEED>=.01 GOTOF "MESSAGES_ALARMS_2" STOPRE SUPA G00 G90 Z0.; G17; G54; SPOS=AC(180.); ADJUST POSITION AS NECESSARY, INPUT IS DEGREES G97; X=(_H_TRAVEL*(1/2)) Y0. Z1.; Z.1; G94 G01 Z.005 F25.; G02 X=(_H_TRAVEL*(1/2)) Y0. Z0. I=-(_H_TRAVEL*(1/2)) J0. F=(_F_RATE) S=(_RPM) M3; SPINDLE ACTIVE, DO NOT FEED HOLD!!! CUTTING_ACTION: X=(_H_TRAVEL*(1/2)) Y0. Z=IC(-(_Z_FEED)) I=-(_H_TRAVEL*(1/2)) J0. REPEATB CUTTING_ACTION P=(_LOOP_CUT-1) X=_H_TRAVEL*(1/2) Y0. Z=IC(_FINAL_Z_CUT) I=-_H_TRAVEL*(1/2) J0.; FINAL Z CUT FINAL_DEPTH: X=(_H_TRAVEL*(1/2)) Y0. Z=-(_Z_DEPTH) I=-(_H_TRAVEL*(1/2)) J0.;CLEANUP PASS, REMOVES Z RAMP REPEATB FINAL_DEPTH P=2; 2 SPRING PASSES AT DEPTH X=(_H_TRAVEL*(1/2)) Y0. Z.005 I=-(_H_TRAVEL*(1/2)) J0.; BACK TO CLEARANCE HEIGHT G01 Z.1 F25.; SUPA G00 Z0. M05; M30; MESSAGES_ALARMS_1: STOPRE LOOP MSG ("PARAMETER MISSET, LOW") M00 ENDLOOP MESSAGES_ALARMS_2: STOPRE LOOP MSG ("PARAMETER MISSET, HIGH") M00 ENDLOOP
  8. I recently ran into an issue that I couldn't find a thread for. We have a fairly new post for Mazak 5x machines that suddenly decided to change how the feedrate worked in corners. Slowing the machine way down on all arcs. We discovered that despite "Adjust feedrate on arc moves." being unchecked it was still processing it like it was checked. We had to blink it on and off, then regenerate paths in order for it to take. This post is more for anybody with a similar problem in the future.
  9. Normally this is a function that's tied to Ctrl + Mouse wheel. Are you sure your control key isn't stuck?
  10. Sorry, all of this info was for Opti-Rough I thought this was what you were using. I have never used Area Roughing. Looking at the 'Help' parameters page it looks like the "Add Cuts" button just below stepdown does something similar to what I was describing above. Like I said though, I don't really know this toolpath.
  11. I have seen this happen for a couple of different reasons. Mostly settings that might be hard to understand. 1. Skip pockets smaller than. (This is mentioned above.) This setting takes into account stock so you have to be careful with that. 2. Helix Radii. It's important to note that this is radial and does not include half the tool size. Typing in .250" with a .500" tool will generate a hole in the part 1.00" in diameter. 3. Steep/Shallow settings. 4. Not using Stepup. This is the setting that gets me almost every time I have this problem. Stepdown looks down until it violates a floor, then it deletes that last step. Meaning if you're within .950" of the floor and step down is set to 1" it will not cut the last section because it's less then the stepdown value. The best way I have found to negate this is to turn on stepup and set it to the same value as the stepdown, meaning it will look both up and down for material getting rid of that last bit of material. Hope this helps, Caleb
  12. Kevin, the issue with the G68.2 may be the code following it. The post I'm using for an Integrex is not setup properly and posts code on the K line that is past 360 degrees occasionally, looking something like this. G54 M108 M212 B10. C20. M107 G68.2 P1 X0. Y0. Z0. I0. J10. K380. G53.1 P1 G97 S2139 M3 G43 H#3020 X-.6858 Y.0534 Z.0764 This throws the machine into a similar alarm state. In your example I can see that you're using A-90. however your I is a positive value. Maybe try switching this either to a negative value or possibly 270 degrees. The moves it makes during this mode can be extremely dangerous, approach this with caution. With Regards, Caleb
  13. Colton, I took a quick look at this. It seems to me that it's the way MC is interpreting the diameter of the tool vs the angle. I got rid of the taper angle in the path and it works fine. With an endmill it's using actual diameter (of shank) which is .375" (hence the .007" overcut you're using in the first path, because the cutting edge doesn't extend all the way to the shank) Where with the thread mill it's better taking into account the taper of the tool, using the tip size instead of shank size. I hope this helps. Caleb
  14. Like this? Limits.zip I'm using a conical limit switch down the center of the part with the setting of the upper and lower limit at 9.405 so it locks the B axis and C is still allowed to move.
  15. I don't happen to use blade expert. Perhaps somebody who does will chime in.

Join us!

eMastercam - your online source for all things Mastercam.

Together, we are the strongest Mastercam community on the web with over 56,000 members, and our online store offers a wide selection of training materials for all applications and skill levels.

Follow us

×