Advanced Search

  #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.

Did you by any chance edit the hal and ini files on a windows PC, or maybe using Libreoffice?

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.

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.

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.
But it didn't brick, so I could flash the right firmware afterwards.




 

So, I did think a bit and decided to actually go on with a change to LinuxCNC. Thanks for the replies helping me to decide in that way.

I think I will try to leave the cabling in the machine mostly untouched, but completely remake everything in the electrical cabinet.

For many of the open questions I will probably stick closely to what Rotary did, as most of the design decisions were considered by this whole forum, and the pros and cons have been carefully considered. With that, I don’t see much of a point in redoing this myself.

I will update here now and again, but only with stuff specific to my project.

With this I will definitely change the Z-axis motor and driver. I do have a Chinese AASD driver from an old project that never happened.
It’s a 1 kW motor, so definitely overkill — but it is already there, so it will work.

One other thing: in the toolholders I got with the machine there was one that does not fit the machine. See picture.
If anyone has a machine that needs this style of toolholder, or knows someone who does, I would be happy to give it away.


 

Hi

This morning I was running v2.9-238.315 and later tested with v2.10-009.072. The issue was present on both versions.

I continued testing and the problem only occurs with o=1 and o=2 magic comments.
o=0 was always working correctly and did not cause any issue.

With o=1 and o=2, the material was written to the *_material.cfg* file, but QtPlasmaC showed a parameter error and did not update the material list. A restart of QtPlasmaC was required for the new material to appear.

I found the cause inside the function rewrite_material_file() in qtplasmac_gcode.
The code checks material_reload like this:But on my installation, this command returns:Since TRUE cannot be converted to int(), a ValueError exception is raised.
This stops the reload process, which leads to the UI not updating and to the misleading “parameter missing” message.

I applied a workaround that accepts both 0/1 and TRUE/FALSE strings:
After this fix:

* o=1 and o=2 now correctly create or update materials
* the UI refreshes immediately
* no more incorrect popup message
* no restart of QtPlasmaC required
* o=0 continues to work as before

I also added a local improvement: after a new material is created, it is automatically selected as the current active material.

If needed, I can provide a clean patch and test G-code examples.
I am also available to run additional tests if required.

I have attached to this post the NGC file I have been using since this morning.
The temporary example file was not working either, except when using o=0

Thanks

So it's a mystery, Your hal/ini files work for me.
(after changing to 10.10.10.10 IP address because that's how my test PC is setup)

Do you always get this error:

hm2_eth: ERROR: Could not retrieve hardware address (MAC) of 192.168.1.121: Resource temporarily unavailable

That happens before any joint/axis ini settings are processed and is only related to low level communications.

You can sometimes get this error after power cycling if the network link is not established yet, so could happen in testing
but is not in anyway related to the number of axis.

 

That is just a list of error codes produced by the Fanuc control. I have a working converter for the 4-wire, low speed (1.024 mbit/second) encoders. I am now trying to decipher the 2-wire, 2.73 mbit/sec encoders. I have been able to trick an encoder to start responding by flipping switches on a pulse generator. But, I tried to set up an FPGA to get the encoder to respond, and I get NOTHING!
So, these encoders apparently need a different command to select the mode before it will respond.
Jon

If you have made changes to any wiring, please upload the latest pic showing the current state of everything.

Thank you and good luck!

You can steal 5V from your PC either via USB or by tapping into the main power supply wires for HDDs and stuff (shut down your PC before you open it and splice wires).

There is some risk involved in doing so, but you should be fine.

Please note that USB has limited power available, you can also fry your motherboard much more easily through USB ports as they connect to the motherboard as opposed to the PSU directly.

A USB-B charger or a MEAN-WELL power supply is also a good option.

Perhaps some filter caps would help?

Large caps with a low ESR can damage your power supply/PC due to their very high inrush current; probably don't go above 470µF unless you are sure your power supply can handle it or you don't care about your power supply's survival.

Can you post your actual gcode file?

What version of qtplasmac are you running? It’s in the header of the window.

There is a temporary example file for
both metric and imperial in the nc_files\plasmac folder…  here: 

github.com/LinuxCNC/linuxcnc/blob/master...porary_materials.ngc

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.

One thing I didn't notice in the vid or the thread discussion is that there is a separate manual for the braking module.  It's referenced on page viii (Part G - 11) of the VFD manual.

The braking module manual shows a "T1" and "T2" connection on the module.. but those aren't shown in the main VFD manual.

Based on the diagram, I suspect those need mains power to 'activate' the braking module.

I'm sure there are some parameters to change as well, but this might be a possibility.  Maybe have a look?

And yes...dogshit manuals.