I definitely agree with your opinion ... therefore I have testing at CoreDuo, i5 and i7 too ... and then just share my observation 

As I said before I am not expert of this topic but it is very interesting to help if there is a play to ...

can you share your hardware setup with us which is the best to avoid spiking please?

 

Yes, I think I understand you better now. Still you asked me what I would be doing about the spiking, and in my testing there is no spiking that I should be doing anything about, at least as far as the code we have contributed, and as far as my testing shows to me, but I am open to different hardware having different reactions to the algorithms, but this has to be empirically shown to be true with a test similar to mine, it is easy to introduce third variables unintentionally, so any testing has to be done with the least variation as possible, try to change only planner_type 0 to planner_type 1
This toggle exist exactly for the purpose of quick comparison between original trapez vs new s-curve.

I think we are not understanding us now ... I just share latency histogram to just prove my RT and latency free setup(eliminate hardware setup source), not to share pictute of spikes of my latency... I defenetly know that latency histogram and scope are two different things but over histogram we are fast and visible proving our setup of RT... 

here is scope of Intel core duo and AI tells me that Intal core duo has not some hardware instructions which can cause overloading from time to time ... here was most visible spiking 

Edit > yes my testing was doing exactly as you are talking ... first test was 3 phase and the 7phase generator .. 

it was just testing after experience with scurve of grotius where spiking what much greater and creating time lagging during cloud of point movement ... this situation is now not present at all I think, it works really well .. motion is excelent 

great job ! I am amazed.

No, the servo drives of the Y-Gantry each have their own connection to the encoder TB3/4 and analog interface TB5.
Attached is a picture of my 7i77 axis connection.

If I connect only one of the two Y axes to the analog interface TB5 and enable with F2 the axis enters control mode (drifting slightly but no jog possible). However, if I connect both axes to TB5 and enable them with F2, the axes immediately spin at high speed and a following error occurs.

@PCW What do you mean with "test  this with the linear axis disconnected"?

Note: The axes are currently not connected to the mechanics and are essentially lying loose on the table.


 

Spikes when you run latency-histogram are caused by the CPU doing other stuff, like checking the network status, reading your mouse and keyboard inputs, display graphical elements, going to sleep because its got nothing to do.
This is not in topic of this discussion about s-curve

Edit:
My test methodology was analytical, I ran same g-code, on same machine, same halscope size, changed the least variables as possible, only planner_type 0 vs planner_type 1
Please in future if anyone wants to bring forth issues about our s-curve implementation, they should use similar testing methodology, during our own internal testing of the S-curve calculations, we also often forgot to do this straight fair comparison, and it sent us on wild goose chases. Mind that we are aware that there are blending issues, this is something that we are working on, but these issues persist in both planner_types. Therefore please try to compare planner_type 0 vs planner_type 1 without changing anything else before bringing forward issues.

I have just posted the latency of my system in the case of checking and searching spikes source... 

Oooo it amazing to find that checking a scope is a source of spiking itself... thank you for briliant observation!

Yes I just finished testing, and our S-Curve acc tp seems to be computationally better, and spiking less the servo thread compared to the original trapez acc tp, as far as I see, thanks to our work you are getting a better and more computationally efficient TP with planner_type = 1 

Now I'm a bit confused about what spikes you want me to fix, the pictures you sent are of the latency-histogram, which I think you cannot even run when you are running linuxcnc, interpreting gcodes, and actually run our code the new s-curve acc tp, planner_type = 1

I think you might have some misunderstanding of where our S-Curve lives within the LinuxCNC architecture, we only changed the TP which stands for the Trajectory Planner. The Trajectory Planner is not calculating anything when you run latency-histogram, whatever spikes you see in latency-histogram have no connection with the Trajectory Planner, does that clear things up? Or is there something I'm missing? Am I misinterpreting you? Or am I missing something else?

Edit:
On our system I see way more spikes when moving windows around, opening glxgears, or even simply having halscope in view rolling the servo-thread, when halscope is minimized I have way less spikes to 20k compared to when I run either g-code you supplied. There is a catch I can only see that I was having less spikes AFTER I restore halscope in view, and then the spikes start again, making me conclude that the act of checking the spikes with halscope introduces more spikes than anything we are doing with the S-curve or trapez TPs, but I repeat in my testing our S-curve is more computationally efficient than normal trapez TP

