Advanced Search

Great idea. I'll probably post more on this when i get closer to testing it. The 5HP vfd showed up yesterday.

Thank you for a very quick reply!

I will take some more photos and check that cable going to the drive board next time I'm around.

Based on your suggestion, I feel like it's worth to do the budget way to show that all bits are working!

Regarding drivers, I think the steppers might be able to take ~80V but I can't find the datasheet (will give it another go some time) but since it's not going to run in an industrial setting, the highest possible speed is not really required, so TB6600 might be enough

Good point, Rodw.

Part of my interest in the GPIO was to use encoders for screw mapping or closed loop control, thinking the more ethercat components i buy(controller budget) the less the retrofit budget for the mill.

However a serious deficiency in motion control cannot be compensated for in motion hardware and vise versa. 

I now have an Ethercat IO module next to me (arrived this morning along with some cat 6e patch leads) but due to me being a clown it seams the connection module for the ethernet cables is a discreet entity, and that will arrive tomorrow along with a 2x channel encoder interface.

On rout from china is an Rtelegent ECT60 Ethercat closed loop stepper driver that should be compatable with the 4x nema 34ish encoder equipped steppers i removed from my first cnc retrofit project. If i can bully them into working together i will order 3 more. 

As for the Ethercat IO and encoder inputs i have aquired some Beckhoff modules.

EK1100 Ethercat coupler  (don't forget this bit )
EL2609 18x 24v digital output 
and possibly the wrong encoder interface for TTL grrrr
 

 

Okay thank you ill try it now

Since I create the G-Code at home ....

Characters with Freecad ...Sheetcam

I check the result with qtplasmac_I_metric

Then drive with me to my hall and cut as far as possible, very good but what notice is this EStop label!

No matter what Estop setting I take the label I always have whether 0, 1 or 2!

Can you change that?

King regard

Juergen
 

Following the link to the kernel's git, Its interesting to see a string of commits about printk before the last 3 commits Phoronix mentions.
printk has been one of the most troublesome RT issues to solve so I would say that has been the enabler.
From memory printk prints error messages from the kernel to the console which is very slow and causes issues for RT
Its exciting...

Your latency looks fine for ethercat. To me it does not make sense to adopt ethercat and use another system for I/O. Use a ethercat I/O module

spumco wrote:

Thanks Rod.

When I first tried using this H2+ LCNC was in the middle of the python2/3 fiasco and I was struggling between Deb 10/11 and the r8125 drivers.
 

Me too and why I fled Debian 10 in favour of building from source on Bullseye. I had to build the wifi driver. Now that PC points to Seb's buildbot. It uses ethercat so not so sensitive to network latency. HArdkernel say building the NIC driver gives a lot better performance. I may have done that.

Well i have some results, but I'm not sure what they mean in real terms beyond the recomendations in the documentation. I would be curious to know how they compare to other peoples results.  

DUT                       base thread  (us)                  servo thread (us)

RPI 4b sd card       -24.7 (sdev2.5) +79.1        -149.2 (sdev5.4) +148.6
RPI 5   sd card       -23.6 (sdev 1.0) +19.3         -30.6  (sdev2.1) +31.6
RPI 5   NVME         -13.1 (sdev0.9) +12.1          -15.7 (sdev2.1) +16.3



 
(left running for 7 hours, result above unchanged)

Going by linuxcnc.org/docs/stable/html/install/latency-test.html  the sub 15 microsecond base jitter provided by the RPI 5 with NVME should allow software stepping and the hardware seems capable from this crude test.. And yes i did take a photo of the screen because i am a luddite.
 

@tommylight
I using pulse train servo system with encoder feedback to 7i95, the question for open loop system is to gain some insight in linuxcnc.
@PCW
Changing P to 500 cause system to oscillate so I adjust it down to 0.1-0.2 still cause an audible hums. Is that a sensible P term? Or should I go lower?

Despite taking apart the thc controller and examining the guts, I don't know how the thing works.
There's no encoder(i originally thought there was but it's actually a brake) and I wouldn't know how to identify a potentiometer feedback.
It would touch off on the top when turned on and then probe with either ohmic or current sense before cutting.
I assume it had some way of knowing it's height, but maybe I'm giving them too much credit.
Maybe I ought to pop that brake off and see if an encoder would fit. Tone rings, hall sensors, I'm all over the place.

