Pointers in Labview

Similar Questions

• How to pass pointers around labview

  Hello

  What is the proper way to pass pointers, pointing to the DLL allocated memory around labview?

  I spent some time with the cast of type C standard working as:

  typedef struct
  {
      void *mem;
  } myVars;
  
  int InitMyVars(int64_t *myVarsLVPtr)
  {
      void *myVarsPtr = NULL;
      myVarsPtr = malloc(sizeof(myVars));
      if(myVarsPtr)
      {
          *myVarsLVPtr = (int64_t)myVarsPtr;
          return 0;
      }
      return -1;
  }
  
  int UseMyVars(int64_t *myVarsLVPtr)
  {
      void *myVarsPtr = NULL;
      myVarsPtr =(void*)*myVarsLVPtr;
      //return funcWithVars(myVarsPtr);
  }
  

  Subsequently set up nodes to call library as follows:

  

  And pass the pointer on labview as a 64-bit number (since it's a pointer, I value, it makes no difference if its signed or not signed, please facepalm me so bad)

  In this way is very ugly. I don't like it. Found several discussions, saying that "whenever someone writes a code like int tmp = (int)(&something); a little fluffy kitten chokes to death." Unfortunately, so far of programming was a certain felinicide. "It makes me a kittenchoker series.

  It is also dangerous for the different platforms, for example. i686 and x86_64.

  I was self learning all that now look back at it, it's like if I missed something some time.

  There must be a better way.

  I am grateful for the suggestions.

  
  

• Effective way to make and receive pointers with C/C++ DLLs in LabVIEW

  What is the best way to pass a handle using the dll programmed in Labwindows/CVI between call node of the Labview library?

  I read a very useful on post

  https://decibel.NI.com/content/docs/doc-9080/version/5 on and the reception of pointers with dll C in Labview.

  However, my request is for the Labview interface with a camera.  In the camera API, it defines

  #define void * CameraHandle

  And then a CamHandle variable should be used by a lot of other functions.

  In CVI, if not used as DLLs in Labview, I would

  Sub OpenCamera()

  {CameraHandle ;} CamHandle

  Sub SetParameter (CameraHandle CamHandle)

  {

  }

  void CloseCamera (CameraHandle CamHandle)

  {

  }

  If CamHandle is a type void *, how can I make it since one node/function in Labview when I use the Setup to call a library function?  In the post I read, it say how to get the value of the arrow tip using a pointer to the value, and then dereferencing pointer.  However, what I need, is to pass the pointer itself.

  Thank you very much!

  Best,

  Charles

  
  

• List of pointers Moveblock

  Hello

  I have a list of memory addresses and use Moveblock to get the values (which is a 640 x 480 arrray 2D in my case). That's just fine until calling Moveblock multiple times (for example using different memory addresses) for all my paintings 2D (120 tables). The problem is that it takes a few tens of ms FRO Labview to generate this 120 X 640 X 480 (when you use a loop that calls Moveblock 120 times). Is it possible to directly call a list of pointers and directly retrieve the corresponding 3D table.
  Best

  Well and where your array of pointers come from? The C code gets just a LabVIEW 3D Board, which is not an array of pointers, but simple a memory table with [column * lines * pages] elements. This is the table that you get after you have copied your array of pointers, which is nowhere to be seen in this code C, with MoveBlock() in a LabVIEW 3D Board. In order to do the same thing you do in LabVIEW with MoveBlock() you must have two parameters, the first being the pointer array (more dimensions 3, C pointers have inherent fixed size information) and the second being the table 3D of LabVIEW, then you must first use LabVIEW memory, from Manager to resize this 3D array handle before starting to copy the data into it using memcpy() or MoveBlock() would be too of work and is only slightly slowever as the best implementations of memcpy().

  Most likely, you won't be able to squezze a lot even if you implement that in memory of C. Copying takes time, if you do enforcement by calling a C function as MoveBlock() of LabVIEW or function as memcpy() in C code. There is a good chance that you can win a little because the LabVIEW diagram code made a few test validation, you can omit in your C code, but it will probably not like some exponential improvement. LabVIEW is implemented in C (++) and generally optimizations where a C programmer will need to spend a little time to get the same level. Of course your particular case of calling external code as MoveBlock() limits the possibility for LabVIEW make a lot of optimization, because he does not know what the code called behind the library node call made (even if you call a function of Manager of LabVIEW here) so it can't do things as the loop place , rescheduling of code and many other things without risking that some unknown to LabVIEW, side effect of the called function would be influenced.

  You think that your LabVIEW code is nothing more than a loop, but it you call in the function MoveBlock and the way you do that which might be important detail that now need us to understand what could be improved. Given that it is such a simple VI I don't understand the reluctance to simply post, but are rather some pseudo-code that you want to do us to complete for you the same thing you did in the LabVIEW code, we don't see.

• advice on craps in labview programming?

  Find how to make the dice work is quite difficult, but I'm not expert LabVIEW. Le but est de faire un jeu de craps de travail avec une structure de boîtier. A case for each of the 6 dice, more a 7th case by default. Everything must be in a while loop with a timer and a main stop button. There must be a button for the user to start a new game at any time. A digital display and logic should be used to determine the score. Pointers?

  

  Above shows how the case structure you should be connected. I hope you can find the rest yourself as this pretty well basic.

  If still not sure, do a free course of Labview.

• Menu fonts in LabVIEW 8.6

  I have problem with menu, of Greek characters in LabVIEW 8.6.

  I installed the patch to take care of other languages, and everything good in the development environment.

  But to exe (executable), Greek characters in menu cannot be displayed. To the front of the exe, they are ok.

  Any suggestions?

  Open your file labview.ini with notepad (it's the pure text). Copy the fonts settings in labview.ini file in the same directory as the exe file. You can find more pointers in this thread-> http://forums.ni.com/ni/board/message?board.id=170&message.id=384369#M384369

• assessment of suitability of LabVIEW for industrial machine control

  Greetings,

  I'm trying to determine if LabVIEW and related equipment are able to meet several organizational needs - which is a direct control of industrial machines as the main driver interface.  Specific IO is quite simple and not time critical, with the exception of a few security control.

  I'm trying to find information or use case examples where LabVIEW has been used in a Setup to autostart when the user/operator is ONLY presented with the Labview VI that acts as the user interface of the machine - without access to the underlying operating system - whether it is * NIX or Windows.

  Most of what I've found so far seems should be directed to LabVIEW providing a global monitoring environment, where the individual machines of control is managed using dedicated plc and HMI.  I would like to know if LabVIEW and related products can be used in place of traditional PLC and HMI hardware.  If not, what are some of the existing approaches for fusion environments?

  If anyone has experience or pointers to information, I would be grateful.

  See you soon,.

  Rob

  Industrial control, we do all the time with LV the first thing to understand is that it is a language of programming like the others - what will happen is what you write. Nothing more, nothing less.

  The second thing is that there is no "related material". LV code can run on a number of platforms, but the actual IO modules you use could in principle be all devices which you can talk to (which means that they have dedicated drivers or memoranda of support that you can use, such as Modbus).

  The third thing is that it is possible to use a desktop for that OS (we do regularly), these systems are not designed for this. Beyond security considerations you mentioned, that must be implemented in dedicated hardware anyway, you should always accept that it is running on a desktop OS means there is a chance of things occur occasionally because preempted or your machine may get stuck in total, etc. For systems that we do, it is generally quite acceptable (and in fact is not often), but it's something to know. We usually leave the UI of the BONE in place, but it is also possible to replace the application from the shell with your own application, and then you will not see the classic interface at all (although users who know what they're doing can access if they really want to). There are different versions of the OS that may be preferable to something like that, but I have no experience with it.

  An obvious point to raise is that NEITHER has a hardware PLC-like dedicated that can run your code of LV and is actually designed to do this. The most obvious is the cRIO devices family. These work exactly like robots, with the exception that they are significantly more efficient and much more expensive.

  In regard to the mix of things, the classic way is to have the code on the PLC information and using something like Modbus, exactly as interactions with HMI systems jobs. LV is not a HMI program, however. It has some advantages, like being able to encode and do custom things and a few drawbacks, like not being able to do the UIs of basic or logging as easily. There is an add-on for LV that is supposed to add a bit of this, called the DSC module, but I don't really have experience with it. The decision on whether to use a program to HMI or code your own (in BT or any other language) should depend on the system and the implementer.

  Again, LV is like any other programming language. You can control applications in C, but you must know C and build the relevant parts. Goes same for LV - you will need to know and to be able to write specific code you want. NOR has some reference designs, they come out on the subject, but I never watched their close collaboration. You can look at the table at the bottom of this article to see this - http://www.ni.com/example/30331/en/

• Call COM components as a service Windows 7 (NOT A WEB SERVICE!) via LabVIEW

  First of all, what I'm trying to do is completely new terrority for me and I've looked everywhere, impossible to find a solution. I have reviewed the following resources and tried to get out but nothing helps:

  [1] ActiveX and LabVIEW
  http://www.NI.com/white-paper/2983/en

  [2] ActiveX and COM - part I
  http://www.NI.com/white-paper/2981/en

  [3] tutorial: Configure the node of the function of the library Call to call a Simple DLL
  https://decibel.NI.com/content/docs/doc-9069

  My problem is that I got a COM which was installed to run as a Windows 7 service, always running in the background (service.msc). So far, it seems only to be an intuition that you shoul dbe able to use:

  (A) ActiveX in LabVIEW to call the COM object by name or the .dll file.

  (B) call the .dll file of the service using the library function node call

  I see the COM running as a service if I (service.msc). I see also two .dll files associated with this service (they have the same base name as the service running). Let's say the service is called "TestService" then the other two .dll are called "TestServicePK.dll" and "TestServiceXY.dll." In test ActiveX and node library function call, I tried to call the two .dll files. When I tried the ActiveX method I get "the selected file is not a .NET, type library or executable automation assembly."

  Also COM binaries were made in C++, but if I understand well there should not be a problem at least for the library call feature.

  This seems to be a case of corner.

  Actually COM! = ActiveX!

  COM uses ActiveX to implements its objects and also to instantiate and control their but COM is simply a binary model of the API and some functions to control the instantiation and the lifecycle of objects COM, nothing else. The only way to access COM objects correctly (when no ActiveX type library is provided) is to have a C (++) compiler that can analyze the header files according to interface with the interface object methods. All ActiveX controls use COM to implement the interface calling of their objects, but also adds a type library in the DLL and a few other niceties such as the properties of the object. This type library describes how to match the properties and methods of the ActiveX for real virtual table COM interface pointers.

  LabVIEW lists this type library in order to be able to interface to the COM, Active X objects interface. A pure COM library is missing all these subtleties. If LabVIEW would be favourable to a COM interface node, its configuration should allow the configuration of all the things that describes the type library. This configuration would require a lot of manual configuration details, similar to what the library node call, only a magnitude more complex. If this is not really an option.

  If your server COM DLL does not an ActiveX type library interface, the only way to access it in LabVIEW must obtain such a type library as an external interface (not possible for all COM components) or to wrap the COM DLL server by a traditional DLL, which translates the methods standard COM exported C functions then that may be called by the node library call.

  Creating a library of types from a single COM DLL is more or less unfeasable. You should at least have the original IDL file that was used to create the interface com write a C (++) wrapper for your object COM is very probably the most practical approach, but will require some good C programming knowledge as well as experience handling COM objects in C code.

• Impossible to deploy on cRIO versions after update Labview 2014 SP1 F3

  Hello world!

  I'm quite confused how to solve my problem.

  the NOR-update, I installed the critical update F3,

  but now I can't deploy my based on the cRIO-9068 more.

  It says that the version is different or I compiled for the wrong architecture.

  should I install drivers for devices of cRIO 2015? pointers would be welcome

  thx for your time and now for some screenshots to illustrate my problem

  

  my version of labview

  

  my version of cRIO and installed software

  

  

  * peinlich *.

  I misunderstood the error message.

  seems there is still startup.rtexe on the crio himself.

  which was not able to start,

  but it won't let me overwrite of the Project Explorer.

  SSH'ed in the device and delete all the files in/c/nor-rt/startup.

  and now it works

  Sorry for the spam

• How Labview grab handles in the array?

  I have an array of large 2by2, and I do a lot of travel such as the removal of the top row and add the data to rank the lowest. The size of the array never changes, but I manipulate the data a bit.

  My question is: how Labview manages this manipulation? Is this just smart enough to manipulate pointers rather than copy the values over and over again?

  I'm looking at the interface with the dll, and it would seem that Labview for a 2by2 arry have only a pointer to all the numbers such that the number is simply distributed over a block of memory. Is Labview all done with any size chart? Just store in a large part?

  Thank you!

  d1sturbanc3 wrote:

  I have an array of large 2by2, and I do a lot of travel such as the removal of the top row and add the data to rank the lowest. The size of the array never changes, but I manipulate the data a bit.

  My question is: how Labview manages this manipulation? Is this just smart enough to manipulate pointers rather than copy the values over and over again?

  I'm looking at the interface with the dll, and it would seem that Labview for a 2by2 arry have only a pointer to all the numbers such that the number is simply distributed over a block of memory. Is Labview all done with any size chart? Just store in much?

  Thank you!

  Yes to the most, "depends on" the rest of your questions.

  Operators of memory "inplace" you will work within a single buffer. Some of the normal array operators will do the same (replace the subset of table for example). Build table, no.

  Try to use "tools > profile > buffer Allocations... Show.

  To see where you have additional buffers in your code.

  BTW: The process using «Show the buffer...» "and then rewrite to eliminate is sometimes called"Chase points ".

  Have fun!

  Ben

• Python, call DLLs in LabVIEW: Fatal internal error when accessing output String Cluster

  Hello

  We have compiled a DLL in LabVIEW (TestError.dll) and tried to call it from Python.

  TestError.dll includes 2 functions:

  1 testErreur: cluster 1 entry string, 1 channel indicator

  2 TestError2: 1 channel input, 1 bunch of output string

  What we try to do in Python is actually something like this:

  1 provide values to controls in the functions of the DLL.

  2. call the DLL.

  3 get the values of the indicators.

  What we have seen are:

  1 read/write operations on normal data types (string, digital) indicators/controls are OK

  2. write operation on the Cluster string entry is OK

  3. read operation on the Cluster output string is not OK. The following error is still prompted for:

  «Unrecoverable internal error: 'MemoryManager.cpp', line 437.» LabVIEW version 8.6... »

  Also joined the TestError.prj and python code.

  Grateful if someone can help to explain why we get this error and how to overcome?

  Thank you

  howmean

  What we have seen are:

  1 read/write operations on normal data types (string, digital) indicators/controls are OK

  2. write operation on the Cluster string entry is OK

  3. read operation on the Cluster output string is not OK. The following error is still prompted for:

  «Unrecoverable internal error: 'MemoryManager.cpp', line 437.» LabVIEW version 8.6... »

  Also joined the TestError.prj and python code.

  It is very logical that it does not, and the bad news is, it cannot really be implemented reliable of a process not LabVIEW.

  LabVIEW channels (and tables) are very specific species. They are then called handles, which are pointers to a pointer to a block of memory. If you have a control or indicator on its own, the Prototype configuration allows you to configure this setting as a C. LabVIEW data pointer, when creating the DLL, create heels C for each exported function and place the code to do the translation between the past C pointer to and necessary LabVIEW data handle. For strings and arrays within the cluster, there is no configuration option and the DLL is expected to pass a structure with data handles native LabVIEW in there.

  You may say that creating handles data in your calling process enough to trick LabVIEW. For the input variables that actually CAN sometimes work (but is a delicate and dangerous generally to handle this). There is no way to make it work for output variables. LabVIEW will try to resize handle to fill data in that he wants to make. This resizing is done using internal memory manager of LabVIEW. This will work only if it had been allocated by EXACTLY the same instance of the memory manager. Otherwise, it refers to a different memory segment and catastophally fail. The only way to make this work perhaps, with luck, taking your heart and prayer to the gods, is to lvrt.dll to allocate a handle that you must pass to the DLL. Still find the good lvrt.dll, which will execute your DLL LabVIEW is a major challenge.

• use a C++ DLL in LabVIEW

  I have a DLL that has been written in C++, and the typedef in C++ code is defined as:
  CY_BUFFER
  Definition
  typedef struct
  {
  int size;
  char * data;
  } CY_BUFFER;

  There is a function that should return the number of version as shown below:

  C function
  Version CY_INT (CY_BUFFER * buffer);

  A sample of code C to write to call the DLL is listed here:
  Example in C
  #include "cy_runtime.h".
  const int CUDA_DEVICE = 0;
  If (Initialize (CUDA_DEVICE)! = CY_SUCCESS)
  Returns - 1;
  Buffer CY_BUFFER;
  If (init_buffer(&buffer)! = CY_SUCCESS)
  Returns - 1;
  If (version (& buffer)! = CY_SUCCESS)
  Returns - 1;
  If (free_buffer(&buffer)! = CY_SUCCESS)
  Returns - 1;

  I have built wrapper LabVIEW using the DLL import wizard, but may not know what I have to do. I read the pointers to C/C++ dll dereferenciant in LabVIEW, but I do not understand how to use. Y at - it someone who can point me in the right direction here.  I can't edit the C++ DLL, but I don't know in theory, only the types of data, I just may not know what the wizard trying to do when he created the GetValueByPointer VI code it generates automatically.  If its C++, do I need to not use the wizard at all and create from scratch?  Any help would be appreciated gratefully.

  In addition to what Nathan said, you probably have an alignment problem. C compilers tend to align the elements in a struct to their inherent normal size. This means that the char pointer will be aligned to 4 bytes when you use LabVIEW 32 bits and bytes 8 when you use LabVIEW 64 bit. Now since the DLL also provides the init both the free function, this makes things a little easier. You can simply create an array of 4 integers from 32-bit bytes, pass it as a pointer to array to the function init() and version() free() and the only thing you need to do before release called an additional function of MoveBlock() where you adjust the offset in this table for the number of bits of LabVIEW.

  

  This involves a number of things:

  (1) your struct is indeed using 8-byte alignment, which causes the pointer to the byte offset 4 in for 32-bit LabVIEW and structure at byte offset 8 for 64-bit LabVIEW. Are you of any changes by using 64-bit LabVIEW, now that you have these 4 additional elements of the cluster between the size and the pointer?

  (2) in fact, the size in the struct element specifies how much data is in the buffer tank.

  And for the functions of the DLL error handling was completely omitted. To match the C code, you have shown that you should always check the function returns the value too before continuing.

• What algorithm ZIP LabView use?

  Hello

  My basic question is: what algorithm ZIP uses the ZIP VI when compressing files?

  The case is that I have access to a file zip created from LabView, but I don't have access to LabView himself to decompress the file, so I have to use a third party program to decompress the file.

  Any info and pointers are appreciated.

  Kind regards

  Mads

  Mads,

  If you work with IO filo palette, right ZIP functions?

  The zip that results is then moved in a database.

  First question:

  You can extract the ZIP before it is copied to the database? If so, you can open using 7Zip, WinZip or WinRAR?

  Second question:

  If the ZIP file works before moving on to the database, but fails once he was pulled from the database: what kind of data do you use for the ZIP file in your database? Are you sure that the construction of the binary file of the ZIP is not changed by the database?

  Norbert

• Thr type hbitmap in the labview

  Hello

  I had a Dll located in the internet.

  Now, I want to use "Call library function node" to get the data of this DLL.

  Unfortunately, I don't, t know how to set the "HBITMAP" without knowing the type of law in labview.

  the code of the DLL: extern "C" __declspec (dllimport) bool __stdcall DataMatrixDecodeBitmap (HBITMAP hImage, char * pResult, int * pSize, int nTimeOut);

  

  Is any body knows the right type of HBITMAP in the labview? Table? or labview can, t take charge kind of guy.

  Any suggestions would be much appreciated.

  Thank you

  Hello

  try looking in the header, what is this type of data. It can be a custom structure defined in this file. If so, thread a cluster with the same elements that are in the structure.

  EDIT: found on google

  --------------

  Although Windows handles are under 32-bit Windows for most of the pointers to memory
  It would be a bad idea to try to directly access these data. Windows handles are
  supposed to be types of opaque data whose internal structure is only known for Windows
  and more specific to Windows versions that are similar or better than the one that created it.

  The Windows API gives you (almost) all the specific access features
  information inside a handful. HBITMAP would need to access the API
  function GetDIBits(). This function works with a HDC device context handle you
  probably need to get your capture card interface. This is necessary to convert
  device-dependent in a HBITMAP independent unit information
  (the GetDIBits DI) information in the settings that you want to receive.

  -----------------

  So, here's an I32 or I64, depending on your system. It is a pointer to a memory space.

  And here is a previous discussion: Forum OR

• LabVIEW XML, GXML or EasyXML?

  I develop routines to collect behavioural data.  I want to generate a "header file" that contains two types of data - experience at the level of (constant) data, such as the name of the object, the material settings, date, etc. and 'trial trial' data, such as what stimulus was used and what response was recorded.  I have will also be the collection of analog and digital data in separate files and record "pointers" in these files as part of data "trials."

  I happened to use XML to write the header file.  My thoughts are that the 'readable' was a plus, and the file format would be 'naturally' headed by the data that is generated.

  I noticed that there are three sets of XML routines, the 'native' screws of XML of LabVIEW, one OR 'package' called GXML, and a set of routines of JKI called EasyXML.  Other than if one assumes that EasyXML is "easy-to-use", are there recommendations or suggestions about which to use?  They have different functional properties?  What are the reasons to prefer one over the other?

  After doing some tests, the winner seems to be... (drum roll, please)... GXML.  It produces output "appearing to own", is pretty easy to use and has features 'editable' (I made a few "improvements" that make it more forgiving data I throw at it).  Hope she continues to get support from the community and NEITHER and became perhaps best known and most easily available.