KFLOP replacing LPT/Mach3 How To

[judleroy]

A few things to note. K-flop will work with mach3 and most of the stuff it does is supported. I like the k-motion Cnc so no issues for me but if you love mach3 you don't have to stop using it. Also most off the things you would like to do in k-flop already have c-programs in there database that make setting them up easier. You may need to make some changes to them or add to them but most off the time the changes are pretty straight forward to make. I don't know anything about c but have gotten along just fine.
The best feature by far is Tom the owner who can help with most questions and sending you where to look for answers.
Judleroy

[Fish4Fun]

eaglezsoar,

To be fair and honest, if Mach3 and the LPT is doing everything you want it to, there is likely no good reason to migrate to the KFlop. If, however, you want to use USB from a laptop, a PC that does not have an LPT port, are having trouble with Mach3, or want better performance from your steppers, then the KFlop solves those problems. Additionally, if you are just starting out and have not purchased Mach3 then the cost of the KFlop with KMotionCNC is within $75 of Mach3 alone, making the KFlop an "easy choice" as far as I am concerned.

jasminder,

As stated above, if you have an existing system performing satisfactorily the KFlop may not be a good choice for you. If you are having problems with an existing system, or are building a new system then the KFlop has a lot to offer in flexibility, performance and stability. As far as configuring the KFlop using the KMotion App, yes, it can be a bit scary, but hopefully I will have a front-end ready for use for simple open loop stepper systems in the next week or two that will make the task considerably easier.

Gerry,

I have revamped the way my front-end works wrt Axis/Chan/Master/Slave, here is a screen shot:



Honestly all of the fancy gui stuff only really changes a couple of lines of the configuration script, but hopefully the gui will make those changes more intuitive to users.

Fish

[Luger]

Hi Fish

Can you send le your application for creating a configuration script for the KFlop using Open Loop Steppers?
It is very well

Thanks you

[nova24]

Hi Dennis,

You can slave an axis to another by setting the MasterAxis parameter in an axis to the axis channel number you would like it to follow. To de-slave the axis set the MasterAxis back to -1. Normally one will de-slave while homing to square up the axis then enable slaving.

HTH

Tom,

If I have a stepper motor and an encoder on each side of my gantry and my encoders are attached between my gantry and table, giving me the actual position of my gantry, not the motor or drive screw position, will the Kflop controller correct for positional error between the two encodes to keep the gantry square?

I'm thinking positional error could result from manufacturing tolerances between screws or loss of motor counts due to slippage from the stepper motors.

Dennis

[TomKerekes]

If I have a stepper motor and an encoder on each side of my gantry and my encoders are attached between my gantry and table, giving me the actual position of my gantry, not the motor or drive screw position, will the Kflop controller correct for positional error between the two encodes to keep the gantry square?

I assume your encoders are linear, yes that is possible. Configure each side to operate as a closed loop stepper configuration. Also slave both sides together. This arrangement will correct for mechanical errors in the screws and such and also an occasional motor miss-step. However is your motor is miss-stepping it is likely to stall which would in turn trip a following error fault. But at least this would be better than continuing undetected and twisting your gantry.

Regards

[nova24]

I assume your encoders are linear, yes that is possible. Configure each side to operate as a closed loop stepper configuration. Also slave both sides together. This arrangement will correct for mechanical errors in the screws and such and also an occasional motor miss-step. However is your motor is miss-stepping it is likely to stall which would in turn trip a following error fault. But at least this would be better than continuing undetected and twisting your gantry.

Regards

Awesome!

I haven't had an issue with missing steps or stalling, just wanted to make sure I'm covered in case I do. This type of performance is what I'm used to in more expensive CNC motion controllers and I'm very excited to see that this controller has features like this. Thanks!

Dennis

[ger21]

This type of performance is what I'm used to in more expensive CNC motion controllers and I'm very excited to see that this controller has features like this.

Adding encoders to steppers isn't going to improve performance at all. As Tom said, it will basically just detect when errors occur.

[TomKerekes]

Adding encoders to steppers isn't going to improve performance at all. As Tom said, it will basically just detect when errors occur.

Not sure why you would say this, and that is not what I said, it absolutely would increase accuracy dramatically unless the motor goes into a complete stall and then it provides the additional benefit of following error detection.

Here is a description of Closed Loop Stepper operation in KFLOP.

The two plots near the end with Blue graphs show the encoder error in open loop and then closed loop modes. The error plot is in units of uSteps on a system with 50X microstepping. This example is for a rotory encoder mounted on the motor shaft. The plot is for a fairly aggressive motion up to 4000 full steps/sec. Notice in the first case an error of almost 2 full steps (~100uSteps) which right on the edge of a stall. In the closed loop case the errors are dramatically less. The green plot is the correction being applied throughout the motion






Regards

[ger21]

Sorry Tom, I guess I misuderstood. When you say you have an error of almost 2 full steps, how is this possible? have the 2 steps been lost? If not, how do you make the correction? Do you add the 100 microsteps, and then take them away when the motor catches up?

