The encoder board originally posted occupies the second parallel port, using pin 2-9 as inputs, there for it's easily possible with a second parallel port. I have all my IO's mapped out in a spread sheet, and I think I have one or two inputs left between the two parallel ports after it's all said and done. Now mine involves a tool changer and some other goodies that generally the common home shop guy will not have, but the point is there are plenty of IO's to do what you want.
WOW!, I vaguely remember seeing a setup window for an encoder, and it had entries for resolution and how much error was allowed.
I know my memory is not the best, so I may have assumed it was something it isn't. I have not pursued it any further so I know I can't be positive. Are you familiar with this?
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Antoine de Saint-Exupery (1900 - 1944)
Nope, never seen or heard of anything like that in Mach3. Mach3 has no built-in capability to do anything with encoder inputs other than display them. And even with macros and brains, the only thing it can do when an error condition is detected is fire an E-Stop, which is a pretty brute-force response. There are external motion controllers that can handle things more gracefully. I'm now using a KFlop with a CNC controller app I wrote myself. The KFlop can do true closed-loop control even with steppers. But, setting up a KFlop is FAR beyond the abilities of your average CNCer.
Regards,
Ray L.
This would be fine for my purposes. As you have commented, a properly designed stepper system should not miss steps. So I wouldn't be looking for a missed step here or there. I would be concerned about a more drastic crash where the motor is no longer in sync with the pulse train. It would not be an issue to fire an E-Stop once that happened, since I would be reaching for the E-Stop myself.
Not to split hairs (well... maybe to split hairs), when you say "true" closed loop, it is doubtful with steppers. Yes a loop is closed (as is with step verification), but "true" closed loop is a servo. The stepper would need to be operated as a brushless DC motor, and would require a special controller with a position sensor of some kind, to commutate the motor.
Ray, I am intrigued by the KFlop too. What was the reason you went with it? Didn't you have a SmoothStepper? The KFlop seems to have more features. Is that what you found?
Last edited by HawkJET; 03-11-2012 at 03:52 AM.
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Antoine de Saint-Exupery (1900 - 1944)
Gerry
Mach3 2010 Screenset
http://home.comcast.net/~cncwoodworker/2010.html
(Note: The opinions expressed in this post are my own and are not necessarily those of CNCzone and its management)
That is pretty much what the KFlop does with steppers. It does, in effect, 512X micro-stepping, and run the stepper in a PID loop with encoder feedback.
Mach3 was simply too unreliable - I was having constant problems with erratic, unpredictable behaviors that both Brian and Greg spent months working on, but never could fully resolve. We know what was happening, but could never pin down why. As a result, I have a mountain of broken tools and scrapped work, and was never able to leave the machine running without being there with my finger hovering over the E-Stop button. The KFlop has proven absolutely bullet-proof.
But, the KFlop is not for the faint of heart. Getting it setup to duplicate the functionality of a typical Mach3 install is a big job, and REQUIRES writing a far amount of C code. The KFlop is more a CNC controller "kit" than a complete, finished controller. You have to write your own C code to initialize the axis parameters, do homing and probing, handle your pendant and other controls, control your spindle, and other things. I ended up with probably a few thousand lines of C code by the time I was done. I also went a few steps further and wrote my own Windows CNC controller app in C#. That was a fair amount of work, but I now have an app that does exactly what I want it to do, and that I can easily modify and extend to add further capabilities. That is simply not possible with any other solution I'm aware of (though Mach3 v4 will have at least some capability in that directions, and I may port my app to v4 when it comes out).
Regards,
Ray L.
Jim, if you have Mach3, you can use it to read encoders on each axis and compare the reading to the commanded position. If there is an error larger than you specify, Mach3 can execute an E-Stop.
I have not poked around Mach3 to see if I could find the setup I mentioned earlier. It doesn't exits, then you can write a macro to do it. Mach3 checks the DRO 10 times per second so it can only be a monitor for some kind of crash and it will not "save" your part. It may be more complicated though. I don't know if Mach3 can easily know where it is supposed to be each 1/10 of a second....
I plan to set up my machine this way, so hopefully it is simple.
My first impression of this was that it wasn't really "true" closed loop, but as I think about it more, it may be.
WOW! Ray, you did a lot of work!
If one were to do a basic system, would it be more straightforward?
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Antoine de Saint-Exupery (1900 - 1944)
For a system that comes close to a commercial system, I would think Kanalog with AC/BLDC servo's and simple ±10vdc trans-conductance (Current mode) drives such as A-M-C.?
Were I to implement it, this is what I would shoot for.
Al.
CNC, Mechatronics Integration and Custom Machine Design (Skype Avail).
“Logic will get you from A to B. Imagination will take you everywhere.”
Albert E.
The position updates come from the low-level driver (PP, SS whatever). Mach3 knows where it *told* the machine to go, but only the driver *knows* where the machine is right now. So, the worst-case latency of a position update determines the minimum resolution at which you can detect a problem. At 200 IPM, that's about 1/3", best case. At 30 IPM, about 0.050". So, you're still not going to catch a problem in time to save a tool or workpiece.
Now, the KFlop WOULD allow you to catch things much sooner by writing a custom DSP program to monitor commanded position and actual position, in more-or-less real-time (DSP programs can run as often as once per pass of the servo loop, or about every 90 uSec).
Like I said, there is NO built-in support for homing, probing, jogging, spindle speed control, and several other common functions. Those are all provided by user-provided C code running on the KFlop DSP. Getting the basic axis motion going is pretty straight-forward. But there is a STEEP learning curve to really understand how the whole system works, and create a usable, full-function CNC machine. Much had to be learned through experimentation. Though it was a painful process, for me it was worth the time and effort, as I now, for the first time, have a completely robust and reliable machine.
Regards,
Ray L.