Teknic Clearpath-SC and LinuxCNC

I have an account. I tried to upload one of the manuals just now but the site said that it's 6.5MB file size exceeded the maximum.

Where would be a good place to post it and link to it?

Hi Mike

I'm an applications engineer for Teknic. You've brought up several good points and I wanted to provide some additional information direct from the manufacturer.

You asked: "I'm curious to know how difficult it would be to integrate the -SC functionality into LinuxCNC."
Honestly, this is not an easy question to answer. The effort needed to integrate the ClearPath SC motors with LinuxCNC is based on the specific objectives for your application and your familiarity with LinuxCNC and C++ (Teknic’s software library). The “sFoundation” software library and API (application programming interface) for the ClearPath-SC family is written entirely in C++ and is designed for portability across different operating systems. All of the source code is available for download directly from our website. Many customers use our libraries on Linux based computers and since most Linux code is developed in C/C++, I'd say the odds are good for compatibility between LinuxCNC and ClearPath SC.

The specific use case you describe in your post is appropriate and is actually why we elected to continue step/dir support with this new ClearPath-SC family. ClearPath step/dir motors are frequently used in the CNC industry so we kept the step/dir inputs but added the ability to simultaneously talk to the motors for status information & other features.

So what can you do with this software interface from something like Linux-CNC?

* In the case of limited step output rates, you can change the motor’s input resolution (steps/rev) and this would give you higher resolution when cutting slow and then lower resolution for the higher speed rapids. Naturally, the code would have to keep track of these resolution differences.

* You can read several motion status variables such as position error, RMS torque and other motion variables to help diagnose problems within machine mechanics. It can be quite powerful but you do have to be careful to not get overwhelmed with this data.

* The C++ library has a built-in function to load motor configuration files. This is, admittedly, more oriented for high volume OEM machine builders.

* You can read the measured position of the motor’s internal encoder after you disable the motor (an operator may elect to manually move the head while motors are disabled) – this enables position recovery without rehoming. Using the “Power-Hub” main power distribution board provides logic power backup – you get similar position recovery functionality after removing main hazardous power from the servo motors (e.g., a door interlock or safety barrier).

* The software library within CPM-SC handles point-to-point moves well, so you can use the software protocol directly for things like a tool changer or a part loading/unloading option (this might be handy if you don’t want to use up one of Linux-CNC’s step/dir axes).

* The new, larger NEMA56/143 ClearPath motors could be used in a spindle application (and you can switch between positioning and velocity modes) but keep in mind that the top speed of these NEMA56 ClearPath motors is about 2,500 rpm.

Finally, there were some question(s) regarding RS232 / serial communications. A cutting machine can be a very electrically noisy environment (spindles, water pressure pumps, plasma, etc.). ClearPath’s communications channel is optically isolated and has high noise immunity. The SC4-HUB board is specifically designed to condition the serial (or USB) signals for use with this communication channel. We also recently benchmarked CPM-SC with a Linux-based BeagleBone Black single board computer using a local UART and achieved over 1,000 commands per second.

So there are some interesting possibilities here, but you would need to be familiar with C++ to interface our libraries to the Linux-CNC program. We’d certainly help answer any technical questions regarding our library.

Please contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. if you have any further questions. Thank you for your post.
-Abe A.

Hi Andy - sorry for the delay in getting back to this post.
The C++ class library is thread safe and was written on top of the original C function library. We also include all of the source for the lower level C function library.
The serial protocol is open and available but you would have to derive the protocol from the source code documentation (in other words, the protocol documentation is all detailed within the source code).
Hope this helps, let me know if you need any other information - thanks.

Hi,

I am running ClearPath SK NEMA34 motors on my X Y Z A axis using the MESA ethernet IO board for step and direction. I have found them to be really good and never needed position feedback as they follow the step dir pules 100%.

I am currently looking at writing a new homing routine, so that whenever the machine enable is pressed, then the motor enable line starts the hard stop homing sequence with 10% torque, ( extremely repeatable positioning ) and when the HLFB line goes high, I know homing has been complete so then continue to enable the machine and set all axis as homed and zero machine co-ords.

