Neil Pate

OK experts C experts :-) My goal is to write my wrapper DLL with as least fuss as possible, as my C skills are not great. I have access to the .lib files, it seems to me that life would be easier if I statically linked the additional libraries as then I do not need to mess about with loadlibrary, GetProcAddress etc etc. Is this sensible? Note the code I am going to interface to is quite old, and in all liklihood is not going to change.

Thanks for the info everybody. I am going to start looking into this today, I will keep all your suggestions in mind.

Rolf, this is a going to stay a 32-bit application for its entire lifetime. There is exactly zero percent chance this will change. So if ShaunR's method works that sounds like the winner to me. I do this kind of DLL interface stuff rarely, so am always struggling to remember the details of pointers and buffers etc. I wan't to try and keep things as simple as possible, and having dealt with memory allocations in the DLL before I would like to try and avoid it if possible. All I need is the data back in LabVIEW via a PostLVUserEvent, I don't think the caller of the callback every expects anything meaningful in return. Now, I have not actually dug any deeper, I have some sample C code that shows the library in use (although here it uses a .lib rather than the DLL, but I expect the function handling to be the same). At some point I am going to need to go through this.

Hi Jack, The library I am trying to integrate into my code is a "standard" TCP/IP based message protocol. The only function I need to call that requires the callbacks is the Init. The Init, which is called only once at the start, defines which two other functions are used in the event of a message being received and an error being detected. int Init(LinkType iLinkType, DataProcessingFunc pDataProcessFunc, ErrorProcessingFunc pErrorProcessFunc); As far as I can tell, almost all the other functions in the library are used for configuring the communications or sending data, and all of these are "normal" type calls with no fancy prototypes or crazy structs being passed around. The library itself is cross-platform (I know for a fact it can be compiled to run under Linux), I have access to a "normal" 32-bit Windows DLL (not assembly). I am not sure of the calling convention but I think So my plan was just to wrap up the Init and implement a DataProcessingFunc and ErrorProcessFunc in my DLL, those last two would just pass data straight back to LabVIEW using PostLVEvent. int Send(tyLinkID iLinkID,tyMessage message); tyLinkID is just a plain integrer typedef struct { tyMessageType nMsgType; DWORD nAddress; BYTE *cType; / WORD nTypeLength; BYTE *cData; WORD nDataLength; } tyMessage; I plan on calling the Send function directly from my LabVIEW application. Any problems that you can see from a cursory glance?

Yes, it works like that on my LV2015. The heartbeat light thingy keeps on blinking until the top-level VI is stopped.

Thanks guys! This is good news as I was not really very excited to wrap every single other function exported by the DLL. I think I will wrap up the Initialise function (this is the one that requires the two callback pointers), and then implement the two callback functions as simple functions to PostLVEvent.

I need to implement a certain comms protocol into some software I will be creating. This has been provided for me as a DLL. The problem is that the DLL uses callbacks for the message processing functions, which I cannot easily do from LabVIEW. So my idea was to create a small wrapper DLL which implements the callback functions but sends the data to LabVIEW using PostLVEvent. I will have DLL_A (supplied by my customer), and DLL_A_Wrapper (created by me) Now, something I do not know, can I call DLL_A functions directly from within LabVIEW or do I need to wrap all the DLL_A functions as well? I suppose my question is more like, when LabVIEW loads my wrapper DLL, do two copies of DLL_A exist in memory?

I can confirm I have also seen this behaviour recently with LV2015. Manually editing the .lvclass was the only thing that worked for me.

Yup I am pretty sure there is no other code interfering with this notifier. The refs are the same in both instances. Does anybody know if we can poke inside the "standard" probes (i.e are they VIs like custom problems, or are they done at a lower level like inside the C++ code?)

Hi all, I have seen something today I was not expecting. If I probe a notifier wire, in the probe window I get two different messages in the Probe Display on alternate executions of the same piece of code: I get this: Notifier name: Latest notification: Number waiting: 0 Refnum (in hex): 0x08800000 and then I get an empty value in the probe display, with the value in the table reading: "Unnamed - 0 waiting - 0x880000 So both tell me the same thing, but I wonder why I get this alternating effect. It is very noticeable in the probe window as the blue line that highlights the current probe is skinny and then fat. This is LV2015. Am I doing something strange in my code or have others seen a similar effect.

