Advanced Search

The EaserCAT 3000 is functional ? Suitable for a basic lathe ?

Looks interesting.

Got the lube pump, hydraulic pump, coolant pump testes and tempeary wired up. And got most of the wires from the spindle motor, transmission,  lube pump, hydraulic pump, coolant pump and the spindle brake wired to DIN terminal.
Also i made a DIN rail in the control cabinet. 
I did also some test on the software.
 

Ahh you see the light! Be sure to read the correct version of the documents for the version you are using. Everything you need to know is there in those docs!

I have a boxford 160 and need to put back the encoder 
does anyone have a picture of how this goes ?    

Hi Rod,

Here is the submakefile that is used for the tpmod_scurve.
This repository uses the original makefile system to compile the scurve. It has no cmake build system.
It's quite straightforward. It can not be made simpler to incorporate into the source.

I also need to stop using google to find linuxcnc docs, rather than having some known-good bookmarks on hand. Not only does google often point to old versions of the docs, it will also take you into the middle of the document. While I'd read most of the page @PCW linked to, I think I'd never even seen the first several sections, with the excellent colorful diagrams. Wish I had!

Detecting the drive pin could also cause parameter tracking issues if an anomaly happens.

Maybe detecting pocket pins on each index and a homing pin is better.
And just make the motor stop with a slight delay, so the geneva drive fully engages.

By e.g using M65 P4 Qxx in subroutines.

Grotius wrote:

Hi Rod,

You mean adding the cmake project into the original makelists.txt file and build it from there is the way to go?
I did not test that option.
 

I don't know anything about make or cmake but yes, just use cmake for the emc/src/planner folder. 
I noticed that Linuxcnc uses submake files for each folder in src/emc but you don't seem to do that.
Also because you mention motmod.so and liblinuxcnchal.so I assume you have modified the code in other modules. If that is the case, is there a way that planner can specify what it needs to use at run time so these modules can be used with both tpmod and planner?

It would be so cool to incorporate this into the base code and if it is modular as the original designers of Linuxcnc intended, it wont break anything existing.. and  it becomes available to everybody.

Thank you both. I'm certain you're right: Home is set to 0. So if I switch to homing at the 12,12 corner, and change HOME to 12 for both X and Y, it will almost certainly do what I want. INI file attached, in any case.   If HOME had been grouped with the other HOME_* variables, I might have noticed. 

I used Argon drives on a retrofit, they are very good and have nice software for setting them up, good documentation too.
You do need a dongle though, and the comms between dongle and drive have a hard coded speed that can not be changed, so might have issues. Use good USB cable.

Meanwhile i found a driver that could fit my needs but i'm too late .The Argon Drive made by  Granite Devices can do step/dir and Analog+-10V but sadly is no longer in production.
I guess i will have to wait til next month and see what Leadshine come up with ,assuming the technician i talked to did not bullshit me.

About the Index sensor - Pocket sensor vs drive wheel sensor
This could be a design issue, but if I look at my geneva mechanism I think for indexing ideally you would want to detect the pin on the geneva drive wheel, so the drive wheel is fully locked in the geneva wheel.

If you detect just a pocket pin, the drive motor and drive pin will stop at the disengagement position of the pin, where the lobe takes over.
 

If I detect the drive pin on the drive wheel, it would allow for more error margin as the lobe is fully engaged.
But this would require both the index sensor and homing sensor to be high to complete initial homing.
Otherwise the first index move after homing could be false, depending on the direction.
 

What is the usual way to do this?
If I check the subroutines the M13 homing cycle is not considering the index sensor, only the homing sensor.

Maybe bind Index sensor to the Homing sensor input signal in HAL using AND2 ?