You need to check if your encoder outputs quadrature.If it's true, it will be easier and cheeper to buy a Granit device driver for that.
Sent from my SM-A705FN using Tapatalk
You need to check if your encoder outputs quadrature.If it's true, it will be easier and cheeper to buy a Granit device driver for that.
Sent from my SM-A705FN using Tapatalk
Thought about this also but the current gear is much to hard to machine a straight bore, would need to be ground. It is also looks like the teeth have been lapped, judging by the high finish. Getting a gear with the same quality would be expensive. Will check to see if a gear is available.
Thanks,
Troy
I was reading something similar from another retrofit control package that make there own drives for Fanuc servos. They showed how to replace the encoder and use there software to adjust the commutation.
Do you know if there is a certain way to disassemble a AC servo? Read something years ago about some servos and steppers will lose magnetic strength when removing the stator from winding.
Thanks,
Troy
- - - Updated - - -
Will get number of encoder and see what i can find.
Thanks,
Troy
How is yours configured? I guess its servo directly driving the worm gear is it? Probably would be hard to find one of those. Mine has a spur reduction before worm gear, so a little easier to deal with. I just sleeved my gear initially but the straight spur gears were a little noisy at high speed so I bought a set of helical spur gears from KHK. They had the exact sizes I needed. Great company to deal with. Japanese quality and they have a warehouse in the US. Might want to check with them.
A new drive and encoder swap sounds like a good option too if you can get it to work. I've heard about loosing magnetization as well. I dont know details but I would certainly find out for sure before pulling anything apart.
From what i know you can loose magnetization from overheating the motor. Inside are neodymium magnets.
Sent from my SM-A705FN using Tapatalk
So i found a older post that goes over the same encoder i have, sounds like he may have replaced the encoder? The thread has not been updated on what he did.Think i might contact Granite Devices and see what info they have.
https://en.industryarena.com/forum/p...01--89786.html
As far as disassembling a servo motor and losing magnetic strength in the rotor, I have heard the same thing, but I don't believe it. My suspicion is that someone really screwed up the job, probably the commutation, and blamed it on demagnetizing the rotor. It a neodymium permanent magnet assembly, about the only way you can demagnetize that is with heat, a very powerful AC field, or beat the hell out of it with a hammer.
Disassembly and reassembly can be a bit tricky, you have to control the rotor on the way out and back in, you don't want it banging on the stator or other parts. And it's going to want to grab onto any iron. I would think that a wood or aluminum plug with a bearing size pocket in the end and that was a slip fit in the stator would be a good idea, this would allow you to control the rotor as it's pulled out. It is not going to want to come out because of the magnet, so it needs to be pulled out with a screw type puller assembly, and reinstalled the same way. To really do it right, you are going to have to build a fixture to disassemble and reassemble, preferably out of non-magnetic materials.
I would be tempted to reengineer the drive system on the 4th axis and install the DMM servo. Maybe using parts of the Fanuc motor so that gear relationship is not disturbed. I have done things like that before, but then again I'm half crazy
Jim Dawson
Sandy, Oregon, USA
That was one of my first thoughs as well. I was picturing the fanuc shaft cut in half running inside custom made double bearing block made with the same flange dimensions as the existing motor. Have part of the old fanuc shaft sticking out of the back of this bearing block and apply power to that. If all else fails. lol
I dont think thats to crazy...so does that make me crazy?
Contacted Granite Devices and they said that the Argon is match for this servo and as long as the encoder is incremental that there Argon drive will work well.
Still looking for more info on encoder.
Thanks,
Troy
Hello all, hope all are doing well,
Been working on my control panel and thinking of getting another konnect board because iam out of inputs. But wondering about kmotioncnc controls.
Can the following Kmotioncnc buttons be duplicated with physical momentary buttins?
Axis jog buttons.
Feed forward button .
Feed reverse button.
A button for each of the 3custom screens.
Block Delete check box.
Single step.
Restart gcode.
Shutdown or equvilant of keyboard ctrl F4.
Troy
Hi Troy,
Most should be possible externally.
Regarding:
Axis jog buttons - Possible with Jog() commands from KFLOP
Feed forward button - possible withFeed reverse button - possible withCode:SetFROTemp(0.2);A button for each of the 3custom screens - possible by "clicking" the appropriate screen button. Use Screen Editor to determine the name of the Button. For one example they would be: IDC_But10, IDC_But11, IDC_But12 so:Code:SetFROTemp(-0.2);
Alternately KFLOP could load the appropriate screen script file.Code:ScreenScript("WinMsg:DlgName;IDC_But10;BM_CLICK");
Block Delete check box.-
Single step - possible withCode:ScreenScript("WinMsg:DlgName;IDC_BlockDelete;BM_CLICK;"); // toggle ScreenScript("WinMsg:DlgName;IDC_BlockDelete;BM_SETCHECK;BST_CHECKED"); // Check it ScreenScript("WinMsg:DlgName;IDC_BlockDelete;BM_SETCHECK;BST_UNCHECKED"); // Uncheck itRestart gcode - possible withCode:ScreenScript("WinMsg:DlgName;IDC_SingleStep;BM_CLICK;");Shutdown or equvilant of keyboard ctrl F4 - not currently possible without a patch. I think it is actually ALT-F4. KFLOP can push down ALT then press F4 but then KMotionCNC Exits with no way for KFLOP to release the ALT key.Code:DoPC(PC_COMM_RESTART);
TK
http://dynomotion.com
Hi Tom,
Great to see it can be done. Will order another Konnect.
Your correct its ALT F4 not CtrlF4, my bad. Anyhow, its not a deal breaker if it cant be done.
Currently working on the code for the Override potentiometers. They are working but when i execute a feed hold during an axis move, the axis slowly decelerates to a stop. Example: At 80IPM feed of X axis, it will take a few inches before it comes to a complete stop. I copied the potentiometer override code from my lathe, which works fine on it.
Any idea what might be causing this?
Thanks,
Troy
Hi Troy,
Using your configuration I get a feedhold deceleration time of 0.034 seconds which results in a stopping distance of 0.73 inches from 80ips.
But I had to defeat a lot of your code as I don't have the hardware.
After doing a feedhold please run this program to print the deceleration time used to see if it is the same as mine
.Code:#include "KMotionDef.h" void main() { printf("Decel time = %f\n",CS0_DecelTime); }
Otherwise you might debug it by commenting out sections of your code to see what is causing the issue.
You might also post your trajectory planner settings.
TK
http://dynomotion.com
Hi Tom,
Using the Main init code V3.4, which has the code for Feed,Rapid and spindle override potentiometers i get a Decel time = 0.175179 on my X axis at a feed rate of 80IPM and takes about 1.5" for axis to come to a complete stop. If i run my Main init code V3.3, which does not have code for potentiometers i get the same Decel time = 0.175179 at 80IPM on X axis and takes about an .125" for axis to completely stop.
I dont know how i can comment out any of the Potentiometer Override code without breaking the code.Otherwise you might debug it by commenting out sections of your code to see what is causing the issue.
Attached is my main init code v3.3 and a screen shot of TrajectoryPlanner page.
Troy
Hi Troy,
Thanks for narrowing down the cause. I think I see the issue.
Is being called continuously. Which keeps recomputing CS0_TimeBaseDelta during the stop causing a sort of slowdown of the slowdown.Code:SetRapidFRO(RAPIDO);
Even though this function is local to KFLOP it shouldn't be called continuously rather only when needed when something changed. So please try adding similar code as with FRO and SSO so that it is only called when something changes and not too often. So change the above line to:
Also add in the needed variables with the FRO and SSO variables:Code:// Change Rapid Override if Pot changed significantly // and it has been a while since the last change if ((RAPIDO > LastRAPIDO + CHANGE_TOL || RAPIDO < LastRAPIDO - CHANGE_TOL) && T > LastRAPIDOTime + CHANGE_TIME) { SetRapidFRO(RAPIDO); LastRAPIDO = RAPIDO; LastRAPIDOTime = T; }
Please let us know if it solves the issue.Code:double LastRAPIDO = -1; double LastRAPIDOTime = 0;
TK
http://dynomotion.com
Hi Tom,
With your code change the feed hold to stop is much better now.
There is more issues that i forgot to mention with the Override Pots.
1. When overriding a Feed move to 105% or more, the axis has a jerk motion to it similar to when drip feeding a gcode program to an old type cnc and the buffer is starving for gcode. Also the feed percent display shows the calculated override feed increasing and decreasing when this happens.
2. The Rapid override potentiometer is not working. The Rapid override percentage display in KMCNC does not change when using potentiometer. But the voltage input in Kmotion Analog Status screen shows the potentiometer working. There has been one time that the potentiometer did slow down a Rapid move, but i cant get it to repeat.
You think my code for the MPG pendant is causing these issues? Because this is all that is really any different to the main init code i use on my lathe.
Thanks for the help,
Troy
Just remembered that i changed the Trajectory Planner setting Hardware Override to 1.5 when i was doing some tests a couple days ago. And this is what is causing my starving issue when feed override is above about 105%. So disregard issue number 1.
Hi Troy,
Its somewhat tricky when having a screen control and a potentiometer both control something as they can conflict. Instead of having the potentiometer change the RRO directly we should have it tell KMotionCNC to change the RRO then have KMotionCNC change the RRO so they remain in sync like what is done with FRO and SSO. So try changing:2. The Rapid override potentiometer is not working. The Rapid override percentage display in KMCNC does not change when using potentiometer. But the voltage input in Kmotion Analog Status screen shows the potentiometer working. There has been one time that the potentiometer did slow down a Rapid move, but i cant get it to repeat.
toCode:SetRapidFRO(RAPIDO);
HTHCode:DoPCFloat(PC_COMM_SET_RRO, RAPIDO);
TK
http://dynomotion.com
:banana: It works Tom.
Now i have another issue i have had for a while that was intermittent and now is more constant, is a custom button i have that runs a C program to issue a MDI move of G53 G0 Z0 then G53 G0 X10.55 Y0. Now i must click the button about 4 to 5 times before it will execute. Is there a better way i should do this with ccode? Here is my C code .
#include "KMotionDef.h"
Thanks much again Tom,Code:int DoPC(int cmd); int DoPCInt(int cmd, int i); #define GATH_OFF 0 // define the offset into the Gather buffer where strings are passed main() { MDI("G0 G53 Z0"); // Move Z to Reference Position MDI("G0 G53 X10.550 Y0"); // Move X,Y to Reference Position } // put the MDI string (Manual Data Input - GCode) in the // gather buffer and tell the App where it is int MDI(char *s) { char *p = (char *)gather_buffer + GATH_OFF * sizeof(int); int i; do // copy to gather buffer w offset 0 { *p++ = *s++; } while (s[-1]); // issue the command an wait till it is complete // (or an error - such as busy) return DoPCInt(PC_COMM_MDI, GATH_OFF); } // Put an integer as a parameter and pass the command to the App int DoPCInt(int cmd, int i) { int result; persist.UserData[PC_COMM_PERSIST + 1] = i; return DoPC(cmd); } // Pass a command to the PC and wait for it to handshake // that it was received by either clearing the command // or changing it to a negative error code int DoPC(int cmd) { int result; persist.UserData[PC_COMM_PERSIST] = cmd; do { WaitNextTimeSlice(); } while (result = persist.UserData[PC_COMM_PERSIST] > 0); return result; }
Troy