03-25-2011 08:28 PM
I know this is not what you want to here but run LabVIEW under Windows. I prefer Mac for most things but with LabVIEW there just seems to be too many issues. I'm not saying ditch your mac and get a Windows machine. Most developers I know who use a Mac run the Windows version of LabVIEW on a virtual machine using Parallels. I am not sure if you can trade in your Mac LabVIEW for the Windows version though.
Sorry that I don't have any useful input on your problem. I think you are getting some good help from NI. But I am just suggesting something that will resolve this and possibly other issues.
03-25-2011
09:09 PM
- last edited on
03-31-2025
11:41 AM
by
Content Cleaner
When I try datasocket on Linux it does not work but GET.vi works just fine on Linux. So I don't think that GET is using Datasockets. May be you can use an external C file that downloads a file and saves it but I also think that a website should be downloadable even on a MAC. I am also surprised that nobody pointed this out before.
I guess people have reasons to use LabVIEW on MAC since it exists and people are using it. I am using Linux version since I prefer using Linux and also to be able to generate executables for Linux. It can be important that you want a cross platform application and LabVIEW claims to be a cross platform application. This was one of the reasons for deciding to write application using LabVIEW.
Of course they cannot make everything exactly same in different platforms but one would expect to find simple functionality.
When I search online for Linux Professional Labview and click functions it shows Data Communication VIs and Functions and under that you can see the DataSockets. It says it is in the Base packet.
http://sine.ni.com/nips/cds/view/p/lang/en/nid/4582
I am sure that they would not list this component on the webpage if it was not supported. There must be something we are doing wrong... Can any other Linux/Mac users check this example?
03-26-2011 11:06 AM
I just tried your DataSocketExample.vi on my Mac. Both DS Vis generate error 1181, Protocol not Recognized.
Mac OS X 10.6.7, LV 2010 SP1.
Lynn
03-26-2011
03:21 PM
- last edited on
03-31-2025
11:41 AM
by
Content Cleaner
@snlzkn wrote:
When I search online for Linux Professional Labview and click functions it shows Data Communication VIs and Functions and under that you can see the DataSockets. It says it is in the Base packet.
http://sine.ni.com/nips/cds/view/p/lang/en/nid/4582
I am sure that they would not list this component on the webpage if it was not supported. There must be something we are doing wrong... Can any other Linux/Mac users check this example?
This list is unfortunately not correct. I see for instance under it also Apple Events!!!!! But that is clearly a Mac only feature. Or the .NET functions which is for obvious reasons only Windows! (No Mono doesn't count, before NI goes and makes use of an alternate not officially by MS endorsed technology the hell is freezing over ).
On the other hand I didn't see the Pipe VIs, which is a Unix only feature!!
03-26-2011
03:35 PM
- last edited on
03-31-2025
11:42 AM
by
Content Cleaner
I found this information:
Gets or sets the URL to which the control is connected. Valid URLs for using the DataSocket properties to connect controls are the opc, ftp, and http protocols on Windows, and the dstp and file protocols on all LabVIEW-supported platforms.
It is official now 😄 It is interesting that nobody mentioned this before in the forum or anywhere on the internet.
I prefer a method that will work in Mac and Linux and Windows to download files. Maybe I will have to use external libraries/executables? Anybody with experience on this? Some external C code maybe?
06-08-2011 09:33 AM
This is highly disappointing. I support a team of scientists using a mixture of windows/mac/linux machines. We have supported them with tools like python and C++ for years. I hoped labview would now allow us easier platform independence than those languages. I told everyone LabVIEW was the way to go. We spent thousands of dollars on full development systems for 3 OS's. But now I keep running into these gotchas that make me look like a fool for suggesting labview is platform independent. For some reason, I can't even build an application on my LabVIEW 2010 sp1 full developer suite for mac.
My work around is that I am going to write python code that I call through the sys exec vi. This is problematic since I can't store session references in python between system exec calls. So everything will be slow. Also one could argue we don't need labview if we are using python anyway.
Sounds like NI's answer to ANY problem with the mac is "read the fine print somewhere in ni.com that says we don't support that function on the mac." They can't even find the fine print for us.
06-08-2011 09:51 AM
Another solution to the original problem would be possibly to simply code up a Get HTTP VI. Datasocket came probably into it since they support also HTTP Get under Windows but it's not the catch all answer. Yes a fully compliant Get HTTP would be a bit of work to implement but many times a basic HTTP Get (HTTP 1.0) works too.
And the interesting thing about this is that you don't even need to code it up yourself. It already exists, both on the NI forums and as (not officially released) OpenG VI. To get the OpenG VI you do have to access the CVS OpenG library repository on sourceforge, either by a CVS client or through the CVS Web Browser interface of Sourceforge.
06-08-2011 10:26 AM
In the meantime I had contact with the NI customer support and they found a workaround to use within LabVIEW and they told me they found a fix (for Mac and Linux which was experiencing similar problems) which will be included in LV2011 and its runtime.
I have to agree that the platform independence is not as good as one assumes but overall LV runs quite smooth in Mac for me, I am also able to build stuff!
06-08-2011 11:13 AM
On my MAC, I have the full development version with most of the toolkits installed. The HTTP methods are installed by default by the LabVIEW installer in the locations noted by the others. In my installation, the HTTP Get.vi fails. The error I see indicates that a Call Library Function cannot find the function being called. Because the BD are password protected , we cannot troubleshoot the problem.
Why on earth is this password protected? GET and for that matter the PUT and POST HTTP commands are very simple methods that use TCP. The protocol is described in www.ww3.org/protocols and is easily implemented in LabVIEW. The VI below is a very simple example of how to use GET to extract the contents of a web page. This is easily modified to suit a particular call to a web site if necessary and is platform independent.
JohnCS
06-08-2011 03:51 PM
In LabVIEW 2010 and LabVIEW 2010 SP1 for the Mac, some of the HttpClient VIs do not work. The workaround is to do the following:
Open a terminal and type:
cd /Applications/National\ Instruments/LabVIEW\ 2010
This will get you into the root LabVIEW directory. Next type:
ln -s resource/ni_httpClient_nossl.framework .
This will create a symlink in the main LabVIEW folder to the "resource/ni_httpClient_nossl.framework" folder. Go back and run your HTTP GET VI and you let me know if it works now.