Advanced Search

What does

mesaflash --device ethernet --addr 10.10.10.10 --readhmid

report?

There was a firmware error in 5I25T firmware that was fixed toward the end of last year.

What is your .bin file date and md5 checksum?

The current version is

MD5 (5i25t_7i77_7i74d.bin) = 90c674c34dfdbb3d597f0886768fb830

Nov 22  2024
 

Awhile ago I had been trying to set up my mesa electronics for a conversion I would like to do. I needed to flash the proper firmware for a 7i77 and a 7i74d and I found the firmware and flashed it. But then it was no longer recognized by the readhmid command or the computer. I have done the fallback jumper thing and am able to flash the firmware and do the reload command and I see it has changed the pins but then when I power cycle and move the jumper it is not recognized again on boot up. What am I doing wrong?

I believe the high frequency parts are on the other side of the wall to the left. Pic attached of what i think is the high frequency parts.

The torch- and work+ have been identified so that shouldn't be a problem.

 

 When I remove that, the following error occurs.



 

  If I understand correctly, he has a problem with 6040, which would be the control word.
Unfortunately, I don't understand what the problem is with it. It is present in both files.

To toggle program run/stop you would need to use :

forum.linuxcnc.org/30-cnc-machines/33529...20p-retrofit?start=0
There should be some configs attached there for BMC20, might help you get an idea but i do not think neither use Carousel component.
Edit,
this one uses gray code for 8 tools i think, was way to long ago.
forum.linuxcnc.org/30-cnc-machines/31792...-sbz-130-01-retrofit

The problem is that stopping a program will also switch off coolants (mist and flood). This is inbuilt behavior so by connecting 'halui.program.stop' in your hal example you are clearing 'tog2nist0.is-on' which upsets the logic.

When 'tog2nist0.in' goes true and 'tog2nist0.is-on' is false it sets 'tog2nist0.on' to true until 'tog2nist0.is-on' goes true. It then sets 'tog2nist0.on' to false. (So it basically produces a pulse on 'tog2nist0.on').
See the logic diagram in the manpage:
github.com/LinuxCNC/linuxcnc/blob/0bc97e...nts/toggle2nist.comp
In your case:
When 'tog2nist0.in' goes true it sets 'tog2nist0.on' to true which causes a program stop which forces 'tog2nist0.is-on' FALSE so the component waits forever with 'tog2nist0.on' True.

One way around this would be to change the component to have a maximum waiting time for 'tog2nist0.is-on' to change state.

[edit]
Attached is a modified component. 
As an example set '.pulse_length' to 1000. Mind you it will only fix the lockup state not the flawed logic behind the hal construct. 

 

cnc@CNC:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 18:a9:05:29:cb:8b brd ff:ff:ff:ff:ff:ff
inet 10.10.10.1/24 brd 10.10.10.255 scope global enp0s25
valid_lft forever preferred_lft forever
inet6 fe80::1aa9:5ff:fe29:cb8b/64 scope link
valid_lft forever preferred_lft forever