Jump to content

bublina

Members
  • Posts

    31
  • Joined

  • Last visited

Everything posted by bublina

  1. So I can make files, deploy them into LabVIEW directories and it will make the RT software package pop in MAX and also take care of the binaries to be deployed into RT target when used ? Sounds good. I tried to find how to do it (produce CDF files and follow some directory structure), but only found this: http://www.ni.com/white-paper/12919/en/#toc1 Which describes doing it through some NI wizard. I dont have CRIO (only seen it on the internet pictures ) nore any realtime module, so this is quite a time distant task. Thanks for the answer. p.s. Does the NI runtime include some mechanism to check for correct deployment of the dependencies, does it somehow translate OS errors when reporting missing *.so files? Does it make sense to drop usage of dlopen, dlclose and dlsym on the realtime linux target? Upon reading on the ELF linker/loader, it seems to me, that programmatically loading shared objects brings more bad than good, since the ELF loader does already do all this stuff much better than windows + shared objects have VERSION!!? on linux.
  2. Hi, I have a library, that is using unmanaged built binary code, so far I can target Windows32, Windows64. Also I am now attempting to compile with ARMv7 and x64 ni compilers for the latest rt-linux CRIOs. What is the correct way to install for different platforms using the VIPM ? 1. So far I just put all the data, that might be necessary, into the package and let my own VIs take care of the installation process (copy correct files to correct locations etc.). 2. The other way around would be to produce multiple libraries, like LIBRARY_WIN32, LIBRARY_WIN64, LIBRARY_LINRTx64 etc. and let the standard VIPM deploy it using the standard file deploy options.
  3. Yes yes, you are completely right. I was kinda dull and supertired when finaly revealing where the problem of my crashing was, so I just lazy posted here However, I think it is better to use DSNewHClr, that correctly initialized the handles to nullptr. It feels much safer, so all the if(*ptr) have predictible result. Thx for answer.
  4. Hello, I am passing some data from dll to labview. It is an array of clusters. Cluster looks like this: typedef struct { LStrHandle longname; LStrHandle name; uint8_t intraonly; uint8_t lossless; uint8_t lossy; } CodecInfo, **CodecInfoHdl; typedef struct CodecInfoArr { int32_t dimsize; CodecInfo Arr[1]; } CodecInfoArr, **CodecInfoArrHdl; But I think it is reproducable with any kind of array of clusters where are other handles, like LStrHandle in my case. The operation is pretty straightforward. I check the incoming handle, I handle the situation where it is empty or filled with data and in the next step I have an empty handle to work with. So far I have an array handle returned from DSNewHandle allocated for the resulting array size. I start copying the data, but since there are strings involved, I call my general char2LStrHandle function to fill string handles. void PrintChar2LVStrHandle(const char *charstr, LStrHandle *StrHandleP, bool forcenew = false) { MgErr error = mgNoErr; std::string temp = ""; if (charstr) { temp.assign(charstr); } if ((!IsHandleEmpty(StrHandleP)) && !forcenew) { error = DSDisposeHandle(*StrHandleP); if (error != mgNoErr) throw(WrpExcUser("PrintChar2LVStrHandle()", error)); } *StrHandleP = (LStrHandle)(DSNewHandle(Offset(LStr, str) + sizeof(uChar))); if (*StrHandleP == nullptr) throw(WrpExcUser("Could not allocate string handle", CUSTOMERROR)); //(**StrHandleP)->cnt = 0; error = LStrPrintf(*StrHandleP, (CStr)"%s", temp.c_str()); if (error != mgNoErr) throw(WrpExcUser("Could not print to string handle", error)); } There is a lot of junk&unnecesary code, but the core of the function is to check the handle, and if it is valid, just print into it. The function that checks the handle looks like this: bool IsHandleEmpty(const LStrHandle *h) { MgErr err, heaperr = mgNoErr; err = DSCheckHandle(*h); //heaperr = DSHeapCheck(0); if (err) return true; return false; } It is just a stupid wrapper around DSCheckHandle. Now the problem is, that with the way the array handle allocated the array elements, some handle pointers, from time to time point to memory so unfortunately, that the array elements that get processed later have string handle pointer pointing to memory that is already filled with data from previous array filling loop iterations. It is not the exactly same memory, since the data is little off (garbage, count is wrong etc.), but it is sufficient enough for the DSCheckHandle return, that the handle is valid. So the memory gets a treatment like it would be a real handle and it corrupts the labview heap, so when the data gets deallocated, LabView / runtime will crash. So far I tackled the solution with simple optional parameter (bool forcenew = false) and went through all the function references in code to set the flag if the data comes from new array handles. Finally the question: Is there more elegant solution to this, somehow correctly check the incoming string handle ?
  5. So problem causing is here: Project properities->Linker->Optimization->References if optimized = error, if not, all is ok. Some clarification would be nice, I only found it trial @ error.
  6. Hello, I am wrapping ffmpeg into LabView, so far I wrapped few functions to set up a stupid videoplayer, all works, but only in debug mode. once I want to use release build, during setting up the functions in library call dialog, I get error saying : "Entrypoint of procedure imaqCloseToolWindow could not be located in avcodec-54.dll" or such, I translated from windows native language. From the error description, it semmed to me a linker problem, but code compiles and linkes without errors. All DLLs are in place. So far, I did not find the build option, that might be causing this. Please help me, why is this happening. I know it is definitely some stupid nwbie mistake. I stripped down the code for release build to only contain returns and such. And still getting this error. This is how does the *.h file looks like: //Header for FFMPEG LV wrapper#define DLL_EXPORT __declspec(dllexport)#ifdef __cplusplus extern "C" {#endif#include "libavcodecavcodec.h"#include "libavformatavformat.h"#include "libswscaleswscale.h"#include "libavutilavutil.h"#include "nivision.h"#include <string.h>#pragma comment(lib, "devlibavcodec.lib")#pragma comment(lib, "devlibavformat.lib")#pragma comment(lib, "devlibswscale.lib")#pragma comment(lib, "devlibavutil.lib")#pragma comment(lib, "nivision.lib")#pragma pack(push, 1)typedef struct FFMPEG_Video{ AVFormatContext *pFormatCtx; AVCodecContext *pCodecCtx; AVCodec *pCodec; AVFrame *pDecFrame; AVFrame *pBGRAFrame; SwsContext *pConvertCtx; int VideoStream; int AudioStream;} pFFMPEG_Video;#pragma pack(pop)#pragma pack(push, 1)typedef struct{ char *name; Image *address;} IMAQ_Image;#pragma pack(pop)DLL_EXPORT int32_t FFMPEG_open_file(int32_t *session, char *path);DLL_EXPORT int32_t FFMPEG_read_frame(int32_t *session, IMAQ_Image *LVFrame);DLL_EXPORT int32_t FFMPEG_close_file(int32_t *session);DLL_EXPORT void FFMPEG_register_all(void);#ifdef __cplusplus }#endif The code compiles and links without warnings (W4) Please help Best regards
×
×
  • Create New...

Important Information

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