Jump to content

hooovahh

Members
  • Content Count

    75
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by hooovahh

  1. I too would be interested in a way to make this work in an automated way. But until then one thing that might help make less steps, is making a VIPC with all the packages you want contained in it. Then on the new machine, after installing all things NI, you can double click that VIPC file, it will open it in VIPM, and ask what version to install them in, and then it installs all the packages at once. It still is a manual process but you don't have to select packages from a list, or be connected to the internet.
  2. I have a build that crashes LabVIEW with an access violation, and then VIPM gets an error. The build is attached. What the problem is, is that in there is a class, and that class is renamed during the build process adding the suffix "_hooovahh". But in that package is also a demo VI named "Defined Slider Test.vi" which uses a property node on that class. I've found that if I build, with the demo VI having a property node, linked to the existing class name, that during the build a rename takes place and crashes LabVIEW. If I disable the rename it builds properly, and if I enable the rename, but remove the property node in the demo VI, it also builds properly. I also found that if I add this demo VI to the class it renames properly which for now is a fine work around. Can this bug be addressed so that VIPM properly builds and renames the class, while not crashing LabVIEW if a property is linked to the class in another VI? Won't Build With Demo and Rename.zip
  3. The period folder is auto generated by VIPM during the build process. This is a temporary location where all files are copied to and processed. During the build this path exists and has the files in it. After the build fails (or finishes) it will cleanup that folder.
  4. Can someone from JKI tell me why this package doesn't build? It is relatively simple with no Pre/Post VIs, no file renaming, only a functions palette. But there are some XNodes and they are going into the vi.lib. On attempting to build it gives the following error: During the build I navigated to those folders and they exist and the files are there. If I remove that one XNode and its support files it builds properly. If I add it back with the support files it fails to build. I've tried mass compiling, resaving, and renaming VIs but it still errors. If I delete all other XNodes, and all other support leaving Common and the Compare to Constant, it also fails to build. Any help is appreciated. EDIT: LabVIEW 2018 SP1 F3 32-bit, VIPM 2018 0.0.f2, Windows 7 x64. XNodes Won't Build.zip
  5. I guess alternatively the Pre/Post VIs could be placed somewhere under the package source, so they are scanned. However for me I use the same Pre/Post VI for multiple packages and it is stored in a folder that isn't shared by any package. Thanks Jim.
  6. If there is a dependency added to a Pre/Post Install/Uninstall VI, this dependency isn't detected by the Scan for Dependencies function. Attached is a package that has a single VI that doesn't do much. But the package has a Pre-Uninstall VI that has a dependency on an OpenG Wait. Scanning for dependencies doesn't find any and I suspect it is because the Pre-Uninstall VI isn't part of the package source. The reason I want this is because my Pre/Post Install/Uninstall VIs are getting large and I wanted to make subVIs but they aren't brought into the package, only the top level. My work around for this is to call subVIs that are already installed. I intended on making a single package that is something like "Package Tools" which all packages that use the Pre/Post VIs will depend on. I can still add this manually but will often forget since all other dependencies are properly found on a scan. Reuse Test.zip
  7. Well I was just able to uninstall and reinstall that package with 2016 32-bit Windows 7 x64. What version of VIPM are you using? I'd expect every version to be compatible with OpenG. Do other packages install alright in 2016?
  8. Update from JKI: This issue is planned to been fixed in VIPM 2018. So I can successfully build packages with VIMs in them. But I found that if I need to make a package, that depends on a package, which contains a VIM, the build will fail. First install the hooovahh_array_vims-1.0.0.6 package. Then try to build the File IO package, which at the moment only contains one VI. If it is like my setup the build will fail with this error. If I remove the VIM dependency by replacing it with the OpenG one the build is successful. Build Fail VIM Dependency.zip
  9. So on VIPM 2017.0.0f1 I'm having a build that fails if I have some specific VIM, and the Renaming Convention is set. If I don't have renaming, or if I don't include this one VIM then things seem to work properly. Here is the error And attached is the source and build spec. If the Filter 1D Array-VIM.vim is removed from the source, then the build works (renaming all the other files to have _Hooovahh as a suffix). Or if the Filter VIM is left but renaming is disabled the build is successful. Array.zip
  10. The recently posted update VIPM 2017 F1 fixes this issue for me. Finally I can build all the VIM packages I've been wanting to.
  11. I found that if you go to the main download page and enter your email address it will start the download for version 2017 of VIPM. Even though the page still says the version is 2016.
  12. So...is anyone from JKI monitoring these forums? I have a show stopping bug that I posted two weeks ago, in the latest version of VIPM, can anyone give any advice? Thanks.
  13. Update: this issue has been fixed in VIPM 2017f1 I've been using the new VIMs feature of VIPM 2017 and am having some issues getting it to build successfully. If I have a VIM on the palette it builds just fine, but if I add a VI that calls that VIM the build fails, even if that VI isn't on the palette. Attached is a zip with my source. It fails to build because the normal VI "Is Variant Repository.vi" calls a VIM that is in that package. If I delete that VI the build works fine. Is this a known limitation that a package can't be built, if a VI calls a VIM? Here are the errors seen when the build fails. Thanks. Variant Repository Source 2017.zip
  14. So if anyone is interested in the second half of my post, I've attached a VI that does what I was suggesting. It takes a list of Installed Files which the Post-Install VI can return. Then for all Libraries and Classes it looks at the members, and find where they are on the palette and finds the most root MNU file installed and sets the default menu to this palette. So for instance if you have a palette with an Advanced subpalette, all members in that Advanced palette will actually point to the root palette when you right click which is think is a normal work flow since the right click doesn't give bread crumbs to navigate up, only down. I intend on using this in my package building instead of the built in function because of its support for multiple classes and libraries within a package. Set All Libraries and Classes Default Palette.vi
  15. So I thought I'd try out the Add Palette to Library or Class option when building a package and I found a few limitations, but first let me mention a bug that I think prevents it from working properly. I tested the feature by building a package and checking the box, then selecting a .lvclass file that is in my source. I then built the package and installed it. But when I right clicked on a class constant or a member of the class the root palette didn't show up like I expected. I opened the installed class and saw what in my case was the "functions_Hooovahh_CAN.mnu" file added to the root of the class. I also opened the class in a text editor and saw the line: functions_hooovahh_can.mnu The problem I see is that this is a case sensitive operation. I editing the text in my class file to read: functions_Hooovahh_CAN.mnu Then closed and reopened LabVIEW and my root menu now shows up if I right click a node on the block diagram. This was built with VIPM 2016 SP1 2016.0.1 build 1991. In addition to this I think this feature is a bit limiting. This feature only works if you are building a package with one class or library in it. My reuse library is build in ways that mirror the NI palettes, and as a result having a palette like "File I/O" means there are several subpalettes each potentially with their own library. Being limited to only selecting one library for a package means this just doesn't work properly. What I think would be a neat feature is to look at the members of a class or library, then figure out what is the most root palette created that a member belongs to, and then add that mnu to the library and adding the default menu there. I think I can do this in a post-install VI but think others might benefit from a simple one click checkbox which would do this for you. It is also possible that I'm the only one that has more than one library or class in a package.
  16. So I have a package that has a Post-Install Custom Action VI but the path to it is not under the main source folder. As a result when I scan for package dependencies, the ones that the Post Install VI rely on are not listed, and when installing the package on a new machine, the install will fail and I believe it is because it is installed before the dependency, since one was not found.
  17. Okay I think I got a new one that's related. I had an error today on an uninstall of a package. I suspect this is because I have a Post-Uninstall VI that gets ran after a package is uninstalled. But it has a dependency on a subVI that is in another package. I didn't investigate it too far, but what I suspect is happening is I have a dependency that says package A depends on package B. Then in my Post-Uninstall VI in package A, I call code that gets installed with Package B. During an uninstall, does the order of an uninstall occur so that package A will be uninstalled before package B?
  18. I understand cleaning up references is generally a good thing, but is there a reason the JKI State Machine attempts to close the This VI reference of a VI that is in memory? This in my mind is basically a no-op and can be removed because the close can't remove the VI from memory since that is the VI that is running. Which brings me to question why we even get a copy of the This VI reference and put it in the shift register. If you have a property or invoke node set to the VI Server class "VI" then you can leave the reference unwired and it assumes "This VI", which is actually seen in the "Initialize Core Data" case. Is there a good reason to keep a copy of This VI in the cluster? And if so is there a good reason to have a Close Reference in cleanup?
  19. Yeah I tested it and you are right that the dependencies are installed before the preeinstall VI is ran. But what type of solution is there for including a sub VI that isn't in a package? For now I inclined the VI but it is a bit of a pain updating it.
  20. What is the best way to handle having a Pre and Post Install VI call, that has dependencies on other VIs that either might not be installed yet, or other subVIs that aren't part of a reuse library? For instance I have a Pre-Install VI and it uses some OpenG functions. The problem is I suspect it is possible that the user hasn't installed the OpenG functions yet. It might be a dependency of this package being installed, but I assume it can't be guaranteed what the order of install is, but maybe I'm mistaken and this isn't a problem. But the second issue I have is my Pre-Install VI has a few subVIs, that aren't a part of the project. When building the package I don't think these subVIs are included, and when the package is being installed the Pre-Install VI is called and I see the searching dialog trying to find the subVIs in a temp folder which is where I assume the Pre Install VI was extracted to and ran. Should subVIs in general be avoided in Pre and Post install VIs? Should they work as expected but for some reason mine crapped out for an unrelated issue?
  21. Thanks Jim I appreciate the effort, this will make adopting reuse easier.
  22. Is there a good reason that the JKI State Machine isn't licensed under BSD, or LGPL? I'm sure JKI has their reasons to have a custom licence agreement, and that is their right. But some things in that standard JKI agreement seem odd when applied tho the State Machine Template. It has a section in there for High Risk Activities (section 5.2) saying you should not us the State Machine Template on any application that failure of the software could lead to death, injury, physical, or environmental damage. If I'm a lawyer I'd say that basically means I can't use this template to do anything that interacts with the real world. Need to control a power supply? Nope, it could cause injury or damage if the power supply is hooked up wrong. I'm working on a sensitive program at the moment and they are looking at the reuse packages being used. They haven't said the JKI template is a problem, but if they are going to push back it will be because of this.
  23. All very good stuff, and thanks for explaining some of the reasoning used. I generally don't use the Duplicate Case, because I like where in the case my new case should be. Like I may want "UI: Update UI" to appear after "UI: Defer Panel" because generally Update UI happens after a Defer, so I will use the Add Case After to ensure my order is what I want. If I use a template case and duplicate it I then need to perform another step to rearrange the cases. But I could change habits if it means things like the Add States VI comes along. The only other thing I'd like to say is on the cluster initialization. I agree to keep dependencies like a subVI and type def'ed cluster to a minimum for templates like this. What was I suggesting was more like moving the bundle and the init data outside the while loop like this. This could be a user preference thing. Because this way it is easier to quickly see the init values without having to change states, and it is easier to add new data. But this does make the template wider. For me it doesn't mean I need to make my window larger. This could mean a horizontal scroll is used to see the init data. This doesn't seem ideal for a template because a first time user of it might be confused not being able to see everything. Honestly I could see making my own modified JKI state machine that moves the bundle and makes a few other modifications that might be user specific preferences. Like I don't like the return key toggleing the OK button causing an exit. If anything I use Escape to exit.
  24. I should probably make a new thread for this too, but the state machine could used some Linked Input Tunnels for the cluster of data, string states, and error data, through the case structure and event structure Also I'm a fan of having cluster initialization happening outside the while loop. This is the stuff normally found in the Data: Initialize. I tend to have lots of data and it doesn't always fit in that case. Adding it on the outside also makes it easier to add new data. This also cuts down on the number of uninitialized shift registers which can lead to problems if you aren't careful. Which brings me to another possible improvement. The error shift register could have an Error In on the input instead of being uninitialized. Oh and if you do add an error in, it would be nice to have an Error Out, and to wrap the while loop in a case structure that does nothing if there is an error coming in.
×
×
  • Create New...

Important Information

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