43 minutes ago, JParis said:

I have used a gundrill on uppers and the end of the hole is interrupted....in that application it worked out OK

We might give it a try then. We'll talk with various manufacturers and see what they recommend. Thanks!

8 minutes ago, jlw™ said:

i would look at iscar sumocham for first choice or eldorado/dme for a gundrill.

Thanks, Jlw. If we can't find an off-the-shelf solution we'll talk with them about something custom. Thanks!

Not sure I'm tracking on your idea for a modified spade drill shank. 

We considered a gun drill at first but the finished hole diameter will end up as an interrupted hole - a gun drill probably wouldn't do well in that situation. The pilot size (.75") is small enough that it would be solid thru the length of the hole, so no issues there. 

We have coolant fed spade drills but we have issues with them wandering. We had planned to drill a pilot hole with a deep hole carbide drill, then come in with an inserted drill with a pilot that would follow the pilot hole. 

Hi everyone,

I'm looking for suggestions on custom tooling companies that could produce a piloted/inserted drill for deep holes. We're trying to drill about 16" deep in 7075 aluminum with roughly a 1-9/16" diameter. Tool will need to be for a CAT50 horizontal mill. We're currently talking with Guhring and Allied Machine & Engineering. At first they were positive they could produce this for us, but lately they've been pushing back, either telling us it isn't possible or suggesting other methods. I understand tooling companies have a great deal of experience and may not want to try something in case it doesn't work to cover their bases. 

Are their custom tooling companies anyone has worked with that has been willing to produce some crazy stuff? I appreciate any suggestions. Thanks. 

Duh, haha. Thanks. 

Does anyone know how to disable to automatic syncing of the verification and programming windows? I know how to disable it once its open, but it would be nice to be able to turn it off completely. Thanks. 

I was in a similar situation when we first starting setting up our Mitsubishi EDM and mastercam posts, and power libraries. It took a few months of back and forth with our reseller and Mitsubishi application guys but we were able to get the correct post and power libraries for our machine. As everyone else has said, this is something a good reseller should be able to handle. 

Cathedral,

That look room looks like a thing of beauty, albeit an expensive one! Maybe one day we will be that clean and organized.

Sounds like you need to go into your machine definition and re-attach your post. So do you have an original post, and you then made a copy that you edited? 

When you're working off a network location, after you move your files up on the server, it's best to remove the versions on your local computer....

 

Many times Mastercam will run home to them if it finds them locally

Right. We have all of the old definitions and stuff zipped on everyone's computer so Mastercam can only find what is on the network. 

Here is what my Machine Group dialog looks like. 

Did you save it in the Machine Definition?

Yes. Every time I move any of the files I will check the location of the control def and the post and re-attach and save if either of them are lost. I also re-attach the operations and defaults files as well. 

Welp, I'm back at square one. Figured I had everything worked out so I moved the MD/CD and post files around and no it's all messed up again. I'll have to try that control definition trick. 

Sounds to me like you Defaults for that control got over written. Might be best to save a copy of the 2017 one out int oa secure place. Convert your X9 version to 2017 and see if you get the results you are looking for. If you do then it confirms your Control Definition got changed. You either use the newly converted one or you spend the time going through everything from the newly converted one and the old one. Colin taught a trick not to long ago where you can rename the control to a .mcam and open it and look through everything that way verse having to go through the control definition to change things for your operational defaults.

It looks like I finally fixed it by doing just that. I had tried converting just the machine and control def and obviously that didn't work. We've moved all of our definitions, posts, etc, to a central location on our server so everyone is tied to the same posts and everything. Since I'm the only one using wire I think all of that got scrambled somehow - Mastercam may have gotten confused looking for everything because it couldn't find what it needed. I converted the operations and defaults from X9, pointed to that and everything seems to be working now. Thanks Ron!

Morning everyone,

I've been having some serious issues with my wire machine/control definition in 2017, not sure if it's just me or if anyone else has had similar issues. 