Can anyone suggest the best place to do this ?

Should I modify the existing lowlevel homing code in C to cater for hard homing and add some extra ini file parameters as required, this would be more general I suspect ? I would submit to ?

The other way would be to connect to the motor via serial as described above and call for homing when needed, ( probably still need to modify C routine).

Could this be done with HAL file configuration ?

Also want to hook into the enable function to automatically home axis when machine enable ( with the Clearpath set to always home on enable this happen now ), but have to manually then go and set all axis as homed.

Any feed / idea would be much appreciated.

Hi soehlrich,

I am an applications engineer at Teknic Since you are referring to the HLFB (high level feedback) from the motor, you are probably using an SDSK motor as opposed to an SC series motor which has been discussed earlier in this thread. The SD family provides feedback via HLFB. The SC family provides feedback using C++ application code.

Both the SD and SC ClearPath motors are capable of automatically homing to a hardstop. However with the SDSK motors, the completion of the hardstop home can be verified using the ASG (All Systems Go) option for the HLFB signal. The signal will go to a high I/O state when the move is completed.

That being said, I am not versed in the LinuxCNC code so I can’t comment on the easiest way to accomplish the “homing complete” function for your machine. Perhaps someone on this forum will have more specific LinuxCNC suggestions.

You mentioned that the machine enable is connected to the enable inputs on the motor. It may be easier to implement homing in LinuxCNC if you connect the enable inputs of the motor to the general purpose I/O on your MESA board. This will let you programmatically enable and disable the motors through LinuxCNC. This will allow you to control exactly when the motors begin homing as opposed to the motors starting to home as soon as you enable the machine.

If you have any questions regarding the function or operation of the ClearPath motors, you can send an inquiry to This email address is being protected from spambots. You need JavaScript enabled to view it..

Best regards,
Tom T.

Personally, I would feel much more comfortable allowing Linuxcnc to control the homing routine in a conventional way, using home or limit switches. Because I can easily imagine situations where having the drive automatically move to home on drive enable, could cause serious problems.

If you think you must let the drive handle it with hardstop homing. I think the way to try this is to use the rising edge of the HLFB (using an edge hal component) to trigger the home switch input axis.N.home-sw-in. I would still make Linuxcnc initiate the homing routine, and require homing after the drive is disabled. Configure the homing routine in Linuxcnc to use a homing sequence simular to the 1st homing sequence example in the manual here.
linuxcnc.org/docs/html/config/ini-homing.html
Configure the drive's homing to "User seeks home; Hardstop detection enabled".

It is a bit of a shame that the drive doesn't have a couple more inputs to use for sending a homing signal or limit input when used as step/dir devices.

PS I think I would also try to use the falling edge of the HLFB as a drive fault signal.

EDIT: Todd, upon reading your response again more carefully and thinking through the scenario again, I think my comments below are less relevant, probably redundant. I don't know how difficult it would be to mitigate any problems associated with auto home seeking upon enable, but upon further reflection, there's probably no point in even discussing the "First" vs "Every" enable homing, because of the lack of feedback to the controller. So... I basically withdraw what I said below, except for the general idea of "don't make things more complicated unless necessary". /END EDIT

Personally, I would feel much more comfortable allowing Linuxcnc to control the homing routine in a conventional way, using home or limit switches. Because I can easily imagine situations where having the drive automatically move to home on drive enable, could cause serious problems.

I'm not personally a fan of hard stop homing, but many have used it with great success. In any case, you don't have to re-home the motors every time they're enabled. There's a setting in the software that you can select between homing on EVERY Enable, or only FIRST Enable after Power On. If you used the power distribution hub (which includes logic backup power), then you can still cut off DC bus power for, say, E-stop or manual operation, and the encoders will retain their position. This is pointless for the -SD motors because the controller can't read the encoder position, so those need to be re-homed every enable.

