ShaunR

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.

Doesn't VIPM check the dependencies before installing or can't you check for the dependencies in the pre-install.vi?

Well. Assuming you have enabled the bridge (last line of the troubleshooting in the manual) have you tried adding the alias manually?

Don't you mean "wire by wire"? Generally, VI's are functions so you could write the same functions but the contents would be completely different. Many functions just wouldn't be relevant because of the way LabVIEW works - especially if they are to control the UI. Then it also depends on what you are going to write the new code in. Delphi UI's are, for example, event driven so you are in a completely different paradigm. If you have architected your program then you can transfer the architecture but you are still moving to a different paradigm (from data-flow). A lot of the LabVIEW support (drivers etc) come with other language bindings, so the really hard stuff such as DAQ and VISA etc wouldn't be too bad. Personally, I would do (and have done) a complete rewrite and change all the things I didn't like about the old program-if push came to shove. Saying that, though, you would be better off replacing parts, piecemeal, with DLL's until there is no LabVIEW left. I was in a position where I could do a complete rewrite (ah, Waterfall development ) At least then you can reuse the DLL's at the very least. If you also create DLL's from LabVIEW code, you can integrate them into the new, non LabVIEW software and then replace them later with non-LabVIEW DLLs. Boy, you've had a huge black pill suppository, haven't you

In addition to JKSH comments, You are using an express VI which are known to be slow. What is the throughput do you require? How much data are you trying to save (every second, every minute)? A typical mechanical hard disk will be able to cope with about 50-100MB/sec. A decent SSD 200MB/sec at least. The Win 32 File IO is much faster than the native LabVIEW. The link contains examples including queue buffered which JKSH commented on.

If you can't see it in MAX then it's not your code. Have you followed the troubleshooting guide in the manual? https://www.ni.com/pdf/manuals/375250b.pdf Is it an MXI controller?

While that may be true to a greater or lesser extent. Stack Overflow will close the thread so you can't give more details, ask more probing questions or help them in any way. What it means is that Google search is littered with dead ends.

I wouldn't know. The only time I ever go over there is when there is a link from here

I don't see what all this fuss is about, to be honest. Lavag isn't a company requiring growth for shareholders. Everyone is welcome, of course, but I don't really care if it's just an old-boys network of 20 people. Answers to my questions come from here and never from NI - neither their support of forums. Don't forget that Lava stands for "LabVIEW Advanced Virtual Architects". They are a dieing breed so it's no wonder there are fewer around. If you want to know how to use LabVIEW then it's better over at NI. If you want to discuss (or argue about ) methodologies and concepts; Lavag is the place. As regards Stack Overflow and Reddit - give me a break, Reddit is a hell-hole of politics and Stack Overflow is full of stuck-up people who would rather chastise you for how you formulated your question.

There's not much. Some useful functions are documented (Moveblock, for example) There is a file (extcode.h) which has many of the function prototypes which is located in the cintools directory. That and tribal knowledge about C and LabVIEW equivalence is usually what people use. Rolf knows a lot (I mean everything) about the underlying, opaque, structures used by LabVIEW but for most of the functions, C knowledge and extcode.h is usually all we have.

Antoine's new profile pic is enough to scare anyone off of the forums-including search engines. He's really let himself go.

It stops at 2018. all the stuff you listed is on the FTP site for 2017 just search the page for, wait for it, "2017"