dadreamer

You mean links like these? Will ekit links die too?

Now, after you've succeeded with C# examples, I'd advice to put them aside and try to build a very basic C/C++ DLL in your editor. Maybe start with something trivial like a sum of two numbers or even empty function, returning a constant. After you get your DLL, try to call it in LabVIEW. On success, you may go further, introducing "extcode.h", PostLVUserEvent and slowly turning your function into the callback. Also I'd like to ask about your LV code. Why do you use Event structure without While loop? That sample should also do the job. And maybe a good idea to take NET_DVR_Logout_V30 and NET_DVR_Cleanup out of the loop, so they'd get executed anyway.

I've never ever encountered such releases, if speak about LabVIEW and other NI software. Maybe they were pre-LV2009 releases with some 'evil' cracks, but from what I saw, people are seeding mostly genuine files plus some tiny ... eh... "cure", that does nothing except modifying those *.lic's in \ProgramData\National Instruments\License Manager\Licenses. But I don't encourage anyone to use torrents. Why bother, when it's often enough to google a little to find the links to the distros 🙂 (if not already collected).

In fact, a simple callback function could be implemented right on a diagram using this method, but I don't recommend it, because even if any small mistake is made in the asm code or in the CLFN's settings, LabVIEW is going to bite you painfully. 🤓

Yes, but HCNetSDK.dll is an unmanaged C/C++ library and they have to use marshalling everywhere in the code to transform the types, crossing between managed and native code.

You need to create a standard native Windows library (DLL). You may use any IDE of your choice, that's able to do that, e.g. Microsoft Visual Studio (Community Edition is fine as well). In that IDE you need to export the function with the following prototype: typedef void(CALLBACK *REALDATACALLBACK)( LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer, DWORD dwBufSize, void *pUser ); Make sure your exported function matches it exactly. Also you need to include "extcode.h" from [LabVIEW]\cintools directory, because you're going to use PostLVUserEvent LabVIEW Manager function. The logic is that you don't do anything in your callback except calling PostLVUserEvent, passing pBuffer into it. But if you want to use more than one camera in parallel, then more logic is needed. You could try to use lRealHandle or pUser parameters to distinguish the cameras. Start with an easy setup of one camera for now. In LabVIEW you need to call LoadLibrary and GetProcAddress functions from Windows API, in order to load you DLL and get the address of your callback. You pass this address into NET_DVR_RealPlay_V40 upon the call. After that you register your user event and wait for it in your Event Structure. If everything is done right, you should receive the events right after calling NET_DVR_RealPlay_V40. Read vugie's post in the topic, I linked above, to get the main idea. Also please don't mix C# and C/C++ here, they are different beasts. Of course, you may learn from C# examples, but you're trying to use C/C++ written library through CLFN's, so you need to use C/C++ language to create the callback. If you were to use C# and .NET assemblies, you'd use instruments from the .NET palette.

I don't see how it would help, as both V30 and V40 functions do use callback technique to pass data.

I'm afraid you'll have to write it on your own. It's not that super tricky, but requires some basic C knowledge. Here's the post, that could be a good starting point (as it was for me many years ago):

Well, it's time when things get more complicated. The NET_DVR_RealPlay_V30 function needs a callback function to be registered, in order to transfer live stream data. But it's not that easy to implement callbacks in LabVIEW. You would have to write a small wrapper DLL, that would receive the data and pass it to LabVIEW with PostLVUserEvent function and then in LabVIEW you'd be able to catch those events in your Event Structure. Are you sure, you can't work with these cameras using NI-IMAQ(dx) and NI Vision? Can you see your camera in NI-MAX? As an alternative, you could try to use VLC API, if the camera transfers common RTSP stream and you know its address.

Try this VI. hikvision 6-1.vi

Still not everything is correct on your diagram. Since lpDeviceInfo is an output parameter of that NET_DVR_Login_V30 function, it requires the memory to be allocated before the function is called. You can't feed an uninitialized pointer into the function. In LabVEW to pass a struct into a function you have to make a properly sized cluster (of 80 bytes in our case) and wire it to the CLF Node. This is how NET_DVR_DEVICEINFO_V30 struct is declared: struct{ BYTE sSerialNumber[SERIALNO_LEN]; BYTE byAlarmInPortNum; BYTE byAlarmOutPortNum; BYTE byDiskNum; BYTE byDVRType; BYTE byChanNum; BYTE byStartChan; BYTE byAudioChanNum; BYTE byIPChanNum; BYTE byZeroChanNum; BYTE byMainProto; BYTE bySubProto; BYTE bySupport; BYTE bySupport1; BYTE bySupport2; WORD wDevType; BYTE bySupport3; BYTE byMultiStreamProto; BYTE byStartDChan; BYTE byStartDTalkChan; BYTE byHighDChanNum; BYTE bySupport4; BYTE byLanguageType; BYTE byVoiceInChanNum; BYTE byStartVoiceInChanNo; BYTE byRes3[2]; BYTE byMirrorChanNum; WORD wStartMirrorChanNo; BYTE byRes2[2]; }NET_DVR_DEVICEINFO_V30,*LPNET_DVR_DEVICEINFO_V30; This NET_DVR_DEVICEINFO_V30 struct is a bit bulky to form, so here's a VI from which you can copy it and paste to your own VIs. NET_DVR_DEVICEINFO_V30.vi Now in your CLFN set this 5th parameter as Adapt to Type -> Handles by Value. With such a setting LabVIEW will pass a pointer to the NET_DVR_DEVICEINFO_V30 cluster and after the function call you should receive it filled with some device data. Also to note, LONG is I32 on Windows, not I64.

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?