Advanced Search

besriworld wrote:

It seems quite complicated. Has anyone done it with +-10v control? I want to try it on my lathe.

It's been a while since that post, and my lathe project has been stalled for a few months... but I had to give up on C-axis.comp.  I didn't get far enough to try the polar kinematics.

The insurmountable problem I encountered with caxis.comp was that it interfered with synchronized spindle moves (threading).  I wasn't able to figure out how/why it was causing problems, but once I abandoned it for a spindle/axis scheme proposed by @Aciera and @PCW, threading started working properly.

There is still an issue with threading in LCNC - thread start point varies with RPM - but that's not related to caxis.comp.

It seems quite complicated. Has anyone done it with +-10v control? I want to try it on my lathe.

Ok, time to get back to this.

What am I doing again?

I’ve managed to detect WCS (G54–G59) from a loaded .ngc file and output it to the terminal.
To be precise, it prints the WCS to the terminal log.
But I haven’t yet succeeded in sending it to MDI to change the GUI WCS.

Code implemented inside qt5_graphics.py > StatCanon:
Sample G-code:
Terminal output:
As you can see, G54 appears at both the top and bottom.
This needs further filtering to ensure only the first actual WCS used in the program is considered.

Greetings fellow machinists!
Back in 2023, I did a reconstruction of my old CNC router for my woodshop. I have decided to use EherCAT hardware as my main communication interface tween LCNC and the main build components. A friend that makes CNC machinery advised me that I use Delta servo system, as it is the best option for my budget. I have decided to go for Delta ASD-B3 drives with 1kW motors. The setup in LCNC for the drives was rather easy. I had to use generic driver for lcec and couple it with dominik’s hal-cia402 component.

Everything seemed to work fine until last week when I have noticed that the circles turn out to be slightly oval. This is especially prominent on semi- and quarter-circles. I see this effect while doing interpolation in XY, XZ and YZ. The error seems to be of the same size and in the same position in the 3 planes.

I have also noticed that when I make a slot it is slightly wider than the tool diameter and slightly shorter than programmed. What is more the depth pattern is visible and alternating on the sides. This is depending on the cut direction. I usually use ramp plunging along the whole length of the slot and this effect is not visible then but when doing single line slot milling with small ramp plunge then the score lines are visible.I have tried few things like tuning the servo drives, changing LCNC configuration parameters like axis acceleration, speed; arc blending settings in [TRAJ] section but nothing seems to work. I have tried both slow and fast work feeds but the effect is prominent no matter the speed.

Something interesting I have found is that when squaring a piece of wood (hardwood like oak, beech or soft materials like pine, MDF, chipboard) one corner is seemingly sharp and the opposing corner is rounded and then this is mirrored diagonally. The radius seems to around 1mm. When squaring I have created a subroutine that uses arcs at corners so that the tool is not chipping the piece at the corners and sometimes to avoid burns.

Y- and Z-axis are ball screw with 5 and 10 mm pitch and are belt driven with 1:1 ratio. X-axis is helical rack and pinion with 1:10 gearbox. I have checked for mechanical issues and none is present or apparent. The gantry and the axes in general are square, as far as I can measure. X-axis is 4100 mm of travel but along that distance, I get like 0.02mm deviation from the zero point. Y-axis is around 1600 mm and Z-axis is around 560 mm. I have enabled E-Gear option in the servo drives as 10000 PPR.

I have attached pictures of the interpolation errors I get. I am open to discussion of what might be the cause of this - communication lag, drive parameters, LCNC config. I will also attach my INI and EC configuration files.

Hi everyone,
I am pretty new to LinuxCNC and currently working on a setup where a light distance sensor is mounted on a XYZ stage. My goal is to approach an object along z-axis until the sensor reading enters a defined window (26 – 27 mm) and then scan the object along the x-axis, stopping the moment the sensor reading exits that same window.

My current approach was to use probe mechanism with G.38 moves.
The .hal file:
The G-code:
When running the G-code, the probing along Z-axis works just fine and the movement stops the moment we enter the window. When probing along X-Axis starts, it moves for just a tiny bit (~0.2s) and then throws an error: Probe tripped during non-probe move.

The motion.motion-type has value 5 (which is Probing) during both G38 movements, so I don't know where the error comes from.

I'd greatly appreciate any insights into this issue!
Thanks in advance.

If the machine has no built in home switches, it really makes no sense to
have multiple index marks on the scale.

It it possible there is an electrical issue causing false index detection?

Is there documentation on the scale types?

That's a well known issue, has been around for years and has been discussed quite a few times.
I'd be careful running dist-upgrade as it can mess kernels up.
If you want to upgrade packages a simple apt upgrade will suffice.
To be honest all I run on my desktops, laptops and servers is apt upgrade.
But if dist-upgrade works for you that's great.

Reply based on misread image.

The root issue is not sserial related but latency related
(notice that the first error is a watchdog bite)

I would

1. Run a latency test

2. Check the network latency with:

sudo chrt 99 ping -i .001 -q -c 60000 10.10.10.10

or

sudo chrt 99 ping -i .001 -q -c 60000 192.168.1.121

(depending on 7I80 IP address setting)


 

My apologies for the late reply. I was travelling and forgot about this.

It appears I had forgotten to update the pdf schematic to match the rest of the files. I have now done that. This includes an improved crowbar circuit that I mentioned some posts back. The new circuit should be less sensitive to which components are used. Otherwise I only rotated the RJ45 jacks from the previous version.

I have had and and still have a few other projects that have taken priority, so not much progress on the Maho.

MennilTossFlykune

Thank you for your advice.

I've been focusing on incorporating this all day today, but I still can't get out of the error. To be honest, I don't even know where I am now.

thanks tom, i tried some changes in this section and those didnt work, but later on last evening i finally got it working, but i dont remember exactly which ones i changed. when i get back to the shop later today, i will log all the keys i modified and put a list together for anyone with this model of vfd. also, there was some keys where i could adjust the scale of the pwm so at the anything under 5v gives me 12k rpm and i get 400mhz at 9.45v

Hello, good day. I'd like to know if anyone has been able to help replace the original computer on the Sodick A320D machine.
Thank you very much.

To do the above suggestion to get a hal pin that shows the commanded S speed even when the spindle is stopped. The link gives instructions for creating a python script that reads what the commanded S speed settinging is from the Gstat python module and then creates a hal pin and writes the value to it.

You will need to create at python script with the following, and save it as a file in your config directory named "spindle.py" and make that file executable.
Then load/run that python script when you start Linuxcnc by adding this line to your hal file for your config. (Replacing YOUR_CONFIG with the name of your config dir.)
You can even test this before adding it to your hal file by simply running the python script from command line while Linuxcnc is running. Just type "python3 ~/linuxcnc/configs/YOUR_CONFIG/spindle.py" and hit enter. (After first creating the spindle.py file, saving it to your config dir.)