It all started a few months ago - I went into 2017 to do some wire work (I had done previous wire work in '17 with no issues) and when I went to create a new contour it was giving me options for "Agie Contour", not the usual wire contour options I had before. It should be noted that the MD/CD, post, etc, are all for a Mitsubishi machine, not an Agie. For whatever reason, the machine think it's an Agie now and even after being on the phone for over an hour with our reseller trying to resolve the issue, it still will not work. This is just a brief summary of the issue, I know, and I can provide images of everything if anyone needs it. Just wondering if, based on my explanation, there is something silly I'm missing.

Another thing to note is that I can go into a different mcam file that worked before, and everything still works as it should. I can go into X9 and everything still works as it should (I've been using X9 to get around this issue but it really needs to be fixed for 2017). I tried migrating my MD/CD from X9 to rule out any issues with corruption of the 2017 defs but that didn't work either.

Hopefully someone has some insight. I really appreciate it, you guys have all been really great helping out. 

Yes, Zoller. We use it to track tooling for 26 machines (lathes, mills, multi-task). I think it would be fine for your size shop, especially if you know you are expanding, although I bet it will make it harder to justify the cost. Once we got organized and started using it fully, we were seeing a savings of around $15,000 a month in tooling. Which means our investment is paid off already, and since we're ESOP, once everyone saw that money they we're like, "yeah, this is the right thing to do."

 

The difference will be in how organized your shop is. Our shop stared in 1956 and the guys kind of carried that mentality over from year to year. I started in aerospace so when I came here I knew we were throwing away money with disorganization so, when I finally had enough weight to throw around, I threw it at this project and got it started. If your shop already has decent discipline, your ROI might be a lot longer.

 

EDIT: just want to point out that the savings was in tooling alone by reducing redundant inventory and doesn't come close to capturing the time we save during set-ups and such. We're a job shop so we're doing set-ups all day, every day and that time alone is worth more than I can count.

Wow, that's an impressive amount of savings. I would say our organization is okay. We use a tool vending system but the overall tool management is still very much a hands-on process. The issues we run into consistently are changes made to tooling that do not get recorded and we wonder months down the road why the tool list doesn't match what's in the machine and why our CAM files do not match the process in the code (i.e. we'll hand edit a cycle if it gets changed to a carbide drill but our programming doesn't get updated). We also run into issues where the operators do not follow the tool list faithfully and tool setups tend to wander further and further from their original specs over time, which is terrifying.

I'm thinking for this to all work the way I think it should, we'll need to have one or two more experienced guys on the floor be in charge of the tool setup, rather than the, for lack of a better word, button pushers (though I started out as one so I shouldn't bad mouth them too much). Those few employees would have the access to the tool setup sheets from the management software and update things when they change which would, ideally, alert us programmers what we need change. 

I also think it would help the programming side immensely if we had up-to-date tool library information we could trust to program with, without having to wander into the shop to verify. Like you said, time savings is something that can be hard to quantify but can make a huge difference down the road.

Thanks for the input!

That all makes perfect sense. I'm still really new to post editing - I've been able to make small edits here and there but there are a lot of things that I'm still working on understanding. Thanks for your help!

I was able to just now work it out, adding that logic inside the boolean for the retractflg and setting the last value of the offsets within plast. Here's my solution:

      if retractflg = 0 & op_id$ <> last_op_id,  #output if not forced output above with the G43
        [
        if mr1$ <> 1 | (mr1$ = 1 & mr2$ <> last_mr2), phsm1_on
        if tlngno$ > 1000 & tloffno$ > 1000, #New tool offset logic *Offset #8000=HB/DB, 9000=HC/DC       #FHC 02/27/17
          [
          if tlngno$ = 8000 & tloffno$ = 8000 & tlngno$ <> last_tlngno & tloffno$ <> last_tloffno,
            [
            pbld, n$, "G56",  pfzout, "HB", "DB", scoolant, e$
            ]
          if tlngno$ = 9000 & tloffno$ = 9000 & tlngno$ <> last_tlngno & tloffno$ <> last_tloffno,
            [
            pbld, n$, "G56",  pfzout, "HC", "DC", scoolant, e$
            ]
          ]
        else,
          [
          pbld, n$, "G56",  pfzout, "HA", "DA", scoolant, e$
          ]
        ]
      c_msng$ #Single tool subprogram call
      plast
      toolchng0 = zero

plast
      last_op_id = op_id$
      last_cuttype = cuttype
      last_rotary_type = rotary_type$
      last_tlplnno = tlplnno$
      last_mr1 = mr1$
      last_mr2 = mr2$
      last_mr3 = mr3$
      last_mr4 = mr4$
	  last_tlngno = tlngno$ #FHC 02/27/17
	  last_tloffno = tloffno$ #FHC 02/27/17

That's what I thought, as well. A null tool change is just a new operation with the same tool, correct? Here is my current null tool change block. Near the end you should be able to see the logic for the offset options. 

ptlchg0$         #Call from NCI null tool change (tool number repeats)
      toolchng0 = one
      if op_id$ <> last_op_id,
        [
        rd_params$  # Read parameters - pparameter
        pmisccheck
        ]
      pcuttype
      toolcount = toolcount + 1
      if toolcountn <= tooltotal, nexttool = rbuf(4,toolcountn)
      else, nexttool = first_tool$
      retractflg = 0
      if cuttype = 0 & last_cuttype <> 0, clampend_flg = 1
      if (mi10$ & (op_id$ <> last_op_id | (op_id$ = last_op_id & xform_op_id$ <> op_id$)))
        | ((tlplnno$ <> last_tlplnno | rotary_type$ <> last_rotary_type) & ret_on_indx)
        | (mr1$ = 2 & op_id$ <> last_op_id & mr2$ <> last_mr2),
        [
        phsm_off
        if mi10$,
          [
          pretract
          n$, *sm00, e$
          result = force(spdir2,spdir2)       #Force spindle output after M00
          result = force(speed,speed)         #Force speed output after M00          
          ]
        else, pretract0
        retractflg = 1
        ]
      else,
        [
        if mr1$ <> last_mr1 | mr2$ <> last_mr2, phsm_off
        if clampend_flg,
          [
          pbld, n$, pclamp, e$
          clampend_flg = 0
          ]
        ]

      pcom_moveb
      pcheckaxis      #Check for valid rotary axis
      c_mmlt$ #Multiple tool subprogram call
      comment$
      #pcomment3
      pcan
      if plane$ < 0 | opcode$ = 3 | opcode$ = 16, plane$ = 0
      if op_id$ <> last_op_id, pbld, n$, sgplane, e$
      pspindchng
      if coolant$ <> 0 & coolant$ <> sav_coolant & sav_coolant, pbld, n$, sm09, e$
      pbld, n$, scoolant, e$
      sav_coolant = coolant$
      if coolant$ = 1, sm09 = sm09_0
      if coolant$ = 2, sm09 = sm09_1
      if coolant$ = 3, sm09 = sm09_2
      if op_id$ <> last_op_id, pstock
      if sav_mi9 = 1, workofs$ = sav_workofs
      if (wcstype > one & workofs$ <> prv_workofs$) | (tlplnno$ <> last_tlplnno) | retractflg,
        [
        if convert_rpd$ = one,
          [
          gcode$ = one
          feed = maxfeedpm
          ipr_type = zero
          ]
        sav_absinc = absinc$
        absinc$ = zero
        pindex
        if retractflg,
          [
          if safe_index,
            [
            if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$
            pbld, n$, pgear, e$
            pbld, n$, *sgcode, [if not(index), sgabsinc, pwcs], pfcout, pspindleout, e$
            if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$
            pbld, n$, pfxout, pfyout, e$
            ]
          else,
            [
            if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$
            pbld, n$, pgear, e$
            pbld, n$, *sgcode, [if not(index), sgabsinc, pwcs], pfcout, pfxout, pfyout, pspindleout, e$
            if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$
            ]
          phsm1_on        #must remain before G56         
          #pbld, n$, pfzout, scoolant, e$  #"G56", "HA", "DA", #*tlngno$, *tloffno$,
#New tool offset logic *Offset #8000=HB/DB, 9000=HC/DC       #BJL 08/29/16
          if tlngno$ > 1000 & tloffno$ > 1000,
            [
            if tlngno$ = 8000 & tloffno$ = 8000,
              [
              pbld, n$, "G56",  pfzout, "HB", "DB", scoolant, e$
              ]
            if tlngno$ = 9000 & tloffno$ = 9000,
              [
              pbld, n$, "G56",  pfzout, "HC", "DC", scoolant, e$
              ]
            ]
          else,
            [
            pbld, n$, "G56",  pfzout, "HA", "DA", scoolant, e$
            ]
          ] 
        else,
          [
          if fmtrnd(prv_cabs) <> fmtrnd(cabs),
            [
            if safe_index,
              [
              if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$
              pbld, n$, [if not(index), sgabsinc, pwcs], pfcout, e$
              if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$
              pbld, n$, pfxout, pfyout, e$
              ]
            else,
              [
              if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$
              pbld, n$, [if not(index), sgabsinc, pwcs], pfcout, pfxout, pfyout, e$
              if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$
              ]			  
            pbld, n$, pfzout, e$
            ]
          else,
            [
            pbld, n$, sgabsinc, [if not(index), pwcs], pfxout, pfyout, pfzout, pcout, e$
            ]
          ]
        pe_inc_calc
        ps_inc_calc
        absinc$ = sav_absinc
        ]	
      if lock_codes = one & cuttype <> last_cuttype & cuttype > 0, pbld, n$, *sunlock, sunlockcomm, e$
      if cuttype = zero, ppos_cax_lin
      if lock_codes = one & cuttype <> last_cuttype & cuttype = 0 & fmtrnd(prv_cabs) = fmtrnd(cabs), pbld, n$, *slock, slockcomm, e$
      if gcode$ = one, plinout
      else, prapidout
      pcom_movea
      if retractflg = 0 & op_id$ <> last_op_id,  #output if not forced output above with the G43
        [
        if mr1$ <> 1 | (mr1$ = 1 & mr2$ <> last_mr2), phsm1_on
        ]
      c_msng$ #Single tool subprogram call
      plast
      toolchng0 = zero

This may be where my problem is, because it normally wouldn't output a new length or diameter offset unless forced to, or it saw a change in the toolplane of the next operation. When I added that logic to the very end, after the "if retractflg = 0" logic it then would output the tool offsets, even on every pass of a multi-pass contour. That's where I tried to add the conditions it being not equal to the previous. I hope that makes a little more sense. 

Hey everyone,

I'm working on getting our Okuma post to be able to use the available offset options in the control (HA/DA. HB/HB, HC/DC). We had help getting this option for tool changes and null tool changes, however I'm trying to get it to work in between different ops with the same tool number. Here is an example of the logic in the ptlchg0 block:

      if tlngno$ > 1000 & tloffno$ > 1000,
        [
        if tlngno$ = 8000 & tloffno$ = 8000 & tlngno$ <> prv_tlngno$ & tloffno$ <> prv_tloffno$,
          [
          pbld, n$, "G56",  pfzout, "HB", "DB", scoolant, e$
          ]
        if tlngno$ = 9000 & tloffno$ = 9000 & tlngno$ <> prv_tlngno$ & tloffno$ <> prv_tloffno$,
          [
          pbld, n$, "G56",  pfzout, "HC", "DC", scoolant, e$
          ]
        ]
      else,
        [
        pbld, n$, "G56",  pfzout, "HA", "DA", scoolant, e$
        ]

As you can see, I'm trying to get it to recognize and output the new offset value only if it has changed. It's still posting out whatever offset value is active regardless if it was previously active or not. I may just be trying to put it in the wrong spot or maybe the logic just isn't right. Any help is always appreciated!

H adress is a C axis incremental motion (H-343.4599 will rotate 343.4599degrees from that point). I don't know what your tool path should exactly do but it can be correct.

Thank you, Colin. That is exactly what it is doing, chamfering around a cylinder using the C-axis for rotation. There is a tab on the cylinder that it chamfers (using the absolute C-axis positioning along the Z-axis), and between the start and end of that tab it must be switching to that H incremental C rotation. Makes sense!

Hey everyone,

I'm trying to better understand inverse feed for a Mazak Integrex J200 Mill-Turn. I'm doing a C-axis contour path to cut a chamfer on a part and I'm just not sure if the code is correct. Everything looks okay, there are feed rates on each line, etc, but it's posting out an H address for the C rotation when there is no movement in Z. Is this correct, or is something not right in my control def/post? Sample code is below. I appreciate any help. 

O1111(OP1 - 13965)
(2/24/2017 10:36 AM)
(OP1 - 13965)
(*************TOOL LIST************************)
(T6 | .25 CHAMFERMILL                |  LEN. - 6.  |  DIA. - 6. )
(***********************************************)
N6
(T6 | .25 CHAMFERMILL                |  LEN. - 6.  |  DIA. - 6. )
(CHAMFER ALL AROUND)
M200
G10.9 X0.
G20 G40 G80 G18 G94 G90 G98
G91 G28 X0. Y0.
G91 G28 Z0.
G90
T6 M6
G91 G28 X0. Y0.
G91 G28 Z0.
G90
M901
M108 M212
G55 G0 G90 B90. C274.9295
M107 M211
G97 S1000 M03
G18 G90
G0 G18
G43 H#3020 X2.755 Y0. Z.073
X1.855
G94 G1 X1.7275 F4.
G93 C275.5825 F203.184
Z.0591 C275.5298 F285.756
Z.0459 C275.3789 F286.292
Z.034 C275.1358 F287.07
Z.0241 C274.8127 F288.053
Z.0167 C274.4258 F289.045
Z.0121 C273.9945 F289.848
Z.0105 C273.542 F291.257
C272.5421 F132.676
C271.5417 F132.614
C270.5414 F132.632
C270. F245.038
C269.0001 F132.676
C267.9997 F132.614
C266.9994 F132.632
C266.458 F245.038
C265.4576 F132.614
C264.4568 F132.561
C263.4562 F132.589
C262.6712 F168.998
Z.0094 C262.4453 F579.793
Z.0062 C262.2405 F575.363
Z.0012 C262.078 F572.686
Z-.005 C261.9737 F570.045
Z-.012 C261.9366 F566.069
Z-.0645 C261.9385 F76.226
H-343.4599 F.386
Z-.0644 C278.2722 F642.842
C278.1425 F1022.849
Z-.0645 C278.075 F1965.581
C278.0615 F9848.908
Z-.012 C278.0634 F76.284
Z-.005 C278.0259 F565.892
Z.0012 C277.9215 F570.049
Z.0062 C277.759 F572.689
Z.0094 C277.5542 F575.365
Z.0105 C277.3288 F580.996
C276.3288 F132.667
C275.3282 F132.576
C274.3274 F132.566
C273.542 F168.925
Z.0121 C273.0894 F291.2
Z.0167 C272.6581 F289.848
Z.0241 C272.2713 F289.044
Z.034 C271.9482 F288.052
Z.0459 C271.7051 F287.071
Z.0591 C271.5542 F286.292
Z.073 C271.5016 F285.762
C272.1545 F203.184
G0 X2.755
M05
G91 G28 X0. Y0.
G91 G28 Z0.
G90
M01
M30

It's been a year since we purchased and began implementing TMS Silver. It's been working great; biggest problem was changing the mindset of all the employees that use it.

That is Zoller, correct? Not sure how large your shop is, but would you recommend it to a shop on the *relatively* smaller size - we have about a dozen mills (though that is going to increase in the near future).

And yeah, apart from learning the software and building the databases, the biggest hurdle by far is going to be making sure everyone in the shop abides by the proper practices. 

Frank we have the MDM for Data Management and revision control from the NC files to the Mastercam files but we have nothing to for Tool management at this point.

I am going into a meeting with the MDM developer in about an hour. I will ask if there are any thoughts for adding any type of tool management in near future 

 

Frank any cahnce you and me spoke?

Jay, 

That's what I have gathered so far from my research. Cimco MDM looks like a very nice product and the integration with Mastercam is obviously a plus. I had been talking with local dealer and even an applications engineer from Cimco (I think... he didn't seem to have much knowledge on the MDM product), but haven't heard back in a week or so. Since then I have shifted my focus to strictly Tool Management solutions because I think that is where we have the most to gain. However, I always appreciate any info that could help make our shop more productive!

Frank,

 

I manipulate WinTool and Zoller databases on a weekly basis. I've written half dozen applications to query WinTool and CIMCO databases. Don't bother to waste time building MC databases if you are going to have WinTool2Mastercam interface.

 

Not a technical constrain, but anyway WinTool is MS-SQL or MS-Access and Mastercam is SQLite. It's like saying your are going from TCP/IP data transfer to save stuff in a file.

 

 

Besides, their tables don't have much interoperability with each other in terms of how data is structured. They're designed with different purposes in mind.

Daniel,

Thanks for the insight. I'm still learning more about the background computer programming aspect of things (editing posts and, as you do, manipulating databases). The possibility of the two databases (WinTool and Mastercam) communicating well with each was a concern of mine from the beginning. I'll suggest to our programming staff that we hold off or at least not put so much time into our tool library work until we have a better idea of the direction we are going. Thanks for all the help!

WinTool admin here...

 

Your efforts in other systems will be pretty much useless datawise speaking...

 

There's a thread here about Tool Management software... It's worth a read...

 

You mentioned Cimco? For tool management?

Yes, I had looked into Cimco for a complete data management package, but I guess that doesn't apply to what we're looking for now. I had also seen that thread on Tool Management recommendations - I'll revisit it and go over more thoroughly. 

Your reply is what I was looking for, as to whether or not we're wasting time updating and building Mastercam tool databases before trying to implement any kind of tool management package. I understand with any type of software there is going to be a lot of upfront work creating these databases, but if they need to built from the ground up within their software, then we're probably just doing more work than is necessary. 

I apologize for any lack of clarity. I'm a younger, less experienced programmer trying to learn as much as I can about how all of this works before we dive in to such a big project. The company I work for is probably relatively small (about 40 employees and a dozen mills) compared to a lot places, but we're anticipating a lot of growth in the near future and want to get as organized as possible before then. 

Thanks!

I have a question for those who have implemented tool management software at their shops. 

We're currently in the process of updating our "master tool crib" mastercam tool library, which contains all of the tools our shop uses. We're also looking at our options for tool management software, talking mostly with Wintool right now, although I'm waiting on more info from Cimco. 

My question is this - should we be waiting until we implement a software to go through all of the data entry stages? Or is it still a good idea to have up-to-date, detailed mastercam tool and assembly databases?

Let me know if I didn't explain something clearly. 

Any input is appreciated. Thanks.