SocketSetReuseAddr=TRUE on MAC OSX LION

[pRoFiT]

I have LabView 2011 installed on my Macintosh running Lion and the code that works in windows will not work on MAC. I'm getting error 60 socket already in use. Now i fixed this on windows by adding SocketSetReuseAddr=TRUE to my labview.ini file. Searching for a fix i tried to change the "Labview.app 2011 Preferences" file to include the same line. At first i added it to the one under users\library\preferences\ but every time i started labview it would remove that line and create a new preference file and backup mine as labview.save or labview.1. then i tried copying the preference file to the Labview.app folder and adding SocketSetReuseAddr=TRUE this seemed to keep the setting in both places but i still get error 60?

My Software is using some example library i found for multicast searching of upnp devices found here http://forums.ni.com/t5/LabVIEW/upnp-service-support-in-labview/m-p/287167/highlight/true#M151168 inside the search vi it says to add SocketSetReuseAddr=TRUE. Well this is fine in windows.

Is there any MAC uses out there that can help me with labview preferences? or Error 60?

-Corey

[pRoFiT]

bump. no one uses labview on MAC anymore? version 1 was only mac.

[johnsold]

I am running 10.6.8.  When I first tried that UPNP VI, I got the same error message. I added the key to the preferences file. The VI ran without error, but did nothing. I have no experience with UDP so I am not sure what to expect.  Then I started getting errors due to the old version of the General Error Handler and its subVIs.  I just used Diagram Disable to get rid of them.  The code runs.  I removed the key from the preferences fiel and the program stil runs.

Not very helpful, but if you have other suggestions I will give them a try.

Lynn

Using LV on the Mac since version 1.2.

p.s., Versions 2.0 and 2.2 also were Mac only.  Version 2.5 was the first Windows version.  There never was a version 2.5 for the Mac.

[johnsold]

If you want to live dangerously, look at the LabVIEW Wiki config file page.

Lynn

[pRoFiT]

Well i know adding that line to the file should work. It does work for windows.

When the example upnp program runs it should recieve responses from UPNP devices on the network. So you would need something on the network with UPNP. Most routers have it but not enabled. Some network printers have it. I use it for IP Video Cameras. i think some network media extenders use it for control.

Maybe ill try on my mac at home this weekend and see if i can get it to work. Need to install it first and MAC OSX LION 64 bit and labview are not really friendly yet.

Only other thing i noticed was when i changed the preference file under user\library\preferences the file would keep my setting up to the point where i loaded my project. Then after that the file would change. Maybe that file doesn't get loaded until a vi or project are opened? not sure.

I'll look at that configuration page. maybe something is in there i can change.

p.s. also im running an eval on the mac since my license is for windows. not sure if i can load my license into a MAC PC? ill contact my NI sales rep about that.

[johnsold]

I think the license is different for the Mac and Windows versions.  I have never heard of being able to transfer one.

I have a router.  I will look at its control settings to see if I can enable UPNP.

The Mac version of LV is only 32 bit, I think.

Lynn

[pRoFiT]

Okay not sure what's going on with this upnp (ssdp:discovery) code on the MAC.

I went strait to "Send MSEARCH multicast.vi" and opened up wireshark to get a better look at the network traffic.

First off the "constant return" that is being used does not include /n So I removed it and replaced it with /r/n in a string constant, changed view to "/ Codes Display" to see the /.

All the TCP/IP and UDP code I've seen wont work without a proper return (/r/n)

Next when comparing the the example UPNP "Send MSEARCH multicast.vi" in wireshark compared to "Intel Device Spy" (a good upnp tool from Intel, found here http://software.intel.com/en-us/articles/intel-software-for-upnp-technology-technology-overview/ ) I noticed that device spy had an extra /r/n a the end. Typically in HTTP commands you end the header with an empty line and a /r/n Pretty much giving you your Header and then /r/n/r/n And this search has similarities..

On top of that I added "Content-Length: 0" but 0 content is a given for this function and in my windows app I don't include it and it works fine.

So now I have identical UDP Multicast calls. In wireshark I run the MAC Labview search. Nothing responds. I start Intel device spy and it sends the same command and everything on my network responds.

Okay at this point I'm going crazy! Using a freaken network app WIRESHARK shows that both commands are identical except for who sent it and one works and the other doesn't!!!! arghghrhghg. Frustrating.

Any Mac users get that upnp example to work? Maybe get a UPNP MAC tool and compare? I'm using intel device spy and wireshark from my windows pc to troubleshoot.

good thing is that the rest of my app seems to work fine on the MAC. except some wierd error 42 when using GET HTTP.

[ColdenR]

Hello pRoFiT,

It looks like there was a CAR (corrective action request) out on this issue. However, it is listed as fixed for LabVIEW 2011. Since you have LabVIEW 2011, in theory things should be working.

Can you try replicating this problem using "UDP Multicast Sender.vi" in the example finder (help --> Find Examples) under Networking --> TCP & UDP --> UDP Multicast Sender. If you could also use the UDP Multicast Sender.vi from that same directory to receive the message, then we could have an exact replication of the situation described in the CAR.