You just need to hide the fp, not close it.

You certainly can run the code as you wish. A VI does not need to be running to be inserted, but if you do this and then run it there is a nasty transition when the VI changes to running. The refs are not related at all. The subpanel will not do anything with the inserted VI ref. Inserting a different VI does not destroy the original VI ref. You can get a ref to the inserted VI from the subpanel. Hold onto the VI ref if you want to do other stuff to the VI like aborting it etc

I think it is safe to have multiple Event Structures in the same VI as long as they are configured to respond to different events. I have used this technique where I have one Event Structure to handle all User Events, and another to handle User Interface Events.

Ah yes, now I recall that thread, thanks. (I confess I did not google it, getting lazy in my old age...) I am a bit on the fence on this, will probably try it out for a bit and see how well it fits into my workflow.

Hi all, I remember some time ago a discussion somewhere (cannot remember where) about the possibility of a Variant To Data figuring out which data type to output depending on what type the output was wired into. Even though the type input is shown as a bold input (i.e. "required"), it is possible to leave this off. I have always manually placed down the desired output type, just as a force of habit more than anything else. It seems that as long as there are no other structures in the way the Variant To Data is able to figure out the type it is being wired into, so is there any sense in placing a type constant? Interested to hear what others do here.

I did not know that was possible, cool. However that sounds like a lot of work for a LabVIEW programmer

Yeah I kinda expected it... It's a bit annoying really, it is not like Windows 10 was all of a sudden released on the world with no notice. So strangely I was poking around in my Vision pallette and even though I had to switch off my Pc during the installation the IMAQdx VIs are there. Will probably go up in smoke if I try and run them though Edit for grammar

Hi All, I have recently cobbled together a new PC, and have put Windows 10 on it (which I really like). Everything works quite nicely, but have had a lot of trouble installing NI Drivers. I have the August 2015 Software Reference Library USB stick, and cannot install DAQmx or Vision without the installer hard-crashing my PC (power off required!). I have no issues installing other software (LabVIEW, toolkits, TestStand etc) off the USB stick. I was able to get DAQmx to install by using one I downloaded, but this technique has failed me for the Vision drivers. Anybody else experience this behaviour? I would suspect it is just something about my system the installer does not like. I have a pretty new Skylake based CPU so perhaps that could be it? Kind regards Neil

Right, well then I will truly park this for now. Thanks for the info Rolf.

Thanks guys, I did not know about the menu being non-standard. Do you think there may be some way in via the Qt DLL? Actually, there is pretty much zero % chance I am going to have time to explore that. Will just have to live with it for now.

Hi All, Does anybody know how to set the menubar colour in an application? I have done some digging and it seems this is possible using the windows API, just wondering if LabVIEW had some way to do this natively? (I doubt it, just thought I would ask).

Hi there, Has anybody used the OPC UA client that is part of the DSC toolkit? I am trying to use it to connect to a PLC and am getting error -336653 "The status of the OPC UA server is uncertain" I am able to create a local OPC UA server in LabVIEW and connect to this with no issues from the LabVIEW OPC UA client, and can connect to the PLC just fine using a different client. After speaking with NI it looks like this may be a permission issue, but I have tried all the obvious things in the OPC UA client (like client and server certificates), with the same result. Any tips? Crossposted http://forums.ni.com/t5/LabVIEW/OPC-UA-client-cannot-connect-to-PLC/td-p/3195246

Any suggestions for Chrome?

Yeah I want to try and use FTP to download things like DAQmx without having to go through the NI downloader which I find gets quite choked sometimes. Thanks for the FTP link, that will be useful for LabVIEW related stuff.

Hi All, I am trying to get a new PC back up to a usable state (installing software etc). Am having some trouble accessing the NI.com FTP site. Using filezilla I can access ftp.ni.com with no problems, but cannot get find support/softlib where the juicy bits get downloaded from. As I said this is a new PC so I had to create the FTP connection from memory, have I done something stupid like not put the right authentication or something?