Jump to content

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


Recommended Posts

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 by Rolf Kalbermatter
Link to comment

image.png.e64f5ec7a6b567705776bb74dfc6782c.png

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.

image.png.96bd60c84a55734b63f2e2c6f0946149.png

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

Link to comment

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 by Rolf Kalbermatter
Link to comment

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

image.png.d6c235287e4cba4f50ef8642f662d93c.png
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.

image.png.ab50f1308023884de5a74cf5de16df90.png

Edited by alvise
Link to comment
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 by dadreamer
Link to comment
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.


 

image.png.46fe4934708389848435ed56e9c1d730.png

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.

image.png.8451925490edff98edaee590e4ead989.png

image.png.234da2fba0ed9d1c9beb71bb1990657c.png

 

Link to comment
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 by dadreamer
Link to comment
17 minutes ago, alvise said:

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


 

image.png.46fe4934708389848435ed56e9c1d730.png

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.

image.png.8451925490edff98edaee590e4ead989.png

image.png.234da2fba0ed9d1c9beb71bb1990657c.png

 

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!

Link to comment
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?

image.png.fee278109102f8903ef9225a0ec1e5f8.png

Link to comment
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?

image.png.fee278109102f8903ef9225a0ec1e5f8.png

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 by Rolf Kalbermatter
Link to comment
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?

image.png.7841de55893e078f4fa65e401acbf222.png

Edited by alvise
Link to comment
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.

image.png.73bf2d67fa56639e521e73e9ff263b11.png

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 by alvise
Link to comment

image.png.73bf2d67fa56639e521e73e9ff263b11.png.5efd970aedb3fbfd3b5e722e4b57b05f.png

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 by dadreamer
Link to comment

 

1 hour ago, dadreamer said:

image.png.73bf2d67fa56639e521e73e9ff263b11.png.5efd970aedb3fbfd3b5e722e4b57b05f.png

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.

image.png.b0e98cb6bc19154d5ad4a1974a6c8750.png

   image.png.fa353334342f3c7fe9014c2f73f1e29c.pngThis 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.

image.png.36a05dee070c0ab2ad0e019618b35d1e.png

Edited by alvise
Link to comment

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.

image.png.36a05dee070c0ab2ad0e019618b35d1e.png.2607ec531919b06f999cba5904d952f2.png

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 by dadreamer
Link to comment

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".

image.png.7879584bb6045f5ed2b8a0d51b15f97c.png

Link to comment

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.

image.png.f6c6619f9725ce2397dd7804b8fa2b47.png

 

 

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

image.png.f6b389567902999fa9080f8914b1f727.png

and..

image.png.4adffbdd86f1d69015cc280c28da2078.png

I still get the following result.

image.png.38ea63fd7ab25928fbbbcab78c610420.png

Edited by alvise
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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