Advanced Search

First thing you'd need to do is convert your signed integer encoder counts and turn counts to floats using the CONV_S32_FLOAT hal component. Then you would need to multiply the turns by 65536 and that and the counts together to get the total counts, finally you would need to multiply the total counts by your encoder scale to get the distance (or if a rotary axis degrees.) You could do most of the summing and scaling in a single step using the SUM2 hal component since each of the SUM2 inputs have their own scale factor inpout.

But I'm not exactly sure how you might use that position information to set the home position for homing the axis in Linuxcnc. (But I think it could/can be done.) Also remember that data feedback from modbus isn't in real-time, and is subject to significant transmitting delays and resulting inaccuracy, So you will need to only use that feedback for position when stopped or only for "rough" positioning when moving.

If you build LinuxCNC now from Master you don't have to patch the kernel anymore from 6.12+.
To be clear, of course you still need a PREEMPT_RT built kernel.

Hi, any progress?
In the software there is not so much to change, but there is the MAX_ACCELERATION setting. It will restrict the acceleration if set lower in the ini file.
You can have a look and see what you have there. The last lines in StepGen3.h
 

I'm trying to follow Deje63's step by step to build the RT Kernel but I end up with an error:
"reversed (or previously applied patch detected) assume -R?" when trying to run command
"patch -p1 < ../patch-$RT_PATCH_VERSION.patch".
I'm not sure what it meant so I tried to patch anyway but end upp with make throwing "Error 2" at me,.on makefile:1921. Any idea what this might be and/or how to rectify it?

OR even better if anyone might be able to share an .img with LinuxCNC working with Rpi5 and built on RaspberryOS Lite.
I can't get the GPIO pins to work with the distro on the downloads page and it looks like in the man pages that a build on RpiOS is necessary for this to work...

Edit: attached Deje's txt-file for convenience. 

at least previous solution working not everytime .... these because Xinput v2 it seems .... seems these command helps QT_XCB_NO_XI2=0  .... so QT6 being obligate to use XInput2 ..... seems these solve the situation .... if you not find other mine post on these thread ... these issue is solved.

Precisely better insert the command in main.ccp ... qputenv("QT_XCB_NO_XI2", "0") .... previous of QApplication macro .... (solved)

regards

There is rumor of Big Tree Tech making one, but that is still just a rumor.

I spent some time digging into the rs274ngc code last night.  I don't think it's viable to modify the G10 L20 at that level to use the "actual" position of the joint.  I didn't see any references to "actual" position in the structures that contain setup/block info in that code.

I did learn along the way that the Z axis "touch off" offset value is stored in numbered parameter [5203 + (P * 20)] , in other words the Z axis workpiece offset for P1 (aka G54) is stored at #5223.  This parameter value can be viewed via an MDI debug command (debug, #5223) after a touch-off.  Writing the value directly with #5223 = 123.456 doesn't do anything useful.

So I'm probably best off trying to accomplish something via a small GUI modification, or maybe something with a clever G code remapping?
 

The implementation of an exotic curve into the planner.

1. Curve absolute length is known.
2. Minimal direction changes during curve interpolation at runtime.

 

It works, thanks a lot for your help!

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.