Advanced Search

O.M.G.

I just watched your video.  @Aciera was right, as usual.

What you are pointing at is the tool path, not the pawn.  I've circled the 'pawn' in red.  What you are pointing at and claiming is the 'base' is, in fact the pawn's head after the cuts are made.

White = tool path (are tool will cut)
Black = pawn after material is removed

This still doesn't explain why positive SEARCH_VEL moves left during homing but we can circle back to that.

 

One other thing about a supported rotary set up is if you have a stock width that will fit the bore of your set up you can reduce you cutting distance compared to cutting from plate. when you look at things like duty cycle that's a big plus when your cutting @ 60% duty. On top you don't have to wear your slats down either, so you reduce your operating cost. so, it makes sense on small parts to keep this in mind.

when you get to a point where you are processing a lot of sheets the skeletons of the sheet add up to quite a bit of wasted material. this is just something you notice if you are around it all the time. i know time is money and that's why it happens but looking for savings can't be forgotten about at the same time.

Hi.

One question:

The actual master , can compile on Debian 10 ?

I'd be willing to test this out and provide some data. I currently use the BCL-AMP setup with QTPlasmac and while it works, it could definitely be faster in its tracking. The sensor outputs the nonlinear signal which is also noisy. After filtering (hardware and software), it works, however I feel as though it is not sensitive enough now due to being averaged and filtered so much that any abrupt changes in height will cause the nozzle to touch.

A cleaner, linear response signal could be the ticket, as I have fiddled with the PID parameters quite a bit as well as my Z axis velocities and accelerations and it is still not really where I'd like it to be.

Let me know how I can be of help.

Thank you for the tip.  I'll have a look this evening at index-enable.

If it makes any difference, I'm not using orient.comp for the main spindle... although I am using orient for the sub-spindle.

Main spindle is using caxis.comp but there aren't any references to index-enable in it other than a "//detect index-reset" statement.

If it is an index-enable issue, I wonder what would cause it to stay high?

Relevant HAL section for what it's worth:
# INDEX-ENABLE
net SPIN0-INDEX-ENABLE      <=> hm2_[MESA](BOARD).0.encoder.04.index-enable
net SPIN0-INDEX-ENABLE      <=> spindle.0.index-enable
net SPIN0-INDEX-ENABLE      <=> joint.2.index-enable
net SPIN0-INDEX-ENABLE      <=> pid.s0.index-enable
net SPIN0-INDEX-ENABLE      <=> pid.c.index-enable
 

Can you post the g-code file as well as your HAL?

I'm not quite ready to suggest you call in a priest.

You could sure make all of this SO much easier by simply providing the basic information you have been asked for.

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