Advanced Search

today is sunny ... cold ... there are snow in the ground .... is possible to skii .... I'm not at work ... at last the perfect day .... good Christmas day to all

Aussie:

Fark it's hot, can't ski but can chain an otto bin lid behind the bike and hope the road doesn't chew it up or the missus finds out, Chucking a sickie, too good to work, Merry Chrissy mate.

BTW that's the version for "Polite Company".......when read don't pause between words...Apparently the Aussie accent is said to come from drunkenness.

How should the control word be written and transmitted if it is not a writable pin? I need to write and transmit the control word; how can I do this if it is not writable through HAL? This is a valuable instruction that the driver must execute

@Julian,

Thanks for creating a test configuration. This is really helpfull.

I’ve been dealing with an issue related to acceleration spikes in the HAL scope output for joint.0-acc-cmd and joint.1-acc-cmd during runtime, specifically when interpolating splines. I wanted to share the problem, its root cause, and the solution I’ve implemented in case it helps others facing similar challenges.

The Problem:
When interpolating lines or arcs, the HAL scope output for joint.0-acc and joint.0-acc behaves as expected. However, when interpolating splines, I observe acceleration spikes in the HAL scope. These spikes are problematic and can lead to undesirable behavior in the motion system.

Root cause:
The issue arises from how splines are interpolated. Splines are typically interpolated based on their total length, which is calculated by evaluating a finite number of points (e.g., 20 points) along the spline trajectory. Unlike lines or arcs, the absolute length of a spline cannot be calculated mathematically in a straightforward manner. This also applies to more exotic curves.When the spline is treated as a series of connected line segments (a "linestrip"), each segment has an angle relative to the next. These angular changes cause abrupt direction changes during interpolation, resulting in acceleration spikes. The same issue occurs if the spline length is pre-calculated and interpolated from t=0 to t=1 acceleration spikes still appear in the output.

Possible solutions:

1. Filtering Acceleration Spikes:
   One approach is to filter out the acceleration spikes by using a stepgen backend for XYZ joints. However, this is more of a workaround than a true solution.
2. Restricting Curve Types:
   Another option is to use only curves whose lengths can be calculated absolutely (e.g., lines and arcs). While this avoids the problem, it limits the flexibility of the system.

My Solution: Arc-Strip Interpolation
After much thought, I designed a solution that allows the use of any smooth algorithm or exotic curve without introducing acceleration spikes. Here’s how it works:

1. Waypoint Generation:
   The curve is transformed into a fixed number of waypoints (e.g., 21 waypoints). The number of waypoints can be adjusted (e.g., 9 or 51) depending on the desired precision.
2. Arc-Strip Interpolation:
   At runtime, an arc-strip interpolator processes these waypoints. The interpolator treats the curve as a series of connected arcs rather than lines. For example, 21 waypoints can be divided into 7 arcs (since each arc requires 3 waypoints). The total length of these arcs is known absolutely, eliminating the need for approximate length calculations.
    

By treating the curve as a series of arcs (an "arc-strip"), the system avoids the abrupt direction changes that cause acceleration spikes. This approach maintains smooth motion and works well for a wide variety of curves.

Why This Works:

• Smooth Transitions: Arcs inherently provide smoother transitions between points compared to straight lines, reducing abrupt changes in direction.
• Absolute Length Calculation: The total length of the arc-strip is known precisely, avoiding the approximation errors associated with spline length calculations.
• Flexibility: This method can be applied to any curve type, including exotic curves, as long as it can be represented by a series of waypoints.
   

Conclusion:
This solution has resolved the acceleration spike issue in my system and allows for the use of complex curves without compromising motion quality. I hope this explanation and approach can help others facing similar challenges. If anyone has further insights or alternative solutions, I’d love to hear them! 

Wanna come Down Under for summer Tommy, been quite mild this year only a couple days over 40C and luckily in Sydney no 2 days in a row have been over 40C. Mostly 30 - 35 then some days it's been pishing rain. Probably a bit hotter up Rods way, but to be fair Queensland is 20 years and 1 hour behind the rest of Australia.
As I type this it's just gone midnight local time and it's a cool 26C.

Best bang for buck will be a RPi5 (if you didn't have a RPi5 I'd suggest an ex corporate PC) and either a Mesa Ethernet (preferred as you are not locked into a single platform)or SPI card. SPI & Mesa is supported on the RPi5 by the hm2_spix driver.

There are some other projects floating around Linuxcnc-RIO, but at the end of the day the Mesa cards are solid, well supported and don't look like disappearing soon.

Speaking from experience, regarding "roll your own" external motion cards, carefully work out a costing, sure the base FPGA card maybe cheaper than a Mesa card, but then you have to factor in all the other bits & bobs bring that up the same feature set.

