Advanced Search

I just made logical changes in ldscript, by looking at 3 scripts in repository. I think you are good in programming so you can make out something by looking at those scripts.
FYI... I am using ben-jacobson repository for remora_stm32f4xx_pio. He has working on nucleo_f446 board.
No spi issue was resolved. Since I was using RPI4, I have to include spi_clk_div=32 as argument to make spi working.
Other issue with tmc was resolved by changing spi to spi2 and assigning new interrupt.

Hi,

I had a quick look to the platformio.ini and it seems consistent. For the ldscript I'm afraid I'm not the right person to look at it, as I have absolutely no experience with this. Did you already try to reduce SPI speed, as you had issues with SPI communication? I think this line set it to 45MHz in EthComms.cpp:

spiHandle.Init.BaudRatePrescaler        = SPI_BAUDRATEPRESCALER_2; 

I wrote that firmware to the board.
I used the discovery option and accepted the component changes.
This still make zero sense:

What is the PID output controlling, torque or velocity?

From the video it looks like you are controlling torque, in which case
you either need cascaded PID loops (inner  velocity --> torque and
outer position --> velocity loops) or a single loop with a large amount of D term

I would first  try adding D term to your existing setup. the more D term you add,
the more P term will be stable. 

A torque loop --> position loop with no D term, that is, the restoring force
is only proportional to displacement  is  basically a pendulum...
 

Looby wrote:

Cant get any to run live as they just hang at a blank cursor screen.
[1]

Cant even get anything installed due to a "bad archive mirror" error.
[2]

What causes this so I have some idea what to avoid in the future? What in the hardware would cause this?
[3]
 
 

1. I'm currently fighting with a pc with that disease. It seams to be a GPU related issue. I've tried literally everything I can think of, no luck. Odd thing is, I have an identical machine at a client, running the same hardware on Debian just fine. I'm ready to try swapping out the brand new Gigabyte RTX4060 8GB graphics card with another one, beginning to think I might have hit a genuine hardware fault. I'm running various other 4060's and this is the only one doing this.

Might be a bit tough to get into any diagnostics on the live boot to see what is failing. In my case I was able to ssh into the pc from another machine right next to it so I could look at things like: "sudo dmesg", "sudo lspci -v", "sudo journalctl -b 0" and discover the gpu is not properly starting. That pc is booting an SSD with Debian already installed, with open-ssh running. I tried Nvidia drivers of several varieties.

I do not know what graphics your machine runs, it might not even be Nvidia.

2. First thing I check when I get that error: Is my pc's clock set correctly? Usually that is the problem. It does not have to be perfectly correct, but there is a limit to where security certificates fail to work. I open a terminal and:
check the date:
nwe@debian:~$ date
Mon Feb  9 04:39:11 AM CST 2026
set the date:
nwe@debian:~$ sudo date -s "Mon Feb  9 04:39:11 AM 2026"
[sudo] password for nwe: {typed my password and hit enter}
Mon Feb  9 04:39:11 AM CST 2026

3. I feel your pain. Some hardware/software combinations simply fail to work correctly. It seems there's a lot of hardware that 'just works'. In general, avoiding low end hardware and very very new hardware can save you lots of grief. Search the forums and buy something that is working, I mean exactly the same model and version, lands you a pretty good chance of success. But, as you can read in my #1 above, not even that is a guarrantee. Two identical machines. One just works. The other just doesn't.

I'm not pointing fingers at Linux saying this. My biggest letdown of all time regarding unexpected incompatibilities was on a proprietary os.

Bonjour, j' ai une carte pcie parallèle lpt 2 ports puce asix 9865 . J ai essayé les 4 adresses proposé par " lspci -v" ans le fichier hall , in out epp ... Rien a faire je n' ai que les sorties pin 2 a 9 qui fonctionnent, les pin 1,14,16,17 ne renvoient aucun signal quelle que ce soit la configuration dans hall.
Quelqu'un a une idée ? Ma carte n ai peut-être pas compatible . Le pc est un DELL optiplex 7010 , et il n y a pas de réglage dans le bios 
Merci a vous 

After days this is my system now Linux version 6.1.0-42-rt-amd64 (This email address is being protected from spambots. You need JavaScript enabled to view it.) (gcc-12 (Debian 12.2.0-14 deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40), Linuxcnc 2.9.8 and Python 3.11.2

The Probe_Basic GUI starts but i still have errors -> see attached files

 

Also you would typically configure P2 if you only have one breakout board
as that has the first stepgens and pwmgens,

Here's firmware that places the first stepgens and PWMgen on P1:

 

(basically just reverses the connectors)  You would need to use
pncconfs "Discover" option to get it to display the correct
GPIO and channel numbers.

 

A 1.8V low level is not valid for a 5V single ended encoder output
Maximum low level for TTL signals is 0.8V

This may be a wiring error or similar.

Stepgens for 2-9 for axes. Where is two? Where is 10 thru 14?

Yes, the config will work, but features might not.
You have to choose stepgens or PWMgens or encoders that you want to use, also pins for IO if needed.

So you are saying that if everything on the config page says "unused", it will still work?

Remove the dots after the 0 for I and D.
From video, definitely something wrong, but no idea what, that is not normal oscillation as it is moving way to much back and forth.
Do some plots using halscope for command and f-error

Isn't always. LOL