ShaunR

so your objection isn't the callback, per se. It's the PostLVUserEvent data type which is a void*. What if we fixed the data type to be an array of U8? That is the most common usage for getting data from callbacks and most types can be massaged into an array of bytes. I was thinking more of a Sunday afternoon while drinking a Negroni

I was wondering if we could have a generic solution for callbacks using Variadic functions/templates or maybe the Pack Expansion. We could prime the callback with a call to set the callback parameter list (cluster?) and target (the dll) we need and then apply the callback which has a PostLVUserEvent in its function body.

NI have just put the distro's behind a paywall. Those links will die.

Open source freeware and torrents have a similar ethos. You should at least understand that. Why do people help on the forums? What do they get out of that? What do you expect to get for your invaluable help here? Time is money, right? BTW. They are rhetorical questions to hopefully instill a little cognitive dissonance at your out-right rejection of torrents and similar. I think it's very clear from the posts here about accessing old versions the service these torrents could provide IF NI was happy with it. You just seem to think it would never happen because, what? Game theory? (Moon Knight episode one has 2117 seeders ATM)

Who says you don't get something in return? Someone makes LV 2020 ISO available and maybe downloads Moon Knight. Don't tell me you are new to this torrenting malarkey. I have a 12TB Nas box. A few hundred gigs of karma is nothing.

Looks like The Pirate Bay is going to become NI support.

As Rolf says. No! They will give you chance to figure out how to call functions without everything crashing and what needs to be initialised before you call any functions. They are simple functions so a good starting point. You have to walk before you can run.

