Niatross

I have tried and failed to use the iphelper api in the past. Can you tell me how to actually get hold of the source code for it. You google it and you get a load of old articles about asking for the Microsoft SDK on a CD, broken links or information that didn't make a lot of sense to me. Probably just my inexperience with C++ development though.

That was a quick turn around. I was going to have a look into it myself but I hadn't even had chance. Thanks for sorting it!!

I am trying to use this to convert a map with an enum as its key. It seems to convert the map to something which looks sensible but when I try and convert the JSON back to a map I am getting an error saying that the it is trying to create a map with identical keys. I haven't had time to look into what is causing this properly, I was hoping someone had some thoughts.Enum Map.vi

Wasn't there something in the NI rebrand/one of the partner meetings shortly afterwards, about them having NI certified products from third parties. I can't remember what they called it but from memory it was basically a scheme where NI may push your 'solution' using their regional representatives (Or whatever their frontline sales people are called now) Note: the above is full of half remembered facts from things I was only half paying attention to at the time so might be total drivel.

I have had problems recently with the 'Save for Previous Version' when running 2019. It turns out I had used a Map in my code. It looks like LV2019 freezes up rather than giving you the normal error message that your VI's contain features incompatible with the version you are saving to. I am assuming that it would do the same for a set.

Personally, I don't mind the logo, or the colour scheme. I prefer the old colours and logo, but no one likes change do they What I resented a little bit is that the webcast has been promoted for about a month, promising 'something extraordinary' In my opinion what was delivered wasn't extraordinary, it was 50 minutes of my life that I won't get back. It offered no value to NI's customers, brought no knew knowledge to the table and just felt like was repeatedly been hit in the face with a PR and marketing hammer. There isn't a problem promoting the amazing things people do with LabVIEW, but it doesn't need such a song and dance. I would have preferred to have seen an open discussion about this 100 year plan that NI mentioned, what areas they are going to focus on in the coming years, how they are planning the transition between current gen and NXG LV. A lot of our careers are pretty heavily tied to NI, we aren't impressed by marketing hot air, we just want to be efficiently kept in the loop regarding what NI is doing and how it is going to affect our companies. (I say 'we', that's my opinion, but I would be surprised if I was the only one who thought this)

I am trying to solve two problems, in the same application. I am open to alternatives because I am really not happy with how it is working at the moment. I need to get live image data from 3-4 cameras to about 30 clients on a WiFi network simultaneously. Originally I planned on doing this by transmitting the JPEG binary data via UDP multicast which works well on a wired network but I was getting to many dropped fragments (and therefore dropped datagrams) over WiFi for it to be useful. I can't use TCP because there would not be enough bandwidth to do that to 30 clients. I started looking into MPEG4 streaming, and therefore FFmpeg. As part of the application I need to do some image manipulation within LabVIEW. My current dataflow is: Cameras ---IMAQdx-----> LabVIEW -----MJPEG via TCP---- -> MPEG4 stream via UDP (FFmpeg) --------WiFi--------> Client reciever (FFmpeg) -------MJPEG via TCP------> LabView Next week I am going to revisit trying to just do a MJPEG stream in LabView over UDP becasue what I have described above is currently quite ropey. Second problem. It is a bit of a bodge, but I need to stream a screen capture of a particular application which is running on the server to all of the tablets. Again I need to do a little bit of manipulation before it goes to the tablets. I don't know of another way of bringing a live screen capture of an individual window into LabVIEW apart from FFmpeg (I know you can use some windows API's for screen capture but FFmpeg still works if the application is behind other windows). Beyond that I have got the same issues with streaming the data and was planning on using FFmpeg. I was sending the q command so that FFmpeg would close its network connections so that I can reopen them later...may not be necessary so I will test it without. In summary, my questions are: - My internal MJPEG stream over TCP to 127.0.0.1 works fine but I am sure there is a neater way if you know of one...I did consider using a file as the middle man but could think of a way of doing this other than writing indiviudal frames to disk as seperate files which I though was just as bad...if not worse from a CPU and disk usage point of view - As I said previously, sometimes when I try to close the FFMPEG instance, it crashes LabView with no error. I haven't been able to identify a pattern so far. I am open to other suggestions as far as the overall system is concerned.

Thanks for posting this. I am trying to use FFmpeg in LabView as well (Proving to be a real pain but this has made it a lot easier!!) Do you find that closing the FFmpeg isntance sometimes causes LabView to crash, especially if FFmpeg hasn't started processing frames yet so sending q doesn't work (Whilst it is waiting for a stream for example) My shutdown process is to send a'q' character, if the process has exited that's fine, if not send a ctrl-c. In this case I am finding that whilst the FFmpeg instace ends the wait on exit either hangs indefinitely or causes LabView to crash and close. This is the most stable implementation I have managed so far. Any suggestions on better ways of closing FFmpeg? Also, have you worked out a way of sharing data between FFmpeg and LabVIEW. (Use LabVIEW to provide image data or get image data into LabView) I know you can use the stdin and stdout. I haven't tried stdin for providing image data to FFmpeg yet but stdout does have a tendency to loose data, There is something blocking your stdout callback code causing it to miss stdout events (Or it just takes too long) I have had to resort to TCP mjpeg streams directed to 127.0.0.1.