LabVIEW
Slow TCP duplex handling on remote connections
I got someting in NiViEnet.out, could it be something like this?
Roger
I'm 99% positive that the setsockopt function is actually in the vxWorks file (without any ending) but since it is the actual kernel it may be in a different binary format than the usual .out shared libraries and therefore the Call Library Node may not be able to link to it.
But all you would need to do is writing a small shared library module (.DLL on Windows, .so on Linux, .out on VxWorks. .Framework on Mac OS) that links this function and exports a somewhat different function name. (A different function name is very important since I learned the hard way that VxWorks has only one big global symbol table that any exported shared function is listed in and having a shared library export the same name as another already existing symbol makes that library simply fail to load.
You do not need the VxWorks Workbench or whatever it is called software. There is also a fully GNU based toolchain available. It is command line only while the VxWorks has a nice graphical user interface but it has worked for me in the past. NI has a distribution here to download. You just have to watch out that LabVIEW 8.2 uses a different VxWorks version than the newer LabVIEW versions and therefore needs also a different toolchain.
I'm currently working on a much more involved total replacement library for all LabVIEW network functions that would automatically support reading and setting the options and more on any connection, among other things such as IPv6, ICMP, raw sockets, and transparent SSL support. (I don't think IPv6 is supported on the RT targets though and getting SSL to work on there will also require some modifications to the SSL libraries too!) However I'm still quite a bit away from starting the work to compile and test that code for the real time targets so it won't be of much help for you right now.
RogerI wrote:I got someting in NiViEnet.out, could it be something like this?
Roger
Hmm, NiViEnet is the TCP/IP passport for the VISA software and as such obviously would need to IMPORT socket functions. So I have a strong suspicion that this is actually the import symbols table and not the export symbols table.
RogerI wrote:Rolf,
Does your tcp code have a FOSS license? If that is the case, how do I get hold of it?
/Roger
Sorry I do not intend to make the shared library source code of that LabVIEW library available.
It does make use of a few undocumented features in LabVIEW, but more importantly this source code represents MANY hours of programming, testing and debugging, especially the last two parts are VERY time consuming.
Okay, I see. Too bad though, you might have got at least two more eyes looking for bugs and helping out with debugging. 
As Linus Torvalds put it: "With enough eyes on the code, even the hardest bugs becomes trivial".
Roger
RogerI wrote:Okay, I see. Too bad though, you might have got at least two more eyes looking for bugs and helping out with debugging.
As Linus Torvalds put it: "With enough eyes on the code, even the hardest bugs becomes trivial".
Roger
You may be right but my experience with publishing C source code for LabVIEW related tools is that nobody bothers to look at it when they get some problem. And those who might using it for whatever they decide (independant if it is compatible with the license the source code was brought out) do not seem to report back anything from their findings. I have in all those years never ever received any bug report for any of the LabVIEW related C code I have made available. I would like to think that this is because there have been no bugs in my C code, but I do know better than that. 
Rolf, I bet you are or have used some Linux distro, tell me, how much source code have you contributed back to eg. the kernel?
My high estimate is that for every 1000 Linux machines or users out there, there exist max 1 hacker that contribute code to any FOSS project.
I solved my problem with a, "Cough", hax0r. Do a read after every write, and a write before every read. Too bad it creates extra IO and 1 byte extra traffic for every send and read.
What code have you FOSS'd?
Roger
RogerI wrote:
What code have you FOSS'd?
Roger
Well, quite a few libraries at OpenG are from my hand.
LabVIEW only:
- LabVIEW LargeFile library for Windows
- parts of the OpenG package manager which resulted later in the VIPM
- other contributions to OpenG
LabVIEW and C shared lib:
- LabVIEW ZIP library for Mac, Windows, Linux and LabVIEW RT
- LabVIEW Pipe library for Windows, Linux
- LabVIEW PortIO library for Windows
- LabPython library for Windows to integrate the Python interpreter into the LabVIEW script node, theoretically portable to Linux though never attempted it
Non-LabVIEW related:
- Some patches and fixes to the Wine project.
- A few minor patches to the ZIP library from Gilles Vollant based on zlib.
So while I certainly wouldn't count for making a significant difference in the FOSS world I do think I have done a little more than nothing. 
