Advanced Search

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.

Thanks, I will give this a try. I won't hold my breath though as I believe deflection may play a role to create a non-repeatable deviation. I mostly work with wood and usually complete a job after setup so a slight variation at tool 1 wouldn't likely hurt.

Thanks, Interesting idea, I think though this would work with tool holders. I have a simple collet and the tool mount has slight variations each time I load it.

    
Sorry for the previous message. I hope, this works.
Best regards
Hartwig

Hello Mbrandt.
I have used the following type of "HDH Exe Platine" with 3 channels.
www.ebay.de/itm/204779209363?srsltid=Afm...Gj67v4RUzT0PLvOgckrB
Very simple and very small. It fits between the glas scales and to the MESA directly. For mine I have paid less than 200 Euro.
 

Yes, I think he is

Edit:
Don't really have any tricks up my sleeves or anything, YangYang or Mika-net here on the forum coded the S-curve, I did most of the testing, we have not till now found anything better, performance and accuracy wise, it's possible some Algo is out there that is better we just have not come across it.
About the spikes, no idea we run 1ms servo and have not noticed realtime errors, I wasn't looking at servo thread in the scope during testing, I'd like your test codes to compare the spikes, possibly try some optimization, but the current code in the PR is best we got today.

I would use a new output pin that follows the state of estop. 

I think there is no simple answer now.. but from testing last few days its waaay good to control any hardware and smoothness is uncomparable...

I will share testing gcode in comming days .. but basically I go through all examples in nc_file folder and then my code.. my code will be avaible here

I am now searching the best solution of testing and validation ...there is not space for one lady said..

To prove all main stuff but idea is basicaly simole.. step by step test all avaible G code which I have from real machine but there is some limition of my time 

Btw 杨阳 is mika-net at forum? If am I wrong?
 

Hello Hartwig,
Thank you for your reply. I think my machine has some sort of EXE, its a board and the name is NCP59. But i dont know where to intercept the TTL signal from it. There is a version of this board with an extra digital output, but i dont have it on my machine. And buying 3 Heidenhein EXE is a step back. I would like to use a modern version of that.  Maybe a 7i85S or someting like that? 

And the Suplier you sent seams good and I will buy der 7i97T from him.


Here is a picture of the NCP 59:
(1, 2, 3 are X, Y, Z)

 

Thank you so much for the response, I have been going through a trial and a half with this install :') I bought some 2.2k 1/2W resistors just for this project, and have been battling to get a result

In halshow, none of the inputs change state, even the estop. But watchpin in the terminal shows clearly that estop, probe and for whatever reason, Z max (Home) limit switch change state even though it currently doesn't have a pullup. I only get a reaction from Z max when sensor is active.

I currently have a pullup on my X min, but can't get any reaction out of it no matter what state the proximity switch is in (on/off or jumper to GND) when using watchpin.

Just for reference as to wiring, I have all +wires > COM+> +WAGO fed by +FIELD, same setup for GND. Then individually connected sensor wires to MESA inputs. Pretty obvious, but just in case, I figured I best note it.

Also, I figured I will include multi readings in both states for all inputs with sensors on and off. X max excluding as I have found it to be dead. I will be replacing all of these anyway with PNP when they arrive. But was hoping to atleast get it running.

Readings are as follows:

X max DEAD
X min 3.9 off, 7.8 on
Y max 14.7 off, 18.4 on
Y min 12.3 off, 8.3 on
Z max 8.0 off, 14.9 on
Z min 12.4 off, 9.0 on

Readings might be telling or maybe not?

My GUI is also massive and a PITA, so I have mostly been doing my stuff through SSH. No matter what commands I send, I cant get the GUI to scale properly that's everything on the screen though, for whatever reason, my mini pc with Debian 12 cant seem to recognize the screen through HDMI. Any suggestions there would be absolutely amazing!

Should be good! Run it!