Now I had a couple of Spartan FPGA dev boards floating around so adapting the Mesa SPI firmware and designing a couple of PCB's wasn't a great cost........but having to buy the parts to populate them was a different story. Getting a Mesa board to Australia is about $100 dollars just for postage alone last time I checked. To tell the truth it just started out as "can I get the firmware to run" then it snowballed.

I'm not trying to put you off but just some food for thought. Another point, delving into cnc is not cheap, so pricey can be kind of relative.

Mesa isn't a cult, it works, works well, is well supported by not only end users but by Pete from Mesa........who was kind enough to help me with a few questions regarding the project mentioned above. If my personal circumstances would allow it I'd be buying a few more Mesa cards to run my Lathe. The mill is fully equipped.

I did this on some machines. But it causes inconvenience when transferring the configuration, especially if it needs to be done remotely.

Nserega.90 wrote:

Hello guys! I want to thank JT very much for the work done! This is very cool! After reading the documentation, I want to try to make a graphical interface for a CNC lathe. I'm not good at programming, it's easier for me to sit with a soldering iron in my hands))). But I think something will work out))) Question: I want to implement a light and dark theme. Can I make a switch to change the theme (light/dark)? So as not to write this in the .ini file. So that I would have the opportunity to switch the topic from the program! 
 

To change themes without restarting "might" work by using a custom python but I've never tried that.
gnipsel.com/linuxcnc/flexgui/python.html

JT

Good day all,

I wanted to share my experiences using the Raspberry Pi 5 to run my CNC machine and ask for some advice, as I am not sure where to go from here.

Please note, I am a novice at best!

To my surprise, I managed to set up LinuxCNC with EtherCAT to run my A6 servo motors that I got from StepperOnline. I am using the Probe Basic UI, and I love the setup so far. Big thanks to RodW for all the work and instructions on setting up EtherCAT.

I am also using an Arduino Mega connected to the Pi for general-purpose I/O—this also works great. (Using LinuxCNC_ArduinoConnector from: github.com/AlexmagToast/LinuxCNC_ArduinoConnector) This will mainly be used for buttons and tool changer I/O, so latency is not an issue. An EtherCAT I/O module would be better, but they are rather pricey.

What I would like to do is add a step/dir interface for my Z-axis, as this is still driven by a closed-loop stepper motor (my X and Y axes are EtherCAT). I want to be able to run the motor at a maximum of 200 kHz step rates. In the future, I would like to add a second Z-axis as well.

What I have tried:

• Using the GPIO pins from the Pi, but this does not generate step rates fast enough to run the motor. This also causes some latency issues, as the step generation is now done on the Pi.
• I switched out the Pi 5 for a Pi 4 (since SPI is not supported on the Pi 5) and tried using the Remora SPI interface to run a BTT SKR 1.4 as an external step generator. However, this also had a maximum step frequency that was too low. Additionally, I would prefer to use the Pi 5 instead of the Pi 4.

I would also like to build a second machine using only stepper motors with a step/dir interface. My motor drivers accept a maximum of 200 kHz.

I am looking for a solution that will allow me to run LinuxCNC on a Pi 5 with external step generation around 200 kHz that is not too pricey.

Any advice on which direction I should go next would be greatly appreciated.

Hi,

I'm trying to calibrate my probe, esch time i start any probing routine the pribe will only teavel down 0.5mm even though i have the max z clearance set way above this. No matter what i change i get the same results. I'm on version 2.9 

Here are my settings (mm)

 

 

Yes, I created the file on a Win computer... but I used VS Code.  Haven't had any of the typical 'wordpad' issues others have reported when using Win to edit/create files until now.

I'll create a new one from scratch on the Debian PC and see how it goes.  Thanks again.

i did the test. Does not work in the air.
How do I understand the best option to buy a new plasma cutter for CNC machines with Pilot Arc?
I saw that Stahlwerk CUT 70 with Arc Pilot is not expensive on amazon.de. costs about €450. I saw there was a discussion about this plasma cutter before. is it worth buying it or are there any proven and more profitable cutters?

I was able to move servo. But motion is too jerky. And servo is starting from any position. G0 x0 don't move to servo 0. It moves to where it was started.

RNJFAB wrote:

Halshow has the reading fluctuating from about -3650 -> +3650 with no plasma source having power.

Repeating myself here, interference, lots of it, so check the wiring and especially the grounding, ground loops will cause havoc.

You are welcomed, always.

Hello guys! I want to thank JT very much for the work done! This is very cool! After reading the documentation, I want to try to make a graphical interface for a CNC lathe. I'm not good at programming, it's easier for me to sit with a soldering iron in my hands))). But I think something will work out))) Question: I want to implement a light and dark theme. Can I make a switch to change the theme (light/dark)? So as not to write this in the .ini file. So that I would have the opportunity to switch the topic from the program!