LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1097 when passing array from C++ DLL to LabView

If the move positively causes the error, then there are only two possibilities left:

 

- something you do in preparing the driver is not right so that the function stumbles over the invalid data somehow.

- the function has a bug

 

The CLN function configuration at least can't be the problem, as that seems exactly how the function was meant to be called.

Rolf Kalbermatter
My Blog
0 Kudos
Message 51 of 55
(970 Views)

cb0023 wrote:

The run continuously strategy was a result of trying to escape these 1097 error messages. In loops they would constantly crash but running it as one iteration repeating in run continuously solved this problem (temporarily). Also the sequence is necessary because I want those actions to occur sequentially in that order so I'm afraid to some extent the sequences will be remaining. All that said any feedback regarding the 1097 I'm receiving from the below attached VI would be greatly appreciated!


When you say that it crashed in a while loop, what exactly occured? Did you get an error on a LabVIEW error wire, did LabVIEW pop up a dialog box saying an error occurred, did the application crash and quit unexectedly, or did something else happen? Can you upload code showing how you tried to use the VIs in a loop? Seems possible to me that there's a connection between the crash, and the problem you're seeing now.

 

Do you ever get the error on the first call to the function, or only on later calls? When you had it in a loop, did it ever crash on the first iteration? I wonder if by using Run Continuously, LabVIEW is in some way unloading and reloading the DLL between runs, which wouldn't happen if you placed it in a loop.

 

About the sequence structure: typically an error wire is used instead of a sequence structure to dictate execution order. At least one frame of the sequence isn't necessary as you have it now, and several more would no longer be needed if you properly replaced the local variables with wires.

0 Kudos
Message 52 of 55
(968 Views)

Hi, I´m trying to control a parallel port and I´m getting the same error as you Error 1097 occurred at Call Library Function Node in Untitled 2.vi

Actually, its working when I I´m yriting on the port. Im just getting the problem when I want to read

Is there anyone who can help me please ??

0 Kudos
Message 53 of 55
(780 Views)

mriwah,

 

Since this is an older thread, I would recommend that you make a new thread on this topic so your issue can get more visibility.

Kirk L. | Applications Engineer | National Instruments
0 Kudos
Message 54 of 55
(758 Views)

@mriwah wrote:

Hi, I´m trying to control a parallel port and I´m getting the same error as you Error 1097 occurred at Call Library Function Node in Untitled 2.vi

Actually, its working when I I´m yriting on the port. Im just getting the problem when I want to read

Is there anyone who can help me please ??


I can't right now take a look at your VI and don't know which Windows API you are trying to use, but your mentioning that writing works but reading doesn't, would hint at a typical LabVIEW programmer error when tryingt to access C functions through the Call Library Node. When you call a C function that should return some information in one of the parameters, the caller usually has to allocate the memory buffer before calling the C function. This is contrary to normal LabVIEW where each function allocates whatever memory buffer it needs itself.

 

So your data buffer in which your C function should write the data bytes you want to read needs to be allocated by you. You  can do that with the Initialize Array function in LabVIEW with a big enough size that the function documentation for your C function should mention. Most C API that can return a variable amount of data usually use at least two parameters for this the first being a byte array buffer and the second a numeric integer that tells the function how big the buffer was allocated in which the function should return the data. Sometimes the function returns a third parameter which indicates how many bytes of the buffer it actually filled in. This third parameter is then either passed as a seperated integer number passed by reference (as pointer) or the length parameter itself is passed by reference and is initialized to the actual buffer size before calling the function, and updated by the function to indicate how much data was actually returned.

Rolf Kalbermatter
My Blog
0 Kudos
Message 55 of 55
(745 Views)