Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/20/2022 in all areas

  1. I don't know much about CINs, CLN, or DLL calling in LabVIEW. But don't be discouraged. Our history makes us what we are. There's several projects I started and spent a lot of time on just to do nothing with, but I feel like I learned stuff or grew as a developer and a person just because of the journey. Maybe that time could be better spent elsewhere. But with that mentality I'd never do anything for entertainment.
    3 points
  2. If you have an MNU inside a class (or library really) you can set it as the Default Menu for items in that class or library. Then if you right on members of the class, or the class constant, then the menu you specified will be available as a shortcut. Lets say I install a File IO package with a palette for it. And then I install as Zip package. I might want that zip package to insert items in the File IO palette, or I might want to make a subpalette for the Zip, or make a subpalette under Advanced for the the zip which is also in the File IO. In any of these cases you can then add the MNU to the zip class, and set it to the default. Now I can have the File IO palette come up if I right click a Zip class, or I can have it come up with the subpalette if that's what I did during the install. Here is some information on it. https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/setting_default_palette_menus/ https://forums.ni.com/t5/LabVIEW/Here-s-a-scripting-VI-for-LVClass-default-menu/td-p/2429356 In the scenario I described you'd want to edit the Zip class, but you also will need to edit the File IO palettes, either adding Zip items, or adding subpalettes to it, or linking the Zip palettes to it some where. Doing this causes browse dialogs if say a required Zip DLL was missing and needed to be installed as part of the system. In that case I'd just include the DLL, but in my actual dependencies is XNet which can be a 1GB install so including that in the package isn't ideal.
    2 points
  3. Basically the point I was trying to make also in previous topics about CINs. 😀
    2 points
  4. I had to do that once. Moved from LV to C++ A translation doesn't make sense as many concepts don't transfer well between languages, so it was rewritten from scratch. It's actually funny to see how simple things become complex and vice versa as you try to map your architecture to a different language. I assume by "done" you mean feature parity. We approached it as any other software project. First build a MVP and then iterate with new features and bug fixes. We also provided an upgrade path to ensure that customers could upgrade seamlessly (with minimal changes) and made feature parity a high priority. The end result is naturally less buggy as we didn't bother to rewrite bugs 😉 It certainly took a while to get all features implemented but reliability was never a concern. We made our test cases as thorough as possible to ensure that it performs at least as well as the previous software. There is no point in rewriting software if the end result is the same (or even worse) than its predecessor. That would just be a waste of money and developer time.
    1 point
  5. 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.
    1 point
  6. 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.
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.