dadreamer

I have no experience with these cameras or Hikvision SDK, but some things on your BD caught my eye immediately. Looks like the HCNetSDK.dll developer made all the functions to have stdcall calling convention, whereas your CLFN's use cdecl calling convention. You've set NET_DVR_Login_V30 CLFN to accept only 4 input parameters, but the function wants 5 parameters. You've set NET_DVR_Logout CLFN to accept 4 parameters, but the function needs only 1 parameter. In some CLFN's the parameter types don't match the prototypes exactly, e.g. wPort should be U16 (WORD), not U32 (DWORD). Use Windows Data Types table to find out, what WinAPI types represent. These are the prototypes for NET_DVR_Login_V30 and NET_DVR_Logout (as written in Device Network SDK Programming User Manual V4.2): LONG NET_DVR_Login_V30( char *sDVRIP, WORD wDVRPort, char *sUserName, char *sPassword, LPNET_DVR_DEVICEINFO_V30 lpDeviceInfo ) BOOL NET_DVR_Logout(LONG lUserID)

They are Code Interface Nodes. This is an obsolete and no longer supported technology, that was superseeded by Call Library Function Nodes. If you want to know more about CINs, take a look at Code Interface Reference Manual. You still can download C Code Generator package and install it onto LabVIEW (2017 is the latest version), but it's not actively maintained these days and I even suppose, that it was deprecated from LV 2020. If you want to dig this deeper, that thread may be useful for you.

Probably this is a long shot, but you could try to check/edit C:\ProgramData\National Instruments\NIvisa\visaconf.ini file as written here. I think, direct editing is not a good idea, so use System Configuration toolkit.

I'm not aware of such a method. Maybe this example can help somehow: Get Library Icon (lvlib, lvclass, xnode, xctl) without loading dependencies in memory

It was me. And not partially. 64-bit CINs do work absolutely the same way as 32-bit CINs. I successfully managed to call all the entry points and later adapted three examples from Code Interface Reference Manual to 64-bit CINs. Moreover, I managed to make LabVIEW load external subroutines, that was impossible and unsupported in versions 8.0 to 2016. But in fact all this extra knowledge gave me nothing for my real work but wasted time and efforts. I stopped experimenting with CINs in around 2015 or so and never really came back to this legacy tech.

You can find the information about public Manager Functions freely available on NI website. Also read this Using External Code in LabVIEW very useful (but kind of outdated these days) manual. But note as well that LabVIEW exports a whole bunch of totally unsupported internal functions, which are not intended for any public/production use-cases. Of course, you may figure out how they work and even try to use them in your programs, but do that at your own risks and don't let those projects out of your lab.

Not sure about the toolkits, but you can easily find LabVIEW 2017 SP1 download links having done just a proper googling: http://download.ni.com/support/softlib/labview/labview_development_system/2017 SP1/2017sp1LV-WinEng.exe http://download.ni.com/support/softlib/labview/labview_development_system/2017 SP1/2017sp1LV-64WinEng.exe

I'm pretty sure, you can find LabVIEW 4 demo version on NI ftp server. I've also seen 3.x, 4.x and 5.x versions on macintoshgarden. As for the others, not sure, if they could be shared here as it still seems to be illegal, even though these versions are super dated and (almost) nobody uses them for production now. Well, I do have some, but I'm going to see the admins position about this. P.S.: I too like this kind of fun and I'm seeking for some versions. Still couldn't find 1.x to try it in some early Mac emulator. Interested in BridgeVIEW distros as well and maybe in some old toolkits like Picture Control Toolkit.

I meant this second window. It actually allows coding there. But after saving and reopening all the code things are gone.

Well, this was discussed a lot here and on NI forums. The link there is invalid, the new one is Closing References in LabVIEW There's a paragraph about implicit references (current app, current VI, controls/indicators on the panel): All the other references should be closed with Close Reference node as a good manner rule. Of course, you may leave everything opened and LabVIEW disposes/closes it on the VI/project unload or on the app exit. But it's gonna eat up some extra resources in the system and slightly slow down your program. Or you may always close everything and don't care about the ref types. 🙂 Just a note for another guys out there, who might use that VI.