[TomKerekes]

When you say you have an error of almost 2 full steps, how is this possible? have the 2 steps been lost? If not, how do you make the correction? Do you add the 100 microsteps, and then take them away when the motor catches up?

Hi Jerry,

NP. No the steps have not been lost. The actual position and the commanded positions do not match because of electrical and mechanical inaccuracies.

Electrically the coil currents in the motor will typically lag behind the commanded microstep position.

Mechanically the motor rotor is connected to the pole positions magnetically which is somewhat similar to a spring. If you force the mechanical position away from the magnetic pole there will be a restoring force that initially increases as it moves away just like a spring. But instead of increasing linearly it is really sinusoidal. The force will initially increase linearly (near the zero crossing of a sine wave), but then level off at the peak, then start to decrease, and finally go negative. A miss-step will occur when the force goes negative and is then drawn toward the next pole rather than back to the original pole.

Regards

[TomKerekes]

how do you make the correction? Do you add the 100 microsteps, and then take them away when the motor catches up?

When primarily using an Integrator (I gain) to do the correction as described in the link, the integrator is always looking at the current position error. If it is behind then it advances the correction at a rate proportional to how far behind it is. If it is ahead it decreases the correction at a rate proportional to how far it is ahead.

So no, when the motor "catches up" then the correction is perfect so we want to leave it whatever it is, not remove it.

Regards

[Fish4Fun]

Luger,

I will be happy to send you a copy as soon as I do a bit more debugging, hopefully before the weekend. The weather here has been seasonally wonderful and I have been working on outside projects the last few days, but it is suppose to turn cold/rainy this evening or in the morning, and I will get back to my inside projects list.

Tom,

Are there any particular encoders you would recommend for NEMA23 Frame steppers? I know ZERO about them, but I would assume the mitigating factors would be PPR and Top RPM.....

Fish

[bradodarb]

Hey Fish,

A master homing program that Tom and I wrote is available here::

http://f1.grp.yahoofs.com/v1/0BnlTsy...MM/HomeMM_V7.c

It supports up to 8 axes, allows several types of homing, enables you to separate homing cycles per axis into 'sequences', supports multiple simultaneous axes per sequence, SLAVED axis homing, etc...


It has not been thoroughly tested for all use cases, but initial testing looks good.

Although I originally designed it for use with MM, it can certainly be used for anything, you can either set things up from some helper methods in the file (LoadUserData(), CreateHomeTask())... or you can directly set persist.UserData to have it generate the sequences from that.

I was thinking it would be cool if you could set the persist.UserData stuff in your generated Init.c program from your nice interface = no more .c file editing for homing!

-Brad Murry

[Fish4Fun]

Brad,

You are too kind.

I have spent the past three days banging my head against a wall over something silly....I use the Vectric software (Aspire) to generate my g code, and I have been using the "Mach2/3" g code output settings.....well the "header' from those g code files includes a g9x that forces "machine coordinates" followed by a G94? that is not supported by KMotionCNC...end result, the machine is left in "Machine Coordinates", regardless of 'setting zero" in the "relative coordinates'. I "crashed and burned" more bits/work than I can even begin to rationally discuss because of this...NOT KFlop or KMotionCNC's fault, my own STUPIDITY! When I set the g code output in ASPIRE to EMC2, LOL, all crashes stopped and things started working JUST LIKE THEY SHOULD, lol!

Prior to my little epiphany, I was ready to scrap my front-end because I thought it might be to blame....It is not, but.... I am still left with the notion that I might not be qualified to write a front-end for something I am still wrestling myself. My goal was to make replacing the LPT/Mach3 with a GFlop and KMotionCNC "easy" for a Mach3/G540 user, but I am beginning to suspect that Tom was correct when he said, "There is no 'common solution' everyone has a unique set-up". I have about $50 worth of bits and ~$20 worth of stock to support his assertion, but I still "know" my steppers run MUCH better with the KFlop; I am just a bit unsure I want to incur the wrath of those who might use my front-end to destroy their tooling/stock while they go through the rest of their learning curve.

What I would love is for you to review my (ridiculously) simple app to make sure that it does what I say it will do, because right now I am low on confidence. If my code does NOT generate reliable init.c files I would REALLY rather never let it "loose". You don't have to look @ the code if you don't want to, just pass/fail the .exe (for a NON-Encoder set up that uses a G540 ....[or similar type driver]). If you think it is a waste of time, I certainly understand.

I was thinking it would be cool if you could set the persist.UserData stuff in your generated Init.c program from your nice interface = no more .c file editing for homing!

