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!

[Anonymous]

Alright Bob,

I got another thing for you to look at if you don't mind.  When we were running a program we got the error message. Y axis out of limits. However, when we were cutting the part the Y axis was well within the limits. When we looked at the G code the Y axis was within limits as well. The only thing I could think of is that this operation was mirrored, and the error occurred when the operation would have been entering the mirrored portion. The error specifically mentioned line N5202, which can be seen below. I will also attach the whole file just in case you need more to reference.

N5199 (2D POCKET22)
N5200 M110
N5201 M3 M64 S12000
N5202 G0 X-13.2628 Y-12.721
N5203 M111
N5204 M23
N5206 Z1.5
N5207 Z0.2
N5208 G01 Z0.1375 F200.
N5209 X-13.2637 Y-12.7202 Z0.128
N5210 X-13.2663 Y-12.7178 Z0.1191
N5211 X-13.2704 Y-12.7138 Z0.1114
N5212 X-13.2756 Y-12.7084 Z0.1054
N5213 X-13.2814 Y-12.7018 Z0.1016
N5214 X-13.2872 Y-12.6944 Z0.1
N5215 X-13.2933 Y-12.6858 Z0.0996
N5216 X-13.2988 Y-12.6769 Z0.0993
N5217 X-13.3038 Y-12.6676 Z0.0989

[Anonymous]

Hey Bob,

