[dharmic]

Kudos to someone who can park their ego long enough to recognise and admit to themselves (noone else really matters) that they've been caught up by their own brain. Chill, or better: laugh, man. We are funny critters and we're wired weird.

Chuckles aside - you (and now I, thanks again!) are up and running with our freshly dialled in 4th axes, so I'm gonna count this one a win

[islaww]

I have been able to successfully integrate a laser fork sensor as a "no touch" probe. Although this example is on a wood lathe, the same exact principle would apply to a metal lathe. I used the "Digitizing Bundle" option available with the Centroid Acorn and take the digital point output via a Vectric gadget and direct import into VCarve Pro software.

Here is a peek:


Similar videos on my YouTube page: https://www.youtube.com/user/Islaww1/videos

[ubergeekseven]

I have been able to successfully integrate a laser fork sensor as a "no touch" probe. Although this example is on a wood lathe, the same exact principle would apply to a metal lathe. I used the "Digitizing Bundle" option available with the Centroid Acorn and take the digital point output via a Vectric gadget and direct import into VCarve Pro software.

Here is a peek: https://www.youtube.com/watch?v=C7b7He0mtxk

Similar videos on my YouTube page: https://www.youtube.com/user/Islaww1/videos

That's pretty nifty. Fast too.

Sent from my SM-N950U using Tapatalk

[ubergeekseven]

So, I started a new post for this issue and have an active post on the Fusion 360 forum as well as the warp9 forum for my motor controller and some issues I have with my rotary axis speed when doing wrapped jobs.
I use both Aspire and Fusion 360. WIth Fusion 360 I have been playing around with mixing wrapped and indexed toolpaths so that I can cut planar and wrapped output. All works well until a retract and movement to the next cutting position occurs. My A-Axis is a 100:1 reduction and the movements during retract-positioning for the next cut are insanely slow. The cutting is as I expect though. If the x-axis needs to move 15 inches from the current position and 340 degrees on the a-axis at a feedrate of 100, the a-axis moves at 100 degrees per minute and then takes 3 minutes 40 seconds to get to the next position. Then the cut take a couple seconds and repeat.

Do you experience the same limitation on the rotary axis that I am? What CAM software are you using if you are not getting this sort of issue?

[dharmic]

Fusion/Mach3

No such issue. Check your max speeds, your steps per unit (degree), your mach3 radius compensation and if all of that is sane maybe have a look at a simple toolpath as generated and see what the feedrates are on the G00 / G01 A moves.

[ubergeekseven]

I had a feeling you would not have issues. My radius is set as 0.0001 as suggested by many people. Do you enter the actual radius each time? The movements are fine with G00 /G01 moves. I have the a-axis tuned to just below missing steps. It is as fast as possible. Everything works great until repositioning. Adaptive 2d toolpaths are the issue so far. Thanks for your info though.

[dharmic]

Time to check your POST configuration in 360 then. Crank out a simple wrapped slot and see what the G-code looks like, then work from there.

[ubergeekseven]

yeah, I am working with a post processor guy from fusion right now to try and figure it out. It has something to do with the G94 moves.The Warp9 ESS controller people suggested using Mach4. Tried the demo simulation with the same results. It is definitely a post issue. I will keep at it.

[ubergeekseven]

i just wanted to add the information that I actually use now. Looking back in this post, I never posted what I figured out.
open config -- toolpath

Make sure that “A-Rotations Enabled” and “Use Radius for Feedrate” are both checked

[ubergeekseven]

Thanks again for this probing macro. I have been using it again lately and sometimes I have some weird issues. half the time I run it, when it goes to probe the z0, it will do it fine and then instead of just moving up at the end, it will press down and then move up. I tried this several times and it does not happen every time. As long as no steps are missed, it will be centered on the xyz0 location.
It is a bit worrying and I have had it happen coming from north to touch off as well. super weird that it does not happen all of the time either.

that being said, it is super helpful during setup. One question I have is about the distance to move to start the probing in each location. I assume that in the macro code, the line with
north = Approach(1, -5*rodRadius, fast, slow)
the -5 or 5 in the positive direction is a distance. If i assume 5 is inches, multiply that by my rod radius which is 0.125 the distance should be 0.625.
I am guessing that the 5 is in whatever measurement is set up, in or mm. is that correct? I am asking because the distance is actually greater than the 0.625 calculated in real life.

basically I am trying to reduce the distance it moves because the slow movement I set is great for fine tocuh off but from that distance it takes 30 seconds or so before it touches. The first jump to north seems to position pretty close to the rod and then it backs off for the slow touch and is much farther away than the first positioning. All the rest of the moves are the farther distance and only that first north to south move is close to the rod. Any suggestion on this?