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:

Frank Caudillo

Verified Members
  • Posts

    166
  • Joined

  • Last visited

Everything posted by Frank Caudillo

  1. We might give it a try then. We'll talk with various manufacturers and see what they recommend. Thanks! Thanks, Jlw. If we can't find an off-the-shelf solution we'll talk with them about something custom. Thanks!
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Cathedral, That look room looks like a thing of beauty, albeit an expensive one! Maybe one day we will be that clean and organized.
  8. 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?
  9. 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.
  10. 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.
  11. 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.
  12. 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!
  13. 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.
  14. 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!
  15. 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
  16. 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.
  17. 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!
  18. 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!
  19. 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
  20. 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.
  21. 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! 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!
  22. 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!
  23. 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.

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

×
×
  • Create New...