dadreamer

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?

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.