SV stall error

[Samandkimberly]

All-in-one retrofit of a Milltronics/Fryer bed mill...just initially commissioning. Went through bench test, encoders work the way they’re supposed to, checked motor grounds, hooked up estops, etc per schematic....powered up, everything fine...motors are sitting in their final location, but not connected to machine. Machine still has spindletest program loaded.

I hit MDI and both x and z motors spin for a split second then the Main relay kicks in and I get:

SV STALL ERROR Reported by CNC11!!!

I don’t know why the motors are trying to spin at this point. If I disable the x and Z motors I get no errors, but I stopped short of trying to run the Y motor until I sort this out. I did wire my own motor/encoder cables, but i used all the Centroid parts/cables, and i have the right crimp tools, and I’m not bad at this sort of stuff.

Any thoughts or pointers? I’m happy to post lots of pics/details, but I thought I’d see if anyone had obvious suggestions before I did. Thanks!

[Samandkimberly]

Oh yeah - is there a list of All-in-One errors somewhere? I’d love to learn more about this, and other errors first, before I bug everyone. I did try searching for this in the manuals I have, but no joy.

Sam

[tblough]

Stall errors at setup are usually caused by the encoder counting in the opposite direction of the motor. If these servos and encoders were purchased from Centroid, this should not be the case, but if you assembled them yourself, then this might be the issue.

Go to F1 Setup/F3 Config/137/F4 PID and verify that the encoders count up when the motors are manually turned in the counter clockwise direction when facing the shaft. If not, you need to swap the a+/a- encoder wires with the b+/b- wires.

If this is correct, verify that you have the + and - incoming motor power and the motor power leads wired correctly on the ALLIN1DC. Note that the motors are wired with the positive lead on the top, but incoming power has positive on the bottom.

[Samandkimberly]

Encoder counts are in the right direction. Polarity on the motors and power supply is verified on a meter as correct. Here is some other random data:

I’ve seen relatively large min/max errors 300-2000 when I first spin the motors to verify direction. The min and max numbers are always the same as each other, and they never change after that initial motion. If following is not disabled this throws an error. While the most likely culprit would be my wiring, I find it odd that this only happens with a seemingly random number on the very first move.

I keep getting an MPG1 encoder error. There is no MPG1 encoder on my system.

I can’t for the life of me understand why the CNC12 controller is applying power to the motors when I hit the MDI button. That seems plain wrong.

Below is a pic of my wiring....not the most sano job I’ve done buy the connections are to the print, and well made. I’m also attaching the most recent report from tonight.

Next step for me is to check wiring on the two funky axes, but I’m not optimistic that I’ll find a problem.

Thanks, Sam

report_0402181935_2019-01-06_21-19-10.zip

(113.7 KiB) Downloaded 137 times

[Centroid_Tech]

When you press F3(MDI), the control is energizing all of the axes which means that it's applying power to your axis motors. If your motors take off on you as you have stated, then Tom is correct in that the encoder signals don't match the direction the motor is moving. When the motor is energized, even though it's not moving, the control is still trying to hold the motor in its place. When the encoder signals don't match the motor power signals, the control sees the signals moving one way. It tries to correct it by sending power to the motor but it never can as the encoder keeps counting in the opposite direction. It will eventually stop this with a Position Error which is the message that you are seeing directly before the SV_STALL_ERROR. The easy fix for this is to physically swap the motor power signals at the ALLIN1DC. You will find the Position Error message in the Error Code section of the operator's manual. The SV_STALL_ERROR message is more of a way for the PLC program to know that the CNC software has a fault and it allows the PLC program to stop everything.

[Samandkimberly]

Thanks for the explanation. Unfortunately, that doesnt appear to be what is happening. I tried reversing the polarity of the motors and got the exact same result. So I put them back, and carefully wached as I recreated the failure several times.

When I hit MDI, between one and three of the motors begin to rapidly rotate simultaneously, all clockwise looking at the motor shaft. They dont move far before the SV stall error cuts power, maybe 45 degrees, then they coast to a stop over a few revolutions. All three encoders show a negative move. This all seems like the power, and the encoders are working at least in the direction they’re supposed to.

I went back through the motor/encoder setup step by step and I seem to have done everything correctly. I did notice a typo on page 24, instruction 8, where it suggests setting parameter 303 to 3; the screenshot below shows parameter 302 set to 3. I followed the screenshot, which makes a lot more sense.

I’m at a loss in what to try next:

- I’m becoming more certain that this is not a wiring issue. Its very unlikely the motors would actually turn, the encoders read out properly, and all three motors have the same wiring issue. Cabling, connectors bought from Centroid, assembled by me.

- Encoders are 2,000 line ones bought from Centroid. I dont suspect those.

- x and y motors are painted over, but are documented as SEM MT30M4-38 26 inch lb DC brushed motors. Z is a Milltronics labeled SEM 40 inch lb DC brushed motor. Perhaps a motor/control compatibility error?

- system voltage is high, 176V, but the 140V motors were working with this before I started this project. Is it possible that the high voltage is accelerating the motors to quickly, overrunning the encoders and causing the failure? A new transformer is on the way to fix this, but I’d rather not put commissioning on hold until it gets here.

Suggestions?


Sam

[tblough]

P300=1
P301=2
P302=3

P308=1
P309=2
P310=3

X motor to Axis1, x encoder to enc1
Y motor to Axis2, y encoder to enc2
Z motor to Axis3, z encoder to enc3

[Samandkimberly]

Tblough - I’m certain that i have the P300...P310 parameters set as you show them.
Is there another location outside the parameters where I need to link the x motor to axis 1/x encoder to enc1, etc, as you show above?

Sam

[tblough]

If they are linked correctly, then the only other possibility is that the encoders are reading opposite the motor direction. Reverse + and - on each motor that runs away and try again.

If that fixes the run away problem, then you need to verify that each axis moves in the correct direction. If the axis moves in the correct direction, then you are done. If it moves opposite the way is should, then you need to switch + and - back and then reverse the A, B and /A, /B wires on the encoder for that axis.

[martyscncgarage]

Tblough - I’m certain that i have the P300...P310 parameters set as you show them.
Is there another location outside the parameters where I need to link the x motor to axis 1/x encoder to enc1, etc, as you show above?

Sam

Sam,
Use the Utility function to generate a report and post it here.

Marty