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.

So I've decided to start with a new config and work from there, no embedded tabs to worry about.

New version of Linux, new version of Linuxcnc, new configuration, that's bound to open!!!..........not a bit of it. Another error box.

All as attached.

Any offers?

   
 

I can post if anyone is interested.

Please do.

If anyone is interested I now have a Logitech Dual action F310 controller working as a pendant in LinuxCNC for the Scorbot ER 3 Robotic Arm. I can post if anyone is interested.

Great, yes I have an unused 7i97. Let me know if you need any other info. 

Thanks! 

LinuxCNC/HAL is very powerful and customizable once you get
over the learning curve, looks like you are getting there...
 

I also like Axis a lot, it is like a duck = calm and easy on the surface but beating like hell underneath!

Again, you have one motor spinning in the wrong direction on Y axis, did you check that?

PCW wrote:

Another trick would be to sidestep the "not" issue
and use another (hopefully unused) function to get
the not functionality:

loadrt siggen
addf siggen.0.update servo-thread
setp siggen.0.frequency .1     # 10 second period)
loadrt oneshot
addf oneshot.0 servo-thread
setp oneshot.0.width 2           # 2 second on time
loadrt logic personality=2050
addf logic.0 servo-thread
setp logic.0.in01 true
net cool-trigger siggen.0.clock oneshot.0.in
net coolant-out oneshot.0.out [some_parallel_port_pin]
net coolant-on logic.0.in-00
net gate-coolant logic.0.nand  oneshot.0.reset siggen.0.reset  # when coolant is off, reset both siggen and oneshot


also note that "coolant-on" is a made up signal name, you need to replace it with the actual
signal name used in your configuration for this function
 

I made it work with the "NOT"

I changed

Loadrt not for loadrt not count=3 in main hal.
In postgui hal I have commented loadrt not
I also realized that I didn't change the name of "coolant-on" to the one in my configuration.

Now it works perfect.

What for any of you is a minute for me turns into days T_T
but I really like it because I'm learning a lot about linuxcnc.

thank you very much for the help.
 

Another trick would be to sidestep the "not" issue
and use another (hopefully unused) function to get
the not functionality:

loadrt siggen
addf siggen.0.update servo-thread
setp siggen.0.frequency .1     # 10 second period)
loadrt oneshot
addf oneshot.0 servo-thread
setp oneshot.0.width 2           # 2 second on time
loadrt logic personality=2050
addf logic.0 servo-thread
setp logic.0.in01 true
net cool-trigger siggen.0.clock oneshot.0.in
net coolant-out oneshot.0.out [some_parallel_port_pin]
net coolant-on logic.0.in-00
net gate-coolant logic.0.nand  oneshot.0.reset siggen.0.reset  # when coolant is off, reset both siggen and oneshot


also note that "coolant-on" is a made up signal name, you need to replace it with the actual
signal name used in your configuration for this function

Yes, there's another "not" component instantiated somewhere.
probably best to change the loadrt not command in the main hal
file so it instantiates all the "not" components needed