Oh, trust me. Annoying I do well
Nope; no end at all. Just like buying electronics, always something newer and (mostly) cheaper. Just have to pick a time and go.
Downsides... Well, you seem to be a kindred spirit in the obsessive research department, heh. I will save you some time, and list what I perceive them as.
Dynomotion Documentation
This used to be my biggest pet peeve. The data is there, but due to the configuration complexity of the devices, the number of choices is overwhelming. I have done documentation and manual production work in the past, so I certainly can sympathize how difficult and time consuming it is to produce it for a dedicated device. Add to that the (general) engineer reluctance to document and provide examples, couple that with the need to produce it for all the various permutations, and NOPE factor quickly rises to exponential notation levels. Just a taste: KFLOP supports Serial, ModBUS, USB, Steppers (closed and open loop), Servos, tachometers, encoders, tying most Inputs to different hardware Outputs, multiplexing data, several flavors of drive output.
I found it very daunting at the start. Again, Dynomotion has made a concerted effort to streamline and make finding information easier. They have somewhat recently set up a Wiki, and it is being populated with information. The website links and pages are being streamlined and made less difficult to locate information. I must stress the example programs were always there, as was the documentation, but I always compared finding it akin to a knowledgeable software programmer looking up a function in an index or hardware engineering looking up the specifications for a component, compared to that of a beginner trying to tell the difference between a procedural and a object oriented language... There was a largish learning curve.
C Programming
This would be my second largest. From the Dynomotion support site:
http://dynomotion.com/Support.html
Programming in C
To use our products you will need to program at least a little bit in C. If you are new to programming there are many resources to help you in this rewarding endeavor. There has been a lot of discussion recently about how everyone should learn how to program and we don't disagree with this idea. Programming is a powerful enabler in general, and this is especially true in combination with our products.
This scares a lot of people initially. Something like Mach3 and Smoothstepper, the basic parameters are generally set for you. Set Mach3 inputs and outputs, kernel speed, counts per inch, do some fine tuning, and you are away. With KFLOP, all of that (and more is open to adjust).
The controller is programmed upon startup with what is usually called the init.c program. This contains all the settings needed: # axis enabled, what IO to use, what to monitor, you name it. Unless you have embedded it in the KFLOP, this is required to be opened, compiled, and downloaded once upon each startup. It sound tedious, but it is really clicking one icon. My machine boots, Kmotion opens, displaying the last used init.c, and I select the combination icon and in a split second, the machine is live.
Getting to that stage requires, at the minimum, opening the example program and modifying it to your needs. Here is a link to the sample file for a 3 axis machine running a KFLOP and KSTEP (I could not find the Dynomotion hosted variant; this will d0):
https://github.com/parhansson/KMotionX/blob/master/C Programs/KStep/InitKStep3AxisNoDisable.c
There are 217 lines in the file, the first 180 are all parameters for the 3 axis (about 34 lines per axis). ONCE these values have to be looked at and set (often, you can leave the majority the way they are). This file, as is, will program the KSTEP drives and execute G-Code. It does not have any code for E-Stops, pendants, encoders, limit switches, etc.
I have past programming experience, but it is with PHP, BASIC, PYTHON, not C. It took a few moments, but it was not that difficult. Most of it was of the Copy-and-paste-Frankenstein method. When I wanted to add the hardwired pendant, I eventually found similar functionality and adapted the code (their smooth MPG example (Multi Pulse Generator). I only had to conceive the fall-through logic tree for the axis selector and range (my pendant did not have an enable to conveniently shut off the axis control; hindsight) and select the INPUT and OUTPUT ranges I was using; the rest of the code is theirs.
// Example Init program that includes "smooth" MPG motion example
// which makes use of the exponential motion command.
#define SELECTX 24 // KFLOP JP4, Pin 15 (I/O 24):
#define SELECTY 17 // KFLOP JP4, Pin 06 (I/O 17):
#define SELECTZ 19 // KFLOP JP4, Pin 10 (I/O 19):
#define SELECT4 21 // KFLOP JP4, Pin 12 (I/O 21):
#define FACTOR1 23 // KFLOP JP4, Pin 14 (I/O 23):
#define FACTOR10 25 // KFLOP JP4, Pin 16 (I/O 25):
#define FACTOR100 26 // KFLOP JP6, Pin 05 (I/O 26):
#define QA 16 // KFLOP JP4, Pin 5 (I/O 16): define to which IO bits the AB signals are connected; I've assumed A+ and B+
#define QB 18 // KFLOP JP4, Pin 7 (I/O 18):
#define COUNTS_PER_MM 100.0
// Pendant reading code
// convert quadrature to 2 bit binary
//BitA = ReadBit(QA);
//PosNoWrap = (ReadBit(QB) ^ BitA) | (BitA<<1);
BitA = ReadBit(QB);
PosNoWrap = (ReadBit(QA) ^ BitA) | (BitA<<1);
// Diff between expected position based on average of two prev deltas
// and position with no wraps. (Keep as X2 to avoid division by 2)
DiffX2 = 2*(Pos-PosNoWrap) + (Change2+Change1);
// Calc quadrature wraparounds to bring Diff nearest zero
// offset by 128 wraps to avoid requiring floor()
wraps = ((DiffX2+1028)>>3)-128;
// factor in the quadrature wraparounds
NewPos = PosNoWrap + (wraps<<2);
Change2 = Change1;
Change1 = NewPos - Pos;
Pos = NewPos;
// Determine which Axis is selected; Logic tree. If none are selected, disable pendant MPG control, as the unit is in the OFF position
// Pendant purchased did not have a ENABLE switch, no free conductors to install one; this will work fine to function as an ersatz one.
if (ReadBit(SELECTX)) // is x selected?
Axis=0; //X axis in my setup
else if (ReadBit(SELECTY)) // is y selected?
Axis=1; //Y Axis in my setup
else if (ReadBit(SELECTZ)) // is z selected?
Axis=2; //Z axis in my setup
else if (ReadBit(SELECT4)) // is 4th axis selected?
Axis=3; //A axis in my setup
else
Change1 = 0; // Disable Pendant, since OFF is selected (none of the above resolve to TRUE)
Factor = 0; // Force the change factor off (13 Nov 2015)
// Determine which multiplier is selected; unlike above, must be one of the three positions by hardware design
// Factor numbers by design, how much to move per MPG pulse
if (ReadBit(FACTOR1)) // is X1 selected?
Factor = 1;
else if (ReadBit(FACTOR10)) // is X10 selected?
Factor = 10;
else if (ReadBit(FACTOR100)) // is X100 selected?
Factor =15;
}
}
For my case, it was certainly worth the mild pain to gain the flexibility.
I would suggest downloading the software, and having a look. There is no limitations or time limit (since it needs the KFLOP) but you can load in C code and have a look at Kmotion (C code interface), and KmotionCNC (G-Code interface). All of the sample C code files are included.
KSTEP vs Gecko
Tom Kerekes (Dynomotion head public figure) has publicly stated that he feels the KSTEP is an excellent price point device: lessened wiring, works plug and play with KFLOP, and covers most peoples needs. Having said that, he has stated the Gecko drive in some ways is superior.
Individual Drives Vs. All-In-One
This one I have some personal experience with: the KSTEP has all four axis on one board. Blow one of those out, and you are left with three choices: repair it yourself, send the board back for repair, buy another. With the individual Gecko drives, you still have an operational machine while you decide what to do with the blown drive. On the other hand, the Leadshine or Gecko all-in-ones leave you in the same boat. Just do not experiment with unknown steppers (my case) or have loose wiring (others) and no issues.
Current Limits
The KSTEP sets the stepper current limits in discrete increments. My chosen motors are slightly underpowered given the available jumper settings, but considering the motors were oversized to begin with...
Microstepping
The KSTEP is permanently set at 16x microstepping, and some feel you lose too much positional accuracy going over 8x or so; in reality, the drive is multi-mode. Like Gecko, switches over at higher speeds from pure microstepping. I have the LMS 3960 mill (similar to yours but at the time the air spring was extra), and any lost accuracy is due to the mill, the slight lash in the couplers, the stiction of the ways, ,the 0.200 inch lead Thompson ballscrews long before the steppers are the issue.
Hardware Configuration
If you do anything outside of the more-or-less-standard configuration, you might find yourself having to do some modifications. For example. Out of the box, the KFLOP and KSTEP allow control of up to 8 steppers (dual drive 4 axis) and up to 8 encoders. The problem is that the interface connector between the KFLOP and KSTEP uses the same pins as the second set of encoder lines.
If I (eventually) get around to putting my CUI encoders on the steppers with linear encoders, I will have to custom make a ribbon cable, and re-locate some of the inputs (since they multiplex over the same connector). This really is not a problem, since dual loop control is indeed possible, but rarely done on this size of mill. Tom Kerekes has asked for people to send him examples a couple of times; I have not seen anyone take him up on it yet.
Really, just comes down to prior planning prevents (tinkle) poor performance. The more things I feel like hanging on, the more it looks likely to get one of the other input output boards they offer. Tom has had people frequently run a KFLOP with two KSTEPS; in fact, his recent demo robot is doing so.
Dynomotion's 6-Axis Cable-Driven Demonstration Robot
Heh; forgot about this:
KFLOP running from Raspberry Pi (not something I am interest in, but does show what is possible; note: this is done by others than Dynomotion, so support is very limited)
Pendants and E-Stop
little more work here, as you should do a hardwire interface. With MACH3, people use USB pendants, which takes away the real-time element. real-time is something I agree with, since I do not want the computer interfering with control. I have three e-stops: the KmotionCNC software abort (shuts down the KSTEP enable via USB communication to the device), pendant hardwired switch and another on the machine box; the last two physically remove drive from a relay, simultaneously removing spindle power and the drive power to the KSTEP. Barring fused relay contacts, the machine is stopping. In addition, hitting the E-Stop physical button also drives an input low, which is monitored by the code I put in the KFLOP init.c, which additionally triggers the enable.
Motion Buffer
Since the KFLOP and KSTEP are the real controllers, the box sends out data in advance; pull the USB connection, and the machine will still operate until the buffer empties. Some consider this an issue.
KMotionCNC vs MACH3
Mach3 wins, for sheer amount of screens and configurations. KMotionCNC is very minimalist. Now, considering Mach3 works just fine with the KFLOP using the Dynomotion authored plug-in, it is not a big issue. KmotionCNC does the job for me, allows up to 7 concurrent programs to run, allows manual data input, jogging (even if the screen layout is somewhat...lacking). Lathe functionality is being developed and conversational programming is not there (I use G-Wizard for that, the rare time I cannot type it in or copy a previous example and alter it).
With the release of MACH4, the somewhat lukewarm reception it is getting from plug-in developers, well, that is another story.
Every time I start to decide on something...
There is no end to this, is there?