As much as I am enjoying my journey down this rabbit hole, I don't wanna drag you down with me.
Trying to see things from your perspective, I can imagine thinking, "Why doesn't this guy just do what everyone else does, you know, the stuff that works?"
Sometimes I get lost in the details and forget what I'm even trying to accomplish.


 

In fact, Linux has been really close to merging PREEMPT_RT into mainline for years, and most of it has been mainlined during this time. The patchset size decreased significantly as parts of it were accepted, so there has been less patching with every new release. If it decreases to 0 in 6.12, that's great! The kernel will still need to be configured to enable PREEMPT_RT and built, but that's not a problem.

2020: www.phoronix.com/news/Linux-PREEMPT_RT-Soon
2022: www.phoronix.com/news/520-Maybe-Real-Time-PREEMPT_RT

Raspberry Pi Imager is a user-friendly software by Raspberry Pi Foundation for writing an operating system image to an SD card of Raspberry Pi or eMMC of a Compute Module. The interface includes a step where an image can be selected, and the selection includes third party operating systems as well. Getting LinuxCNC included in this list might help to raise awareness of the fact that LinuxCNC can run on RPi and of the project in general. Also, this can be the preferred and the easiest way of installing the OS for users who are not comfortable using the command line.

To submit LinuxCNC for inclusion, we need to host ready to use RPi images, 40x40 pixel icon and some JSON ( example submission ). When it's all accessible with direct links, someone should fill the form , and wait for approval.

So one of the first questions that seems to crop up is latency/jitter and general performance of the RPI5 vs PC hardware and older RPI models.
 
I don't have an old pc available but i do have a RPI 4b and a PRI 5, both with 8gb of ram. and i can test the RPI 5 with and without the PCIE NVME hat to see if that makes any meaningful difference.
For fun i might try a usb bootable image for the laptop i used for Mach4 and Ethernet Smooth Stepper.

All will be tested with Linux CNC 2.9.2, SD card tests are done with a fresh image from the RPI Imager using the same sd card. 

For the NVME test  i have been playing with that install(2.9.2) for a few days (and the jitter looks worse for it I think).

All tests done with 10x glx gears running and Linux CNC guide open in firefox and scrolled around to get some idea of loaded up performance. 

All RPI tests will be also using the same keyboard, mouse and HDMI + USB touch screen 

As a side note the NVME drive seems to make the PI5 feel more responsive and quicker to bootup. 

The performance of the PI4 with a desktop is new to me as i have only used it headless to run a 3d printer with klipper.  

Hi again.

I spent quite a bit of time on this in the past week and I believe I narrowed down the problem. My worry is that I don't know if it can even be solved, haha.

Firstly, I dug deeper into what rodw suggested with making sure I had a dedicated NIC to EtherCAT. Turns out the generic EC driver doesn't reserve one for itself. I found out there is an igb driver in the 6.1 kernel, which was great. I had to remove everything EC related and rebuild it from source, however, since the configure tool needed the --enable-igb option passed to it for igb support. You can't do that when you install from repositories AFAIK. Either way, now the NIC doesn't even show up under "ip a" anymore. EtherCAT has it completely reserved for itself, which is great.

Now, the real culprit. As I mentioned before, I saw some blink and you'll miss them spikes in the latency. After a lot of reading, I came to the conclusion it is related to Intel SMI (System Management Interrupt) . Diving into some more old documentation, I saw it mentioned as a culprit . However, these posts seem to be very very old at this point. The tool suggested at the end of that wiki article did not help me, as it only reports that "No SMI-enabled chipset found".

This cannot be the case, though, as in my BIOS there is clearly a setting called "Global SMI Lock." Additionally, I found this utility called BITS. It provides exactly what I need - an SMI latency test. The PC failed said test miserably, with 300μ being reported. That is, by the way, the exact size of the spike the LinuxCNC Latency Test reported. I am attaching a photo of the test result. I am assuming the tool from the wiki article is simply very old and does not support the onboard PC's chipset (the CPU of which is an Intel Celeron N2930). The MSR 0x34 register as reported by turbostat is also 1.17, which I am not sure how to interpret exactly, but seeing as it is well over 0, it must not be good.

I will spend the day trying to somehow disable SMI and testing the machine with a different PC that I know passes the BITS SMI test.

Does anyone have any idea on how to go about disabling SMI? I believe the only option in my BIOS is this Global SMI Lock I mentioned which didn't seem to do much. On some old forums I saw people mentioning you need to mod and reflash your BIOS. I'd like to leave that as a last resort as doing it improperly will essentially deep fry the motherboard.