OK. You are clearly drowning in the learning curve so lets get back to basics. You need a strategy! You have a working example (Preview.cs). Do you know how to compile it? If not, that's your first task-get an executable out of the example code. This will be your golden standard for checking your program is doing things right. Next. That example saves a file in the callback (实时流数据.ps). You may have to change the filename to an ascii one for LabVIEW to read it as LabVIEW doesn't support Unicode. You should be able to read that file from LabVIEW (after is is closed). That is the raw data that you would normally get back from a callback. Read that file in LabVIEW and figure out how to interpret it (it's a byte array [array of u8]. The callback is public void RealDataCallBack(Int32 lRealHandle, UInt32 dwDataType, IntPtr pBuffer, UInt32 dwBufSize, IntPtr pUser) This callback (for a .NET Assembly or a similar one for C[++]) would be where you put the PostLVUserEvent instead of saving to a file. Your problem at that point is telling the callback to use a LabVIEW refnum. Don't worry about putting that in for now, we can talk about that later. Once you get that far, you will be a long way through the learning curve for this API but just by reading the file you can work on presenting the data [U8 array] in LabVIEW (you will feel progress) while you think about how to get the data directly. Look to see what the example code is doing with it and replicate it in LabVIEW. There are also other functions that you can call directly from LabVIEW that don't require a callback (e.g. NET_DVR_CaptureJPEGPicture & NET_DVR_CapturePicture) and take normal parameters that you can pass directly. Get those working from LabVIEW (more progress)

Callbacks is the one instance when I would suggest a .NET solution in LabVIEW (in the absence of anything else) for all of these reasons and everybody knows what I think about .NET

Be afraid; be very afraid Generally, there is no concept of a pointer in LabVIEW. LabVIEW is a managed environment so it is more like .NET. You don't know here it is stored or even how much memory is used to store it. The CLFN will do that out-of-the-box .Yes. Because you don't know where it is for the lifetime of the variable.

You are playing with fire. Ownership is key. DO NOT manipulate pointers in LabVIEW-period! You either manipulate data by passing it to a DLL (like an array where LabVIEW owns the data) or you provide functions to manipulate data (where the DLL owns the data - where is your freeing of the pointer allocated inside the DLL?). LabVIEW has no ability to know what a DLL is doing with memory and vice versa. You must also take into account the pointer size. (32 bit LabVIEW or 64 bit LabVIEW). For some types, this is handled for you (arrays, for example) others you will want to use the Unsigned/Signed Pointer sized Variable (for opaque pointers) and pass that BY VALUE to other functions. Look at the Function Prototype in the dialogue. You will see the C equivalent of the call. Note that you do not seem to be able to do things things like int32_t myfunc(&val). Instead you have to use "Pointer to Value" and it will look like int32_t myfunc(int32_t *val). If you are trying to manipulate pointers, you are doing it wrong and it will crash at some point taking the whole IDE with it.

3 is the way to go. He just needs to read this thread.

I am a great fan of SCPI. I always try to get device developers to follow that standard. It makes different device commands much more structured and interchangeable. Failing that it is generally a good idea to manipulate string based comms as strings. It is much more flexible, more modular and the LabVIEW case structure takes strings as cases (make sure to make them case insensitive). Converting commands to objects will bloat your code immensely, cause it to run like a slug and ultimately difficult to maintain (IMO). That doesn't mean that you can't use objects, just not advisable for the driver aspect. You state you have hundreds of cases. It sounds like each case addresses a command regardless of similarities-linear programming. My first port of call would be modularity rather than architecture. Take a look at what you can break out into shared modules between cases and even between devices. This is much easier with strings but you will be bound if they are objects requiring different base classes as you identify more similarities. This is why I said try and manipulate as strings. Once you have a more modular rather than linear layout, you can then look at objects (for different devices?). If you have done the work above, a lot of the class override methods will be just a wrapper around a modular subVI. and, where they are completely different in execution, you can add the device specific functions or modify the input/output from a modular subVI to make it compliant with the device. That is my advice. I'm sure others will have other thoughts.

If you can do that, you'd be a billionaire.

Merging them is easy. Make each one a subVI then use a case statement to switch between them. How you switch will depend on if you have a specific signifier for each controller command set or, worst case, you just test against a list of commands for each. Is the comms string based or more binary?

'There's your answer. BTW. If you try to debug it, it works fine

Hold my beer That's a great program, your son must be at least 8 or 9. If you did [insert some sage programming wisdom here], it might actually do what you think it does. Your program has a couple of bugs. Let's give it to someone that might be able to fix them. Hmmm. I've seen that architecture before. Isn't it called the spaghetti factory pattern? Don't worry. It's not that bad. I'll just put in a capital requisition for another 8 monitors to view the diagram.

Those dialogues (one, two and three button) run in the root loop. If there is a race condition, LabVIEW is screwed. Never use them. Spend two minutes to make your own dialogue.

A prototype is just a program before you up issue it to version 1.0.0. Either that or it becomes a test harness. Why would you throw away anything that's useful? All the examples in ECL started as prototypes and they now double as black-box regression tests.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LgySAE Nothing is mentioned in the application note.

Who said you can't teach an old dog new tricks I'll have to have a play but generally I use polymorphic VI's for that.

OK. That's the bit I'm missing. Maybe a silly question but why? Is there a specific scenario where this is desirable? LabVIEW palettes aren't scoped and I have never included them as part of a class; so I'd be interested of the benefit. I've always included them as external file regardless of class since some palettes may have multiple classes in them.

There must be something I'm missing. Right. So it can add or not depending on whether the dependencies are installed. Shouldn't this be the pre install,? VIPM will try to compile the menu before the post install. Is this where you are getting the dialogues because all mnu's are created as part of the VIPM package and are therefore present when VIPM makes the palette at install? OK. But if the sub palettes are separate mnu's, you just don't include those that are for those not installed, right? If you copy over only the mnu's you need (or use your previously stated VI's to make them) and don't rely on VIPM to compile the menu's (no mnu's as far as it is concerned) then no dialogues will be thrown. You just then need to make LabVIEW compile the mnu's at the post install or rely on LV to auto compile them

I agree. That solution is by far the easiest and simplest. I'm just lucky that I have an installer (written in LabVIEW) that can generate the mnu files on-the-fly. So deciding which menu items to add wouldn't be difficult. In fact. thinking about it. You could probably do something almost as good if you could segregate the icons into palette sets, made each a separate mnu file, and then, during the pre install, copied over only the ones you wanted based on what was installed. LabVIEW would probably do the rest or you could force it to recompile the entire mnu hierarchy in the post install.

When VIPM doesn't do what I need, I create an installer with a post install VI that runs it and a post uninstall that deletes it. VIPM just copies it to the correct location.