Post for a SCM Record 220 with NUM 1080

[Anonymous]

Hi,

We are looking to fully integrate Fusion360 into our design process and utilize its CAM fuctionality, wanted to see is anyone has a post processor for a SCM Record 220 with a NUM1080 controller?

Thanks!

[bob.schultz]

Do you have sample output for this machine?  I can then see if there is a generic post that closely matches your requirement that can be used as a basis for your post if no one else has already built a post for the SCM Record 220 with a NUM1080 controller configuration.

[Anonymous]

Hi Bob,

Yes I do and I am attaching it below. Also I have a copy of Alpha Cam's (which we are using now) post processor for a Record 220 which I am attaching as well. Can the alpha cam one be tweaked to work with fusion?

[bob.schultz]

Thanks for the information.  I will take a look at it and see if I can decipher the alpha cam post.  Do you have a part you have already programmed using HSM.  If so this would be beneficial for me to  test with.  Also if you have a controller manual explaining the codes that would be great too.

[Anonymous]

Hey Bob,

Here are the NUM Controller programming manuals you had asked for, I will work on getting you that HSM file. Thanks for helping out I appreciate it.

[Anonymous]

Hey Bob,

Here is a sample that we had drafted up for a fusion post for our machine, this might help you in the process.

Thanks Again!

Cameron Houston

[bob.schultz]

Hello Cameron,

You seem to have selected one of the more complex seed posts for your sample.  You're a brave soul.  Here is a simplified version of the post.  Since I do not have a typical part that you would run on your machine I made due with a part I had here.  This post will require a lot of analyzation on your side to see if the codes are correct.  There are different methods on how Inventor passes information to the post than the way that Alpha Cam does, so I did not fully implement all features of the Alpha Cam post, plus I do not know which features you require and which are "extra".

Please test this post fully and provide the part you are testing with, the output NC file, and a list of all changes that you require to be made.  If you are familiar with the format of the posts, then of course you are welcome to try the modifications yourself, especially if they are small.

This post is provided with no guarantees that it will run the machine in a safe manner or at all, so be diligent in your testing.

Thanks

The accompanying advice and or non-standard post processor is provided as-is and without warranty of any kind, and usage is at the user’s own risk.

[Anonymous · Accepted solution]

Hey Bob,

Again thanks for all the help with this process we really appreciate it. We finished up our testing of the post and we have a few bugs that I was wondering if you new a way to fix the post so it won't happen.

The first thing is the Decimal places in the E60000-E62000 at the beginning of the generated code and at the end would sometimes be over 10 digits. We were wondering if there is a way to adjust this and curb them at 3. This can be seen at the end of the attached generated G code files. 

Secondly, and this might be fusion CAM question, but is there a way to get our tool # to be our unique tool reference number because right now it seems to be generating them randomly and we have had to go in manually change the G code for every tool change.

Thirdly, and this might be a fusion CAM process as well, but we noticed that the spindle speed would vary and not stay constant. Does this have anything to do with the post or is this a fusion CAM strategy.

Fourth, this could be because of Fusions precision, we noticed that on a few of the curves we were cutting the machine got vary choppy like it was trying very hard to interpolate between the points.

Fifth, we got an error message saying unknown sub program sequence # for the following line of code

      N9870 M38

      E60000=-63.194-304.8*1000

      N9880 G77 N13 N9880

      N9885 M39

      N9890 G79 N1

The M38 appears to be fine as it is referenced on the G code generated by our old post.

We did some looking around and we think it might be the M39 which reference vacuum zone 2. None of our previous code with the old post did that. (FYI it was not the N9880 repeating itself either as we tried removing that part and still got an error).

Lastly, this line of code got the error unknown character and we don't know why as it looks like all the line of code generated around it.

     N32765 X2.979 Y2.5159 Z-0.2374

     N32770 X2.9803 Y2.5187 Z-0.2376

(This is in file 010.xpi)

I have attached the G code generated for 2 different test operations as well as Fusion file for the operation.

(Note: for 030.xpi we shortened the operation to only the contour)

[bob.schultz]

Thanks for providing the model and a good description of the problems.  Here are the answers to your queries and an updated post that hopefully resolves your issues.

1. The decimal places output with the E6 codes are now limited to 3 digits.

2. The tool numbers are assigned to each tool in the tool library.  You will need to edit the tool number in Fusion.

  a. Open the operation of the tool number you want to change.

  b. In the Tool page press the Select button.

  c. Press the Edit Tool button at the top of the Select Tool form.

  d. Change the tool number to your desired tool.

