Really don't see what could be different between configurations that affect basic communications.

unless there is some marginal power issue (does the 7I96S reset when starting the 5 axis configuration?)
Or maybe a memory fault of some kind in the PC, the reported error really has nothing to do with the number
of axis.

And as I said, your 5 axis hal/ini files work fine here with a 7I96S

A pncconf created configuration might be worth a try, just to see if a quite different
5 axis configuration changes the symptoms.

 

I’ll post my wiring diagrams once I’ve got them more organized, I’m working out of a google sheet that’s set up for tracking the status and purpose of each wire. 

Okay, I think I understand why it is doing what it does. 

The brake is working, but only during a speed change. So with C13 = 0.5S, and C023 at 110% current, the spindle speed change from 70 Hz to 20 Hz is braked (nicely). So that solves my decel between CSS facing cuts.

But switching spindle off, makes the spindle coast down. Since I am commanding the VFD with analog 0-10V, I thought spindle off just meant 0V commanded, but now I think about it, I sort off remember being surprised that is not the way LinuxCNC works. I suspect the spindle stop actually  deactivates the spindle drive enable signal which I have connected to VFD Pin 28,  and therefore the VFD is disabled every stop.

Since I controlling the VFD with a 0-10V analog signal, what can I do to have  LinuxCNC set that analog signal to 0V when I command a spindle stop?

I thought I was only only using Pin 28 it for machine start up and shut down, and E-Stop. It looks like I need to put a delay onto that disable to give the VFD time to be braked down to stop with the analog speed command, before the VFD is disabled.

RotarySMP wrote:

Those are the thermal overheat switch, which with that wiring will cut power to the main VFD in the case that the brake module overheats. To test it, that connection is not necessary.
 

Makes sense now that I look at the diagram more closely.image missing /media/kunena/emoticons/unsure.png

Are the LED's on the brake module illuminated?  Green for ready, yellow for braking active?  Just trying to work out if your #2 (dead component) theory is true.

thank you very much, I will try this tomorrow related to hal file, this is an example for a spindle, I believe it is similar for feed? I also need information on where this file should be located, in which Linux folder ``hist.comp``? and do I need to add any line to the ini, except halfile=...

 #SE USAN CON LOS POTENCIMETROS DE OVERRIDE PARA QUE AL ENCENDER LA MAQUINA MUESTRE EL VALOR CORRECTO DE LA POSICION DEL POTENCIOMETRO

loadrt hyst names=hyst.feedpot,hyst.SPDLpot
loadrt mux_generic config=fs2,fs2

#SE USAN CON LOS POTENCIMETROS DE OVERRIDE PARA QUE AL ENCENDER LA MAQUINA MUESTRE EL VALOR CORRECTO DE LA POSICION DEL POTENCIOMETRO

addf mux-gen.00 servo-thread
addf mux-gen.01 servo-thread
addf hyst.feedpot servo-thread
addf hyst.SPDLpot servo-thread

# --- OVERRIDE SIGNALS ---

# --- ANULAR VELOCIDAD DE AVANCE Y DEL SPINDLE ---
# ----BIT DIRECT VALUE

setp halui.feed-override.direct-value true
setp halui.spindle.0.override.direct-value true

# ESTABLECER ESCALA DE CAMBIOS DE LA ANULACION DE AVANCE Y SPINDLE

setp halui.feed-override.scale 0.01
setp halui.spindle.0.override.scale 0.01

#

---

OVERRIDE AVANCE

---

setp hyst.feedpot.gain 0.05
setp hyst.feedpot.deadband 0.7
setp hyst.feedpot.step 1
setp mux-gen.00.in-float-00 100

setp scale.1.gain 60.61 # ESCALAR LA ENTRADA ANALOGA DE AVANCE OVERRIDE, VALOR ANALOGO 200/3 VOLTIOS = 60.61
setp mux-gen.00.in-float-00 100 # ESTABLECER EL VALOR DE AVANCE OVERRIDE EN 100% CUANDO SE APAGA LA MAQUINA

net analogin0 scale.1.in <= hm2_7i92.0.7i73.0.0.analogin0
net feedpot-raw scale.1.out

net feedpot-raw hyst.feedpot.in
net feedpot-hyst hyst.feedpot.out mux-gen.00.in-float-01
net machine-is-on mux-gen.00.sel-bit-00
net feedpot-mux mux-gen.00.out-s32 halui.feed-override.counts

