Using the DLL files of an application compiled with C# with labview

[Rolf Kalbermatter]

49 minutes ago, alvise said:

I created it as you suggested. But there are 2 things I can't understand.
-For "BYTE *pBuffer", is it necessary to convert the "Handle" array to string and then convert it back to U32 number?
- For ''if (!PlayM4_OpenStream(lPort, pBuffer, dwBufSize, 1024*1024))'', is it necessary to transmit the result of multiplying the number here with ''1024*1024''?

NO!

Configure that parameter simply as Array, Element Type U8, Pass as Data Pointer! But seriously you should first learn more C before trying to go further on this!

And there is no need to convert the byte array into a string to determine its length to pass to the DLL function. There is also an Array Size function, you know?

Edited June 7, 2022 by Rolf Kalbermatter

[alvise]

I understand better by applying C language. Actually, this is the first thing that came to my mind. But I contradicted myself because I don't have a good command of C language.But I really think about your suggestion. I have a lot of things to reconsider for better mastery of C language.

-Yes, I know it's "array size". 

I created it as I showed above, but the labview crashes.

- 1024*1024= ''1048576'' Do I need to send the result of the multiplication of two numbers directly?

[Rolf Kalbermatter]

What's the calling convention you set for these functions?

And no, you can calculate that multiplication by hand, your hand calculator, an abacus or explicitly in LabVIEW and wire that result to the Call Library Node. It does NOT matter.