3. You have the Spindle Speed set to 12000 and the Ramp Spindle Speed set to 4890.  If you don't want the spindle  speed to change set these to the same values in the Operation->Tool page.

4. You can try tightening the tolerance of the operation.  This value is set in the Passes page of each operation.  In your machining operations I see tolerances of .0004-.004.  You can also try enabling smoothing in the operation you are having problems with and setting this tolerance.  Smoothing is also contained in the Passes page.  You will need to play with these values to see what gives you desirable results.  Once you get the tolerances dialed in, you can use them as your defaults for each part.

5. The codes output at the end of the program are straight from the Alpha Cam post.  There is a "vacuumCode" property that can be changed when you run the post.  I changed this to default to 1 and these codes are not output anymore.  In the previous post it was defaulted to 0, which is why these codes were output.

6. The error you are getting is because the sequence number exceeds 32768.  I have changed the sequence numbers to start at 1 and increment by 1.  I also added a check so that the maximum sequence number that will be output is 32768.  You can change the starting sequence number (sequenceNumberStart) and its increment (sequenceNumberIncrement) using the property table when you run the post.

Good luck and let me know if there are any other issues.

[Anonymous]

Hey Bob,

Thanks for the timely response you are really helping us out over here. I just ran the new post you gave us, but it looks like it still has not curbed the decimal places in the E60000s. I am attaching a text file of the generated code for one slot cut on the same part I sent you before. Is this a non post related error?

[Anonymous]

Looking over the post again looks like you may have accidentally attached another copy of the original one you gave us.

[bob.schultz]

No, the post I just attached is the modified one, I downloaded it here and it matches my latest version.  Make sure you download the post to the correct folder to overwrite your existing post and also be sure to take it from my last post and not from the original attachment.  One way you can verify that you are running the updated post is to check the 'vacuumCode' variable in the Properties table when post-processing.  This variable is set to 1 in the new version.

[Anonymous]

Hey Bob,

Everything ran great except we keep getting an error for the line that says

Last Tool = 

when we negate it with parenthesis everything runs fine and all tool changes go smoothly. Is this something necessary or can we have the post not generate that at all? Any downside to not having it?

[bob.schultz]

Sorry, it seems some debug code was left in the post.  Here is a version with it cleaned up.

[Anonymous]

Hey Bob,

Thanks for all your help in this process we really appreciate it. We have run a few parts and things were working out great until this morning. We were running a part that used a 2D pocket to drill/pocket a series of four hole (we would have drilled them, but our drills are not working at the moment). We set the holes to be pocketed with a negative axial stock leave (-.4 inches). We adjusted the safe distance to reflect this (1.4 inches, ie retract to an inch above the stock). Then we turned off the keep tool down command. However, when we ran the part, it drilled out the first hole, didn't retract and rapided over to the next hole (resulting in our bit snapping off in the part). Even weirder the next holes were pocketed how we wanted them with an inch retraction after each hole was done. More concerning was that in fusion , the simulation showed full retraction between each step. This lead us to believe this might be a post processor error. We are wondering if you could help us out and see if anything in the post may be responsible for this, or if you could explain any other reason fusion simulation would result in a different tool path then the CNC. I have attached the corresponding gcode, aslo here is a link to the part in A360

https://myhub.autodesk360.com/ue293154c/g/projects/2016072638377606/data//DTce943QT6073bba2061bf9c59...

[bob.schultz]

I can see in the NC code where the tool does not retract after cutting the first hole, but unfortunately do not have access to the model when following your link (probably lack of privilege to access your account).  Could you export the model as an .f3d file and attach it here so I can have a look at it?

Thanks.

[Anonymous]

Hey Bob, 

I would give you the f3d file, but the problem is that the file contains components and it will not let me export it as such.  I was wondering, is there anyway I can give you access? I am attaching screen shots of the tool paths and each individual menu.

[Anonymous]

And these

[Anonymous]

Hey Bob,

Forgot to ask, but I was poking around the forum and saw someone had a similar problem and all they had to do was click stock contours to be the same as what they were trying to pocket. Worked similar to a machining boundary could this help? Just clicking the circular profile for both the pocket and stock contours that is.

[bob.schultz]

So what we have run into here is a problem when converting the Alphacam post to Fusion, probably due to the differences in the output from Alphacam  and Fusion.  There was logic in the Alphacam post that would not output the first rapid Z-move depending on settings within the post.  I have now removed this condition and always output rapid moves.  This should fix your problem (I would verify it by analyzing the NC code on your side since I am using a different model).