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

[alvise]

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.

[dadreamer]

Re-read my previous message. And maybe you have a large bunch of events in the queue? Check with the Event Inspector.

Edited June 8, 2022 by dadreamer

[alvise]

I read your previous post and set Everything to UI thread. But the problem is not solved. Labview runs slow when I use the event inspector window. But I guess there are too many events in the queue.

[dadreamer]

5 minutes ago, alvise said:

Everything to UI thread

To any thread. They should become yellow. But yes, you have a way too much events queued!

[alvise]

Should I select all function nodes as Any thread?

Edited June 8, 2022 by alvise

[dadreamer]

4 minutes ago, alvise said:

Should I select all function nodes as Any thread?

46 minutes ago, dadreamer said:

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

[dadreamer]

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

[alvise]

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 June 8, 2022 by alvise

[alvise]

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 June 8, 2022 by alvise

[ShaunR]

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.

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 June 8, 2022 by ShaunR

[alvise]

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.

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.

[dadreamer]

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.

[alvise]

I created something like below, but I don't understand how to save it only once. Because there are numbers of elements that come one after another, constantly changing.how do I know and save only one whole picture is taken.

[dadreamer]

Just save and look at it. It's just for a one-time test anyway, so doesn't matters which moment you're capturing on your camera. You don't need that inner "2" Case Structure, remove it.

[alvise]

I removed the case structure you told me to remove and nothing is saved in the saved jpg file.

[dadreamer]

Can you zip it? The forum tries to handle it in its own way.

[alvise]

of course.

Hikvision-labviewSDK-Test-v1.0.9.rar

Edited June 8, 2022 by alvise

[dadreamer]

I meant that testt.jpg .............

[alvise]

 of course

testt.rar

[dadreamer]

You forgot something.

 

[alvise]

hat did I forget? how did you do this?

Edited June 8, 2022 by alvise

[Rolf Kalbermatter]

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 June 8, 2022 by Rolf Kalbermatter

[alvise]

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.

 

[alvise]

30 minutes ago, dadreamer said:

You forgot something.

 

 

I have to use the method here, right?

Edited June 8, 2022 by alvise

[dadreamer]

6 minutes ago, alvise said:

I have to use the method here, right?

You may stick with that Decode Image Stream VI, if you prefer JPEG format.

33 minutes ago, alvise said:

how did you do this?

Look at the Write to Binary File VI more closely.