Advanced Search

The frame ground on a 7I96/7I96S should connect to
the  earth ground. This is to protect the 7I96S from large
EMI/ static from the Ethernet connection. This is especially
important for noisy machines like plasma cutters.

The reason for the 5V and GND on the step/dir connectors
is to support single ended use. For single ended logic level
drives or drives with common cathode connected OPTOs,
you would typically use STEP+/DIR+ and GND. For drives
with common anode connected OPTOs, you would use
STEP-/DIR- and +5V

meister wrote:

Also possible with W5500 on Mac level
 

No Thank You Very Much. Interesting none the less. 

What we currently have is STUPID FAST and high performance already. Unless a mysterious someone has a requirement for an hypersonic motion machine-tool, nobody here (in our star system anyway) will be able to ceiling the perf of RIO as-is on any parts/processes level. 

Not sure what you did but after updating the git today I'm clocking this x2 speed of what it was a few days ago. Used to be 2.5ms, now down to little more than a millisecond. Impressive stuff, Olivier. 

Optos driving optos, people copying other designs with no real knowledge. Or “it’s what someone on cnczone recommended”.
re UDP, it’s simple to setup, proven by years of implementation and works.
I think what would be great, is that the FPGA reports it’s capabilities to the driver so the driver doesn’t require rebuilding. Tho it would make things way more complicated to implement.
Regarding isolated drivers that topic did come up a little while ago maybe 12 ish months, so it is something that has discussed.
Oh yeah common grounds with optos, that’s something I just can’t fathom. Maybe there is a reason in some applications, but for the most common application, providing isolation, I don’t get it.

These could be an idea for output
www.icbase.com/File/PDF/ONS/ONS56621412.pdf

Shielding can be a very deep topic but basically you can
1: Shield the wires (hopefully very short and not near high power/motor wires, can be challenging to debug/verify)
2: Use differential signals, routed together, ideally with a twisted pair

Differential is definitely the way to go, if your motor controller has separate D+/D- and S+/S- signals you should use them. Differential basically means one line will go high, the other will go low to represent a "1", and they will reverse to represent a "0". Doing it this way means that any electrical noise on the wires due to power supply noise, EMI, magnetic fields, etc. will affect both lines together.

Because differential signaling uses the voltage difference between the lines, most noise will not alter the signal.

For more info, lookup "Common mode noise" and "differential signaling".

If you do use differential signals, make sure to use either twisted pair (hacked Ethernet cables work well) or are routed very close together.

This machine uses an Odroad H2+ (now H3 and H3+). I have used a few of them as you end up with a full AMD64 PC
www.hardkernel.com/shop/odroid-h3/

AndyDM01 wrote:

tommylight wrote:

Aaaaahhh paperless offices ... that never came. That was the promise made by e-mail .
Yes, print screen works on most distros, although XFCE used by LinuxCNC version of Debian did not work but it had screenshot in the main menu somewhere.
I pushed the prtsc button on the keyboard and it works

Flameshot is amazing for screen shots as you can save to file, to the clipboard, jusat capture a section and annotate your screenshot
sudo apt install flameshot
 

steveb48 wrote:

I added the 8168 DKMS driver, added r8168.aspm=0 r8168.eee_enable=0 pcie_aspm=off loglevel=3 to kernel settings and removed the no longer appropriate "hardware-irq-coalesce-rx-usecs 0" from interfaces.

I ran it a bunch yesterday and never saw the error so I have high hopes this was the problem.

Thanks once again for your help Pete!

Its amazing the difference when the right driver is installed. The 8168 driver really should be part of the default kernel. I've been cofiguring a PC with the R8111 with a Mesa card for the last couple of weeks. The only EFR I've seen is when I power off the Mesa card with Linuxcnc still running.

This computer was the reason why I went looking for solutions a couple of years ago and since then  many others have chipped in with enhancements.

yes

Also possible with W5500 on Mac level

github.com/njh/W5500MacRaw/blob/main/sendeth/sendeth.c

I would like to bypass the UDP and IP layers, similar to Ethercat with its own lean protocol.
but then only a direct connection is possible, but a very fast one with minimal delay

How did I missed that out. omg

?????
This is also only UDP via an RMII device and without a soft core

we have everything, but not yet for all FPGAs and toolchains:
github.com/multigcs/riocore/tree/dev/riocore/plugins/rmii
github.com/multigcs/riocore/tree/dev/riocore/plugins/arty_mii

Do you mean this permisions?

?

I have a spare Mesa 7I92H here. If it would help. But she made some trouble and sometimes seems to forget the IP adress and needed some reboots to work again

OK I will see what can fit.