Spindle ramp delay implementation

Moderators: TomKerekes, dynomotion

RogerFroud
Posts: 78
Joined: Tue Mar 30, 2021 8:07 am

Re: Spindle ramp delay implementation

Post by RogerFroud » Tue Jul 13, 2021 9:45 pm

With respect, you didn't explain how to do this, you just made a one line comment without any explanation.

Are you saying that using Execute/Wait somehow causes the Delay_Sec() to be active?
Maybe it causes the calling routing to wait until the OnCWJog.c routine finishes?
Either way, what causes the motion to pause? Is that something that has to be added in OnCWJog.c?

A small hint in the right direction still leaves a lot of unanswered questions. It may be obvious to you since you've written it, but there's nothing intrinsicly obvious about the way this all works when looking at it completely cold. A little more explanation in your answers would be more helpful. I'm not lazy, but I'm also not a mind reader. Rant over.

GabrielR922
Posts: 79
Joined: Thu Aug 13, 2020 10:07 pm

Re: Spindle ramp delay implementation

Post by GabrielR922 » Tue Jul 13, 2021 10:02 pm

Hi Roger.

When you config your M3 Program in the Tool Setup Screen, select Exec/Wait and then select your program.

This will make the system wait for the program to end execution before continue the code.

Also, you can simplify your code.

main()
{

SetBit(SPINDLECW_BIT); // This will turn your spindle on
Delay_sec(SPINDLE_RAMP_DELAY); // this will allow time for it to ramp up.

}

For the speed, you need to configure the "S", below M9 in the same page as before.

You will choose DAC and then input the parameters.

Take care with a open system loop. If you have the spindle turned on with CCW and turn it on in CW, it can cause you problems.

Also you should have at least a check if the spindle is on or not.
Attachments
Capture.PNG

User avatar
TomKerekes
Posts: 2529
Joined: Mon Dec 04, 2017 1:49 am

Re: Spindle ramp delay implementation

Post by TomKerekes » Wed Jul 14, 2021 12:44 am

Hi Roger,
Are you saying that using Execute/Wait somehow causes the Delay_Sec() to be active?
no

Maybe it causes the calling routing to wait until the OnCWJog.c routine finishes?
yes

Either way, what causes the motion to pause?
Whenever an action is configured as Execute/wait the Interpreter Executes the C Program and waits for it to finish before going on to the next line of GCode.

Is that something that has to be added in OnCWJog.c?
The C Program should not terminate until it is ok for the GCode program to continue. If a time delay works for this add a time delay.
Regards,

Tom Kerekes
Dynomotion, Inc.

Tarasevih
Posts: 101
Joined: Fri Jul 09, 2021 11:26 am

Re: Spindle ramp delay implementation

Post by Tarasevih » Wed Jul 14, 2021 4:38 am

Hi. Thanks Tom and GabrielR922. This was the simplest solution.Where in general can you read about C functions for KMotion ?

GabrielR922
Posts: 79
Joined: Thu Aug 13, 2020 10:07 pm

Re: Spindle ramp delay implementation

Post by GabrielR922 » Wed Jul 14, 2021 12:16 pm

Tarasevih wrote:
Wed Jul 14, 2021 4:38 am
Hi. Thanks Tom and GabrielR922. This was the simplest solution.Where in general can you read about C functions for KMotion ?
Hi Taravesvih, for me personally, I found that kmotion is a little complicated to learn because there is too much in it, this gives us freedom to make whatever we want, giving almost infinite possibilities. But also this means you will take some time to adjust and learn a good portion of it. I suggest you start reading in your free time the wiki, below the C programs part of it.

https://www.dynomotion.com/wiki/index.p ... C_Programs

But as mentioned, for this solution that we came, you would need to also read the Tool Setup screen of KmotionCNC.
https://www.dynomotion.com/Help/KMotion ... reenM3.htm

There are a lot of information here and there, because c programs are one thing, kmotioncnc is another and the list goes.

After some time it will be easier to do a lot of things and you will be surprised with the power of kmotion.

Also, there are some videos that Tom made for us:
https://www.youtube.com/channel/UCmILL9 ... 7arfOCX3HA

RogerFroud
Posts: 78
Joined: Tue Mar 30, 2021 8:07 am

Re: Spindle ramp delay implementation

Post by RogerFroud » Wed Jul 14, 2021 1:19 pm

Thanks Tom, that now works as expected in Run, Single Step and just manually turning the spindle on and off.

I'd second Gabriel's comments about it being complicated to learn. There's no shortage of information, it's all there if you know where to find it. However, some fundamental explanation about the way the whole system hangs together would be welcome in the form of a YouTube video.

