4th axis acting up?

[jake2465]

I just ran my first post from Fusion 360 to the centroid M400. This was a live 4th axis test part that was supposed to machine three pockets all 120deg apart from each other. The behavior of the mill was not quite what I was hoping for as the mill table was stuttering whenever a somewhat tight radius would need to be performed. The other part that was even more bizzare was that the pockets did not turn out right either. Every one was different and I used a pattern feature in Fusion to make those pockets, so they should all be the exact same. Whats just as odd is that I ran the part again and the result was different than the first time around ... I am stumped. I don't know how that is even possible because its literally the exact same program.

I put a video on my little channel with the 4th axis running: https://www.youtube.com/watch?v=JjAJQX7XNU8

Notice how the lower wall is not straight, but looks like it was straight about a third of the way into the adaptive clearing tool path? I have no answer for this.

[Sportbikeryder]

Have you attempted to do 3+1 positional machining with the post before trying a full 4th axis move?

I would suggest programming a "simple" hex bar, and attempt machining it from piece of round stock. Machine the part from the top with the end of an endmill AND machine each face from both the rear of the part and the front of the part using side milling. This will help to be sure the zero and the post is accurate. The same can be done with an offset cube to be sure the machine is following the part correctly. Origin of the cube will have to be at the center of the 4th axis rotation in the model.


After that, you may need to change your post, possibly changing to or from inverse time feedrates. The feeds shown in your screen video look to be F9999

That seems extremely high regardless of what the scaling is, and further may be a truncated feedrate that "wanted" to be higher than 10,000 but was limited to a 4 place value.

John

[jake2465]

I have not yet attempted to do 3+1 machining, but I have put in random "a" values into MDI to see if the 4th axis would index correctly and everything seemed to do alright. The only problem I do run into is that if I want the axis to rapid from, say, 0 to 300+ deg or something like that, then what usually happens is that the initial acceleration looks good, but the decel is almost instant and a good thud can be heard on the axis followed by a position error message that forces me to reset with the E-stop. Intestingly that only happens if I ask the 4th axis to swing several degrees like that. If I ask it to only move something like 45 degrees, then the decel is acceptable and all is well. I am not sure if that behavior has anything to do with what I am seeing on the machining side of things.

Anyway, I would imagine that indexed 4th axis is good. the axis has a degree indicator on its castings and every time I put in an "a" value into MDI, I get the desired result (unless I am asking it to swing a lot as stated above).

I made another program that also requires live 4th axis movements to make three pockets around a bar of metal, all indexed 120deg from each other. In fusion CAM, I opened the tolerance up to .010 and set the smoothing to .005. I did this so the amount of code needed to be processed per minute would go down. I don't know at what rate the M400 control can digest code, but I imagine this should not be a problem for it.

The .nc file I will use is listed in the attachments along with a picture from "ncviewer.com" that shows what the tool paths should look like.

[cncsnw]

The only problem I do run into is that if I want the axis to rapid from, say, 0 to 300+ deg or something like that, then what usually happens is that the initial acceleration looks good, but the decel is almost instant and a good thud can be heard on the axis followed by a position error message that forces me to reset with the E-stop.

That probably means you have the Max Rate set to something higher than the motor can sustain. When it stops with a thud and a position error stall message, has it stopped short of the position you told it to go to?

Try reducing the Max Rate to 5500 or 5000 degrees/min.

Regarding the shuddering during interpolated 4th-axis moves: try some of the smoothing options (F1/Setup -> F8/Smoothing). Alternately, if you are not using smoothing (if you select "exact stop"), then you should increase the DeadStart and DeltaVMax values for the 4th axis, maybe to something in the 40 to 80 degrees/min range for each. Those are on the Machine Configuration -> Jog Parameters table.

[jake2465]

That probably means you have the Max Rate set to something higher than the motor can sustain. When it stops with a thud and a position error stall message, has it stopped short of the position you told it to go to?

Yes, when it does that, the 4th axis is usually off by a degree or so on the short side. All my servos are those Estun servos and I think their max rate is supposed to be 3,000 rpm and under. My 4th axis is a 90:1, so at 3000rpm at the servo, the table moves at 33.3 rpm which is about 12,000 degrees per minute. it should be well within the range of the servo. Perhaps what is going on is that the load that the servo is seeing is causing it to fall behind the rate at which it is supposed to move? Whenever I have it rapid, I always see that load meter go in the red once it gets to full speed. The 4th axis is using the 400W servo motor. So, perhaps that servo is a little under powered for that 4th axis?

The table and Z use the 750W motors. At first, they were all set to perform a 300ipm rapid, but they would all hit position error within half a second or so. So, they were adjusted down to 150ipm rapids and that game stopped... the X Y and Z servos all have the same turn rate per inch of table movement. That would be 10rev/inch. At 3,000rpm, the needed rpm from the servos would be right at their max operating rotational speed. So, for them to hit position error would make sense.

I imagine the control is currently set with no smoothing. I will go in there and make some adjustments.

[Sportbikeryder]

As for the test part, i was referring more to the setup in CAM and the post processor being accurate rather than your control outputting the correct rotation when manually commanded. Making a test part can identify problems with fixture tram, zero position, and general location issues.

As for your problem, it seems the acceleration of the drive is not set in your control. If I am not mistaken, there should be settings for the motors to prevent the hard stopping rather than just changing the max rate.

With a 90:1 reduction the backlash in the system combined with the inertia of the system may be causing the "thud" from an instant stop. If you can make the stop progressive rather than instant it should calm it down.

I would still be suspect of a syncronous machinine toolpath that is outputting a feed of 9999 on a 4 digit max display as it is likely not providing a synchronous move unless 9999 is a coincidence.

[Sportbikeryder]

In the video, it looks like the belt on your 4th axis servo is fairly loose as well. Maybe not, but it seems to be moving around quite a bit during reversals.

[jake2465]

In the video, it looks like the belt on your 4th axis servo is fairly loose as well. Maybe not, but it seems to be moving around quite a bit during reversals.

That's what happens when I get in a hurry and use a three jaw chuck to hold the pulley so I can bore a hole to make it fit the motor shaft... If I tightened it up correctly, there would be a couple tight spots every few motor turns . At some point I will buy a couple more of those pulleys and bore them out the right way.

[jake2465]

I would still be suspect of a syncronous machinine toolpath that is outputting a feed of 9999 on a 4 digit max display as it is likely not providing a synchronous move unless 9999 is a coincidence.

I saw that as well. Even with my updated g-code, it comes up six times. Probably twice for each pocket being milled. looks like it is a feed for an "a" movement that is .013 deg different from the subsequent line. So, the 1/F time can only go down to .0001 minute on that post processor. It appears to be a linking move. I imagine it would only be a couple thou of movement. But, yes I agree that it is unlikely that it was truly supposed to be 9999 on the money. I wonder if I can adjust the linking moves to keep that from happening.

[cncsnw]

I think you are right that the servo is undersized for the application.

Having the load meter in the red, with this system configured as it is (velocity mode, with Parameter 57==0), means that the Oak board is asking the drive for all available speed, but it is still falling behind. Since this is happening at a motor RPM that is well below the rated maximum speed of the motor, we have to assume it is a lack of torque.

Can you change to 180:1 instead of 90:1?