Advanced Search

with a run in place installation like yours you should be able to modify any kinematic file.

Hi.
For testing , is can modification trivkins kinematics for it , or is complicated.

Thanks

I had a similar issue on one of my milling machines where I used a modified version of orient.comp.

At the time,not sure about latest version, orient.comp did not check the spindle encoder index each time it is enabled. I modified it so that it does, but at first I made a mistake that caused my modified comp to set the index enable pin for the spindle encoder all the time. This caused the same behaviour as described by you.

Check your index-enable pin while rigid tapping. It should go true and then false when the index is detected, the stay false until you initiate the next tapping cycle

Henk

Jog button is the virtual button on axis. 
Looking down on the lathe from the top view in fusion. Tip is facing up. Tool can face and turn. Tool path is facing.


Iv just noticed something also what could be causing all of this my linuxcnc version is 2.10. That's not fully released yet.

Edit, 
I read that link you posted ,that's very handy. But looks like I had everything setup right so it's not not either lol
 

I fixed it!

Though it turns out it is actually a metric machine (leadscrew moves axis in millimetres).

I originally set the home X switch to "Home X / X minimum limit", but it was annoying and gave me an error while homing.

It is not set to "Home X".

If the machine surpasses the Home switch, it will run off the rail.

Is it okay to set it as just "Home X"?

Murphy wrote:

When I loaded the linuxcnc pawn it came in as the earlier post , inverted When I made a model in fusion , it did the same thing. Messing around with fusion could it be something I'm doing wrong in fusion. The first pic is the tool orientation which looks wrong but it comes up correct in the tool path pic 2. Pic 3 is the tool orientation which I think is correct , but tool is wrong once in tool path , pic 4 

 

Ok, starting to make a little more sense - you're getting bitten by F360's tool orientation mess and the actual program you loaded may be wrong, not your lathe.

The actual tool you plan to use looks like what?  Insert facing up (as you're looking down on lathe), tip towards centerline, and main cutting edge to left?  Or insert facing down?

EDIT -
Based on your screenshots, I think you've maybe got the spindle rotation wrong, which is why the tool appears to be reaching across the part centerline.

Here's a good explanation of tool orientation and how F360 spindle direction affects the toolpath and tool orientation display:
mgfx.co.za/blog/engineering-manufacturin...-cutting-directions/

Yes, jog- to left, and jog+ to right is correct.

But a positive SEARCH_VEL moving left (Z-) is not right.

Something isn't right.  When you press "jog -" is that a physical button, or on the screen?

Can you post your HAL file? 

When I loaded the linuxcnc pawn it came in as the earlier post , inverted When I made a model in fusion , it did the same thing. Messing around with fusion could it be something I'm doing wrong in fusion. The first pic is the tool orientation which looks wrong but it comes up correct in the tool path pic 2. Pic 3 is the tool orientation which I think is correct , but tool is wrong once in tool path , pic 4 

langdons wrote:

LinuxCNC should have some auto config option where you just let it run and it figures out where the home switchs are and everything.

To be able to do that for any of the huge variety of machines that LinuxCNC can control, it would require the software to be SENTIENT!!!
Nothing humanity can create can do that the way you think.
Try AI
-
Off topic:
AI = absolutely not artificial intelligence, not in the slightest, just the name being misused.
Same with:
Calling a liquid "GAS"
Calling "football" a sport that does not use feet.
Etc, etc.

Thanks, So in Z with scale being positive. Z moves by pressing the - jog moves towards spindle (+) jog moves away from spindle. (Which is correct) Search Vel is 15(+) but still searches left(-) towards the spindle. If I but ser Vel to negotiate it searches away from the spindle.

If I set Z scale to negative . The motor is reversed and when I press jog (-) it  moves away from the spindle.(Reversed)

It seems the machine is working correctly the way it's set. It's when I load a program it's all reversed 

Edit 
I just set the Z offset 150 away from the spindle .but ser Vel had to be a negative value for it to move away from the spindle. Even though my z axis is moving correct when pressing the - and + jog

Yes. It looks the same with my 4 axis machines. Normal tp works with different machine setups without a problem. The scurve tp jumps all over the place! But. Only if a fourth axis (rotary, A) is involved. 3 axis programms without a problem.

Looks also that the axis gui is not really "connected". Preview an tp are working without connection.

Why are you still whinging ?

The settings are in the ini and hal files

Just post them

Another important issue is the jerk and acceleration at the segment junction. 
 
 
 

The coordinated velocity and acceleration values on the TP pins look correct. But the values for each axis individually have instantaneous velocity changes (0xVel to 2xVel) at the segment junction, and acceleration jerks that exceed the limits (over 100K). This looks like a calculation error.

On a polyline path it makes a jolt with a frequency of 10-100ms. 
With this speed signal, the servos and PIDs go crazy and can't work.



And the last less important problem I saw is that on a non-realtime system TPMOD stops working when trying to load a programme larger than ~100-200 lines. Therefore, simulation and testing have to be performed only on a realtime system

I would like to express my gratitude. Thank you very much Grotius for doing a great job despite some problems that can be solved. The linuxcnc tp has been in need of improvement for a long time. 
I can provide all the programs I used for the comparison, maybe it will help to fix the errors.

juliankoenig87 wrote:

 I always set with a P value the maximum allowed deviation of a given path. So now I am not really sure. Can I just calculate something?     
 

Yes. Such smoothing is not optimal. The value of P should certainly be the limit of deviation from the programmed path.

I am also concerned about the compression algorithm that creates polygons if you increase the ‘P’ value. I have prepared a comparison with the old path planner:
 
 

It shows that first the polyline is compressed by an algorithm similar to Douglas-Peucker, then the large lines are connected by a b-spline whose radius of curvature is limited by acceleration.  This creates constant changes in velocity, acceleration and deceleration that are bad for milling. The most important thing for milling is to maintain a stable speed. The optimum solution would be to drive with minimum curvature over the entire trajectory. The last image shows the difference in 3D milling.
 
 

The old planner produces a path with minimal curvature, but it always tends to move inside the curve. A similar effect can be seen in this animation comparing "Moving Average" and "CCMA": 
github.com/UniBwTAS/ccma/raw/master/figures/demo.gif


I also have a problem when the trajectory is plotted with a lot of smoothing errors - it randomly moves far outside the limits:


I can provide all the programs I used for the comparison, maybe it will help to fix the errors. 

LinuxCNC should have some auto config option where you just let it run and it figures out where the home switchs are and everything.

Then, all you would have to do is tweak it so the distances are correct.

In Stepconf, I see a home switch location setting, but no home switch direction setting.

Aren't they sorta the same?

After all, if you know where something is, you know which direction to go to get there.