Advanced Search

Gentelmen, I am not an expert of C hard code for this big performance irons... I have coding just embedded stuff (day of 8bits stuff) and from this I am little bit bended to optimsing everything over readable coding ... because of lack everything 

therefore it was just my opinion ... I am open to learn new stuff and let my habits behind 

Luca do you think about the look ahead position control? PositionCommand(t+1) as I said before please? For run the ethernet and ethercat servo packs in CSP control? This will change the lagging and cycle ferror during movement...

I have coded my own component which is solving it by it is not accurate during the accellerations change ... 

Sorry, just for info: the encoder is a separately mounted encoder just for thread cutting, so it has not really to do with the spindle control itsself, though would be nice if positioning the spindle would be possible later on...

rodw wrote:

I don't think it makes sense to manually optimise for execution speed in this day and age. Instead use GCC compiler options -03 or -0fast and possibly native optimisations march=native and possibly mtune=native. This may increase code size and possibly memory usage but I don't see that current hardware has constraints in this area. Gone are the days of massaging code to save every byte to fit in a 64k terminal! I did find using the C ternary operator was more efficient than if-else during that exercise.
 

I disagree. Compilers can do great things, but writing code with performance in mind can make a HUGE difference. I haven't looked at this code to know if there's low-hanging fruit here or not. As an illustrative example, I recently got the PeanutGB emulator running on an nRF54L microcontroller. Various low-hanging-fruit optimizations (pulling branches out of loops, handling 16-bit numbers natively instead of as 2x 8 bit integers, etc.) brought that from running at not even full speed to running at 130~150% speed.

There's certainly an argument for writing readable code over the most optimized- the above changes varied from neutral in readability to highly detrimental to readability.

Any loops are a good place to start looking at optimization- pulling out any branches, unrolling them, and/or reducing calculations that are done in the loop. Basically Amdahl's Law- look at optimizing the parts of the code that take the most execution time.

first of testing was 3dchips.ngc and second the 1001.ngc When I removed the base thread ... most of spiking was gone but last spiking ( less then 300us peaks - core duo, less then 200us peaks - i5 C6930-0060, 80us peaks - i7 ) are present during the in the clouds ... but it is more then perfect and extremly usable for everybodyit amazing job for sure !!!

All the answers to your questions are in the manual:
linuxcnc.org/docs/2.9/html/config/ini-co...sub:ini:sec:rs274ngc

SUBROUTINE_PATH = ncsubroutines:/tmp/testsubs:lathesubs:millsubs - Specifies a colon ( separated list of up to 10 directories to be searched when single-file subroutines are specified in G-code. These directories are searched after searching [DISPLAY]PROGRAM_PREFIX (if it is specified) and before searching [WIZARD]WIZARD_ROOT (if specified). The paths are searched in the order that they are listed. The first matching subroutine file found in the search is used. Directories are specified relative to the current directory for the INI file or as absolute paths. The list must contain no intervening whitespace.

USER_M_PATH = myfuncs:/tmp/mcodes:experimentalmcodes - Specifies a list of colon ( separated directories for user defined functions. Directories are specified relative to the current directory for the INI file or as absolute paths. The list must contain no intervening whitespace.

A search is made for each possible user defined function, typically (M100-M199). The search order is:

1) [DISPLAY]PROGRAM_PREFIX (if specified)

2) If [DISPLAY]PROGRAM_PREFIX is not specified, search the default location: nc_files

3) Then search each directory in the list [RS274NGC]USER_M_PATH.

The first executable M1xx found in the search is used for each M1xx.

I looked at some optimization routes today, nothing sticks, as rodw said modern compiler do already an excellent job. /2 or *.5 does not matter, the compiler does not actually call the division in assembly, /2 stays for code readability. please first give me a code that I can run, that spikes with our scurve, and does not spike with trapez acc. And then we could seriously look at what operations that we introduced might be spiking the servo-thread, and see if optimization is viable/necessary.

I hope someone can provide help for me. I try to go step by step slowly and still are trying to get my spindle encoder to work. I can see it counting in HAL-show, but it does not really work together with my spindle. I assume I missed some linking in my HAL.I attached current HAL and INI attached and a file TXT file called HAL with DOKU where I documented the physical connections to the MESA cards, probably this helps...