​​​​​Hello PCW,I am using a Mesa 7i96M with a 7i76, and I would like to ask a question regarding firmware configuration before requesting any custom bitfile.Question:
Is it possible for PktUART to be used instead of SSerial in a 7i96M firmware configuration?
I would like to understand whether PktUART can be implemented in place of SSerial, or if SSerial is architecturally fixed and not interchangeable.If this is feasible, I would like to request a custom bitfile with the following changes:

• Replace SSerial with PktUART
• Repurpose STEP5 (unused in my system) as a PWM output
• Keep all other functions the same as the standard 7i96M + 7i76 firmware

If this is not feasible, I would appreciate any guidance on recommended alternatives.Thank you very much for your time and for the excellent Mesa hardware.
 

okay, thanks, I understand... just said my observations ... did you check my gcode yet? 

Checking the datasheets:
The Pi5 and CM5 both use the BCM2712 CPU. The CM5 uses the Broadcom BCM54210PE ethernet phy ic. I'm having a bit of trouble finding concrete info on what the Pi5 has, but I see my Pi 5 datasheet in the photo of the Pi 5 it has a BCM54213PE ethernet phy ic soldered near its ethernet connector. According to a quick look at the datasheets, those two chips appear to be interchangable.

In other words Pi 5 = CM5 as far as network drivers is concerned.

I think you could run in a terminal:
lspci -k
to determine whether the correct drivers loaded. It should report the same modules for the network as it does on your Pi 5.

On the other hand, maybe there is a connection problem between the I/O board and the CM5, is the CM5 seated correctly, and the connections clean? One thing I'd try is carefully disconnecting then re-seating the CM5 on the I/O board, it could make a difference.

Hello!
The idea with the Heidenhein board isn't bad. It's definitely a very solid solution. 

I have already asked another company about these small converters. If they are suitable I would like to use them because they are small. 
www.hs-imagingsolutions.com/hardware/signalkonverter

@hartwig, you can edit your comment to delete the long link

It is not a simple change, the look ahead is about velocity not position, it is not something we can easily expose via HAL, it does not exist, we do not have that point ahead of time, we need to calculate it, and you just had us look at performance optimization, this will double the calculations, for cosmetic reason, I don't think you'd want that either.

JohnnyCNC wrote:

I don't have a surface plate or height gauge (yet). I do have a lathe with a DRO. I made a ring that the tool holder fits into. I chuck the ring up the lathe, Turn the lathe tool post holder around so I have a flat surface that will go up against the ring. Zero out the DRO. Move the tool post away from the ring. Insert the mill tool in the ring then move the lathe tool so it touches the tip of the tool. The DRO now shows the tool length. I enter that value into the tool table.

Very inventive solution

No there is no error observations at parts because regulator in servo doing its job .. its just cosmetic issue of lcnc which I can see when I am comparing lcnc with fo example NC application from TC3...

It just my hint.. many of user are facing this ferror a its difficult to understand for them that this error is not the bug but the feature... 

I am just highlighting situation and when you are already in gentlemen.. how much difficult is to create pin position-command-bus or something else which will forever solve this observation please? 

Thank you. Your jobs are amazing ! 

Hello, I am testing LinuxCNC 2.9.7 (official Raspberry Pi 4/5 image, Debian Trixie, uspace) on a Raspberry Pi Compute Module 5 (CM5) with a Mesa 7i95 Ethernet card.
The same LinuxCNC version, Mesa card, cable, and network configuration work on another Raspberry Pi platform, but on CM5: • eth0 stays NO-CARRIER • ethtool eth0 shows Link detected: no • Forcing speed/duplex has no effect • RP1 PCIe device is detected in kernel logs Network: • eth0: 10.10.10.1/24 • Mesa: 10.10.10.10
Is CM5 fully supported by the current LinuxCNC Raspberry Pi 4/5 image, or is newer kernel / device-tree support required for RP1 Ethernet on CM5? Thank you.