Leaderboard

Another things which wasn't touched on in the video. Sometimes you have to interact with hardware with a technician/engineer present. Especially when going through wiring, schematics and generally troubleshooting which is invariably in an industrial situation-in situe. Describing what they can see is very difficult especially with a language barrier and for them to carry a laptop around and use it to send images/video of exactly what they are seeing isn't very practical. A head-mounted bluetooth video camera is fantastic for this and very convenient for them. They just need to pair it with their phone and you can see what they can. If you have ever had to remotely troubleshoot wiring it makes it sooooo much easier discussing wire idents and spotting that clue that tips you off to the solution.

That's right. When you're scripting, you need to use the Undo transaction methods in order to preserve (and add to) the Undo history.

How bizarre! Yes, that works. Dropping a simple ADD function, then deleting it, vaporizes the Undo History. Any thoughts as to why? Can LV not cope with changes that aren't wrapped in an Undo transaction?

If you drop a dummy object on the diagram, then delete it, without wrapping those operations in a Begin Undo/End Undo transaction, it looks like it clears the Undo history.

Well let me tell you about the lvZIP library on OpenG. That is magnitudes simpler than the FFMPEG library in terms of number of exported APIs as well as functionality. And creating that was more like a one or two year parttime project than a weekend project . And I knew some substantial C programming when I started with that, although I sure learned a few tricks during development of that library too. So even with an optimistic outlook I would consider the FFMPEG library to be a substantial full time project that likely takes up several months to do right. As to your specific problem: those AVStream and other parameters are so called opaque data types. Basically that means that the external declaration is simply a named datatype with no public data content. As such LabVIEW can not do anything with this datatype and the import wizard has to leave the not fully declared datatype undefined. Even if you go into the header file and add something to the structure to make it parsable you are really misguiding the import wizard as to what it should do. The only kind of fix that might sort of work would be to define the AVStream and others to be of type void instead of an unfinished struct. Then AVStream* will get void* which is actually what you want to have here. The idea about opaque types is that they are in the external API only treated as a pointer to an undefined struct. Much like what Windows uses HANDLEs for. They are basically a pointer to a data structure that the actual API knows how to interpret, but the caller never should be concerned about in any way. By making it an opaque type the programmer can make sure that any caller will never be able to concern itself with the contents of that structure. Internally in the library source code there is another header which declares the datatype completely so it can be used inside the library properly. The advantage of using AVStream* and friends as seen here instead of declaring every of these types as void* instead, is that you as caller can then not accidentally pass a pointer that describes a different resource than an FFMPEG stream to this function. Well that applies for C(++) only of course. In LabVIEW you don't have that automatic syntax check based on the C header declaration. Personally I would probably redefine all those opaque types to void and then let the import wizard correctly create the library calls. Here they should then end up as a pointer sized integer. You end up with the problem that you loose every type safety as a pointer sized integer that points to an AVStream is not distinguishable from another pointer sized integer that points to some other resource. But solving that issue is even more involved and definitely will go way beyond any type of weekend project.

Thanks, I've only been working on this tool for the last 14 years

Here's a brief example how to draw your own images on plots. The VI simply tracks the x-location of the mouse and draws a circle around the corresponding data point. You could use whatever logic you want (closest Cartesian point, tracking multiple plots, whatever) and draw any info you'd like, but this should get you started if the built in functionality doesn't suffice. Mouse Tracking LV13.vi