As far as integration into LinuxCNC goes (if you did hard homing), it's easy enough to assert the enable signal for only one axis at a time, then use HLFB to see that the homing is complete. There's no reason at all to be more complicated. You just need to set things up within LinuxCNC so the drive isn't enabled until you WANT to home the machine. Then, (assuming you're using -SC motors), the homing only needs to be done once per power-on.

Of course, you CAN add cost and complexity by doing things the traditional way, but why? Don't make it more complicated (and expensive) than it needs to be just because you can. Only make a system more complicated if there is a real requirement (enhanced precision, safety, etc).

If you are going the SC route, you are talking about using a real time serial link to the drives. With that the driver for Linuxcnc (which someone has yet to build, if it even can be done) could easily communicate with the drive, when to home, and be told when homing is complete, as well as communicating all the nessisary position info.

So until you have a working Linuxcnc driver (aka real time hal component) for an SC, you are stuck with doing it the SD way, and the simplest way there is to treat it like an ordinary step-motor.

Hi!
Longtime lurker here, Linuxcnc is awesome. I didn't see this post when I started out on my machine build last year, but I had a very similar plan: Use 4 SC motors with linuxcnc, add in more motors & controls using Mesa cards. I figured it'd just be a quick bit of C/C++ to connect the Teknic motors up and away we go. heh.... I'm posting this here and maybe it'll be useful to somebody who was curious about this as well.

I had trouble getting any realtime driver to compile with added libraries (using gcc/g++, works fine with halcompile but that's a different post I guess, this is about Teknic). I haven't given up but I needed my machine up and running and wanted to know if the serial connection would even be fast enough to do motion control or if I'd have to switch to step-dir. (spoiler: Definitely had to switch to step-dir, not worth it to make a real time module.)

I made a userspace Hal module that communicates to the SC-Hub with 4 motors, compiling the Teknic S-Foundation code into a library that is then included and called from the hal module.

The SC-Hub ExarKernel Driver source code was a bit of a trick to compile for me 'cause it doesn't come with a makefile, only an eclipse 4.x+ project... I didn't manage to get eclipse 4 on linuxcnc (maybe I'm just apt-getting the wrong thing? Probably. Whatever though...) I opened the project and generated the makefile on another machine and that worked. Teknic might want to include a makefile in the future, I'm sure it'd save lots of people lots of time.

I'd love to hear how the Teknic team got the 1k commands per second, (mentioned earlier in this thread) I was only able to hit about 300/sec. And I needed at a minimum to get position and set velocity for each motor. I found with each command taking ~3msec and 4 motors and 2 commands per motor - around 24msec and no way to parallel-ize it (yes could use a serial port per motor, was trying to avoid adding extra cards and ports.) Even 1k commands/sec might not be fast enough for a servo thread because you've got multiple motors.

That said, having the ability to watch torque, following error, reset motor faults, and other Teknic motor parameters should be useful, but not something that couldn't just be done with some current monitors and or encoders on a normal motors setup.

As said earlier in this thread: linuxCNC is not a front-end for a motion controller, it can integrate a bunch of different drives and motors relatively quickly and smoothly. Though Teknic motors can execute coordinated motion with eachother, they wouldn't really be able to coordinate with Linuxcnc controlled motors at a meaningful rate. Long live step and direction!

Also STMBL (mentioned earlier in this thread) looks awesome.

A quick word on integrating the SC motors using step and direction and a SC hub: There is no example in the Teknic manual of how to use an SC hub with step and direction signals, but the manual does show the A+ and B+ teknic inputs tied to 24v on the sc-hub card. If you don't want to melt down your step-dir drivers. *oops... *sigh... cut the jumpers on the SC-Hub board and then you can use the A+ and B+ signals with a normal step-dir driver. That or make your own cable that breaks out the A+/A- signals from the Teknic motor control cable before it hits the SC hub board.

TLDR: Teknic SC motors need step and direction to work with Linux CNC. It's possible to communicate with the motors and integrate the S-Found library into HAL.

Anyway, hope this is helpful to someone and not taking this thread off topic.

Cheers!