Advanced Search

Hi!
@zmrdko : 
thank to you and other experienced users in this thread for educating other folks and providing invaluable linuxcnc knowledge. I have some follow up questions on one of your posts:

- Would you mind sharing which z390 motherboard manufacturer / series do you have that allowed you to achieve 2.3us latency?
- What Intel PCIe Ethernet card did you choose? I saw that in this thread: gitlab.com/etherlab.org/ethercat/-/issues/104 they recommended "cheap realtek 100mb/s" ethernet card.
- Did you go with intel integrated graphics?
- IIRC, you (or maybe other user?) mentioned that with newer kernel the performance dropped from 8kHz (at 4.19rt) to 4kHz.
- Were there any other factors that positively affected performance besides the servo thread latency to get 8kHz? (e.g. ethernet roundtrip was quick)
- Have you measured how long does it take to execute your HAL components in each control cycle?
- Is there some other computer hardware that you leaned about and would be eager to try out with EtherCAT?

I hope this is not too much off-topic. Please correct me if there is a better form to ask these questions.

Thank you for your consideration,
Regards, Jakub

slowpoke wrote:

Bunch of questions, Hopefully someone can fill in a few blanks as I formulate a plan for the lathe.

I'm using Axis for my mill and I'm completely happy with it. I'm now considering using LinuxCNC for my lathe. I definitely want to maintain manual operation capability.

Presently I have a derivative of the Clough42 ELS with feedback from the spindle and a stepper driving the leadscrew for threading. I like the simplicity of selecting various thread pitches metric and SAE electronically.
1) I don't suppose LinuxCNC has this "ELS" capability?

2) I also have DRO scales. Assuming I will use a MESA board, is it possible to connect the scales to the MESA board and use LinuxCNC as a glorified DRO without actually driving any steppers/servos?

3) Assuming for the moment I can use LinuxCNC simply as a DRO, what MESA board(s) would be a good fit for say max 3 encoder inputs and possibly up to 3 steppers later?

 I have a RaspberryPi of some sort and I might try using it for the LinuxCNC for both space and $.

4) What RaspberryPI's are likely to have acceptable latency and what versions should I avoid?

 I find the Axis GUI a good fit for my needs on the mill, what GUI is a good fit for lathe control?

Much appreciated.

 

I won't comment on GUI choice(s) here - those are personal preferences.  Regarding your other questions:

• Yes, LCNC has "ELS" capability.  Not in a turn-key configuration, but there's no reason you can't set LCNC up to act like your ELS.  All the elements are present: spindle encoder + Z-axis positioning motor + configurable logic.
• Yes.  And LCNC already has a "DRO" mode.  See  linuxcnc.org/docs/devel/html/gui/mdro.html
• You can read my long-winded post here:  forum.linuxcnc.org/27-driver-boards/5160...i-buy?start=0#292576
  • I'm not an expert, but I think the absolute cheapest Mesa combination to get an FPGA card (required) and 3 axis/spindle encoder inputs & step/dir outputs is a 7i92 (any variant) and a 7i85s.  You'd still need something else for IO, but that depends on your particular setup.
  • If your IO needs are moderate, a 7i96s and 7i85s would get you the IO and keep packaging to two (vs three) boards.
• Based on very little personal experience, Rpi's usually have decent to very good latency and potentially not-so-good user-interface response.  i.e. 'laggy' if using a power-hungry GUI.  If you are using Mesa hardware you don't have to worry about latency with an Rpi. 
  • I've got an Rpi5 and while I'm not using it (right now), it was just fine when I tested it with LCNC and Probe Basic (no interface lag).
• Lathe GUI - any GUI is fine except Axis.
  

I can't post them easily now, no. Sadly I don't have a working PC at home which complicates matters.

I did however post them earlier in this thread, the hal and ini stayed mostly the same, and any changes I did, did not result in properly functioning movement.

I did check, and no. It rotates correctly. I tested with a separate hal and ini set, where I mapped the outputpins of the moving y to the not moving (faulty) one. It moved as expected.