Advanced Search

I'm sorry
I think you misunderstood me.
I am using the component and trying to understand how the process works from a control technology perspective.
Are the servos initialized and their status checked first, and then the homing process started, or is the homing process started without checking?
What happens if a servo is not ready?
What happens if a servo does not start the homing process or starts it with a long delay (watchdog)?
How is monitoring performed if a coupled axis on a gantry does not start moving during homing?
Since Linuxcnc has no control over this type of homing, these error cases should be monitored, otherwise the machine could be damaged.

In my opinion, the homing process should be initialized first.
Then check whether all servos are in the correct operating mode.
Then start the homing process.
During the homing movement, monitor whether the axes are synchronized (gantry).

 

I understand that you resolved the SPI issue when the RPi was the SPI master and was talking to the Octopus, but for the Ethernet config the Octopus board is the SPI master talking to the W5500 chip. So I would first try to reduce the SPI speed by changing the line I mentioned before.

depronman wrote:

I downloaded the 2.9.8 latest version from the first link in the download page
Burned this iso to a pen drive under windows using Rufus latest version
Live preview works fine
Graphic install consistently fails at the point of installing GRUB

 
 

It's a bit hazy in my memory what I did the ocational time I ran into that. I recall fixing it by choosing a different partitioning scheme during installation.

edit:
One day it was simply not working (grub install failed) and I finally started over with a different pen drive then it just worked. My pen drive was not quite up to snuff. Also confirm your downloaded iso contains no errors.

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.