#

---

FIN OVERRIDE AVANCE

---

#

---

OVERRIDE VELOCIDAD SPINDLE----

setp hyst.SPDLpot.gain 0.05
setp hyst.SPDLpot.deadband 0.7
setp hyst.SPDLpot.step 1

setp scale.2.gain 60.61 # ESCALAR LA ENTRADA ANALOGA DEL SPINDLE OVERRIDE, VALOR ANALOGO 200/3 VOLTIOS = 60.61
setp mux-gen.01.in-float-00 100 # ESTABLECER EL VALOR DE SPINDLE OVERRIDE EN 100% CUANDO SE APAGA LA MAQUINA

net analogin1 scale.2.in <= hm2_7i92.0.7i73.0.0.analogin1
net SPDLpot-raw scale.2.out

net SPDLpot-raw hyst.SPDLpot.in
net SPDLpot-hyst hyst.SPDLpot.out mux-gen.01.in-float-01
net machine-is-on mux-gen.01.sel-bit-00
net SPDLpot-mux mux-gen.01.out-s32 halui.spindle.0.override.counts

Yes, I always get the same error. I've been trying things all day, changing the connections between the drivers that I'm sure work fine. Everything seems to be working correctly in terms of the electronics. I've tried all possible combinations with the drivers and the connections on the 7I96S.

Could there be a ‘conflict’ because there is another configuration that has worked with the same IP? Could there be some kind of ‘cache’?

If I remove the two added axes from the HAL, then I don't have any problems.

Thank you for the reply, but I just flashed at least the 3.3V power regulator with 24V on the still working 7i98 instead, so it will take some time for me to do the repair. Maybe I can even program it using raspberry GPIOs then.
By that coincidence I had an EEPROM with a working firmware, which I just soldered it on the bricked card. Now it works again, but the other one doesn't. image missing /media/kunena/emoticons/laughing.png

On Xilinx based cards you can use any working bitfile for fallback.
It wont have the blinking INIT LED indicator but otherwise the same.

This will protect against things like a power failure during flash update
It will not protect against writing firmware that does not work but has a
valid chip type and CRC (like firmware for a different card)

If you do have working fallback and a bad primary (Good CRC but does not work),
it is possible to recover without JTAG by intentionally causing an error in the primary
flash file load (say by shorting out the flash chip SDO pin briefly at power up)

PCW wrote:

If they did supply firmware, I would try re-writing it with:

mesaflash --device 7i92 --addr 10.10.10.10 --write  vendor_supplied_firmware_file_name.bit --reload

 

My Chinese 7i98 doesn't seem to have a fallback area, so I bricked one of mine by flashing a corrupted Chinese firmware. I wouldn't try again to flash it this way.image missing /media/kunena/emoticons/laughing.png

Since then I am doing it the Chinese way:

sudo mesaflash --device 7i92 --addr 192.168.1.121 --write 7i92.bit --fix --fallback
sudo mesaflash --device 7i92 --addr 192.168.1.121 --write 7i92.bit --fallback
sudo mesaflash --device 7i92 --addr 192.168.1.121 --reload --fallback

If the firmware doesn't work, it says: "No 7I98 board found" and only one LED is on.  So I know if the firmware is bad and I don't go further. After power cycling it, the previous firmware is loaded and it works again.

If it works (and only if it works), i continue with:

sudo mesaflash --device 7i92 --addr 192.168.1.121 --write 7i92.bit --fix  
sudo mesaflash --device 7i92 --addr 192.168.1.121 --write 7i92.bit  
sudo mesaflash --device 7i92 --addr 192.168.1.121 --reload

Then I power cycle it and check the pins:

sudo mesaflash --device 7i92 --addr 192.168.1.121 --readhmid

I've tested some original 7i92 and 7i98 bitfiles and they all work perfectly, so there is no point in using Chinese bitfiles except if the "7i92" card doesn't even look like a Mesa card and really needs a Chinese custom file. I believe, even the files supplied by the Chinese are mostly original files.

I also could flash a Chinese 7i98 fallback firmware called "7i92_fallback.bit" on a Chinese 7i92, so the 7i92 had 50 pins.image missing /media/kunena/emoticons/laughing.png
But it didn't brick, so I could flash the right firmware afterwards.