I ran the test, disabling the 2nd Ethernet interface did not fix things - also I tried passing in the interface and got an Error 54, I tried passing in the IP address in string to IP and also using the string to IP with no input - both generated the error 54 which is something about a malformed address
Have you tried machine name instead of ip address?
Also try changing to static instead of DHCP to see if the same thing occurs.
Lastly, try using a different UDP port number and let me know if you see the same behavior.
Put an indicator after string to IP to verify that it is a valid formatted IP address.
I tried everything suggested without success - I found another thread on the group called "IGMP problem with PXI under LabVIEW 2015SP1" different OS (Pharlap) but exact same symptoms, this appears to be lack of support in the VXWorks kernel for the latest version of IGMP
I think the version of NI-RIO is 3.6 in our cRIO-9025s - can you tell me if updating to a later version with our LabVIEW 10 will work or possibly fix ? I notice that the latest version that is compatible with LabVIEW 10 SP1 is NI-RIO 13.1.1 - I'm wondering if the VXWorks version is different and maybe has support for IGMPV3 ?
Sorry for the late reply. That is a very old version of NI-RIO, so yes try upgrading and let me know what happens.
So I attempted to update to the last revision listed as compatible with LabVIEW 10 SP1 which is NI-RIO 13.1, this completely broke NI MAX (which had some rather cryptic error messages) and several other NI software elements - we are going to have to re-load and start over - So my next question is: what is the appropriate way to update NI-RIO ? do I need to download all the revisions since NI-RIO 3.6 and install in order ?
You do not need to install everything since 3.6. When you reinstall, do so in this order:
LabVIEW Development
LabVIEW modules such as Real-Time or FPGA
NI Drivers such as NI-RIO 13.1
update - was able to upgrade NI-RIO to version 13.1 by removing all NI software and re-installing in the order you recommended. Everything is working as before - this did NOT fix the IGMP multicast issue. I'm out of ideas on this. We can get the system to work by hardcoding the routers to subscribe to the multicast group itself - this keeps the route from getting pruned but doesn't explain why the CRIO does not respond to the IGMP query after initially opening the connection
I am unfortunately out of ideas as well. You have somewhat of a workaround though I understand it's a hack. I'm unsure why the cRIO does not respond to an IGMP query. I searched CAR's and there was a CAR #152908 that implemented IGMPv2 functionality to vxworks targets. If you have a standard support contract with NI, feel free to open a service request about this, as there may be a fix that R&D has that can only be accessed through a proper escalation chain via a service request.