But you will want to store that "port" value somewhere (maybe in a shift register, it's just a suggestion) to use when sending the actual data packages to the decoder.

Edited June 7, 2022 by Rolf Kalbermatter

[alvise]

Yes, there was a "CFLN" that I didn't select as WinApi.
Labview no longer crashes.

Here I will proceed to the next step.

In the meantime I created the change for nPort as you suggested.

But I guess it is necessary to add "CFLN", right? PlayM4_Play.

Edited June 7, 2022 by alvise

[dadreamer]

1 hour ago, alvise said:

PlayM4_Play

Well, it's a bit unclear whether you really need it. I found some conversations, where the guys were passing NULL as hWnd to it, when they didn't want it to paint. Logically it should start the buffer copying and decoding along with the rendering of the contents to some window. But maybe it just prepares its internal structures and the window as the next one is PlayM4_InputData, which actually grabs the buffer.

So I suggest implementing it with the CLFN, but setting hWnd as NULL (0) for now. You may remove it later, if it's not really needed.

Edited June 7, 2022 by dadreamer

[alvise]

7 minutes ago, dadreamer said:

Well, it's a bit unclear whether you really need it. I found some conversations, where the guys were passing NULL as hWnd to it, when they didn't want it to paint. Logically it should start the buffer copying and decoding along with the rendering of the contents to some window. But maybe it just prepares its internal structures and the window as the next one is PlayM4_InputData, which actually grabs the buffer.

-I haven't tried, but I guess so.

 

Now I want to adapt it to ''PlayM4_InputData'' labVIEW, but your previous idea was to replace it with ''PlayM4_GetJPEG''. So I'm looking into this function, but there is ''pJpeg'' in the parameters as in the picture below, what values should be sent to it and I guess its output should be an array of images, right? But here only DWORD returns a number in its output.

 

[dadreamer]

15 minutes ago, alvise said:

Now I want to adapt it to ''PlayM4_InputData'' labVIEW, but your previous idea was to replace it with ''PlayM4_GetJPEG''.

I think now, PlayM4_InputData is necessary. PlayM4_GetJPEG doesn't have an input to provide the "raw" buffer to decode, hence PlayM4_InputData takes care of it. It's being called on each callback, so looks like it copies the buffer to its internal storage to process.

15 minutes ago, alvise said:

So I'm looking into this function, but there is ''pJpeg'' in the parameters as in the picture below, what values should be sent to it and I guess its output should be an array of images, right?

Just allocate an U8 array of "w * h * 3/2" size and pass into the function. You should receive a JPEG memory stream in the pJpeg array, that could be translated into a common LV array later.

Edited June 7, 2022 by dadreamer

[Rolf Kalbermatter]

17 minutes ago, alvise said:

-I haven't tried, but I guess so.

 

Now I want to adapt it to ''PlayM4_InputData'' labVIEW, but your previous idea was to replace it with ''PlayM4_GetJPEG''. So I'm looking into this function, but there is ''pJpeg'' in the parameters as in the picture below, what values should be sent to it and I guess its output should be an array of images, right? But here only DWORD returns a number in its output.

 

You definitely will need the PlayM4_InputData(). Somehow you must provide the decoder with the continuous stream of data packages. Then it may or may not choke on the NULL HWND and it may or may not store the decoded data somewhere internal in the port and if it doesn't choke on the NULL HWND AND does store the decoded data somewhere in the port, you can call the PlayM4_GetJPEG() data. But of course you need to provide a large enough buffer to it, so MAYBE you can first call it with a NULL pJpeg and nBufSize = 0 and use the pJpegSize to call it again with a properly allocated buffer. Lots of may and may not and the only one who can find out about that is you!

[alvise]

1 hour ago, Rolf Kalbermatter said:

You definitely will need the PlayM4_InputData(). Somehow you must provide the decoder with the continuous stream of data packages. Then it may or may not choke on the NULL HWND and it may or may not store the decoded data somewhere internal in the port and if it doesn't choke on the NULL HWND AND does store the decoded data somewhere in the port, you can call the PlayM4_GetJPEG() data. But of course you need to provide a large enough buffer to it, so MAYBE you can first call it with a NULL pJpeg and nBufSize = 0 and use the pJpegSize to call it again with a properly allocated buffer. Lots of may and may not and the only one who can find out about that is you!

Firstly, I sent 0 value to ''pJPEG'' parameter of ''PlayM4_GetJPEG'' function and 0 value to ''nBufSize'' parameter. Everything worked. ''PlayM4_InputData'' returned 1 value. But ''PlayM4_GetJPEG'' function returned 0 value.

1 hour ago, dadreamer said:

Just allocate an U8 array of "w * h * 3/2" size and pass into the function. You should receive a JPEG memory stream in the pJpeg array, that could be translated into a common LV array later.

I made some plugins like below, but I don't understand exactly what you want to say here.

Since I cannot directly create a constant U8 array and write it to its zero index (for example: 640*480*3/2=460800), I need to convert this result to U8 array, right?

[Rolf Kalbermatter]

48 minutes ago, alvise said:

Firstly, I sent 0 value to ''pJPEG'' parameter of ''PlayM4_GetJPEG'' function and 0 value to ''nBufSize'' parameter. Everything worked. ''PlayM4_InputData'' returned 1 value. But ''PlayM4_GetJPEG'' function returned 0 value.

I made some plugins like below, but I don't understand exactly what you want to say here.

Since I cannot directly create a constant U8 array and write it to its zero index (for example: 640*480*3/2=460800), I need to convert this result to U8 array, right?

Unless your data strream consists of very large packets in the beginning, there is absolutely no guarantee that your PlayM4 stream already has enough data the first time around to produce a valid JPG image. It is very well possible that you must feed it with a dozen or more compressed data packages before it is able to even create a single full frame image. And until then the GetJPEG function will likely return false as it has no data to return yet.

Once it has enough data stored internally it may return a valid image but not in the buffer size that you passed to the IntputData method. That image will typically require quite a bit more bytes.

What I did mean to do is to call GetJPEG() first with a null pointer for the data and 0 for nBufSize and then use the return value of pJPEGSize to allocate a big enough buffer to call the function again This may or may not work (again!) depending on the PlayM4 API functionality.

Currently you are anyhow creating a crasho-mobil (again!!) since you pass in an empty byte array and have not configured that parameter to have a Minumum Size that is nBufSize. So you tell the functon: Look I have here a buffer and it contains at least nBufSize bytes, but you really pass in a buffer that contains 0 bytes. Kabom! Crash! as soon as the function has something to write into that buffer and tries to do that, since you told it that there is a buffer of a certain size it can write into.

Quote

Since I cannot directly create a constant U8 array and write it to its zero index (for example: 640*480*3/2=460800), I need to convert this result to U8 array, right?

I have no idea what you try to say with this. If you mean to create an array constant with that size, you can but it is useless. Either you use Initialize Array to create an array of the necessary size or you configure in the Call Library Node the Minimum Size parameter of your array to be that of one of the other parameters, (why not use the nBufSize parameter here, as it very accidentally tells the function what size the byte array parameter has been allocated to). I mean it is just an idea, but it would seem logical to me. 😃

Edited June 7, 2022 by Rolf Kalbermatter

[dadreamer]

41 minutes ago, alvise said:

Since I cannot directly create a constant U8 array

Why you cannot?..

https://www.ni.com/docs/en-US/bundle/labview/page/glang/initialize_array.html

[alvise]

4 hours ago, dadreamer said:

Just allocate an U8 array of "w * h * 3/2" size and pass into the function. You should receive a JPEG memory stream in the pJpeg array, that could be translated into a common LV array later.

First of all, there is something I don't really understand. Do I need to create something like the photo below?

Edited June 7, 2022 by alvise

[dadreamer]

Yes. Or you have an alternative - read the last paragraph from Rolf. Small note: you don't need to convert the array to U8 explicitly, just do a RMB click on the "0" constant and select its representation.

[Rolf Kalbermatter]

11 minutes ago, alvise said:

First of all, there is something I don't really understand. Do I need to create something like the photo below?

That would work, but you also need to wire the nBufSize parameter. Can you guess with what value?

[alvise]

25 minutes ago, Rolf Kalbermatter said:

That would work, but you also need to wire the nBufSize parameter. Can you guess with what value?

This is how I wired dwBufSize->nBufSize.

Ok, I edited it as follows.

Currently "pJpeg" returns a value that constantly changes.
But I guess I need to convert this value to an array to return an image.But it returns exactly the same value as ''dwBufSize''.

Edited June 7, 2022 by alvise

[dadreamer]

7 minutes ago, alvise said:

This is how I wired dwBufSize->nBufSize.

No! Another guess?

[alvise]

I could take the 'pJpeg' array size and pass the size to ''nBufSize'', but ''pJpegSize'' returns the array size I  sent

[dadreamer]

BTW did you test this?

3 hours ago, Rolf Kalbermatter said:

What I did mean to do is to call GetJPEG() first with a null pointer for the data and 0 for nBufSize and then use the return value of pJPEGSize to allocate a big enough buffer to call the function again

Edited June 7, 2022 by dadreamer

[alvise]

 

1 hour ago, dadreamer said:

BTW did you test this?

I don't really understand what rolf is trying to tell here. Even though I've read it many times.But I created and tried it as in the photo below.

   This is how I get a response.

 

To be frank, I tried to apply what I understood from what Rolf said in the picture below, I don't know if it's correct.

Edited June 7, 2022 by alvise

[dadreamer]

Ok, almost correct. You could replace that array constant with an U64 "0" constant, then configure that CLFN parameter as Unsigned Pointer-sized Integer and pass the "0" constant to the CLFN. But if it works as it is now, then leave.

Yes, now delete that "460800" constant and wire the pJpegSize from the first PlayM4_GetJPEG CLFN. That's the meaning of using two PlayM4_GetJPEG calls. First one gets the actual size, second one works with the properly allocated array of that size.

Now create an output array for the terminal marked with the red arrow. If it's a valid JPEG stream, you could try to save it to a binary file with a .jpeg extension and open it in image viewer. In order to convert the stream to a common LV array you may use some extra helper VI like this one.

Edited June 7, 2022 by dadreamer

[alvise]

First, I added the "array" indicator that you marked with a red arrow without making any changes, and the array output was returning only "0" for all indexes.
Then I changed the basis you suggested as in the photo below and the output I got is still "0".

[dadreamer]

Both of your PlayM4_GetJPEG calls return FALSE (failure). You need to figure out why.

[alvise]

Since I created the ''PlayM4_GetJPEG'' function it returns 0 on everything I've tried, 1 never returned.

[dadreamer]

Did you implement PlayM4_Play as suggested?

Edited June 7, 2022 by dadreamer

[alvise]

Yes,but  it was causing trouble every time. It was crashing Labview so I didn't add it later because I thought it wasn't necessary.

now like this.

 

 

I'm testing again. I set it as in the picture below.it is now work.Labview not crashed.

and..

I still get the following result.

Edited June 7, 2022 by alvise