Advanced Search

I like things being spelt out. Assumption is the mother of all F ups.

I have been quietly mapping out calls from control.c which is part of EMCMOT down through to the scurve planner. Building up a relationship graph. When I have that a little more fleshed out will publish.

On blending, want to look into that more as to where and how. Grotius has mentioned (I believe) this would be covered by path rules. At the moment they are pretty basic. Focus has been elsewhere.

i suppose we do... i'm probably stating the obvious, but...

when passing any trajectory kink without a complete stop on it - x, y velocities will have a discontinuity.
when passing a transition from a line to an arc - accelerations will have a discontinuity.

some type of blending is required for all transitions: line-line, line-arc, arc-arc.
i guess opencn guys solved that with some matlab witchcraft...

Interesting graphs with the velocity commands diverging. Do we know why that is happening?

I would expect Mesaflash and hm2_spi to work since they use the generic SPI device driver
(as long as that's accessible and correct), but hm2-rpspi may well need to be updated
to match whatever SPI hardware the RPI5 has.

ATM I can't quite get SPI working, I think I may have a solution but will need to do some testing.
Just wondering if anyone else has found this to be an issue ?

This may affect 7i90, 7c80 and 7c81 boards.

Mesaflash seems to have an issue as well.

So far I've had no input from anyone on this issue.

Yes it is rt kernel. I built on the standard bookworm installation and Intel Cpu. I not try any other distro / iso. Since bookworm is the installation pretty easy. Load debian netinstall file -> write to stick -> and go. Plug and pray more or less In future time i will also try other distro. Should work for AMD too, but not Raspberry.
But for now i am really happy with my set up. Hp G3 SSF I5 with intel networkcard and old AMD graphics card. I disable on board graphics and network. Since this is tmax to hm2_7i76e is straigt on 340000 middle sometimes tmax by 450000 if i open Browser.
 

Calysto wrote:

New here.... my Pi4 1GB (yes, it exists! ) isn't good enough, my Pi5 4GB will be here soon. I'll test your images!

Those interested in having a working image on Raspberry Pi 5 can refer to this post:

forum.linuxcnc.org/9-installing-linuxcnc...berry-pi-5?start=20# 285747

For those who want to use the Raspberry Pi 5 with RaspiOS 64bit containing PREEMPT_RT, an image is available at this link: drive.google.com/file/d/16kKamxMKPdYAeJp...KLf/view?usp=sharing

On this image you can easily install a version of LinuxCNC with the installer script
www.linuxcnc.org/linuxcnc-install.sh
or by downloading the latest version 2.9.1 .deb packages from here
ftp.debian.org/debian/pool/main/l/linuxcnc/?C=M;O=D
Unfortunately, packages for bookworm and arm64 are not available at buildbot.linuxcnc.org/.

Finally you can create the latest version of LinuxCNC as reported here:
linuxcnc.org/docs/devel/html/code/building-linuxcnc.html

This is indeed a problem, i think if Joco test this on his machine he can get a following error.

velocity end=0

velocity end=1, here you see a vel-cmd jump.

New here.... my Pi4 1GB (yes, it exists! ) isn't good enough, my Pi5 4GB will be here soon. I'll test your images!

Any work around? Switching to a x86 computer?

doesn't non-zero end velocity lead to infinite jerks?

Hi,

Github is updates.
Joco, enable ve by setting the hal pin.

I thought to blend the rapids. I think this makes some sence.
 

Thanks Rod, you pointed me in the right direction and there was an easy fix here . Sorry I don't have Pi 5 yet to test your image.

The method is buried in comments in a commit or issue  in linuxcnc's git

I'll wait patiently for my image to be tested. .....