Bostomatic 400-2 Retrofit

If the 7I90 has sserial firmware installed there is
nothing more needed for 7I90 setup

(just leave W3 in the 'S' position)

I was able to ping, flash & check the 7I94-7i89 combo, but the connection drops after a few minutes. I thought it was a NIC, I had to load drivers for the NIC and im not sure they were correct. So I got a new Intel NIC and it loaded automatically and still have the same issue of the connection deactivating. I go to the nm-tray and start it back up and I can ping the 7I94 again. Anybody else see this or is this normal?

PCW... I misread the 7I83 input power connector and hooked it up in reverse, will this damage the card? I hooked it up correctly and connected it up to a 12V PC power supply for testing and the supply shuts off immediately. The supply works fine with the other boards connected and the 7I83's unplugged. Any Ideas?

I went through the PNCconf for the first time and used the 7I80HD for the initial setup. Id this the best method? Linuxcnc diden't launch, and after looking at the main hal file I see I have a lot of editing to do!

1. What does "ip a" report? Dropped connections are not normal

2. If you connected a high current capable power supply to a 7I83 backwards
its likely you shorted the reverse protection diode. Depending on the current
capabilities of the supply this may be the only damaged component

1. Here is it "ip a" report A, with the link working B, after it drops.
A:
bosto400@BostoCNC:~$ 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
valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 34:17:eb:c5:b0:83 brd ff:ff:ff:ff:ff:ff
inet 192.168.90.105/24 brd 192.168.90.255 scope global dynamic noprefixroute eno1
valid_lft 86145sec preferred_lft 86145sec
inet6 fe80::135a:b283:9604:a8bb/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 68:05:ca:e8:4c:4e brd ff:ff:ff:ff:ff:ff
inet 10.10.10.2/8 brd 10.255.255.255 scope global noprefixroute enp4s0
valid_lft forever preferred_lft forever
inet6 fe80::6a05:caff:fee8:4c4e/64 scope link
valid_lft forever preferred_lft forever

B:
bosto400@BostoCNC:~$ 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
valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 34:17:eb:c5:b0:83 brd ff:ff:ff:ff:ff:ff
inet 192.168.90.105/24 brd 192.168.90.255 scope global dynamic noprefixroute eno1
valid_lft 85728sec preferred_lft 85728sec
inet6 fe80::135a:b283:9604:a8bb/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 68:05:ca:e8:4c:4e brd ff:ff:ff:ff:ff:ff

I did notice that the sub net was wierd (10.10.10.2/8 brd 10.255.255.255 ) so I changed the /9 to /24 and I get 10.10.10.2/24 brd 10.10.10.255 now, which I believe is correct.

2. I'm fairly sure I shorted the diode, what component # is the diode so I can test it.? I checked resistance across the v in terminals and both directions measured 0.
Is this something that is fixable? Send it in or can I do it?

1. How did you set the static IP address? I have see Wicd break existing connections like this
(how can the host lose its IP address in "B"? this should no happen even if the link is down)

2. The diode is CR1, a MRA4007

nduerr wrote:

I did notice that the sub net was wierd (10.10.10.2/8 brd 10.255.255.255 ) so I changed the /9 to /24 and I get 10.10.10.2/24 brd 10.10.10.255 now, which I believe is correct.

Not weird at all, it is normal for the 10.n.n.n IP range.
It will work either way.