Advanced Search

Hello all,

I have my milling machine running and following commands well. However, with a small endmill operating in tight quarters, I have some issues with the tool not following the toolpath exactly, I think there is some overtravel. I did the PID tuning months ago and was able to fine tune it after the machine is safely bolted down.

I rewatched some of RotarySMPs videos on the Schaublin conversion and he mentioned that the analog output voltage has to accurately reflect the speed resolution on the motor. Otherwise the initial voltage signal is not correct and the control has to compensate.

It just occured to me that I never adressed that. I have Linuxcnc configured to limit my travel speed to 5000 mm/min. However, the maximum speed the machine could run from the factory is triple that at 15000mm/min.
So this means the Servos only ever run at up to 1/3 of their full speed.

The way I understand it, when I command a rapid move, the Mesacard wants to give it the full 10V, leading to a really rapid move on the motor, way to fast for what linuxcnc anticipated, and that will cause some issues.

Can I change this in my Hal oder Ini files? I think there is a line with maximum output??
I can´t easily change the parameters in my drives, so I prefer changing this in the config.

No worries at all, it has just become increasingly bad info all over the web, so at least here trying to keep info correct.

Just checked some 15 of my old and new configs, luckily i found one where search is positive and latch is negative (on Z), all others are same direction.

2000N i should have just let you convert it sorry i was going off of memory and should have added the extra 0 thanks for the catch on that.

Excellent to see stuff moving!
The torch voltage seems low but that is just a calibration issue.

Is there a reason why you are not using the qtplasmac config? 
linuxcnc.org/docs/stable/html/plasma/qtplasmac.html
Or did this project start so long ago it didn't exist?

Thank you so much! I figured it out with your comment.

It turns out that for whatever reason, when I set up my .ini file, I had commented out the .var file. I just uncommented it and now everything appears to be working normally. The offsets table is updating as I expect when changing work offset locations.

The littlest issues can be so frustrating when you don't know where to look, yet so easy to fix once you realize how the system works. Thank you again!

You could use this module instead www.aliexpress.com/item/1005004921994099.html
Then you could borrow my existing config for it
github.com/rodw-au/linuxcnc-cia402/blob/...t-conf-diewu.xml#L86

Hi , im new to linuxcnc i have been looking to run linuxcnc via ethernet with w5500 and esp 32 can someone please help , linuxcnc will not toggle e stop

Something sounds odd.
Docs on coordinates are here linuxcnc.org/docs/stable/html/gcode/coordinates.html

I wonder if the .var file is marked read only? This would prevent values from being saved.
Delete it as sometimes it gets stuffed up when setting up a new machine.

If you can't find it, check the file name in use in the ini file eg. for my QTdragon config
PARAMETER_FILE = linuxcnc.var

1. As far as I am aware the 'DIAM' value is for the radius of the tool tip on a lathe tool (ie for radius compensation G41/G42):
linuxcnc.org/docs/stable/html/lathe/lathe-user.html
To my knowledge, the values 'FRONT' 'BACK' 'ORIENT' are only used to change the tool display in the preview window.

2. Retraction of an oriented tool is quite simple:
    
    - stop program execution
    - change to MDI mode and execute 'g68.1'
    - Jog the Z axis in the positive direction

I have modified the sim config and brought the 'TWP' button back to the right hand panel. Clicking on this should now define a TWP at the current tool orientation and position.
(G68.1 X#<_x> Y#<_y> Z#<_z>).

The folder has been updated:
forum.linuxcnc.org/10-advanced-configura...hine?start=50#328156

I did check one of my known good configs with a shared home/limit before my last reply. It uses a negative latch velocity.
github.com/rodw-au/vmnmillqt/blob/main/VMNmillQT.ini#L247
(units are metric)

Latching happens so quickly its hard to see what is going on. Sometimes I've slowed homing velocities right down (to 10% or less) to troubleshoot.

Thanks for you Replay.   
I tried it. I think something is wrong.
i get the following replay:
QtPyVCP 0+unknown, Probe Basic v0+unkown
Any idea about this?

Thanks

normally yes, it will increase, and then during threading i think, there is a reset index command which turns it to 0 i think. during css operation im not sure.

did you end up getting the abz encoder? did you do the spindle.speed-in stuff? monitor that while your doing the css and see if it takes a dive while the speed is changing. the remora.sp0 signal looks exactly as i would expect though, with the speed tapering up or down as the diameter changes.

I would start with a MesaCT created configuration.

Hello,

this is just outstanding! Also thank you so much for the Fanuc  tool change example!

I could only try it out for one hour so far and I'm just amazed by the work and effort you done. Without your support, my decision of retrofitting this machine probably would be different! I also tried M19 R180. Worked flawlessly.

And as you correctly predicted i have a few questions so far:

1. Tool table:

The "Orient" and the "Diameter" for turning tools: Is it just informative, or is it used by some background calculations?

2. Tool rescue:

Assuming a drill or end mill doesn't sound right during milling and i stop the programming and want to retract it. When die B-axis is not at 0° it's quite difficult to get the tool out of a hole/pocket without braking it. A function to move the X axis at an B angle would be helpful for this.

That's it so far. I will try and implement the Fanuc tool change tomorrow and see where this will go. Again thank you so much and amazing work