Jump to content

Ryan Vallieu

Members
  • Posts

    37
  • Joined

  • Last visited

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    2003

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Ryan Vallieu's Achievements

Rookie

Rookie (2/14)

  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare
  • Reacting Well Rare
  • Week One Done Rare

Recent Badges

0

Reputation

  1. Characteristic Handles are just U32 types. The readString first performs a readLong to get the stringsize, then performs the read - so it looks like that would be easy to implement.
  2. I think they meant that if you read out the string into your program you are responsible for allocating the memory. the Readstring function called in the Union code does allocate memory for the pointer, but I agree that I don't see a memory deallocation when done. What I meant by the StrLen being used to allocate was using it with the Build Array and feeding that in to the MoveBlock. I will definitely bring this up with the developer that gave me the library. Moving to a LabVIEW only solution shouldn't be too difficult for the communications. Just costs time at this point.
  3. Maybe I am completely misunderstanding here....the 'v' in the case of the switch detecting the string type is just a pointer to the first element of the string in memory. The nice thing about the GetValueByPointer.vi is that you don't need to wire anything in or know the size of the string, you just wire a blank string type. When I make the call into the getValue function, which is upstream of trying to dereference the pointer it returns if the switch detects string type, I am feeding getValue the Cluster of elements, in which 'v' is a U64, as that is the widest the data can be based on the types switched into v. When valuetype is used to drive the decoding and states the data in the U64 v is a Pointer I use that pointer to read the characters. GetValueByPointer handles the memory allocation for dereferencing the string, or in the case of StrLen and MoveBlock - the StrLen is used to allocate the memory for the String. After that I am not using the original Struct in the LabVIEW code and have converted the converted data into variant so I can convert back in the calling LabVIEW code based on valueType, I am not trying to reuse the Value structure from the C call. Am I missing something? The function within getValue that gets the datatype does perform the malloc. In the case of the valuetype being charString it calls a readString() function that performs a memory allocation to hold the string.
  4. I'm dumb 😒 and was looking at the output in the wrong spot in my code when initially trying to validate the StrLen and MoveBlock output you sent. ShaunR your version is working as well as the GetValueByPointer. I am just feeding in a blank string to the GetValueByPointer to define the string type for the return and it is returning the whole string including the \00 at the end.
  5. This is the xnode code that is generated for a string. I wondered why the other system owner wanted to do things that way myself. I guess because this is the API they provide to all the other systems developers. I certainly am talking to the remote system on another process just using the TCP refnum and building the packets and interpreting the incoming message packets. Maybe I will rework this piece in the future, but it is working with including the lvimptsl.so in my support folders
  6. I'm at a loss as to why one works and one doesn't. The code I have for the source of the Union is in my first post on this topic. It seems to be a \00 terminated C string pointer. 🤷‍♂️
  7. I got the same kind of strange behavior. With the Ptr coming from the v in the junction as a U64 - the GetValueByPointer.xnode works, your example points to the wrong memory block, and does not give the same answer. I do recognize WHERE the text came from, but not what the alignment correction would need to be to get StrLen and MoveBlock to point to the correct memory location.
  8. Ahhhhh... https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019ZANSA2&l=en-GB Adding the ..\resource\lvimptsl.so to the project and then making sure to add it to the Always Included as specified in the link under a support \resource\ folder in the build directory allowed the EXE code to run properly. Of course now it is going to bug me why StrLen wasn't working correctly...
  9. I find that GetValueByPointer.vi is working (in LabVIEW Development mode) with the u64 returned in the 'v' union value treating it as a pointer, but when I try the same thing with StrLen and passing the U64 as an Unsigned Pointer - StrLen appears to be not working, returning a size of only 2 bytes, when I expect 7, and then when I feed the u64 pointer into the MoveBlock and Size 2 it isn't returning any characters.
  10. Just found that the GetValueByPointer.xnode is not working in the built EXE - works in development environment. Bah Looks like I will need to set up a CLFN for StrLen and use that with MoveBlock
  11. Using the valueLabel and then either TypeCast or GetValueByPointer.xnode to convert from string is working. Thanks for the insight and the gained knowledge.
  12. Well I have the basic union code isolated and the LabVIEW wrapper seems to work to call into the function. Thanks guys!
  13. That info about Long on Linux being 64-bit cleared up a bunch of issues around the other function calls provided to me. The old system being interfaced is a Solaris system returning 32-bit Long information and the sendLong function called out on the PXIe CentOS system was sending out 64-bit Long types to the Solaris system, so all the messages had 32 extra bits of information. I've made the owner of the API aware of the issue that Long is not guaranteed to be 32-bit on a system so the API must be reworked.
  14. Thanks Rolf! I am on CentOS 7.6 64-bit on a PXIe-8135. Got side tracked, gonna make a test code that feeds constants through that data structure and wrap that so I can know what to expect for data. Thanks, giving that a go this morning.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.