Advanced Search

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.

I see this in master and looking at the code, I see why.
Thanks for details and investigation.
I'll try to push a bug fix soon.

Aqui os 3 modelos que testei funcionaram bem.
Mas com .bit chinês

Before I had TTS tool holders I used a touch plate that I had made. It was basically a spring-loaded brass button in a Delrin base. I used to put each OP in a separate G-Code file and touch-off with the touch-plate at each tool change. Now I have an M6 remap that automatically measures my variable length tools like drills and odd endmills that I don't have dedicated toolholders for. It uses that length in the tool table for the tools with dedicated holders.

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.

We use CSP control with Ethercat, I can't really envision benefit of sending next next position, instead of just next position.

What do you actually observe on real finished parts? Any actual quality issues? Or is this a theoretical concern based on watching HAL ferror signals?

FWIW, I finally got back to working on this with the new 7i84 board and the ferrules I ordered.
I purchased two different ferrules but the one that seems to work best is a 0.14mm2  - 26-28g brown  Digikey PN 288-1656-ND, manu-PN 1163014

These will go in and start over the insulation slightly (maybe where it's been necked down a little during stripping?) but crimps down tightly.
I do think I might all a drop of CA to the plastic end of the ferrule once the wire is in just to move the flex point away from where the bare wire is crimped and up to the insulated part

Back to wiring....

 

Hi everyone, I'm 杨阳. I'm currently studying the lookahead optimization code in the motion planner, and we're also exploring some approaches to improve its computational efficiency. If everything goes well, I hope to contribute further optimizations in the future. 

The hal file shows independent analog outputs and encoders

Are you sure you have the feedback correct for Y and Y2?

You not only have to get the right (matching) directions but the
proper feedback so you don't get a instant runaway at drive enable.

Might be best to test  this with the linear axis disconnected

Ah, I didn't see anything on a real machine. Will have to look deeper.

First tart is here in 2 weeks or so, so ill try it on that.

I think grandixxmo takes the prize already. A complete stable and finished scurve planner with a PR for inclusion in the linuxcnc core code. (new features go into 2.10 so that's where it is). Also tested by another user on real hardware (by endian) In the mean time, try the version in his github. It works!

JanCNC wrote:

But now i got a problem with my gantry Y Axis. If both Y Axis connected to the TB5 and we press F2 the Motors jumps around and an following error occures. Do you have any idea why this happend?

Do you mean both servo drives are connected to the same analog output?
If yes, that does not work, analog drives can not be wired like that as it will mess with the feedback.
Each MUST use it's own output and it's own feedback.