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:

steve f

Verified Members
  • Posts

    258
  • Joined

  • Last visited

    Never

Everything posted by steve f

  1. Joeyls319, One thing that came to mind is to try decreasing the tolerance/linear deviation settings in the toolpath parameters. Increasing tool vector length might help as well. Also, if the corners that your tool is swarfing through has a radius close to the tool radius you might consider using a smaller dia tool so the endmill doesn't "rotate" so tightly around the top corner of your geometery chain/surface and risk gouging. HTH, steve
  2. I told a waitress once in Louisville I'd pay for the meal with Interac... She just looked at me like I was from another planet. Canada has better methods of paying (j/k) steve
  3. Check out Verisurf. The interface looks the same as mastercam and integrates directly into it. It's also modular so you only have to spend as much as necessary for what you need. HTH steve
  4. Hello flamers and freeloaders, Since this post issue seems to be a constantly recuring theme I thought I'd try to initiate a change in direction in this thread. What is a long term solution to people coming into this forum and, through ignorance or intention, looking for free posts. I wonder if this forum page needs a post processor link in plain sight, right up beside the search link. How about it webby? The often mentioned faq regarding posts could be stated at the top followed by a list of machines/controls directing the user to threads regarding that machine as well as a list of forum users emails willing to sell their post processors. Any requests for free posts could be directed to a post specific forum where the freeloaders would get their facts straight and the newbies would get the help they're looking for. Flaming is fun and all, but I think it leaves a bad taste in the mouth of new forum users not familiar with the Mastercam culture and may indirectly create bad PR for CNC Software (although very indirectly). Any suggestions? steve
  5. Thanks Peter, DNC Max has a long list of capabilities and I definitely didn't mention them all. CNCGuy, if you have to deal with many programs look into the NC-Base option that can be added to the Pro version of Cimco Edit in DNC Max. It is a pretty amazing database for managing your programs where doc files, setup sheets, image files, CAD files, etc. can be associated with the NC file for a part. All of that can be linked to part numbers, customers, machine groups or whatever you'd like. One big advantage of Cimco DNC Max and NC-Base are the customizable security settings that can limit access to certain shop personnel to whatever degree you'd like. HTH steve
  6. aft, I think you'd be better off doing what Peter Eigler suggested with offsetting your work because it sounds like what your doing is more like positional 4 axis work than just 3 axis machining on each side of the tombstone. If your tool and work offsets are set up relative to the y axis of rotation, you'll be able to call G55 and specify a B90/B-90 as if you were doing 4 axis work on a vertical. This would also make it a lot simpler than having three work offsets for each face of the tombstone. steve
  7. CNCGUY, Cimco DNC Max will remote request with Fanuc style, Mazatrol and Heidenhain controls. It can also be set up to remote request a directory listing of programs in folders on the DNC pc. It will also support drip feeding sub-programs and remote request can be initiated from one machine on the shop floor and have the program sent to a different machine. As far as bang for your buck, Cimco is hard to beat. HTH steve
  8. tony...yeh, something like a cache. I think after programming for a two or three years most people know just by looking at a part how they would machine it. The trick is to capture that skill of "knowing how" which is a combination of knowing what works from past experience and memory. I've encountered very few occasions where I can use the same toolpath from a previous part on a current one without changing parameters at all. I think it'd be great if we could capture the rules we use to make our decisions about programming and save them to a database instead of just the operations. It's hard to beat an example to get a point across so here goes: Let's say mastercam encounters a straight walled pocket with a 3D contour floor and two holes in the bottom of the pocket. The "feature manager" would show the features in an order like: 3D Pocket, 2 Holes. The rules in the config file would dictate that: the largest tool possible should rough, the largest tool smaller than corner radii should finish, drilling needs to start in material lying in an xy plane, surface rough pocket should be used for roughing 3D cavities, don't adjust stepover in operations, etc, etc. A saved operation from the library would be pulled in that used the same tool and operation that mastercam had established must be used. It would adjust any parameters in any ops that needed it according to the config file and re-generate all toolpaths at once to be associative with each other for things like leftover stock. In this case the operations generated might be like this: surface rough pocket (rough cavity), drill holes on z plane material left by roughing op (mcam would adjust cut depths parameters in rough op so drill would have minimum material to remove but still start on xy plane), remove leftover (with largest tool smaller than or equal to corner rad), and finish cavity (with largest tool smaller than corner rad). The saved operations would be a starting point for mastercam to adjust from to come up with the best solution according to the rules for machining that the programmer had established. Maybe I'll just have to hold out for ver X.1 steve
  9. Down the lines of what MayDay and Charles are talking about, I've been hoping for awhile that Mastercam would start heading in this direction. The problem I've always foreseen with fully automated programming is I don't want to program an entire part, ussually just some or most of the features. (ex: mold base components or a cast part). So this is my wish list Once AFR develops a little more I think it'd be great to have a "feature manager" that recongnizes all possible machinable features and builds a list that would be sequenced in a logical order. The programmers job is to deselect the geometery features that don't need machining (since there's ussually more that do than don't) and re-arrange the sequence if necessary, kinda like Lathe v9. Once all the features and sequence was established, Mcam would go through the manager and apply toolpaths from an operation database that had been saved from previous toolpaths programmed. If the feature manager encountered a feature that didn't have any toolpaths associated with it's type yet, then mastercam would resort to the ussual toolpath parameter window, generate the toolpath and prompt to save it to the database. The whole programming engine would be governed by sets of rules read from a customizable config file where everything from speeds/feeds, cutter size, stock allowance, etc would be established. Initially it would take as much time as programming now but as the toolpath database expanded and the "rules" became more detailed toolpath generation would take less and less time. So how about it Santa Claus...next Christmas maybe? steve
  10. botty, If the post your reseller has quoted you is the Cimco 5 Axis post than what you are saying is most likely true. The Cimco post isn't written specifically for your machine but can be configured by either you or your reseller (through a config file) for virtually any five axis machine out there. You'll have to pay for a post per sim because the potential value of the Cimco post is greater than a custom written one. steve
  11. Kathy, I think everyone here has had to start at the bottom and work their way up. I'm sure we can all think of a few times we were lucky management chose to turn a blind eye to a stupid mistake or two. If this guy reaches the end of probation and he's more useless than when he came in than he's just filling a position that some other hard working student should have. If he busts his a$$ though and wants to learn than he'll probably grow into a good employee. Keep in mind his standard for what he claims to know has only been measured against what he was taught in school. In comparison to learning by experience, school doesn't come close. My 2c steve
  12. I changed the target label in the GOTO statement to [R] so it's less work for the operator to edit but here's what I came up with. :G90 G40 G70 G80 G94 (PGM, NAME="305921 PART_TB.NC") (MSG, MATERIAL - STEEL INCH - 304 STAINLESS) (MSG, PROGRAM - 305921 PART_TB.NC) (MSG, DATE - NOV-21-03) (MSG, DRILL ONE) (MSG, T1 - #21 DRILL) :T1 M06 G00 D1 O0 S576 M03 (GOTO[R]) G90 H1 X.5727 Y-.6225 Z1. Z1. (CLS, "0001") (MSG, DRILL ONE) G90 H2 X.5727 Y-.6225 Z1. (CLS, "0001") (MSG, DRILL ONE) [R]G90 H3 X.5727 Y-.6225 Z1. (CLS, "0001") (MSG, DRILL ONE) etc... HTH steve
  13. Trevor, Down the lines of what James suggested, you might be able to include a system variable associated with the block number at the start of a drilling cycle which updates on each location. I'll look into it some more but there might be spare system variables that could be used for something like this. After replacing the tool he would just need to restart the program at that tool change, the program would jump to the last location drilled using a GOTO statement or he could manually change the location by initializing the variable to the block number he'd like started first. I'll check out the system variables though steve
  14. Hi Trevor, The A2100 control uses four different type of work offsets and each offset type builds incrementally on the other like this: pallet offset + multiple setup offset + fixture offset + nc program offset = part location. They don't all have to be used but that's how the hierarchy of the offsets would apply. How you set up your customers post depends on which machine offsets he wants to use and in what order. All the offset types have seperate tables in the control where the values are input, much like G54, G55, etc. except that only fixture and nc program offset table values can be called from within the program. This might explain it easier: Pallet Offsets: values can be recorded using a G92.2 after moving to the pallet ref position. This is only used for pallet conditions where there is a slight location error between pallets and not on machines with only one table. These offsets are used by default depending which pallet offset setup is flagged as active in the control (leave values as 0,0,0 for machines without pallets). Multiple Setup Offsets: values can be recorded into the multi setup offset table using G92.1. The table values are used the same way as pallet offsets where the program uses the setup flagged as active in the control. Fixture Offsets: values are recorded in the control fixture offset table and can be called from within the program using an "H" address and number corresponding to the fixture setup number in the fixture offset table. NC Program Offsets: works the same as fixture offsets except called using a "D" address. Programs for the A2100 control can be restarted anywhere if a block starts with a ":" colon character. It sounds like your customer is using either H offsets or D offsets so the easiest might be to setup the post so the main program contains all the primary moves after each toolchange with the offset calls and the sub-programs do all the machining. Sub-programs are called from the main using this format: (CLS,sub_name,2) where "sub_name" can be a number or text string and "2" is the number of times to repeat the sub-program. Subprograms need to look like this: : (DFS,sub_name) GCODE... GCODE... GCODE... GCODE... (ENS) I think subprograms can be nested up to 8 times but not positive about that. Comments can be used in nc programs as long as the block starts with a ";" semi-colon. HTH steve
  15. quote: One of the reasons is that they actually have people there working, writing & designing the software that (along with us) have hot chip scars. LOL I remember having blue hot chip fly inside my neck collar, rolling down and lodging in my navel...thought I was going to pass out, it hurt so bad. Back on topic though, I've used (in chronological order): Mazatrol (if it counts) Virtual Gibbs dabbled in Surfcam Mastercam steve
  16. Millman^Crazy, ...good thing about your machine, the less complicated the better. I discovered today after pulling handfulls of hair out that flipped machine coordinates can be accounted for in the generic fanuc 5x post by setting the axis vectors in the machine base matrix. Also figured out how to get correct output of the rotary angles and rotary limits but the big problem is looming above...compensating for the distance from rotary intersection point to tool tip. It's going to be a long week steve
  17. Millman^Crazy, I'm working on a post for a Thermwood 67 as well. It's an older machine that was wired so that the machine axes are flipped 180 about the x axis in relation to a normal top view. It's taking a lot of work to set up different matrices (sp?) and wondering if you've run into the same problem? steve
  18. Hi ak762, ...no hurt feelings here, I haven't had a chance lately to get on here and reply but thanks for the info. I'm open to any suggestions and I'll definitely give yours a try when I get the chance. steve
  19. lars, quote: pbld??? flg_mi5??? []????? Why do the post need to know my max. spindel speed??? pbld: this is a call to feature called a postblock which contains the logic to decide if a block delete character will be written to the nc file. Postblocks in the pst file serve a similar function to sub-programs in an nc file where certain "actions" are used repeatedly. flg_mi5: is called a user-defined variable. You can make as many variables, and call them whatever you want as long as they aren't the same name as pre-defined variables that mastercam uses for internal post calculations. []: these are characters to write your logic/actions in following a conditional branching statement. ex. if drill_length > max_tool_length, [ n, "M00", e n, "CRASH IMMINENT, DON'T CYCLE START", e ] the stuff inside the "[]" would only apply to the statement written before it. The post needs to know max. spindle speed so it's not creating nc files with rpm that's impossible to run on the machine. The best help I got for post changes was a post documentation CD from my reseller...be prepared for alot of reading! HTH, steve
  20. ...all clearer explanation, quote: -the coordinates are written to the file as a group of 12 identical coordinates which isn't a big deal since it only requires to delete all duplicate points after importing into mcam. The program is supposed to append one set of coordinates after the previous set in the file (the machine manual says so anyway) but I can't seem to get that part to work. The coordinates for one postition are written as a batch of 12 identical points appended to each other. The next position is written as a batch of 12 coordinates appended to the previous batch and so on. steve
  21. Hi, For all you cincinnati users out there who occasionally program in macros on the Acramatic 2100 I thought I'd post this sample program I wrote for anyone interested in using it as well as to get some feedback on improvements (kill two birds with one stone). I used this program to reverse engineer the top face of a part that had a curving 3D surface. The program uses a manual indicator with a pointed tip in the spindle and is run in a semi-manual fashion. When the indicator tip has been positioned at the start point it is moved down manually until it reads zero, the cycle is started is, the control captures the x,y,z coordinates, writes them to an asci text file on a 3.5" floppy and moves the table to the next position in preparation for the next set of coordinates. Once all the coordinates were written to file, I imported them into Mastercam and used the grid of points to create a bunch of coons patch surfaces. The problems with this program at present are: -the coordinates are written to the file as a group of 12 identical coordinates which isn't a big deal since it only requires to delete all duplicate points after importing into mcam. The program is supposed to append one set of coordinates after the previous set in the file (the machine manual says so anyway) but I can't seem to get that part to work. -the logic isn't complete (no time lately) to cycle through a complete x,y grid. It will only capture points in a line on the y axis and the steopover to the next line in x needs to be done manually. Anyway, here's the program. I'm open to any criticism/suggestions you may have. ;POINT GRID AQUISITION PROGRAM FOR REVERSE ENGINEERING ;X0=LH SIDE ;Y0=FRONT SIDE ;Z0=HIGHEST POINT ON PART ;TOOLS ;T17=INDICATOR MOUNTED IN HOLDER ;***LOAD TOOL MANUALLY INTO SPINDLE FIRST*** ;**MOVE PROBE TO Z POSITION AND PRESS CYCLE START** G17G40G70G90G94G97 G80 ;SELECT VARIABLE VALUES [#LEN]=1 ;PART LENGTH (X AXIS) [#WID]=.5 ;PART WIDTH (Y AXIS) [#P_LEN]=.05 ;STEPOVER AMOUNT & DIRECTION ALONG LENGTH [#P_WID]=.05 ;STEPOVER AMOUNT & DIRECTION ALONG WIDTH /(CLS,"START") [#STEP]=[#P_WID] (FIL,="A:CAPTURE300.DAT"F1) ;(DO) (DAI,A110 B210 C310 T1 S1="REV ENG TEST") M34 M35 (DAS) G90G0Z1. G91Y[#STEP] ;[#STEP]=[#STEP]+[#P_WID] ;(LOOP WHILE [#STEP]LE[#WID]) M2 (DFS,"START") M26 T17M6 G0G90X0.1Y0.Z1. M2 (ENS) steve
  22. HEAVY METAL, Handshaking is the method that the DNC computer and the CNC control use to communicate with each other when it becomes necessary for both to "agree" when data should be transferred and when it shouldn't. A good example is during drip feed of a long program and the CNC data receive buffer is almost full. To prevent buffer overflow the CNC needs to tell the DNC computer/server to stop sending data until the buffer is emptied out by the machine using up more code during machining. If the control and DNC are set up for software handshaking, the control will send an Xoff Asci character to the DNC to tell it to stop sending data and an Xon character to tell the DNC to restart data feed. If you're using hardware handshake (which is better), the control sends a message to the DNC via a small current over lines on the RS232 cable that are not used for regular data transfer. That's why software handshaking only requires two pins to be connected on an RS232 port and hardware requires four (for Fanuc style control's anyway). HTH steve
  23. Murlin, You might be interested in contacting your Cimco Integration dealer as they sell a BTR protocol as well (I've been told). It would make your transition easier as well if you're using the OEM version of CimcoEdit included with Mastercam. steve
  24. For extra bonus marks add: How many inches will the tool travel under these conditions before turning into smoking ball off molten hss? steve

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...