AlphaCAM nesting problem
Should the postprocessor be modified? March 23, 2002
Question
When I nest parts and generate NC codes for Heian, I get overtravel in my x and y. I suspect that my machine requires x0 and y0 at top right corner, not the bottom left corner as automatically assumed by AlphaCAM. Where in the postprocessor can I modify x0 and y0 location?
Forum Responses
This isn't a problem with AlphaCAM. Do not modify your post to handle this. It's a ton of extra work that doesn't need to be done. Simply move your work offset (G54-G59, etc.) at the control to accommodate your parts.
From contributor E:
The above is right - you will have the least amount of grief if you can use work offsets. However, I have been in a similar situation with a machine that was not very friendly with work offsets, and our solution was to draw everything in the third quadrant. Actually, you do not have to draw it there - just move the finished drawing from lower left corner of drawing is zero, zero to upper right corner of drawing is zero, zero. I definitely have to go with the above on this, but try this other method in a pinch.
Another solution is to set your main work origin, G54, at the lower left corner of the table. Draw a layout of your table in AlphaCAM with the origin at this corner. Keep this file as a template and place your work geometry on this table. Most likely, you have some kind of stops you are working from. This will keep your toolpaths within the travel of the machine and all your work in the X+Y+ quadrant. Be as accurate as you can with your table layout. I use a wable indicator to edge find all the corners of the table.
From the original questioner:
I'm showing my lack of experience with Heian, but here is what I've done. I draw all of my drawings on a template based on third quadrant and my physical origin is with head @ far right and table @ all the way front to the operator. All my routine cad output from AlphaCAM works fine with this setup.
To implement your suggestions, I manually moved head to far left (highest x value) position, and table far away from operator (highest y value). I then reset G54 to 0,0 from operator console and ran nested output. I still get over travel. I have not tested with other 2 positions, but that was going to be my next test. Am I on the right track?
I have 8+ years experience with AlphaCAM. Although all the above suggestions are good, the problem really can be handled best and with no extra effort on your part when programming in AlphaCAM or at the machine, by changing offsets, etc. The best and easiest way is in the post processor, as you originally suspected.
From contributor E:
I re-read your initial post, and the above post also. The "where" is rather dependent upon the controller, and the methods used to manage tools. If you open up AlphaEDIT and then F1 for help, go to Postprocessors>List of $numbers. There you will find the "map" of the post. You could set your machine offsets in a number of places, including $10 File leading lines, $12 Main program leading lines, or $80 Select new tool. There are probably other places, but I use $12 and $80. $12 to establish which set of origins to use, and $80 which includes a construct that parses tool number which in turn dictates which spindle is called. My controller has a table of origins, of which I currently only use two. These are like the G53, G54 and so on. These origins are at the lower left corner of the two tables. My machine homes to the “upper right” like you describe, therefore the origins are negative offsets from the machine home. I have fixed distance spindles that are selected by tool number. Tools 1 to 10 are spindle 1, tools 11 through 20 are spindle 2. If spindle 1 is called, then the origin offset is zero; if spindle two is called the origin offset is AX-SN1 (where SN1 is the distance between spindles). Therefore, when I pick a tool, I check to see which spindle it is, and use the appropriate temporary offset. I won’t get into drill block assignments.
I would suggest you take John up on his offer to help, if your machine vendor has no interest in taking care of the issue. Rewriting a post for AlphaCAM really can be a royal PITA for most. The consequences of incorrectly writing the post can be brutal. However, for someone familiar with both the AlphaCAM system, and your particular machine, it is fairly straightforward, if somewhat tedious.
If you choose to modify the post yourself, make sure you save the working copy somewhere safe, before making changes. Then, you will want to go through the help files, from AlphaEDIT, not from AlphaCAM, and print out most of the related subjects. Including user variables, $numbers, Assignments and Conditionals, and any others that appear applicable. I suggest you spend a couple of hours just cruising through the Help topics. The post generally follows classic computer programming construction, but many of the features are limited in scope. Specifically, you cannot nest constructs, and variable assignments are a bit crude. Branching is a little confusing because you can branch only within each section (with one exception in section $5, executing a file, see $store, $run, $recall), so you could use the same "goto" label in every section without the expected execution error.
AlphaCAM does have one feature regarding the post that seems to get some people really excited, and that is that you can have the post written in Microsoft Visual Basic. It still calls the regular post, but the Post outputs to the VBA application which in turn can do all manner of manipulations, eye candy, and other such stuff, recall the masticated data back into the Post, and output the digested NC code, smelling like roses, if your VBA post is right, otherwise it may be less... palatable.
Have you checked the actual travel limits of your Heian? It's quite possible that you simply don't have enough travel on the machine to accommodate your particular nest. Either that or you need to modify your nesting settings to accommodate your machine limits.
Take a look at your "Gap at sheet edge". It's quite possible that, even after having reset your G54 to the left-most machine limit, lead-in/out moves maybe even further past that point and cause an overtravel.
After having used FANUC controls for well over 15 years I can tell you editing a post to output hard-machine coordinates is just plain foolish. What you have already done is exactly correct.
From the original questioner:
I had to study the machine manual just to understand your suggestions, but I got it working! My problem was that I did not change all 4 work offsets (G54 thru G57) corresponding with each of 4 router heads.
Next task would be to change existing programs drawn on 3rd quadrant to 1st quadrant to work with new work offset.
The comments below were added after this Forum discussion was archived as a Knowledge Base article (add your comment).
Comment from contributor A:
It is very easy to modify your Post in AlphaCam. Modify all your Zero Points and offsets. That way, every time you proccess a program all your points will be correct, no second guessing. You can also change your user prompts so if you do change your head offsets manually you can easily change it.
Comment from contributor D:
What I have done to fix this problem in the past is let ACam create the nest. Before you output code, replace the yellow nest sheet with a new geometry and set the work volume and material size. Move everything to the correct quadrant then output the code. In your case, grab the upper RH corner of the sheet move to 0,0. This should give you code that is X-Y-. All of your tooling information should remain the same.