Think I misspoke, looking at the G Code again it looks like when the mirroring command is set to go both x and y become negative ( Thought the - were just dashes, but in the code before they don't appear) . As if it was mirroring about the x axis (Z-X Plane) when we have the command mirroring about the y axis (Y-Z Plane). Think this might have something to do with the post? Could be Alpha Cam and Fusion have opposite ways of mirroring. When we run the simulation it it shows the tool path being mirrored around that y axis. 

[bob.schultz]

Without having the model you are working with I can only guess what is happening.  It is my thought that instead of mirroring the operation you are actually rotating the operation 180 degrees.  For example, if you check the 'Flip X-axis' box in the Work Coordinate System tab, you will notice that it does not actually flip the X-axis, but rather rotates it.  You will notice the Y-axis of the WCS is also "flipped"  The WCS does not support a mirrored coordinate system.

How do you go about mirroring the operation? 

[Anonymous]

How we mirrored was using the pattern mirror command. If we just hit the flip 180 about x axis wouldn't that show up in the simulation as the tool path being generated flipped on the other side of the x axis? In our case it shows the tool path being generated flipped about the Y, but the G code looks like it was if it flipped about the X. Let me check the WCS, that could be part of it. I will try to get you a copy of the part.

[Anonymous]

Hey Bob,

Here is a test part that should highlight the situation. I have attached the corresponding G code. 

[bob.schultz]

Thanks for sending the test case.  Here is an updated post with this problem fixed.  The post did not support WorkPlanes, which are output when using the Mirror Pattern operation.  I've added this support now.

[Anonymous]

Hey Bob,

Just found something weird and was wondering if you could tell me if this is a post processor issue or if this is fusion. We recently posted a large setup with and extensive amount of operations. When we posted it we were looking at the g code and it looked like it went up to N32768, then started recounting from N1. The code after the N32768 was code for events after N32768, but it seemed like the counting system could not go any higher so it had to start recycling numbers. When we went to run it, the machine read it until the counting restarted and then it stopped and errored out. Is this a fusion setting to restart numbering or is this something in our post? Thanks for all the help!

[bob.schultz]

One of the first problems we ran into with this post was with high sequence numbers causing the machine to error out.  I set the maximum sequence number to 32768, but it probably should be 32767 (my mistake).  Look at line 111 in the post and make the following change.

   var maxSequenceNumber = 32767;

See if this runs on the machine.  You can also change it to a high number (99999), but from previous results I don't think this will work.

[Anonymous]

Hey Bob,

Yeah I do recall that we had that issue when we had it generating by increments of 5. I was wondering was the limit of 32768 set by the post? or is this something with the machine itself?

[bob.schultz]

The post can output much larger number by changing the maxSequenceNumber variable as I explained.  The value 32767 is the maximum value that can be output when using 16-bit integers, which may be what your controller is using.  A simple test case for you to try is to create a short program with a starting sequence number of 1000 (sequenceNumberStart:1) and an increment of 1000 (sequenceNumberIncrement:1000) and see if the controller errors out with maxSequenceNumber set to 999999 or if it errors out with it set to 32767.

[Anonymous]

Hey Bob,

It just came up that when we run programs out of fusion as opposed to alphacam the G Code generated for fusion is much longer, usually 3 to 4 times as long. I started to look into why this is and I found that Alphacam is using a G02 and G03 paired with radial functions where as fusion does not. looked up in the num controller programming book volume 1 and found that G02 and G03 code allow for circular interpolation in the clockwise and counter clockwise fashion. the fusion g code does not call in these commands ever and I am wondering if that is a fusion issue or a post processor issue. It would be nice if fusion could use these command as the longer g code and breaking down of radius into x y coordinates is causing data starving on the machine and longer run times for programs. Would you mind taking a look at the post and seeing if you can find anything that might be the reason? I am attaching a copy of the g code generated by fusion and by aplhacam for the same operation for reference so you can see the use of the radial commands.

[bob.schultz]

I've looked at the post and it does support circular interpolation up to 180 degrees, which is the limit when outputting the radius (R) of the circle.  Since I don't have your part I am guessing that you are driving circles that have greater than 180 degree arcs.  I have added support to automatically switch to outputting the center point of the circle (IJK) when the arcs are greater that 180 degrees.  I have also added support for helical interpolation.

Run this post and check the output of the circular interpolation moves carefully and see if they are correct for your machine.

[Anonymous]

Hey Bob,

None of the moves where actually over 180, tried the post anyways, but did not see any improvement. Still only using x-y coordinates for arcs. Is there any fusion settings that could be limiting this? I have allow circular planes ( under the built in property) set to 1. Is this an effecting parameter?

[bob.schultz]

You can run your part against the 'dump.cps' post and then analyze the output '.dmp' file.  If you see onCircular records in this file, then Fusion is outputting circular records.  In this case the problem is in the post.  If you don't see onCircular records, then the problem is in Fusion.  It would be best if you could send me the model, but if it is not possible then if you do see onCircular records in the .dmp file then provide this file and I can look to see if there is an obvious reason for circular interpolation not being output.

[Anonymous]

Hey Bob,

Used the Dump post like you were talking about. I found the line that says

411: onCircular(false, 1.5059842087152435, -0.35000001351664384, -0.04999999924907534, 1.5059842087152435, -0.35000001351664384, -0.09999999849815068, 30)
sweep: 89.999952deg
radius: 0.05

Based off of the false I am assuming that circular motions are not turned on. How do I go abut turning them on?

[Anonymous]

Here is the file I was testing with

[bob.schultz]

Thanks for supplying the part.  I ran it against the post I last sent to you and I do get circular interpolation output.  You can reference the attached output file and see that there are G03...R0.05 moves for the lead-in arc and G02 ... I.J. moves for moving around the part.  These circular motions are over 180 degrees, which is why you will see the IJ output instead of the Radius output.

Make sure you are running the last post I sent to you (I am attaching it again here for your convenience).  The one place you don't get circular interpolation is on the YZ portion of the entry move. If your machine supports circular interpolation in the YZ and ZX planes, then you can make the following change in the post to enable this support.

   allowedCircularPlanes = undefined; // Allow circular in all plans

[Anonymous]

Hey Bob,

Did notice that it is using circular planes commands. Do not need them in the z axis, so it is good that it is not utilizing them. The thing that is interesting is that when I run that same operation type in alphacam the number of radial commands is vastly larger than that of fusion. Starting the think it may be because of the vector based nature of alphacam being in contrast with the model based programming in fusion. Maybe fusion cant break as many things down into radius as alphacam does? Just a thought, but would that make sense? or should I being seeing the same number of radial outputs?

Thanks Again,

Cameron

[bob.schultz]

Hello Cameron,

Maybe we are looking at different output.  I see circular arcs where ever they can be output.

(Vertical Lead-in)
N34 Y-0.3997 Z-0.0556
N35 Y-0.3987 Z-0.0611
N36 Y-0.3972 Z-0.0665
N37 Y-0.395 Z-0.0717
N38 Y-0.3923 Z-0.0766
N39 Y-0.3891 Z-0.0812
N40 Y-0.3854 Z-0.0854
N41 Y-0.3812 Z-0.0891
N42 Y-0.3766 Z-0.0923
N43 Y-0.3717 Z-0.095
N44 Y-0.3665 Z-0.0972
N45 Y-0.3611 Z-0.0987
N46 Y-0.3556 Z-0.0997
N47 Y-0.35 Z-0.1
N48 Y-0.3 F150.
(Horizontal Lead-in)
N49 G17 G03 X1.456 Y-0.25 R0.05
(Contour motion)
N50 G02 Y3.162 I1.456 J1.456
N51 Y-0.25 I1.456 J1.456
(Horizontal Lead-out)
N52 G03 X1.406 Y-0.3 R0.05
(Vertical Lead-out)
N53 G01 Y-0.35
N54 Y-0.3556 Z-0.0997
N55 Y-0.3611 Z-0.0987
N56 Y-0.3665 Z-0.0972
N57 Y-0.3717 Z-0.095
N58 Y-0.3766 Z-0.0923
N59 Y-0.3812 Z-0.0891
N60 Y-0.3854 Z-0.0854
N61 Y-0.3891 Z-0.0812
N62 Y-0.3923 Z-0.0766
N63 Y-0.395 Z-0.0717
N64 Y-0.3972 Z-0.0665
N65 Y-0.3987 Z-0.0611
N66 Y-0.3997 Z-0.0556
N67 Y-0.4 Z-0.05

This motion is duplicated for every pass down the cylinder.  The only place where a circular arc can be combined is in the Contour motion, which is breaking up the circular move on 180 degree arcs.  If you are expecting arcs up to 360 degrees you can change the following variable in the post.

maximumCircularSweep = toRad(360);

Which will give you a single arc in the Contour motion.  Since you say that your machine does not support YZ circular interpolation, then the Vertical lead-in/lead-out moves cannot be converted to arcs.

[Anonymous]

Hey Bob,

So I guess what I am asking, and what I am thinking alphacam is doing, is that when there is a part like the one I shared previously (Simple cylinder). It could tell the machine G2 R=Radius of the cylinder and that would direct the tool for the entire operations. Whereas in fusion it seems to be breaking the cylinder down into xy line segments. Seems like Alphacam sees a arc, say of radius 3in, and just outputs to the machine G2 R=3in and the tool follows that path. In fusion it seems like  even if the arc is less the 90 or 180 it still breaks up a simple 3in radius into x y line segments.