Sounds like you are getting close. I think the main difference from a spindle drive and a normal servo drive is that the Spindle Drives often have slow response. So open loop FF becomes more important. The FF can handle the bulk of the control so that the feedback only has to make small corrections.
Great news. I configured the spindle for closed loop and tuned the PID to a reasonable setting. I even went so far as to run a test cut on Delrin . Looks fantastic! Might need to do a bit more tuning but I cannot complain about the accuracy. My numbers were really odd so I think my counts per rotation must be something other than I was told. The results are consistent so I believe I just need to throw a scope on it and have a look. I was also able to setup and use a switch. I'll be working on the potentiometers soon. Next question though; How do I control the threads? I know I have 1-7 to work with but I don't see an explanation on which threads actually run. I looked at the treads that are there in KMotion and I saw that I had accidentally duplicated my axis thread, which is on thread #1, on thread #3. I don't need two of the same threads running but I don't see a way to clear it or a way to tell it to run or not to run. Additionally there is a Probe thread I don't need and while none of this hurts anything, I should probably just delete anything I don't need. As always in an attempt to answer my own questions, I did a search but after reading a bunch of on line discussions, I didn't find anything I could use for my particular question. Just waiting for some replacement switches but a very exciting time indeed! I hadn't mentioned but this is a device at a boy's high school for their robotics program. They always show me respect but I could tell they were wondering just what I thought I was doing as I have spent so many hours behind this machine with wires everywhere. They finally saw it move as I was trying another test cut. Feels good to be back in the driver's seat. They are anxious to do some CADing and giving it a try. Exactly what I was hoping!
I've made great progress and even cut a few test pieces. Resolution is great and good enough to reliably mill a bearing press fit hole. Very impressive. However, I have a problem. I wired the e-stop button and the pots. The programs work in KMotion and I can run them manually. How do I get KMotionCNC to run these threads automatically? I selected them in Config and Flash under the Launch On Power Up menu in KMotion, but they just don't run in KMotionCNC unless I first manually run them in KMotion. I'm sure this is a simple fix but nothing I've tried works. What am I missing?
EDIT: Hang on... you have to disconnect the USB... I haven't been doing that. I'll give that a try. That may be the issue.
Ok Frustrating time, No luck today. I selected threads 1,2,3,4 to run on power up and flashed them to memory. I disconnected the main drive to the mill so it wouldn't run wild, disconnected the USB and then disconnected power to the KFlop/Kanalog. When I power it all up and look at KMotion, I see threads 2,3,4 running. I assume thread 1 ran and configured everything. When I try the same thing with KMotionCNC. It doesn't seem to run all the threads. I don't see a consistent pattern but I didn't have a whole lot of time today to do a lot of tests. One other thing I have happening is when I stop and re init the unit in KMotionCNC, the spindle doesn't run. If I halt the program, restart the GCode and init, the spindle will work every time. So something is happening and I suppose the system thinks the spindle is enabled but the jog command doesn't do anything.
SO I seem to be able to tell KMotion to run threads, but that information is not being passed on to KMotionCNC. And KMotionCNC doesn't re-enable the spindle.
Last edited by steve_alaniz; 09-18-2016 at 02:44 PM.
Reason: Additional info
It isn't clear why that doesn't work, except it isn't clear if you compiled and downloaded the programs into KFLOP before Flashing KFLOP. You seem to have a misunderstanding that the programs exist in KMotion or KMotionCNC rather than in KFLOP.
But taking a step back it would be better to combine all the functionality of all your programs into the Init Program so you don't need any other Threads. This is the preferred method so nothing ever needs to be Flashed into KFLOP. The idea is to add one loop at the end of the main() function in your init program that services all your devices. See:
I actually never considered where the program goes. I only assumed that it should be used by both KMotion and KMotionCNC. I couldn't understand why it seemed to work sometimes but not always. I Finally see what is happening but I don't know why. The Kflop rightly runs all the threads on powerup. I can see that in KMotion and it seems to behave well there. Even when I launch KMotionCNC the programs are running. I was verifying a switch and my ESTOP button on the unit. They both worked until I ran a tap file in KMotionCNC. It halts the program I had that programed the action for those switches. Since I need it to control my ESTOP button, I guess I have to try to figure out why its doing that. I don't think writing those into my INIT file will help but I could be wrong. I thought I read that thread 7 continues to run so is that where I need to place those definitions?
If you have a program running in a KFLOP Thread space and you then run a different program in that KFLOP Thread space then the first program will be killed and overwritten by the new program.
I suspect you have some M Codes in KMotionCNC configured to run in some Threads that you are expecting to be left alone. Make sure that whatever M Codes are configured use Thread spaces that are available.
Again the recommended method is to just put everything in your Init Program and only use one Thread (besides anything that executes temporarily like Spindle Control, Tool Change, Probe, etc...)
I did as you suggested and converted the FRO ans SSO programs into functions and added them to the init file. Now that I look at the way the unit works I see that I was always going to have to do this. I think I was under the impression that the threads continued to work as long as the unit was powered but I can now see that It needs to be restated anytime I initialize the system. It's all just part of learning how this all works. So I have a handle on making this work the way I hoped.
My next question is about limiting the effect of the SSO. It makes the spindle increase or decrease speed just like I want except when I overdrive the spindle with the pot and send it a command to run faster than it can, then it accumulates errors and I lose control of it until it "catches up" and then it might actually go into oscillation, so I want to avoid ever commanding it to go faster than it can. I need to set a limit that the pot cannot exceed. I'm thinking I need to do that in JogCW and set a maximum value for Speed after this statement.
float speed = *(float *)&persist.UserData[SPEEDVAR]; // value stored is actually a float
You should probably approach this in two parts. #1 set a reasonable Following Error Limit such that if the speed is ever commanded too fast it will immediately disable. #2 prevent it for being commanded too fast.
At that point in the code the speed is in RPM. So you might limit it with something like:
if (speed > 5000.0f) speed = 5000.0f; // Limit the speed to 5000RPM
OK I've been feeling pretty good about MOST of what I'm doing. Have not yet found a way to control the maximum speed when using the Speed Pot. It seems to override everything I'm not finding where the SSO is read and combined with the speed from the g-code S command. I would like to solve that but it is not the biggest item yet. I am continuing to re-wire this beast and still making good progress. I AM at the point of cutting test pieces out of aluminum and getting excellent results. I will be doing press fitting of bearings so the accuracy is pretty important and so far it's looking good.
However, I was attempting a much more complicated piece and the mill ran for awhile and then inexplicably quit. It seemed to work after a restart but then did it again. I opened up KMotion and opened up the console. It happened again and I got the message Pos Soft Limit Exceeded. I looked at the Axis and saw that it had reach it's "Maximum Distance". So it has counted it's rotations and acting like it is a linear axis that has traveled to the limit of it's travel. OK THAT'S not right. I'm using the JOG programs and I thought that prevented this from being a problem. I'm sure this is a really simple problem, but again, I am stumped. Can I be saved?
OOOOooooh! The system is ignoring the G-Code "S" command and ONLY reading the SSO Value! Ok I have something really weird going on. Not sure how I got to this place but it probably isn't a good idea. I THOUGHT SSO was combined with the S value and adjusted it. This kind of explain why the spindle doesn't always spin up. If I move th speed pot after the "S" code is executed, then I get movement. It's ok if I am running the machine but I need to get this thing going for everyone. New question, can I configure the spindle for an open loop but still have threading ability?
The SSO (Spindle Speed Override) adjusts the speed relative to the current setting. So for example if the Speed is commanded with an S3000 to 3000RPM and then the SSO is set to 1.1 then the Actual Speed should be 3300. You will also need to turn the Spindle on with an M3 command.