Would be great if someone could help me to integrate this encoder.
Thanks
Sigi

Thank you Rod.. I think it will help everybody with low latency and ethercat jitter...

What i can tell from my observation... If anybody using CSP driver over ethercat.. position is sending but there is everytime single cycle lag because of no feed forward observer FF1 like during compensation in the PID overc command velocity ...
There will be best if the planner will have allready positionCommand(t) and positionCommand(t+1) for direct position control setup .. this will directly avoid lagging just for this purpose .. do you think about it?

In axis the preview is always there. But axis doesn't update the preview, once gcode is loaded. Typical example in axis, probing or shifting offsets during runtime. This leads to a misplaced trace compared to the originally loaded preview, which persists.
Flexgui does update the plot, if i shift offsets, G10... updates the view.
What i tested, G38, M66 and even my toolchange routine, block the preview until none of the mentioned before is in the further gcode, and then preview comes back.
 

“I couldn’t find a solution to this issue, and I haven’t received any feedback so far, so I’ve decided to move on from LinuxCNC.”

Do you get the same results using Axis? I ask that because Flex GUI uses the same plotter as Axis.

JT

I don't think it makes sense to manually optimise for execution speed in this day and age. Instead use GCC compiler options -03 or -0fast and possibly native optimisations march=native and possibly mtune=native. This may increase code size and possibly memory usage but I don't see that current hardware has constraints in this area. Gone are the days of massaging code to save every byte to fit in a 64k terminal! I did find using the C ternary operator was more efficient than if-else during that exercise.

I had a brief look at the code and it seemed to be well written and efficient.

In some benchmarking I did some time ago on an i5 with bookworm, the 1ms (1000 ns) servo thread executed in about 200 ns and slept for 800 ns so I don't think you will have issues if the s curve code increases execution time.

Of course it goes without saying the PREMPT_RT kernel needs tuning and that's been hard to articulate even after hours of study. My best effort covered in my recent video which has got jitter down to 6 ns according to one viewer. 


@endian, there is a recent PR from grandixximo on the Ethercat hal driver to sync the servo thread to the Ethercat loop which may help you if committed. github.com/linuxcnc-ethercat/linuxcnc-ethercat/pull/465
 
 

Thanks for the suggestions it gave me an idea! It took all replies to formulate it.

 If I create a base for my tool setter that has a riser. The riser can be any size as long as its lower than the trip point of the setter. This will allow me to remove both known points in space to resurface. Then when I re-install it the 2 known points in space are still referenced to each other.

 Then I calculate the offset from the tool setter trip to the riser top. Now that the offset is known I can adjust the tool change script to detect tool 99, change the X/Y location of the touch point and adjust the offset by the riser/setter offset. This should put the tool length offset routines at the same point as the 3D touch probe creating a calculated common known point in space for both.

 Now job start is similar to before. Manual load tool 99 (3D Touch) or tool 98 (6mm pin). If I load tool 98 setup is as its always been before the 3D touch. If I load tool 99 I get the added features of the 3D touch. Job start should pickup a tool change, use the tool setter and operate normally with either tool 99 or 98 start.

 Whooa! On the Amazon website the probe looked so easy! 
 

Optimalization of RT code is fundamental but I am not expert of them .. golder standard of industrial grade cycle is 250us(which i am facing from my experiences) therefore from before posted scurve planners I have noticed some lagging even at 2ms which is many times bigger...

I saw that many division like "temp/2" in the code, which divider is constant can be replaced by multiply of 0.5 if it is possible ..same but faster?

I am now optimizing the postprocessor and generating the gcode but I am moving to new house and its little bit tricky now .. i have just one working hardware benchtop example with 2ms scan time which is at limit of the RT.. but i have noticed that lagging at starting/stopping of movement is away .. 

Every native cycle as driling turning I need to check too ...

Thanks, I use qtdragon_hd and manual toolchange with a script I found in this forum. The manual tool change works awesome mostly, I am still messing with the script.