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  

   

I've looked into the software's options, and an option to switch enable polarity is not listed anywhere. I'll try to switch position on the Switch 5 and keep you posted

What if you ran the updates sequentially from ver2.0, i know Tormach state that you don't need to but my logical thinking is if they up dated the code and firmware as they progressed then possibly by going straight to ver 2.10 could miss out some important upgrades. Has Tormach released a newer USB master key since ver 2.0. Since ver 2.6 ? they have changed their control boards to include a programmable logic device and not use the mesa version. That looks to me where the changes in firmware have taken place but that then begs the question if you had an older 1100 3 machine do the update scan for the mesa card/version and load the appropriate upgrade to the firmware so if you has say the plasma table with the newer control board the update can figure out the difference and load the option that closer matches the machine.

Then it seems to work. Good luck with the steppers.

I have not been able to test it yet, but with a multimeter I have verified that when I change the direction of a motor the DIR pin changes from 0 to 5 volts.

Hi, changed my Config. I get an error with the path from this. But i attached a screenshoot with my folder. 

FileNotFoundError: [Errno 2] Datei oder Verzeichnis nicht gefunden: 'user_tabs/

USER_TABS_PATH = user_tabs/             # REQUIRED Setting for Probe Basic
USER_BUTTONS_PATH = user_buttons/       # REQUIRED Setting for Probe Basic

Yes it is possible did it in the many ways... but only working way for me was that to switch off the EoE master directly on the master...

I did it during ethercat installation ... install everything like a rodw has in his thread and then turn off ethercat master service ... and finally reinstall just ethercat master with right driver what is directly supported my hardware to supress the latency and then disable feature --eoe ...

I can did a terminal command manual if somebody needs them

regards

In old RIO there was error and enable pins that could be enable in configuration file.
In case of some error, lost communication with LinuxCNC or similar there need to be some pin on board that will indicate such event.

Thanks

Has this error message appeared for anyone?
If so, how did you resolve it?
Can you tell me why it appeared?
 

did you get it sorted?