If you're implementing a system using KMotionCNC, it's not at all obvious to begin with what relationship that has with KFLOP and the KMotion software. KMotion seems to run all of the 'C' programs on its KFLOP hardware, usually Init.c, a homing program and spindle control programs. Each of those is a self contained 'C' program with main() and any functions it may used included or declared locally. Each of these programs is hooked into KMotionCNC in the inappropriately named Tool Setup (which should be Machine Setup in my opinion since Tools are what the machine uses!)

The relationship that KMotionCNC has with those programs is determined by whatever is in the dropdown box, say EXECUTE. Each of these programs appears to run in its own thread, hence the issues with this Spindle delay, where EXECUTE just launched the Spindle start program, and then carried on before the delays timed out.

These 'C' files don't need to be compiled, KMotion seems to do this when they're called. If you're a programmer, this is counter intuitive, and you're left wondering what's going on.

The Init.c program is probably the most confusing for anyone starting out. Basic functions like enabling drives has to be explicitly coded into the endless loop at the end of this. Other functions such as Anti-dithering and backlash compensation are also added here if you need them.

A default Init.c can be found in the folders, but don't expect this to contain everything you will need.

For me, the most confusing of all are the myriad of dialog boxes launched from the KMotion application. and the way some of them are 'Always On Top' which I find very annoying. Microsoft explicitly tell you not to do this, and for good reason. The tools are very powerful, and allow you to configure each axis while testing it with Step responses locally. However, what's not at all clear is that the parameters you're configuring have to end up in the various variables in the init'c file. Those get posted there by pressing the 'Export ALL to Open Program' button... and it really means ALL. That's not just all of the data in the Configuration dialog boxes, but the Step and Filter ones too. Again, it's not obvious because why is this button in the Configuration dialog box and not the main KMotion window? It makes no more sense to have it in the Configuration dialog box than in the Step dialog box. In my opinion it shouldn't be in either, it's just confusing.

You also need to be aware that the open init.c file will only accept values posted to it if those variables already exist. I needed to add a 4th axis, and the parameters weren't being saved in the init.c file. I had to copy and rename them to channel 3 before they could be transferred over. Obvious when you know, baffling when you don't.

'Export All to Open C Program' does prompt you to save the init.c program, but it would be more helpful it if just did that anyway. Why tell the user to do something that it could do itself?

You will probably also need to Save/Compile/Run the init.c in KMotion while testing before anything works. This isn't obvious, and it's possible to end up running an init.c file that doesn't reflect the current parameters in the dialog boxes. In my case, I'm using the alternate connections on the KFLOP board to generate the Step & Direction pulses for my servos. Nothing is going to happen unless the init.c instructs these to be used.

You need to do all of the tuning and setup of the basic functions in KMotion before turning to KMotionCNC if that's your end goal. Setting the Soft Limits can cause confusing issues with the Step Response, with it going into soft limit, so don't set those until you've got it tuned. Homing also checks the Soft Limits, so those need to be disabled temporarily while homing. I've covered this in another post about homing.

Look at the output of the console to see what's going on if you're confused, it may give you a hint as to where the problem is.

KMotion Step response must initially be done with the PID parameters at the top set to zero so it's running open loop. Only when that's tuned can you add a little I value, at which point it's now closed loop. This is not at all obvious.

One the performance in KMotion is satisfactory, you must save the resultant init.c file else KMotionCNC won't have those parameters correctly set. I'd also save the individual motor parameters so you don't lose them.

Once you've done this a few dozen times, you'll be familiar with what's going on, but it's certainly not intuitive. A better, more intuitive KMotion application that removes these manually needed synchronisations would be time well spent on development. I'm sure I'm not the only one to find this counter intuitive. I'm programmed all my life, and even as a programmer, I don't find it easy or logical the way these things interconnect with each other.

Anyway, hopefully this will help some people who are starting out and are as baffled as I was. It's superb hardware and software, only spoiled by the chaotic way that KMotion attempts to tie it all together, and the lack of clarity as to how the system hangs together overall.

In my opinion, more YouTube videos that cover the above would be beneficial. As it stands, it's far too difficult for the average person to get the hardware up and running. If you're developing a product to sell, that's one thing. However, I suspect quite a few people will look at KMotionCNC as an alternative to Mach4 but will be put off by the difficulty in getting a basic system running without a lot of Forum help.

Tarasevih
Posts: 101
Joined: Fri Jul 09, 2021 11:26 am

Re: Spindle ramp delay implementation

Post by Tarasevih » Fri Jul 16, 2021 8:42 am

Hi. Thanks Tom and GabrielR922! The best support.

Post Reply