Again, I am feeling pretty low on the confidence scale right now; to be honest, I am not even sure what the "persist.UserData stuff" means. Deep down inside I believe all of the verbiage between the UI and the DLL ultimately end in hex operands with data/params sent to the KFlop inside a USB packet. That is, TEXT + Params + Data is resolved into a simple Hex Value that is output via a USB packet to the KFLOP. All the pretense of "C Programs", "Down Load" / "Up Load", etc, etc is simply high-level stuff that has little to do with the actual I/O to the KFlop. All the wrappers, containers, parsers etc are just complicated ways of sending a hex value. Anyway, regardless of high-level/low-level communication, I still have a lot to figure out....If I can make it easier for a group of (potential) KFlop users, I will continue, but I am currently unsure if there is even a group I am addressing....

No is a good answer, lol, but Thanks in advance for your thoughts,

Fish

[Fish4Fun]

Hey Fish,

A master homing program that Tom and I wrote is available here::

http://f1.grp.yahoofs.com/v1/0BnlTsy...MM/HomeMM_V7.c

-Brad Murry

Bad Link? I signed up for the group a while back, but this link and the one form the other thread don't seem to be working...prolly a problem on my end.

Fish

[bradodarb]

Bad Link? I signed up for the group a while back, but this link and the one form the other thread don't seem to be working...prolly a problem on my end.

This forum seems to have issues with long urls...

Anywho, here is the file. Do a search for persist.UserData to see where things are being set.

-Brad

[bradodarb]

Prior to my little epiphany, I was ready to scrap my front-end because I thought it might be to blame....It is not, but.... I am still left with the notion that I might not be qualified to write a front-end for something I am still wrestling myself. My goal was to make replacing the LPT/Mach3 with a GFlop and KMotionCNC "easy" for a Mach3/G540 user, but I am beginning to suspect that Tom was correct when he said, "There is no 'common solution' everyone has a unique set-up". I have about $50 worth of bits and ~$20 worth of stock to support his assertion, but I still "know" my steppers run MUCH better with the KFlop; I am just a bit unsure I want to incur the wrath of those who might use my front-end to destroy their tooling/stock while they go through the rest of their learning curve.

-
Well, personally I think it is better to make some mistakes and share them here. If you just wrote a "Transition from Mach to KMotionCNC" that had a bunch of steps to follow- people would likely not know what to do when they ran into a stumbling block.


-
An expert integrator will make mistakes when moving from one platform to another and the severity of the errors is probably relative how much he believes the new system is akin to the old one.

-
It did not sound like the issues you encountered could be blamed on your configurator, rather on a difference in dialect. I think you are on the right track to lower the barrier of entry, keep at it.

-
There may not be a single solution, but I'm a firm believer in the 80/20 rule and again I belive your setup can help the 80% of people that just want to make parts but want the high performance of a kflop.

-
Keep placing those "use at your own risk" warnings! They are great. I used to work for a CAD/CAM company and even though I probably ran 1000's & 1000's of part programs to test new features and post processeors I always kept a hand on the e-stop and slowed the feedrate in 'danger zones'. If I was actually making chips, I would always dry-run first. I pretty much pretended it was my first part every time.

Aside from huge surface machining programs, a few minutes watching your machine run before actually cutting a part(at least on tricky or new type operations) is well worth it.

What I mean to say is that there are methods of operation that should be followed running any machine(I'm sure there is plenty of information on this site on the subject), and anyone who decides to work outside of those methods does so at their own risk.

What I would love is for you to review my (ridiculously) simple app to make sure that it does what I say it will do, because right now I am low on confidence. If my code does NOT generate reliable init.c files I would REALLY rather never let it "loose". You don't have to look @ the code if you don't want to, just pass/fail the .exe (for a NON-Encoder set up that uses a G540 ....[or similar type driver]). If you think it is a waste of time, I certainly understand.

I'll take a look, but from my experience as a proffesional developer if you are trying to wait for a perfect application before "letting it loose" you will be waiting a long time.... No matter how well it works on your system or how many angles you looked at it from I can almost guarantee you somebody else will come along and find some "undocumented features" for you.

And why not let them? You are providing a useful tool for people and at the very least they can help you make it better by informing you about bugs and making feature requests.

If I can make it easier for a group of (potential) KFlop users, I will continue, but I am currently unsure if there is even a group I am addressing....

Er... by the look of the replies and views I'd say that there certainly is an audience!




...where is that long-winded emoticon?....I'm done

Keep up the good work, and that homing routine is aimed at the same 80% your app is so let me know if you decide to incorporate it and need any help.

-Brad

[Fish4Fun]

Brad,

Thanks :-)

Fish

[Ron Dunn]

Fish4Fun, would you be willing to share your configuration application?

I've got an MV3, and I've just ordered one of these controllers. I should have done more homework. To say I'm shocked at the primitive state of the applications and (what there is of) documentation would be an understatement.

Anything that could help me get going would be gratefully accepted.

Ron.

[iknowyoudo]

Fish4Fun,

Don't give up. I just sent off a email to Tom to make sure it will work with my system. Your posts are helpful. My system is servo so I need reliability and this seems to be the way to go. Thanks for all your work and I look forward to seeing the finished result as I'm sure others will find this very useful.