Jump to content

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


Recommended Posts

I just created and tested something like below, but still, if I press the stream button once and the data starts to be received, when I press the "Stream" button again to stop the data flow, the stream does not stop immediately, but after a certain time it stops and I can stop the VI.

image.png.09d3593ef1797e945dcb581978055a86.png

Link to comment

What if you switch all the HikVision and PlayM4 CLFNs from UI thread to any thread (yellow coloring)?

rolf:If you set the Cal Library Node to "run in any thread" it will be executed in whatever thread the actual VI happens to execute at that moment. Unless you set the VI or one of its callers to execute explicitly in the UI thread, there is absolutely no chance that the Call Library Node will be executed in the UI thread. :)

What I can briefly explain is that if I set it in the UI thread, I can run unsafe DLLs. But if I run it as "Any thread", I will run it in the unsuitable thread. This can cause problems :)

19 minutes ago, dadreamer said:

But if GetJPEG call is blocking, you don't have any other ways except implementing PlayM4 callback in the C code.

.That's exactly what I don't know.

Edited by alvise
Link to comment

I set the resolution of the camera to 1280x720 and the problem was solved.

I guess this was a problem because the data was too much.

3 hours ago, dadreamer said:

Can you save that pJpeg array into a binary file and open it in a viewer? Just to make sure it's the cam image.

I'm trying to use the method you suggested earlier here but what do I need to do to save it as just one image. or is it just one image? I guess not.

Edited by alvise
Link to comment
1 hour ago, alvise said:

the stream does not stop immediately, but after a certain time it stops and I can stop the VI.

You can use the Flush Event Queue if you want it to stop immediately instead of waiting for it to consume all events.

image.png.715b10f9561dc52d35747d20cfe06b16.png

If you are not consuming fast enough then eventually you will run out of memory so this VI can also be used to keep a maximum number of events (or over a time) and drop some if that occurs. That would ensure you never run out of memory and you will notice that you get discontinuities in the video (frames dropped) when it is happening.You can even have a boolean on screen to tell you that frames are being dropped.

Edited by ShaunR
Link to comment
20 minutes ago, ShaunR said:

You can use the Flush Event Queue if you want it to stop immediately instead of waiting for it to consume all events.

image.png.715b10f9561dc52d35747d20cfe06b16.png

If you are not consuming fast enough then eventually you will run out of memory so this VI can also be used to keep a maximum number of events (or over a time) and drop some if that occurs. That would ensure you never run out of memory and you will notice that you get discontinuities in the video (frames dropped) when it is happening.You can even have a boolean on screen to tell you that frames are being dropped.

Thanks for the answer, as I said above, actually 1280x720 resolution is enough right now and making a correction in this way solved the problem.
-Currently I'm just trying to save a jpeg array as a photo, but I can't find a clear solution. Currently I'm saving the data as binary using a method like below, but I'm struggling with how to save it as a jpeg.

Link to comment
1 hour ago, alvise said:

What I can briefly explain is that if I set it in the UI thread, I can run unsafe DLLs. But if I run it as "Any thread", I will run it in the unsuitable thread. This can cause problems :)

I doubt there would be problems. Rolf already has set the CLFNs in his HikVision examples to any thread, so I could conclude that those functions are reenterant (thread-safe). Of course, it must be clarified with the documentation from the developer, but I accepted it on faith. 🙂

Moreover, you should move your GetJPEG call to a parallel loop as it's blocking your callback event frame, not letting it to process another events. Hence you see freezes of the GUI. Or limit the event queue in the Event Structure settings. Or use Flush Event Queue as suggested.

1 hour ago, alvise said:

or is it just one image? I guess not.

It is. Why do you think otherwise?

11 minutes ago, alvise said:

I'm struggling with how to save it as a jpeg.

What's your issue? Just write the array into a binary file with a ".jpg" extension exactly one time and you're done.

Link to comment
2 hours ago, alvise said:

What I can briefly explain is that if I set it in the UI thread, I can run unsafe DLLs. But if I run it as "Any thread", I will run it in the unsuitable thread. This can cause problems :)

The documentation for the PlayM4 shared library states explicitly that the DLL should be since version 6.1.1.17 multithreading safe. Of course that statement can be as true or false as anything but it is probably safe to assume for now that it SHOULD work if we don't do massive multithreading. And since we run pretty much everything actually in our test VI event structure it is actually executing very sequentially so the multithreading aspect shouldn't even come into play for now. For a more generic library there would need to be a lot more testing needed however.

And I would actually pull the whole thing a bit apart. I have cleaned up a lot of stuff and put the PlayM4 functions in their own library. My idea was to push the image retrieval into the the timeout case as in included example. Adding that into the data callback may be a little too much taxing. Also Once we know that the callback data seems to be working I would actually remove the data array on the front panel. That does take quite a bit of performance as LabVIEW needs to create a copy of that array every time to display in the control.

Depending on how much the callback event taxes the system it may however never arrive in the timeout case so possibly there is never any update of the BMP data. If that happens you have anyhow already reached the limit of what your system can do and there is simply no way to try to make this still work in this way.

The main idea is that if the program does get into the timeout event case I try to retrieve the current played/decoded frame number and if that is different than the previous one, the stream should be able to provide a BMP image. Retrieve it and once we get there we can look further. I choose to use a BMP retrieval as that should be already in 32-bit RGBx format and that should then be fairly easy (but anything but performant) to pull into a LabVIEW pixmap.

184663212_Hikvision-labviewSDK-Test-v1.1.0.zip

Edited by Rolf Kalbermatter
Link to comment
11 minutes ago, Rolf Kalbermatter said:

The documentation for the Play4M shared library states explicitly that the DLL should be since version 6.0. multithreading safe. Of course that statement can be as true or false as anything but it is probably safe to assume for now that it SHOULD work if we don't do massive multithreading. And since we run pretty much everything actually in our test VI eventu structure it is actually executing very sequentially so the multithreading aspect shouldn't even come into play for now. For a more generic library there would need to be a lot of more testing however. 

Then you say that choosing "UI thread" for "Play4M" and "HCNetSDK.dll" makes more sense for now.

 

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