Advanced Search

@unknown Nope until now it's only at the master branch, when I see time I'll do a pull request for the 2.9 branch. You could possibly build from the 2.9 branch and apply the following patch with: git apply ../linuxcnc-rt-detect-6.12.patch

forum.linuxcnc.org/media/kunena/attachme...rt-detect-6.12.patch

Or just put "LINUXCNC_FORCE_REALTIME=1" in front of the LinuxCNC command of set it as a permanent environment setting

Thanks
Homing I am just gonna do the normal switch plus index for now. So 3 inputs out of my 24.

Other inputs I need are:
- Probe
- Laser tool setter
- Spindle clamp sensor
- Hard limits are either 3 or 6 switches but I will leave those off for now.

Not sure how you handle an MPG with this.

For outputs I have:
- solenoid for tool release
- solenoid for M7 mql

I will be using probe basic I think for this, i will need to figure out the rs485 for the spindle. It looks like I can read back the torque, and alarms, which is nice. My biggest issue on the old setup is the control is blind to errors and when the spindle or an axis stalls it just keeps on keeping on. Gotta get that all tied up.

Hi, sorry, do you mean something like this ?
 

 

Hi Linux CNC forum, 

I'm building on a small CNC for over two years now. Unfortunately, I've been running in some issues while milling circular pockets.  
machine specs: 
Traj XYZA 
y-axis 1190 mm max travel, 20 mm ballscrew with 10 mm pitch, two 750W AC servo (HLTNC) 
x-axis 900 mm max travel, 20 mm ballscrew with 10 mm pitch, one 750W AC servo (HLTNC) 
z-axis 185 mm max travel, 16 mm ballscrew with 5 mm pitch, high torque nema 34 stepper 
spindle - 2,2 kw rattmotor air cooled
Brain of the operation: raspberry pi 4b+ using a parallel port hat and a 5 axis breakout board 
I'm running the premanufactured PI4 optimized Debian Bookworm image. 

Y-axis settings as follows: 
max_velocity = 5000 mm/min 
max_acc  = 20000 mm/min2
min limit = 0 mm
max limit = 1190 mm 
stepgen_maxaccel = 40000 
scale = 10 steps/mm -> (not sure why i set this to 10 -> 200 steps/rev and 10 mm pitch shall result in 20 steps/mm) 
FERROR = 1
Min_Ferror = 0.25

The issue: 
See attachment for further details 
arcs/circular shapes are for any reason shifted in XY - direction, the error occurs above 250 mm/min and is almost unchanged between 1000-5000 mm/min. 

What did i test up to now: 

1. Change base_period up and down -> the servos are set to 200 "steps"/rev, 10 mm pitch -> thus 20 steps/mm resulting in below 2000 pulses per second on one axis. Base_period is set to 100k, shall be fine? Changing the base_period to 40k didn't change anything as well as increasing the base period to 150k. 
2. Change max_acc to 4x max_velocity and stepgen to 2x max_acc -> didn't change anything 
3. check mechanical stiffness and backlash -> everything feels tight and rock solid, the linear guide rails are 20x30mm using very massiv long carriers. 
4. kill all unnecessary PIDs on the debain system in order to reduce latency -> didn't change anything

added the .hal and .ini file as attachments. 

Any hint or recommendation on how to improve this would be appreciated! 

Thank you!
Michael 








 

I haven't had time to use halscope, I'll look at your recommendation for modifying the firmware.

I made a surgical modification to the AXIS GUI to optionally modify the behavior of an axis to use the ACTUAL_POSITION value as part of the offset value sent to the G10 L20 command during a workpiece touch-off.  This is only done if TOUCHOFF_ACTUAL = TRUE is set in the appropriate [AXIS_x] section in your .INI file.

This may not be the most general approach and may yet prove to have some bugs (e.g. i have not tested metric mode yet), but it works for my situation right now anyway.

I'm not sure if this is worthy of creating a PR to include in LinuxCNC, but for anyone who might want to see the change you can view the diff here:
github.com/tangentaudio/linuxcnc/compare...025%7D?diff=split&w=

cheers,
Steve
 

You need to share more about what you want to achieve. Sounds like you are going about things the wrong way...
cia402.comp is an interface between Linuxcnc joints and the ethercat cia402 servo drive.

I attach the configuration files to handle the turret. The only difference with yours is that the one I have did not have the encoder and I had to design one, but without the use of parity pins, you can add it by modifying the turret.hal file. My turret only has a 6-position tool changer while yours has 12, that's not a problem, what I did was design my encoder to only detect 6 positions and only use 3 sense pins to get a maximum of 8 combinations, with your encoder you can do all 12, adding another sense pin to the turret.hal file. As I explained in this thread, the turret originally works bidirectionally, but I could not get it to work that way because the carrousel component does not allow it. In this thread they also discuss this type of turret forum.linuxcnc.org/10-advanced-configura...ute-encoder?start=30. I have to search my notes because I found in another thread someone who designed a component for a turret that works the same as the one we have, but is manufactured by another company. This component does allow the turret to work in a bidirectional manner.

tommylight wrote:

CandCNC ?

I was to polite to say anything but a lot of users have bought a THCAD and converted to QTplasmac.

I then looked at your diagram about io. Just check the docs to see what it says for internal homing and limits as if used, it will consume some pins.
I'm keen to get internal homing working so I can do torque homing to avoid adding limit and homing switches

Great move!
The IO is reasonable from Rtelligent and Deiwu. I have xml configs for both
github.com/rodw-au/linuxcnc-cia402
Rtelligent has PWM
I have both but used Rtelligent on my mill.
There is another one on Aliexpress with a few more features including Encoder but you may need to write the XML which is not that hard.
Note the IO's on the drives are more for homing etc but do work for general IO

I do not use internal homing. I intend to one day but I have had my little Ethercat homing lab on my desk for 12 months now untouched...

For spindle I used RS485. It actually interaces nicely with QTdragon GUI and is very stable speed wise when tested with a laser tacho

I did not end up adding an encoder due to cost. I ended up using a thread mill that gives perfect results. I now wonder what all the fuss is about with encoders. Its only ever needed for threading which is rarely done and thread mills are much easier on the machine and don't need an encoder!

+- velocity values are not possible in counter mode unless you have noise on the "B" input

Try jumpering the "B" input for single ended mode
(and make sure nothing is connected to either "B" input at TB2)

 

No and not planing to, the "influencer's" keep forgetting to tell us just what headache that is. It fails, a lot.
As it is, using the USB is enough liability, adding another set of comms is really asking for trouble.

40VDC is enough
57VAC is enough
Start wiring stuff, build the machine, make chips,...