bigprody

Verified Members
  • Content count

    146
  • Joined

  • Last visited

Everything posted by bigprody

  1. bigprody

    Metric to Inch

    So all of my work in Mastercam is in Metric units. Most of the machines I am posting to are Metric machines. There is a few instances where I need to post to a machine that is setup for inches. I do not want to have 2 copies of the same Mastercam file. How would it be best handled posting from a single MC file to both Metric and Imperial?
  2. bigprody

    Metric to Inch

    Thanks for your suggestion. Unfortunately that is our problem we use the macro variables on every program that we run. I need to be able to post inch or metric, if I have to have 2 separate post processors I guess that is what I will have to do. It just means that if there is a post mod made that I will need to do It twice.
  3. bigprody

    Metric to Inch

    Yes they do but I do not think that solves my issue.
  4. I need to have my post generate code for running tool touch off macros after the main code is run. I already have a buffer that loads up tool info at all the tool changes. My problem is that at times a tool might come out twice thus loading the buffer with the same tool twice. When I then loop thru the buffer and spit out tool touch off macros I get multiple callouts for the same tool. I would like to have the post only create code once for each tool. The goal is to have NC code that needs no editing. I am having difficulty wrapping my head around the logic needed for this. I know how to make this happen at the machine. With macro B I can make it skip a repeat, I would much rather take care of it in the post as it would be much more seamless out on the floor. Any thoughts would be great.
  5. bigprody

    Buffer help, I think?

    Thanks Jeff, everything worked well. I matched up your stuff to my MP documentation and it is making some sense to me. I owe you a beer. If you are ever in the Chicagoland area I would be happy to buy you one.
  6. bigprody

    Buffer help, I think?

    Many thanks. Where do I go to learn all this stuff?
  7. bigprody

    Buffer help, I think?

    So If I have this correct, in the tool change section I run "pget_tool_parameters", this loads the all parameters I need for the current tool. Next I call "padd_tool_to_stack", this loads the parameters in the stack if the tool does not repeat. Calling the write sections seem pretty straight forward. I will dive into this and see how it goes. Thanks
  8. bigprody

    Buffer help, I think?

    Ok, after looking at it a bit more I see what you are doing with pheader$ and peof$. I don't quite understand the logic in the "padd_tool_to_stack" section but if it prevents duplicate tools from being loaded I will just grab what you have and use it. When it comes to the skills I have in my tool box, post mods. are not my best asset. I stumble thru them till I get what I need and then I am done. I seem to only spend time on this when I change jobs, once the posts are set I don't exercise that skill for years. I frequent this forum often, usually just lurking and learning. There are a group of very knowledgeable people on here that are very helpful and have made this forum a big asset for both me and the Mastercam community, you are obviously one of them. Thanks again for your time Jeff.
  9. bigprody

    Buffer help, I think?

    Thanks Jeff, you seem to be operating a bit above my head but let me see if I have what you posted figured out. You are loading a stack (what ever that is), of the tool info, in the parameter read post block. I would guess that I could then output that info later in the post as needed. It looks like there is some logic written to prevent the same tool to be loaded twice, if so perfect, that is the key to what I am trying to do. I will spend some time looking thru my post document stuff and see if I can figure a bit of this out. Thanks again
  10. bigprody

    Buffer help, I think?

    I am running outside if conventional post flow here a bit. I have a couple of buffers loaded with the tool and op info I need. This gives me a counter that I use to re-output the info as I need after the code for the specific operations are run. My peof$ section is quite large as I need to loop thru my operation sequence a few times at the end of posting to get what I need. Again I use the buffers as counters for the loops and extract what I need from them. The path I started down is where I am trying to load another buffer (b4) as I am looping thru one of my main ones (b2). I am trying to evaluate the new buffer (b4) to see if there are any duplicates. It does not seem to be working. Below is the code, maybe something will jump out to you as wrong. "(TOOL CHANGER LOAD PROGRAM)", e$ rc2 = 1 rc3 = 1 while rc2 <= size2, #while read counter, less or equal, to "last row number" [ rc4 =1 tl_skip = 0 b3_speed = rbuf(3, rc3) #read each row, starting with 1. str_temp = sopen_prn + drs_str(2, b3_speed) + " " + drs_str(2, b3_prog) + " " + drs_str(2, b3_numb) + " " + drs_str(2, b3_tcp) + " " + drs_str(2, b3_rl1) + " " + drs_str(2, b3_rl2) + " " + drs_str(2, b3_rl3) + " " + drs_str(2, b3_rl4) + " " + drs_str(2, b3_ptang) + " " + drs_str(2, b3_op) + " " + drs_str(2, b3_dir) + " " + drs_str(2, b3_chktl) + " " + drs_str(2, b3_qty) + " " + drs_str(2, b3_pitch) + " " + drs_str(2, b3_full) + sclose_prn # str_temp, e$ *rc2, e$ if rc2 = 1,#First time thru it skips the check [ b4_tool = b3_tool b4_tool = wbuf(4, wc4)#loads first position of buffer 4 with tool number sb2_str = rbuf(2, rc2) #read each row, starting with 1. 'rc2' auto-increments! brk_str = strstr(" ", sb2_str) str_temp = brksps(brk_str+1, sb2_str) #Tool Number and comment brk_str = strstr(" ", str_temp) sb2_str = brksps(brk_str+1, str_temp) stool_cmnt = "#3006=(LOAD " + str_temp + ")" if b3_tool = 1, ld_tool = 19 if b3_tool = 2, ld_tool = 20 if b3_tool = 3, ld_tool = 21 if b3_tool > 3, ld_tool = b3_tool - 3 "G100", *ld_tool, e$ stool_cmnt, e$ "G100", *b3_tool, e$ if rc3 = 2, "G65P3501Z0", e$ "G65P3010Z0", e$ ] else,#After the first loop, checking buffer 4 for duplicates. [ *rc4, e$ *size4, e$ while rc4 <= size4,#-----------------This is what does not seem to be working. [ b4_tool = rbuf(4, rc4) #read each row, starting with 1. *b4_tool, e$ if b4_tool = b3_tool, tl_skip = 1 ] b4_tool = b3_tool b4_tool = wbuf(4, wc4) sb2_str = rbuf(2, rc2) #read each row, starting with 1. 'rc2' auto-increments! brk_str = strstr(" ", sb2_str) str_temp = brksps(brk_str+1, sb2_str) #Tool Number and comment brk_str = strstr(" ", str_temp) sb2_str = brksps(brk_str+1, str_temp) stool_cmnt = "#3006=(LOAD " + str_temp + ")" if b3_tool = 1, ld_tool = 19 if b3_tool = 2, ld_tool = 20 if b3_tool = 3, ld_tool = 21 if b3_tool > 3, ld_tool = b3_tool - 3 if tl_skip = 0, [ "G100", *ld_tool, e$ stool_cmnt, e$ "G100", *b3_tool, e$ if rc3 = 2, "G65P3501Z0", e$ "G65P3010Z0", e$ ] ] ] "M30", e$
  11. bigprody

    3D Contour flipping back to 2d mode randomly.

    Yes, I am glad you posted this cause I thought I was doing something to cause this.
  12. One of our standard setups here is a array of double Kurt hydraulic vises where parts are clamped on either side of the center jaw. A lot of the jobs are where the same operation is run on the front and back loads. Is there a fairly simple way to have a post output code both how it is programmed and then also rotated 180 for the back load. We run all of our machines using master Macro B programs with the tool paths loaded into them. I am trying to eliminate a lot of the cutting and pasting that we do now. It would be great if I could just program the one instance and the post would handle the rest.
  13. bigprody

    Posting at 180 deg rotation

    Thanks guys for all of the thoughts. Checking on this Monday morning so I will respond in order. Pseudo code: Tool path: O0002 ( STEP DRILL G54 FRONT VISES) G17 G0 G90 X40. Y0. Z3. G99 G73 X40. Y0. Z-31.17 R3. Q2.5 F2667. G80 Z3. G17 M99 O0102 ( STEP DRILL G55 BACK VISES) G17 G0 G90 X40. Y0. Z3. G99 G73 X-40. Y0. Z-31.17 R3. Q2.5 F2667. G80 Z3. G17 M99 The above examples are for the same operation, one for the front vise, one for the back. 2 separate programs, O0102 is rotated 180. We reset the work offset like this. G52 X-[#540*5] and then just recall the sub. No router, Brother D&T machines. Coordinate rotation is defiantly an option. It will change slightly what they see on the floor but I might be able to get that to fly.
  14. bigprody

    Posting at 180 deg rotation

    Thanks for the example. The way we handle it is front left is G54, back left is G55. As we bump along our grid the same 2 work offsets are updated in the program. The setup guys were all born and raised here, this macro structure is all they know, they know it well though and can move thru a setup quite quickly and well. I know there is more than one way to skin a cat with this and I am still the new guy here. After I gain a bit more of a foot hold I will introduce a few fresh ideas. The other goal is if over the next year or so I can dial MasterCam in to their macros it will make it much easier for someone else to program efficiently. I will look into the MPSubrep. Thanks again
  15. bigprody

    Posting at 180 deg rotation

    That is an option, the hiccup with that is the master macros that they run everything thru here. There is no changing that and rightfully so. The master programs are well thought out and the setup workflow that the floor guys have is pretty solid. I would like to idiot proof the programming side as much as possible. They use G54 for the front, G55 for the back. The thought is, program one instance, give it a pitch and a qty using miscellaneous variables and the post just loads the master macro. Simple, just like I need it to be.
  16. bigprody

    greyed op folders

    I am going thru some programs from a previous programmer and ran across something I have not seen before. Why are op folders 14 and 19 greyed out. They seem to post fine.
  17. bigprody

    greyed op folders

    Yup, that is it. DUHHH! Thanks
  18. I am out of my element when it comes to these machines. There is a chance we might have some work that would suit this type of equipment. We would need a thru bore of about 3.0 inches and would be using mostly live tooling. Who makes the ones we should be looking at?
  19. Thanks Doug, that is our initial thought. You and the rest of the ones that have responded are very helpful here. When any of you respond to a post I make sure I read it hoping to tap off as much of your guys knowledge as possible. Thanks again everyone and enjoy your weekend fellas.
  20. Chips should not be an issue, at least initially. As we do it now most of our product starts as saw cut extruded alum blanks. We stack as many into a fixture as we can and then run them on verticals. We would be wanting to bar feed some irregular shapes, do the work on one side, xfer to the other side and finish. Is bar feeding odd shapes rather doable? I am sure though once we have a lathe on the floor turning work will start showing up.
  21. Thanks guys, we run mostly alum. and the tolerances are usually not too tight. We are looking at these to get some lights out hrs with a bar feeder. Sounds like both of you are already doing what we would like to do.
  22. bigprody

    Colors in Simulation

    I hope there is a way of doing this. How do I have each tool give me a different color on the cut stock?
  23. bigprody

    Colors in Simulation

    Nope that is it. Thanks
  24. bigprody

    Post Processing: Office Hours Sessions

    I would be interested as well.
  25. I am looking for the variable that returns the value from Tool Description in the tool database. MC 2019.

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