Also to note for your VI. 1. Looks like UID to GObject Reference.vi is giving away a duplicate reference instead of the original one. Hence it should be closed explicitly with Close Reference after the work with it is done. 2. UID to GObject Reference.vi is not working in RTE. The Context Help for it has the related remark and even though the underlying UidToObjRef function is present in lvrt.dll, it does nothing. So, for RTE another way should be found. 3. Icon picture of Pointer to Refnum.vi doesn't reflect, that reference, not pointer, is outputted. BCJ is not used here as well. Maybe, something like " @ # " should fit more or less ok.

None that I've known of. It needs extra investigations, but I'm afraid no easy way around that. upd: At least you could try to adjust the File Dialog appearance, by replacing it with your own. It doesn't have a block diagram and is in locked state. I suppose, the diagram is created on-the-fly, when the Dialog Editor opens a .rsc as it's always (?) empty anyway. The code to the buttons is assigned by the Dialog Manager API (defined in DIALOG.H; check LV 2.5 sources). Sadly dialogEditor token is not working in modern LV's, so you have to extract, alter and pack that VI "manually". Maybe it's better to experiment with LV 5-7, where the dialog menu entries are available.

For 32-bit system you should add 8 bytes to the pointer instead of 16 to read out the UID. Check my test sample from here. Anyway it mostly matters for Windows, as both Linux and macOS are 64-bit nowadays.

Thanks. I like that toggle switch control on the diagram. Assume, you changed the image, representing True/False states? By the way, I believe this is how exactly analog waveform looks like. Anybody knows, what was the error cluster used for?

Might be worth trying to put useNativeFileDialog token into your config file (/home/<username>/natinst/.config/LabVIEW-x/labview.conf). Check both True and False values. upd: Doesn't work for me. Then maybe try some third party dialog libraries out there, e.g. osdialog or Portable File Dialogs or Native File Dialog / Native File Dialog Extended , there are thousands.

Sure, why not? I was just too lazy to wrap those three VIs into one. 🙂

All the new snippets from here don't work for me. Tried in three browsers. I don't know, whether anyone else experiences the same. I guess, that thread relates to this issue: Old snippets still work fine though, for example this one.

Back to experiments with Basic Object Flags? I think, you forgot to cast a spell on that string constant. 😀

funkyErrClustWire works even in LabVIEW 6.0 (6i). https://labviewwiki.org/wiki/LabVIEW_configuration_file/Block_Diagram Doesn't work in LV 5.0. But! This token is still being read in modern LV versions. For example, this is from LV 2020. So, if you don't like that brown(ish), you can switch to pink classic.

Well, if you implement everything in LabVIEW, you could create such a global with DSNewPtr, which would give you a pointer, that you could easily pass to UA_Server_run. Then when the server is running, you may stop it by writing a zero to that pointer using MoveBlock. In such a way you won't need an additional wrapper DLL. Of course, your global should be one before you call UA_Server_run. Also don't forget to dispose that pointer when finished with it.

If you export running global variable from your DLL, then you could get its memory address with GetProcAddress and pass it to your UA_Server_run function as the second argument. That should work, if I got your tactic right.

Regarding your second issue - on which LabVIEW did you see that it doesn't require a case to handle the Timeout event if the timeout input is wired? I have checked on various LabVIEWs for Windows and even in LV 7.1 it breaks the VI and wants me to provide a Timeout case.

Your issue with Event Structure names reminds me this thread - LabVIEW Event names are completely off. Even though that was experienced on Windows and the OP solved the issue by removing LabVIEW and cleaning up the system with msiBlast. Might it be that something didn't get installed properly in your case?..

Maybe it's time to try WaveIO library written by Christian Zeitnitz then?

It's just that NI designed those JPEGToLVImageDataPreflight and JPEGToLVImageData functions to run in UI thread. I don't know whether it's safe to set the CLFNs to "Run in any thread" and use it, because we don't have the sources. You could test it on your own and see. But it's known that most of WinAPI functions are reentrant, thus you may freely use WIC or GDI+ from multiple threads simultaneously. So, to re-invent JPEG reading VI with WIC this thread could be a starting point (along with Decode Image Stream VI diagram as an example). For GDI+ this thread becomes useful, but this way requires writing a small DLL to use GDI classes. I don't recommend using .NET nodes in LabVIEW here, as the execution speed is that important for you.