Advanced Search

yes but why? when i try ref all... it works fine...
i think probe basic ref y do only ref my y1 axis and not my y2...
i have 2 homing sensors for y

Thanks for the feedback. Any tips on creating a pin file for the 7i95t firmware you sent to use in mesaCT?

I wanted to make my own user tab for them. But I’m unclear how to do that, and I’m unsure whether you can use a user tab well while the machine is running in auto. I haven’t tried yet.
I was going to add them to the user buttons. But I’ve used up most of them at this point.
Down the road, I also want to learn some other things. I’m adding pneumatics to my CNC to run some hold-downs, as well as an air blast.
I had the idea to add a pressure gauge to the system so I could set the machine to pause if there was a loss in air pressure, assuming that would cause me to lose a hold-down.

I have a PrintNC CNC router with ER20 manual collet in the spindle. Work area 1200x600x100. I have a tool setter built into the table so the plate is something like 1mm under the table. The position is X1050 Y70. Why is it like that? Because it doesn't get in the way of big slabs that i can left hanging out of the work area.
I can lower the spindle, but it is still more than 100mm above the tool setter, so I cannot 'touch' it like the settings in PB says (that is if I understood it correctly)

I use the free version of Fusion360 and do jobs like making casting molds out of blocks of polyurethane and some small woodworking projects. So small jobs, handful of tools to change. But I need precision and automation. And that's why I need to manually change the tool (because of poor man's manualspindle), but do the measuring of the offset automatically.

My procedure:

1. I have multiple per-operation files of the job or one big file (free Fusion360 doesn't allow that and I'm experimenting with github.com/TimPaterson/Fusion360-Batch-Post)

2. I fasten the stock to the table, put a pointy rod into spindle and set the WCS origin. Or put the first tool of the first operation and do the setting of origin that way - it's precise enough and I don't have to switch tools unnecessarily.

3. Then I start the program. When it runs into tool change it should go as:

3A. move the Z all the way up
3B. move to defined position where is easy for me to change the tool
3C. wait until I change the tool and click on a button
3D. move above the tool setter
3E. move relatively fast to some Z
3F. move slowly until touch of or error
3G. move up a little bit
3H. move extra slow until touch
3I. <do some magic tool offset sh*t so the tip of the tool in G54 Z is the same as previous tool>
3I. move Z all the way up
3J. continue with the job

So far the subroutine tool_touch_off.ngc does most of it or I modified it to behave like that. What was missing is the moving to known location and what I think is an error - that it doesn't set the new tool number. It stays the same. I added the M6 command so it shows the dialog waiting for change. I lavishly stole that from here: wiki.printnc.info/en/controllers/linuxcnc/tool-setter-no-probe

But it still doesn't work the way I need to. Both of these routines. Fusion360 is messing with G43 in a way I don't understand why - it does "G43 Z15. H0" after each tool change, which messes with the macro above and the fix is "remove that from postprocessor" which is a big no-no for me.

I like very much the idea of tool_touch_off.ngc. Especially the way it get's its absolute position by using a relative position but at known absolute Z height. Very clever! But from a quick test the new tool after change ended up again in wrong Z height.

I am determined to make it work because it is imperative to my work. But it sure as hell ain't walk in the cake. Or piece of park for that matter.

Chris,

Yes, your flag arrangement is precisely what I normally do with limit sensors... but I've got a CNC lathe and banging out 18 round pins was a quick solution.

The unintended consequences didn't show up until well after I'd built everything.  Obviously, the square edge and flat surface, presented across the sensor field, is the way to go.

Regarding my earlier comments... I'm sure you'll put together an implementation guide, and including a giant warning about COUNTS mode and open-loop steppers would certainly go a long way to helping users avoid a crash.

Something else to jot down for your guide and modular ATC config: LCNC's (somewhat) recent addition of motion.misc-error.NN HAL component.

Since stepper/servo drives are not axes, the misc-error pins are exactly the right arrangement to permit an ATC drive motor error to trigger an estop event just like a stalled axis motor - especially in COUNTS mode where there's no feedback between the ATC's true position and LCNC.

 

I started to actually do some work but it was short lived but when Christmas and new years gets here i will have a lot more time to build things. But as of now i have a gantry beam and 1500mm rail to mount on it and all the bits to build the Z axis so it a start my lead screw for my Z needs to be cut down to fit the build. 4 start screws are limited in choices for some reason.

but everything is built around 3 inch square aluminum tubing. came across a drop of this for the gantry beam as well. i'm using 12 mm round rails for my Z. also decided to change some things on my floating head concept. after looking at it for a while i seen a better and easier way to do it