Advanced Search

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.

OK, it's working now - as usual, it boiled down to user error - apologies for that. 
But perhaps, I stumbled upon an idea for a slight improvement but I am no wizzard at this so I could be wrong.

When I first tried adding the custom FW, the folder that the FW file needs to go into, I don't think it was created, yet(?).
It needs to go into: .local/lib/libmesact/7i962 but I am pretty sure there was no such folder at the time.
There was however a .local/lib/7i962 which I then dropped the custom FW into.
Which, of course, is the wrong folder and hence why it didn't show up.

But after having gone through and reflashed with the default FW from your download feature, the correct folder had automatically been established for those downloaded FW files. So, when I opened MesaCT again just now, the .local/lib/libmesact/7i962 was indeed there, full of FWs.
So, I just dropped the custom one in there and then it showed up when I rebooted MesaCT and I could flash it to the board, no problem.

If the above sounds plausible - then perhaps add a line in that text that pops up about where to put the file, that "you may have to create the folder manually". I know, I should have tried that but I am noob and likely not the only one. But if one hasn't used the download feature in MesaCT, it looks to me like you would have to make said folder yourself, no?

Again, maybe the above recollection of events may not be correct either.

Anyhow, thanks for your work on this:)