Teknic Clearpath-SC and LinuxCNC
- AardvarkTech
- Offline
- New Member
-
Less
More
- Posts: 4
- Thank you received: 0
17 Dec 2017 23:25 - 17 Dec 2017 23:32 #103259
by AardvarkTech
Teknic Clearpath-SC and LinuxCNC was created by AardvarkTech
Hi LinuxCNC, my name is Mike, and I've been a lurker here for many years.
First let me say that I am NOT affiliated with Teknic in any way, and this is not a sales pitch. I'm a machinist, CNC programmer, and manufacturing engineer, and I've used ClearPath motors (mostly NEMA 34 MCPV versions) at work for various automation tasks and am interested in exploring other applications.
Has anyone looked closely at the Teknic Clearpath -SC series of motors, and/or actually opened up the s-foundation library and examined the capabilities of the software? I'm curious to know how difficult it would be to integrate the -SC functionality into LinuxCNC. I don't have any hands-on knowledge of either platform, as I'm only still in the researching phase of my DIY CNC adventures, but the possibilities seem intriguing.
Here's are a few really neat opportunities I've identified, just from reading through the available documentation and turning it over in my head for the last few months since the upgraded product line was released:
- The complete ClearPath line of integrated servo motors is now available in NEMA 56 and NEMA 143 frame sizes, with up to 4hp continuous / 8hp peak power (and can be powered from single phase 240V!). The very most expensive, highest power model is approximately $1,400. This makes these motors a very attractive option for main spindles on medium/small machines because of the built in capacity for spindle orient (maybe even for mill/turn applications?), rigid tapping, etc, as well as very high torque at low RPM (something which even the best VFD's struggle with, and at no small cost).
- The SC series motors (as I understand from searching Teknic's documentation) can be controlled by BOTH software commands, AND step/direction inputs. (I read a comment by a poster on this forum that dismissed the -SC motors because of RS232. This is not a limitation, because the step/direction interface and RS232 interface are separate.) This would seem to imply that it is possible to re-configure the motor on the fly depending on current operating needs. For example, the effective step/direction resolution of the axis motors could be instantly changed depending on G0 / G1 status, simultaneously enabling high speed rapid movement AND high precision contouring on a controller with limited step generating ability. Or a main spindle motor could be switched from velocity control to precise positioning control in order to carefully orient a broaching or shaping tool, which could then be used in multiple orientations/directions.
- The spindles, motion axes, out of band axes (tool changers, parts loaders, etc) could be controlled and powered from the same ClearPath-SC communications bus. While RS232 may not be suitable for closed-to-the-controller feedback for CNC contouring, it's just fine for point to point feedback and control of all those other motion tasks. Many I/O points could be eliminated or simplified.
- The SC interface can read motor status, position, velocity, torque, settings, and really offers a lot of control over the system, without a lot of extra physical wiring. This means, for example, spindle motor speed/torque feedback direct to the control software, WITHOUT having to deal with an encoder with its wiring, inputs, configuration, and processing. Sub-millisecond real-time feedback really isn't necessary just to determine when a cutter is overloaded and the spindle is starting to slow down. Also, things like following error and axis overload can be detected and dealt with, without needing a high speed PID loop, with its associated inputs and configuration.
I'm not trying to make a sales pitch here, though I admit that's probably how I come across. For that I apologize. I'm also not trying to say that this platform is better than anything else. Some of its features may not be useful for CNC machines, and some benefits might be so easily dealt with in other ways it's not worth implementing, but even still, I see a great deal of potential here to solve and simplify some real problems, and I'd really like to explore deeper to see what is possible. My goal here is to discuss new ideas, new ways of thinking, and new ways to use a new technology to make CNC, and DIY / retrofit CNC better.
Any thoughts? Please no "If it ain't broke don't fix it" or "It won't work because I have a personal bias" comments. Not helpful.
First let me say that I am NOT affiliated with Teknic in any way, and this is not a sales pitch. I'm a machinist, CNC programmer, and manufacturing engineer, and I've used ClearPath motors (mostly NEMA 34 MCPV versions) at work for various automation tasks and am interested in exploring other applications.
Has anyone looked closely at the Teknic Clearpath -SC series of motors, and/or actually opened up the s-foundation library and examined the capabilities of the software? I'm curious to know how difficult it would be to integrate the -SC functionality into LinuxCNC. I don't have any hands-on knowledge of either platform, as I'm only still in the researching phase of my DIY CNC adventures, but the possibilities seem intriguing.
Here's are a few really neat opportunities I've identified, just from reading through the available documentation and turning it over in my head for the last few months since the upgraded product line was released:
- The complete ClearPath line of integrated servo motors is now available in NEMA 56 and NEMA 143 frame sizes, with up to 4hp continuous / 8hp peak power (and can be powered from single phase 240V!). The very most expensive, highest power model is approximately $1,400. This makes these motors a very attractive option for main spindles on medium/small machines because of the built in capacity for spindle orient (maybe even for mill/turn applications?), rigid tapping, etc, as well as very high torque at low RPM (something which even the best VFD's struggle with, and at no small cost).
- The SC series motors (as I understand from searching Teknic's documentation) can be controlled by BOTH software commands, AND step/direction inputs. (I read a comment by a poster on this forum that dismissed the -SC motors because of RS232. This is not a limitation, because the step/direction interface and RS232 interface are separate.) This would seem to imply that it is possible to re-configure the motor on the fly depending on current operating needs. For example, the effective step/direction resolution of the axis motors could be instantly changed depending on G0 / G1 status, simultaneously enabling high speed rapid movement AND high precision contouring on a controller with limited step generating ability. Or a main spindle motor could be switched from velocity control to precise positioning control in order to carefully orient a broaching or shaping tool, which could then be used in multiple orientations/directions.
- The spindles, motion axes, out of band axes (tool changers, parts loaders, etc) could be controlled and powered from the same ClearPath-SC communications bus. While RS232 may not be suitable for closed-to-the-controller feedback for CNC contouring, it's just fine for point to point feedback and control of all those other motion tasks. Many I/O points could be eliminated or simplified.
- The SC interface can read motor status, position, velocity, torque, settings, and really offers a lot of control over the system, without a lot of extra physical wiring. This means, for example, spindle motor speed/torque feedback direct to the control software, WITHOUT having to deal with an encoder with its wiring, inputs, configuration, and processing. Sub-millisecond real-time feedback really isn't necessary just to determine when a cutter is overloaded and the spindle is starting to slow down. Also, things like following error and axis overload can be detected and dealt with, without needing a high speed PID loop, with its associated inputs and configuration.
I'm not trying to make a sales pitch here, though I admit that's probably how I come across. For that I apologize. I'm also not trying to say that this platform is better than anything else. Some of its features may not be useful for CNC machines, and some benefits might be so easily dealt with in other ways it's not worth implementing, but even still, I see a great deal of potential here to solve and simplify some real problems, and I'd really like to explore deeper to see what is possible. My goal here is to discuss new ideas, new ways of thinking, and new ways to use a new technology to make CNC, and DIY / retrofit CNC better.
Any thoughts? Please no "If it ain't broke don't fix it" or "It won't work because I have a personal bias" comments. Not helpful.
Last edit: 17 Dec 2017 23:32 by AardvarkTech. Reason: Clarity and not realizing square brackets actually mean something in text formatting.
Please Log in or Create an account to join the conversation.
- Todd Zuercher
-
- Offline
- Platinum Member
-
Less
More
- Posts: 4962
- Thank you received: 1369
18 Dec 2017 02:38 #103266
by Todd Zuercher
Replied by Todd Zuercher on topic Teknic Clearpath-SC and LinuxCNC
The Clearpath servos seem to be a good product, and I have used other Teknic drives and motors. It just sort of seams like the Mach3 way of solving these problems while Linuxcnc has embraced more of the traditional ways with direct feedback.
Please Log in or Create an account to join the conversation.
18 Dec 2017 12:59 #103286
by andypugh
Replied by andypugh on topic Teknic Clearpath-SC and LinuxCNC
I don't see any reason at all to prefer step-dir over RS232 in a LinuxCNC context.
All that is missing is a driver. And that ought to be fairly simple, using the Mesa UART for a realtime-all-the-way connection.
I have recently been experimenting with the STMBL servo drive, which offers many of the features that you describe but is already 100% LinuxCNC compatible. (as it would be, being designed by a LinuxCNC user).
For an intro, here is the beginnings of the STMBL documentation . (only about 10% done, but should give a feel for how a smart drive can interface with LinuxCNC)
The STMBL is not without its problems, though. One of them being that the supply is rather limited.
All that is missing is a driver. And that ought to be fairly simple, using the Mesa UART for a realtime-all-the-way connection.
I have recently been experimenting with the STMBL servo drive, which offers many of the features that you describe but is already 100% LinuxCNC compatible. (as it would be, being designed by a LinuxCNC user).
For an intro, here is the beginnings of the STMBL documentation . (only about 10% done, but should give a feel for how a smart drive can interface with LinuxCNC)
The STMBL is not without its problems, though. One of them being that the supply is rather limited.
Please Log in or Create an account to join the conversation.
- AardvarkTech
- Offline
- New Member
-
Less
More
- Posts: 4
- Thank you received: 0
19 Dec 2017 04:04 #103328
by AardvarkTech
Interesting. I like the CAT5/6 plug wiring scheme. Proprietary or "need expensive tools to assemble" connectors drive me nuts. The USB grounding issue looks like a bit of a thorn in the side. I'm curious, what are the goals of this drive? What is it intended to do that isn't available already from existing commercial / industrial suppliers?
I admit to not knowing a lot of the technical details, so forgive me if I miss some things. In this case, I'm not sure at what level a driver would integrate into the bigger picture. I'm not thinking of the problem in terms of STEP/DIR v RS232, but rather, how can BOTH be utilized simultaneously to gain more capability and flexibility from the motors and drives. In fact, I'm not even really all that interested in creating a driver to translate the functions that already exist into the hardware's language. I think Teknic's s-Foundation library is much more powerful than that. Just like LinuxCNC itself, it's a LEGO set that makes all kinds of creative new ways of thinking and building a CNC control possible. Relative to the example I mentioned in my original post regarding on-the-fly resolution switching for G0/G1 moves, I have gotten a sense that step generation speed can be a limitation for LinuxCNC builds where high resolution encoders are used, as some servos have 10k+ counts per revolution, and the new AC Clearpath servos have a 64,000 line (16,000 quadrature counts) encoder. A smoothstepper running Mach3/4 can output 5Mhz steps on all channels, so plenty to drive one of these motors at its' maximum speed (2400 rpm rated speed, 32,000 cpr programmable resolution = 1.28MHz). Some servos have even higher encoder densities. And I'm sure there exists a LinuxCNC compatible motion controller with similar abilities to the smoothstepper. That's not the point. It's only one example of something that could be done with a C++ API directly to the servo drive. Besides, I'm sure that running NEMA 56/143 frame 8hp servos isn't really in the cards for many LinuxCNC users, since it takes a pretty good size machine to need that kind of power, but as new technologies and capabilities emerge, some of the "traditional" ways of doing things seem less helpful than they used to be. Especially when you consider that Teknic is now offering a mass produced 8hp (peak, 4hp cont.) digital servo with integrated drive and controller, that can be directly powered by 1ph 230V AC for under $1,400. Why would you even WANT to mess with trying to tune and synchronize an analog PID loop when a large automation company provides a very economical drive system with a very good auto-tuner and logic that handles changing inertia loads and feedforward gains on the fly?
I do understand that there's a certain group of people who will always want low level control, and like tinkering with the small details. Maybe that's the crowd that the developers and community of LinuxCNC want to cater to. If so, I get it, no worries. But at the same time, I myself, am looking for a platform upon which to build and try out new things, not just copy what everyone else has done before only with a different off-brand servo. So I'm trying to explore what's possible, and maybe more importantly, what's possible NOW that wasn't available just 6 months or a year ago. Like EtherCAT. Superb concept, though from what I have researched so far its usefulness for CNC seems fairly limited and not easy to implement. On the other hand, Clearpath-SC looks like it would be super easy to implement and customize for all kinds of great things.
Replied by AardvarkTech on topic Teknic Clearpath-SC and LinuxCNC
I have recently been experimenting with the STMBL servo drive, which offers many of the features that you describe but is already 100% LinuxCNC compatible. (as it would be, being designed by a LinuxCNC user).
For an intro, here is the beginnings of the STMBL documentation . (only about 10% done, but should give a feel for how a smart drive can interface with LinuxCNC)
Interesting. I like the CAT5/6 plug wiring scheme. Proprietary or "need expensive tools to assemble" connectors drive me nuts. The USB grounding issue looks like a bit of a thorn in the side. I'm curious, what are the goals of this drive? What is it intended to do that isn't available already from existing commercial / industrial suppliers?
I don't see any reason at all to prefer step-dir over RS232 in a LinuxCNC context.
All that is missing is a driver. And that ought to be fairly simple, using the Mesa UART for a realtime-all-the-way connection.
I admit to not knowing a lot of the technical details, so forgive me if I miss some things. In this case, I'm not sure at what level a driver would integrate into the bigger picture. I'm not thinking of the problem in terms of STEP/DIR v RS232, but rather, how can BOTH be utilized simultaneously to gain more capability and flexibility from the motors and drives. In fact, I'm not even really all that interested in creating a driver to translate the functions that already exist into the hardware's language. I think Teknic's s-Foundation library is much more powerful than that. Just like LinuxCNC itself, it's a LEGO set that makes all kinds of creative new ways of thinking and building a CNC control possible. Relative to the example I mentioned in my original post regarding on-the-fly resolution switching for G0/G1 moves, I have gotten a sense that step generation speed can be a limitation for LinuxCNC builds where high resolution encoders are used, as some servos have 10k+ counts per revolution, and the new AC Clearpath servos have a 64,000 line (16,000 quadrature counts) encoder. A smoothstepper running Mach3/4 can output 5Mhz steps on all channels, so plenty to drive one of these motors at its' maximum speed (2400 rpm rated speed, 32,000 cpr programmable resolution = 1.28MHz). Some servos have even higher encoder densities. And I'm sure there exists a LinuxCNC compatible motion controller with similar abilities to the smoothstepper. That's not the point. It's only one example of something that could be done with a C++ API directly to the servo drive. Besides, I'm sure that running NEMA 56/143 frame 8hp servos isn't really in the cards for many LinuxCNC users, since it takes a pretty good size machine to need that kind of power, but as new technologies and capabilities emerge, some of the "traditional" ways of doing things seem less helpful than they used to be. Especially when you consider that Teknic is now offering a mass produced 8hp (peak, 4hp cont.) digital servo with integrated drive and controller, that can be directly powered by 1ph 230V AC for under $1,400. Why would you even WANT to mess with trying to tune and synchronize an analog PID loop when a large automation company provides a very economical drive system with a very good auto-tuner and logic that handles changing inertia loads and feedforward gains on the fly?
I do understand that there's a certain group of people who will always want low level control, and like tinkering with the small details. Maybe that's the crowd that the developers and community of LinuxCNC want to cater to. If so, I get it, no worries. But at the same time, I myself, am looking for a platform upon which to build and try out new things, not just copy what everyone else has done before only with a different off-brand servo. So I'm trying to explore what's possible, and maybe more importantly, what's possible NOW that wasn't available just 6 months or a year ago. Like EtherCAT. Superb concept, though from what I have researched so far its usefulness for CNC seems fairly limited and not easy to implement. On the other hand, Clearpath-SC looks like it would be super easy to implement and customize for all kinds of great things.
Please Log in or Create an account to join the conversation.
19 Dec 2017 11:00 #103336
by cmorley
Replied by cmorley on topic Teknic Clearpath-SC and LinuxCNC
Using a external box (whether a motion controller or a really smart servo drive) to do motion control is not what linuxcnc is about.
linuxcnc at it's heart is a motion controller project.
The number one advantage of not using an external motion controller is that you don't get locked into any one piece of hardware to get specific motion capabilities.
Unfortunately work on the trajectory planner requires a huge investment in time and experience - so it tends not to get much forward development. (In fact just documenting it would be a difficult but super useful project IMHO)
I guess that would be the disadvantage.
Now having a smart drive that leaves the trajectory planning to linuxcnc is a good fit.
People have certainly used linuxcnc to do just as you are thinking but linuxcnc as a project has not.
I don't know the actual numbers but Mesa/pico equipment have a pretty darn high step generation capabilities.
Chris M
linuxcnc at it's heart is a motion controller project.
The number one advantage of not using an external motion controller is that you don't get locked into any one piece of hardware to get specific motion capabilities.
Unfortunately work on the trajectory planner requires a huge investment in time and experience - so it tends not to get much forward development. (In fact just documenting it would be a difficult but super useful project IMHO)
I guess that would be the disadvantage.
Now having a smart drive that leaves the trajectory planning to linuxcnc is a good fit.
People have certainly used linuxcnc to do just as you are thinking but linuxcnc as a project has not.
I don't know the actual numbers but Mesa/pico equipment have a pretty darn high step generation capabilities.
Chris M
Please Log in or Create an account to join the conversation.
19 Dec 2017 11:45 #103337
by andypugh
Replied by andypugh on topic Teknic Clearpath-SC and LinuxCNC
I only really mention thay because i managed to blow mine up twice that way. Once due to a very badly designed power supply, and then just plain carelessness. You don't normally need to connect to the HV board with USB (only for firmware flashing, typically a one-time thing with the HV side)IThe USB grounding issue looks like a bit of a thorn in the side.
My goal in mentioning it was to give some insight into what a relatively smart drive can bring to a LinuxCNC system. The goal of the designers is to have an Open and inexpensive drive. You can build one for about $100. And it does anything you can do with a commercial drive because you have access to the software and can write your own add-ins if you need to.I'm curious, what are the goals of this drive? What is it intended to do that isn't available already from existing commercial / industrial suppliers?
We are straying off the point here, but if you plug an STMBL in to a Mesa card then as if by magic the following HAL pins appear.7 float OUT 0 hm2_5i25.0.stbl.0.0.current 7 bit IN FALSE hm2_5i25.0.stbl.0.0.enable 7 bit OUT FALSE hm2_5i25.0.stbl.0.0.fault 7 bit OUT FALSE hm2_5i25.0.stbl.0.0.fault-not 7 bit I/O FALSE hm2_5i25.0.stbl.0.0.index_enable 7 bit I/O FALSE hm2_5i25.0.stbl.0.0.index_enable-not 7 bit OUT FALSE hm2_5i25.0.stbl.0.0.input_pins-00 7 bit OUT FALSE hm2_5i25.0.stbl.0.0.input_pins-00-not 7 bit OUT FALSE hm2_5i25.0.stbl.0.0.input_pins-01 7 bit OUT FALSE hm2_5i25.0.stbl.0.0.input_pins-01-not 7 bit OUT FALSE hm2_5i25.0.stbl.0.0.input_pins-02 7 bit OUT FALSE hm2_5i25.0.stbl.0.0.input_pins-02-not 7 bit OUT FALSE hm2_5i25.0.stbl.0.0.input_pins-03 7 bit OUT FALSE hm2_5i25.0.stbl.0.0.input_pins-03-not 7 bit IN FALSE hm2_5i25.0.stbl.0.0.output_pins-00 7 bit IN FALSE hm2_5i25.0.stbl.0.0.output_pins-01 7 bit IN FALSE hm2_5i25.0.stbl.0.0.output_pins-02 7 bit IN FALSE hm2_5i25.0.stbl.0.0.output_pins-03 7 float IN 0 hm2_5i25.0.stbl.0.0.pos_cmd 7 float OUT 0 hm2_5i25.0.stbl.0.0.pos_fb 7 float IN 0 hm2_5i25.0.stbl.0.0.vel_cmd 7 float OUT 0 hm2_5i25.0.stbl.0.0.vel_fb
And all you need to do to make that work with LinuxCNC is:net x-cmd axis.0.motor-position-cmd => hm2_5i25.0.stbl.0.0.pos_cmd net x-vel axis.0.motor-vel-cmd => hm2_5i25.0.stbl.0.0.vel_cmd net x-fb axis.0.motor-position-fb <= hm2_5i25.0.stbl.0.0.pos_fb
I don't think it makes any sense at all to use step/dir if you have a real-time serial link.I admit to not knowing a lot of the technical details, so forgive me if I miss some things. In this case, I'm not sure at what level a driver would integrate into the bigger picture. I'm not thinking of the problem in terms of STEP/DIR v RS232, but rather, how can BOTH be utilized simultaneously to gain more capability and flexibility from the motors and drives.
This all becomes irrelevant if command and feedback are transmitted digitally.In fact, I'm not even really all that interested in creating a driver to translate the functions that already exist into the hardware's language. I think Teknic's s-Foundation library is much more powerful than that. Just like LinuxCNC itself, it's a LEGO set that makes all kinds of creative new ways of thinking and building a CNC control possible. Relative to the example I mentioned in my original post regarding on-the-fly resolution switching for G0/G1 moves, I have gotten a sense that step generation speed can be a limitation for LinuxCNC builds where high resolution encoders are used, as some servos have 10k+ counts per revolution, and the new AC Clearpath servos have a 64,000 line (16,000 quadrature counts) encoder.
Yes, and that will work very well if you want the servo drives to be your motion planner. But each individual drive will not know where the other is, so coordinated motion won't work. Imagine attempting to make a circle in X,Y. The start and end points are the same, so you can't tell the motors just to go there. Something needs to send both X and Y a set of target points around the perimiter of the circle. This is where LinuxCNC (or some other motion planner that can "see" both drives) comes in.It's only one example of something that could be done with a C++ API directly to the servo drive. .
The API you talk about can do this, but it won't be able to do it in realtime. LinuxCNC can do it in realtime, but (probably) won't be able to use the API due to the requirement that realtime code calls need to be to thread-safe, non-blocking functions. And in the case of RTAI they also need to be kernel modules, and those have to be written in C.
But, a HAL driver to take the axis.N.motor-position-cmd values and pass them to the drivers on serial? That sounds pretty simple.
Please Log in or Create an account to join the conversation.
19 Dec 2017 11:49 #103338
by andypugh
One argument against this is that LinuxCNC knows more about the trajectory than the drive does, including the required velocity, so can use velocity feedforward in the PID. And also that you can see what the PID is doing.
STMBL turns this on its head a bit, because you can see the PID, and the digital interface means that you can transmit velocity as well as position straight to the drive from HAL. So you can have a PID position controller running much faster and much "closer" to the motor.
Replied by andypugh on topic Teknic Clearpath-SC and LinuxCNC
Now having a smart drive that leaves the trajectory planning to linuxcnc is a good fit.
One argument against this is that LinuxCNC knows more about the trajectory than the drive does, including the required velocity, so can use velocity feedforward in the PID. And also that you can see what the PID is doing.
STMBL turns this on its head a bit, because you can see the PID, and the digital interface means that you can transmit velocity as well as position straight to the drive from HAL. So you can have a PID position controller running much faster and much "closer" to the motor.
I think it depends on the card, but is about 10MHz,I don't know the actual numbers but Mesa/pico equipment have a pretty darn high step generation capabilities.
Please Log in or Create an account to join the conversation.
19 Dec 2017 22:02 #103365
by cmorley
This sounds like a digital velocity drive.
Oh I see - no PID required at all on the linuxcnc side - all PID tuning is in the drive.
Still leaves the trajectory planning (motion planning if you prefer) to linuxcnc.
(I bet those clearpath servos could do that too.)
That does sound very cool.
I like the idea that is can control very different motors too.
I guess as a project linuxcnc could support external motion controllers as well as linuxcnc motion control.
But then linuxcnc turns into a GUI for loading a motion controller.
As I said earlier... It's not really what the linuxcnc project is about.
Chris M
Replied by cmorley on topic Teknic Clearpath-SC and LinuxCNC
Now having a smart drive that leaves the trajectory planning to linuxcnc is a good fit.
One argument against this is that LinuxCNC knows more about the trajectory than the drive does, including the required velocity, so can use velocity feedforward in the PID. And also that you can see what the PID is doing.
STMBL turns this on its head a bit, because you can see the PID, and the digital interface means that you can transmit velocity as well as position straight to the drive from HAL. So you can have a PID position controller running much faster and much "closer" to the motor.
This sounds like a digital velocity drive.
Oh I see - no PID required at all on the linuxcnc side - all PID tuning is in the drive.
Still leaves the trajectory planning (motion planning if you prefer) to linuxcnc.
(I bet those clearpath servos could do that too.)
That does sound very cool.
I like the idea that is can control very different motors too.
I guess as a project linuxcnc could support external motion controllers as well as linuxcnc motion control.
But then linuxcnc turns into a GUI for loading a motion controller.
As I said earlier... It's not really what the linuxcnc project is about.
Chris M
Please Log in or Create an account to join the conversation.
- AardvarkTech
- Offline
- New Member
-
Less
More
- Posts: 4
- Thank you received: 0
20 Dec 2017 02:20 - 20 Dec 2017 02:27 #103372
by AardvarkTech
Replied by AardvarkTech on topic Teknic Clearpath-SC and LinuxCNC
Very good insights. I appreciate learning more about this stuff, and I appreciate the explanations that both ChrisM and Andy have given.
As for motion control, the motion control capabilities of Teknic Meridian and ClearPath-SC drives are really cool. Just search Youtube for Meridian G-Stop Command Tuning(). But as I alluded to above, this feature set is fundamentally designed and purposed for a different application, so probably not all that useful for CNC contouring, but may be VERY useful for things like tool magazines, tool changers, pallet changers, tailstocks, parts loaders, and other ancillary functions of a CNC that need motion control, even complex pre-determined coordinated motion, but don't necessarily need arbitrary multi-axis path following. For the tool path however, what I had envisioned is that LinuxCNC would be in full control of trajectory planning, while the Teknic software would do the servo tuning (initial auto-tune for each axis). Then the optimal tuning parameters could be fed BACK into LinuxCNC such that the trajectory planner could have an optimal picture of the capabilities of each axis, with the result being a motion profile that makes much better use of the acceleration, jerk, and jerk derivative characteristics of each motor/axis combination than any human could manually tune for. The reason is this: At the heart of Teknic's drive technology are some VERY sophisticated servo tuning and feedforward algorithms which are mathematically superior to PID control. As Chris said, re-writing the trajectory planner and changing the servo control algorithms in LinuxCNC is probably a mammoth task, and I'm not suggesting that should be done. At least not now for this purpose. But it might be possible to get some of the BENEFITS of a more advanced motion controller, just by using the more advanced DRIVE, then tweaking the trajectory planner in minor ways to exploit the advantages.
Yes, that is an obstacle. Humbug! Why can't we all just get along and speak one language? Let's go back to Fortran. (I'm kidding. Please don't ban me!)
So besides the low level motion control (steps, PID, trajectory, etc), which is clear can be done in different ways, with mostly similar results, what kinds of things could utilize a smart servo drive (and even its external motion controller) to not replace or duplicate, but extend the capabilities of LinuxCNC in running a whole machine? This is a somewhat more open-ended question, maybe better posted in a different sub-forum, not necessarily limited to Teknic's product, but what are some of the significant limitations of LinuxCNC as a platform right now?
I agree. I could be mistaken, but I don't think the Clearpath-SC supports real-time motion control thru the serial interface in the way it would be needed to drive an externally generated (LinuxCNC) coordinated profile, that's why I suggest still using step/dir as the primary way to cause motion. Fundamentally, what -SC (which has some features in common with Teknic's Meridian line of drive/controllers) is designed for is industrial automation where more flexibility is needed than available from simple point to point motion controllers, but where the total freedom to do anything (like a CNC trajectory planner based on arbitrary G-code) is not necessarily needed. It's kind of a middle ground. As I understand it, coordinated motion profiles can be pre-assigned, then triggered thru software, but true arbitrary path following still uses step/dir. But of course that's only my limited understanding of -SC and sFoundation. It may indeed be able to do much more than I am aware of. That's part of why I posted the original question here... Does anyone have experience with this system, most likely at their day job or in some other context? And does it offer features that are currently unavailable, complex, or difficult to implement and manage within LinuxCNC? That's what I'm mostly getting at, not a replacement for perfectly good functionality, but how can what's already existing be added to, extended, or simplified?I don't think it makes any sense at all to use step/dir if you have a real-time serial link.
As for motion control, the motion control capabilities of Teknic Meridian and ClearPath-SC drives are really cool. Just search Youtube for Meridian G-Stop Command Tuning(). But as I alluded to above, this feature set is fundamentally designed and purposed for a different application, so probably not all that useful for CNC contouring, but may be VERY useful for things like tool magazines, tool changers, pallet changers, tailstocks, parts loaders, and other ancillary functions of a CNC that need motion control, even complex pre-determined coordinated motion, but don't necessarily need arbitrary multi-axis path following. For the tool path however, what I had envisioned is that LinuxCNC would be in full control of trajectory planning, while the Teknic software would do the servo tuning (initial auto-tune for each axis). Then the optimal tuning parameters could be fed BACK into LinuxCNC such that the trajectory planner could have an optimal picture of the capabilities of each axis, with the result being a motion profile that makes much better use of the acceleration, jerk, and jerk derivative characteristics of each motor/axis combination than any human could manually tune for. The reason is this: At the heart of Teknic's drive technology are some VERY sophisticated servo tuning and feedforward algorithms which are mathematically superior to PID control. As Chris said, re-writing the trajectory planner and changing the servo control algorithms in LinuxCNC is probably a mammoth task, and I'm not suggesting that should be done. At least not now for this purpose. But it might be possible to get some of the BENEFITS of a more advanced motion controller, just by using the more advanced DRIVE, then tweaking the trajectory planner in minor ways to exploit the advantages.
And in the case of RTAI they also need to be kernel modules, and those have to be written in C.
Yes, that is an obstacle. Humbug! Why can't we all just get along and speak one language? Let's go back to Fortran. (I'm kidding. Please don't ban me!)
So besides the low level motion control (steps, PID, trajectory, etc), which is clear can be done in different ways, with mostly similar results, what kinds of things could utilize a smart servo drive (and even its external motion controller) to not replace or duplicate, but extend the capabilities of LinuxCNC in running a whole machine? This is a somewhat more open-ended question, maybe better posted in a different sub-forum, not necessarily limited to Teknic's product, but what are some of the significant limitations of LinuxCNC as a platform right now?
Last edit: 20 Dec 2017 02:27 by AardvarkTech. Reason: Fixed a mis-attributed quote, and removed a stupid half-written paragraph that I decided not to include, but got distracted and clicked "Submit" too early.
Please Log in or Create an account to join the conversation.
20 Dec 2017 14:51 #103390
by andypugh
Replied by andypugh on topic Teknic Clearpath-SC and LinuxCNC
If you send the commands on serial in real-time I would very-much expect the drives to respond instantly. I see no reason for them to do anything else.
But you seem to have to register to get the manuals, so I don't know what would be involved.
But you seem to have to register to get the manuals, so I don't know what would be involved.
Please Log in or Create an account to join the conversation.
Time to create page: 0.093 seconds