Does anyone know the password for the GetSocketInfo VI in the above library? I would like to make my own library with several other functions. I would like to use the new lvlib format instead of the llb format. However, the one VI is password protected and therefore I cannot add it in any other library.
TCP_NODELAY.llb library
Started by
Mark Yedinak
, Sep 29 2011 10:05 PM
4 replies to this topic
#1
Mark Yedinak
-
- Premium Member
-
- 422 posts
Extremely Active
- Location:Huntley, IL
- Version:LabVIEW 2011
- Since:1997
Posted 29 September 2011 - 10:05 PM
---
Mark Yedinak - Certified LabVIEW Architect and LabVIEW Champion
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Mark Yedinak - Certified LabVIEW Architect and LabVIEW Champion
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
#2
Phillip Brooks
-
- Members
-
- 758 posts
The 500 club
- Location:Boston, MA
- Version:LabVIEW 8.6
- Since:1999
Posted 30 September 2011 - 03:41 PM
I'm not sure, but isn't "GetRawSocketFromConnectionID.vi" found in the TCP_NODELAY.LLB of that KB the the same as "vi.lib\Utility\tcp.llb\TCP Get Raw Net Object.vi"?.
Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
#3
ShaunR
-
- Members
-
- 2,274 posts
LabVIEW Archetype
- Version:LabVIEW 2009
- Since:1994
Posted 30 September 2011 - 04:07 PM
I believe it is (or at least a wrapper for it).I'm not sure, but isn't "GetRawSocketFromConnectionID.vi" found in the TCP_NODELAY.LLB of that KB the the same as "vi.lib\Utility\tcp.llb\TCP Get Raw Net Object.vi"?.
This is the prototype it (TCP Get Raw Net Object.vi) uses as the call to LabVIEW
int32_t NCGetRawNetObject(uint32_t nc, uintptr_t *netobject);
It is just a typecast to get the nc parm from the connection ID.
Edited by ShaunR, 30 September 2011 - 04:10 PM.
A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort. (Herm Albright 1876-1944).
Founder and general mischief maker on www.labview-tools.com.
SQlite aficionado and websocket zealot.
If it 'aint in LabVIEW, then you 'aint got a clue!
Founder and general mischief maker on www.labview-tools.com.
SQlite aficionado and websocket zealot.
If it 'aint in LabVIEW, then you 'aint got a clue!
#4
Mark Yedinak
-
- Premium Member
-
- 422 posts
Extremely Active
- Location:Huntley, IL
- Version:LabVIEW 2011
- Since:1997
Posted 03 October 2011 - 02:55 PM
I will have to look at that. If it uses a standard library in the LabVIEW distribution I can modify the code to use that. The problem with an llb file is that it uses absolute paths which can cause problems when using source code control. I would like to avoid that issue hence my desire to break the VIs out and add them to a lvlib file instead.
---
Mark Yedinak - Certified LabVIEW Architect and LabVIEW Champion
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Mark Yedinak - Certified LabVIEW Architect and LabVIEW Champion
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
#5
rolfk
-
- Premium Member
-
- 2,050 posts
LabVIEW Aficionado
- Location:Netherlands
- Version:LabVIEW 2011
- Since:1992
Posted 03 October 2011 - 06:59 PM
I will have to look at that. If it uses a standard library in the LabVIEW distribution I can modify the code to use that. The problem with an llb file is that it uses absolute paths which can cause problems when using source code control. I would like to avoid that issue hence my desire to break the VIs out and add them to a lvlib file instead.
The VI in VI lib should work. It may use a different API internally, if NI hasn't updated it, but should in fact do the same. Early on when networking was really sort of an addon API in LabVIEW (~ V 4) there existed a function to retrieve all kinds of internal parameters. One of them was to get the associated network socket of a network refnum. But that function ultimately called the predecessor of NCGetRawNetObject() which wasn't exported back then.
Being a standard VI lib function it should solve your source code control issues.
Rolf Kalbermatter
CIT Engineering Netherlands
A division of Test & Measurement Solutions
