Advanced Search

Back at the computer. From what I can see you should get rid of that when you select G53 for the safe retracts
 

Reporting back; Some of the things which helped are, alignment, coupling and weight. Checked all these, some adjustments here and there and it is better now.

amanker wrote:

I think if you look into remora code. They are also sending hex codes payoad via spi such as estop is 0x65737470.

If you would integrate that into remora then it would be more useful.
 

More useful to whom? I do have a RPi and TMC drivers and want to avoid to buy an extra device. And the tests I made with FluidNC showed me that I was not able to get smooth acceleration at higher rates, that's why I decided to go full SPI. Maybe the audience would be larger if I'd add the functionality to the Remora code, but it would be useless for me.

Yes, the Remora-spi LCNC module sends SPI data to... a microcontroller. The microcontroller then translates the message into steps, or digital ins/outs, among other. To make TMC5160 work with Remora you'll need to adapt the Remora firmware. There's already a part of the TMCStepper library implemented to work with TMC2208/2209 over UART, and you configure the drivers options in the Remora config file, not in LinuxCNC ( like explained here ). The TMC5160 over SPI is not implemented yet, but most of the code is written and dispatched over the GRBLHAL/TMCStepper/FluidNC code. I think you have a better chance to find someone with the needed skills and knowledge to help you in the Remora thread.

I'm not too sure, there maybe other ways but I don't think there's an "out of the box solution". I don't think network integration was one of the major goals.
You may have to dive deeper into the documentation and source code.
There was a gent trying to integrate LabVIEW with Linuxcnc via nml.

I think your best bet maybe to layout what you want to achieve, keep it to a single and not start multiple threads trying to sort out a little bit at a time.
You could probably write your own client program that connects to linuxcncrsh server, it would still be a telnet connection, but would be a self contained client. That I think would involve diving head first into socket programming, once the initial connection is made is almost similar to reading to a writing from a file, that is a bit of simplification but it's close.