sbRIO-9607 Eth0 and Eth1

[richtian]

Hi, 

We've been using sbRIO-9607 to create a product for quite a long time. However, recently, we notice some weird behavior related to Eth0 and Eth1 on the new sbRIO-9607. I'm wondering whether any expert can give me some hints.

Basically, in our design, we use both the Eth0 on sbRIO board and the Eth1 from the RMC connector. We've marked them as 192.168.1.x and 192.168.7.x, both static IPs. It's been working well for quite a few years. But with the latest sbRIO-9607 from NI, we've run into two issues.

1. The API to set Eth0 always returns an error while saving the new configuration. This works well with the old sbRIOs.

2. In the past, if my PC is connected to Eth1 (192.168.7.x), I can ping the Eth0 (192.168.1.x) well. But now, this does not work any more. However, if my PC is connect to Eth0, I can still ping the Eth1 well.

For the above two issues, I'm wondering whether that's a hardware issue (because some chips might be changed because of shortage of specific chips) or a software issue (if it is, it should be related to HW because I'm RADing an image which has been used for 2 years).

I'm hoping any expert can give me some guide.

Thanks

Richie

[KHartley]

Sorry these are all pretty vague but we've not had any issues with recent batches. We only  use the built in port.

Posting the error would be more helpful. Try splitting up your property node group to see which specific call is failing (IP Mode, IP Address, subnet) or causing the error on save.

Pinging the sbrio is more likely a window ARP table issue. You might have to clear the cache if something has become messed up. MAX can also get pissy about switching subnets without a reset.

If you've changed your drivers on the windows computer the entry points can change sometimes in different versions so be aware of that. Ever since 2017 daqmx now includes compactRIO. The safemode firmware could have changed would be my one guess for a "hardware change" but this would require new software in run mode as well for any "breaking" changes.

This is a somewhat old bug but back when I worked at NI the eth phys were particular about what they were talking to so the easiest workaround was a network switch between systems. Without a switch about 1-3% of our boots would result in failure to establish communication with our sbrio over TCP. Not all switches work but more than likely 1 out of 2 switches of different manufacturers will work. During commissioning of a system's we sometimes run into communication issues until we've established communication and move everything over to a static configuration. Fact of life and we retry usually successfully.

Good luck