Jump to content


Highest Reputation Content


#6073 Error 53

Posted by krosefree on 27 May 2015 - 09:42 PM

Hello Javier,

 

Ah yes, that solved my problem.  You are a giant among LabVIEW developers!  Thank you so much.

 

Regards,

 

Kurt


  • 2


#5437 VIPM update error

Posted by Michael Aivaliotis on 18 December 2013 - 11:46 PM

That first error message is related to the autoupdate. Perhaps the download is blocked by your company.
You can download the SP1 update directly from here.

The other error is something new that I've only seen a few times. VIPM is trying to install a package into LabVIEW and cannot because of permissions problems. This might happen because LabVIEW 2012 was installed with limited permissions.

Can you go to:
C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\addons\
and look at what the permission setting is on that folder? That might give us a clue.

Normally LabVIEW is installed with open access to the vi.lib folder. So this is not a problem.
If permissions is an issue then you may be able to get it working by setting VIPM to launch with admin access. You can configure your VIPM to run using "Run As Administrator". You can also set this permanently in the security tab of the shortcut properties page:


2012-05-16_0954.png



  • 2


#5041 VI Package Builder error

Posted by Michael Aivaliotis on 11 December 2012 - 07:55 PM

Just to follow up on this.

We had a customer that experienced this issue and submitted their code through our support form. Based on our analysis, we were able to determine the reason for this error in his case. This does not necessarily mean it will fix your issue but this is something to look at:

If you have your code inside an LLB and there is an lvclass inside the LLB, you will get this error. VIPM tries to read that lvclass file and fails because it's inside an LLB and VIPM has a problem with that. Posted Image

As a workaround, remove the lvclass file from the LLB or better convert the LLB to a folder. This should allow you to build the package. We will add a fix in the next release of VIPM for this issue.

If you really need those files in an LLB you can instruct VIPM to do that during build by defining a destination as an LLB (see image):

2012-12-11_1157.png

  • 2


#3778 Error 10 when using Write EasyXML.vi on an existing file

Posted by fab on 09 February 2011 - 10:45 PM

For this project I am using LabVIEW 8.2

When I use "Easy Write XML File__JKI EasyXML.vi" with the path to an existing file, I get the following error:

************
Error 10 occurred at Open/Create/Replace File in Easy Write XML File__JKI EasyXML.vi
Possible reason(s):
LabVIEW: Duplicate path.
************

I would like to have access to the Open/Create/Replace command so I can set if I want to replace the existing file.
  • 2


#6113 What I really wish I knew before using VI Tester

Posted by dpnsw on 06 July 2015 - 12:34 PM

There are a number of items that are not adequately covered in the documentation OR (in the case of the video) actually show you the wrong way to do things.

 

This is not intentional on JKI's part but rather the result of improvements to the VI Tester which didn't get added to the pinned getting started stuff.

 

Important things to be aware of (tested with LabVIEW 2014 32 bit):

 

*) Don't copy the testExample.vit as per the video as you won't be able to see your tests EVER! The .vit is a template file and the VI Tester ignores all templates. You need to right click on the testExample.vit and select "New from template" and save your VI starting with the word test and ending with .vi (not.vit) eg. test-anything.vi

 

Rob Calhoun also makes the following important points in this post

 

  • Test Cases that do not have any test methods do not appear in VI Tester hierarchy. (Maybe this is a feature, but it's not what I would expect.)
  • After creating and saving a new test method the Test Case still does not appear in the VI Tester hierarchy. This is because the Test Case (class) has not been saved, so it still has no test methods from the point of the VI Tester
  • Only test methods that start with the word "test" (at least this appears to be case-insensitive) are considered test methods.

  • 1


#6072 Error 53

Posted by Javier Ruiz on 27 May 2015 - 04:58 PM

Hello Krosefree,

 

Thank you for your post and your comments about the webinar. I am glad you found it useful. The error you are seeing is not at all your fault, but it is due to the type of RT target you are using. Those targets will not support the FP.Open property or invoke nodes that the JKI State Machine uses on the "UI: Front Panel State". But, fear not, the solution is to disable (or conditionally disable) those elements as shown here: http://www.screencast.com/t/KgBZmgfF

 

Please let me know if you have any more comments or questions.

 

Best regards,

 

Javier Ruiz


  • 1


#6059 SubVIs In Pre/Post Install VIs

Posted by hooovahh on 20 May 2015 - 08:28 PM

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?


  • 1


#6058 Can I rename .vip files?

Posted by Aristos Queue on 20 May 2015 - 05:59 PM

Just to close this thread: Yes, you can rename VIP files after they are created. There does not appear to be anything about the name of the VIP that is encoded inside the VIP file. That turned out to not be the source of the crash, just that the name change code went in at the same time s some other code changes that I thought were "harmless". :-)


  • 1


#6021 When will this be released?

Posted by Jim Kring on 13 April 2015 - 04:54 PM

I'm dying to see more of this.  I bid on a project that may start soon and will use the JKI State Machine, and I'd love to consider State Machine Objects.

 

Hi Jim: Depending on how eager you are to play with this, I could get you an early release to test and provide feedback.

 

Jon: Same goes for you.


  • 1


#6012 When will this be released?

Posted by jonmcbee on 01 April 2015 - 07:26 PM

After seeing the presentation at the CLA summit I am looking forward to getting my hands on the code.  Any idea when this code will be released?


  • 1


#6007 State Machine License

Posted by hooovahh on 30 March 2015 - 12:36 PM

Thanks Jim I appreciate the effort, this will make adopting reuse easier.


  • 1


#5987 Deprecated Property Nodes

Posted by hooovahh on 18 March 2015 - 08:38 PM

Are there some things you're especially wanting? :)

Why yes, yes there is.

 

So at my previous company we made our own QMH+.  I thought about using the JKI but at the time I thought arrays were superior to a string that has return characters in it.  My reasoning for this was figuring a delete from array would have less over head than the Parse State Queue which has lots of string manipulation.  I'm not sure I care so much and a single string is probably just fine.  But for the record I'd prefer an array of string.

 

Another difference I had was all state machine loops pushed data to a central DVR in a functional global.  This of course could have a taste of OO but at the time it didn't.  What this allowed me to do is have a way to access all loops in an application that were running.  So when my VI was running I could go to Tools >> Debug QMH and a window would come up showing me all state machines being ran, what states were being enqueued and dequeued, along with the delta time between each step.  This way I could see how much time each state machine was in each state.  This helped improve speed by finding where the states taking the most time were.

 

This DVR Global also had the ability to log this state changing data from state machines.  Then even if my application crashed I'd have a log of what states each loop went to leading up to the crash.

 

The ability to log, or probe a state machine could be turned on and off using that same DVR global.  By default both log and probe were off for efficiency.  But this could be turned on from the built EXE by going to Help >> Debug Application >> Debug QMH which called a VI that I made to enable or disable these debugging features.

 

The JKI state machine is simple by design.  So I'm sure it is difficult to say how many features you want to pack into it.  And some of the ones I mentioned might not seem like a good fit.  But I just figured over the last 7 years the state machine could use some kind of tweaks or improvements.


  • 1


#5985 Deprecated Property Nodes

Posted by hooovahh on 18 March 2015 - 05:57 PM

It is a known issue that the current JKI state machine uses deprecated functions for the Front Panel Open?  Is this an issue that needs fixing?  

 

The latest version of the state machine was released in 2008 according to the copyright on the package information.  So is there plans to update this state machine to use non-deprecated functions for modern versions?  This would also be a good time to add any features and updates in a new release.


  • 1


#5953 Build resource package similar to JKI_RSC

Posted by Jim Kring on 13 February 2015 - 05:57 PM

Hey Chris,

If you're looking to create your own root-level menu, we support this with the Custom Category feature.

2015-02-13_09-40-37.png

The "RSC" thing is just part of the package name. And, I would not recommend trying to replicate what the rsc_palette packages do, since it involves a lot of arcane and complex stuff that I can't remember all the details about right now and I'm one of a small handful of people in the world who understand the details -- I don't recommend joining that club Posted Image
  • 1


#5926 Frustrated by VIPM 2014

Posted by BrianGShea@NTS on 04 February 2015 - 10:36 PM

Item #1 does not work on a very basic class with out locking or passwords. I was able to get the palette to attach to a library. Unfortunately 90% of my code base is OOP and adding the palette to the library does not allow it to show up on VIs that are part of a class within the library.

It seems like VIPM is able to add the mnu file to the class, but is unable to set it as the default palette. You can modify the class after it is installed through the right-click properties and then set the palette, however, this is tedious and i cannot reasonably expect users of my packages to manually do this. I sure hope this gets fixed in the next release. I'm using the latest build as of April.


I found 2 basic errors when VIPM tries to set the default menu for a class.
1) the DefaultMenu xml tag does not match the project item's Name tag. These are case sensitive.

Example:
<Property Name="NI.Lib.DefaultMenu" Type="Str">functions_nts_lib_Object_Attributes.mnu</Property>
<Item Name="functions_NTS_lib_Object_Attributes.mnu" Type="Document" URL="/&lt;menus&gt;/Categories/ReBT/functions_NTS_lib_Object_Attributes.mnu"/>


Notice the missing capitalization on NTS

2) The URL of the Item is does not start with '/<menus>/' it starts with a series of ../../../ as a relative path from the installation location of the class.

Here are two VIs that can be used to fix the problem and allow the default palette to work. Please note that is not a solution for the community, however it is a demonstration of the fix. It could be a solution if Post Install scripts included dependent VIs or this VI was pre-installed as a package that other packages were dependent on so that this VI exists prior to installing other packages.

I hope that these are fixed in the next release of VIPM.

Thanks,

Attached Files


  • 1


#5847 Manually Add Packages to vipc

Posted by Jim Kring on 05 December 2014 - 09:52 PM

Hey James,

Thanks for your question: it inspired me to write up a short blog post on pinning packages :)

Have a great weekend!

-Jim
  • 1


#5845 Manually Add Packages to vipc

Posted by Jim Kring on 05 December 2014 - 08:17 PM

Hi James,

I've just updated the How to use VI Package Configurations (VIPC) help document to include some info about how to manually add new packages to a VI Package Configuration file. Basically, there's two ways:

You can manually add packages to a VIPC file by dragging & dropping them from the VIPM Main package list into the VI Package Configuration window, as shown below:

2014-12-05_12-12-13.png

Or, you can right-click on the package from the VIPM Main package list and choose Send to Configuration, as shown below:

2014-12-05_12-10-43.png

I hope that helps!
  • 1


#6075 Un-Publish/Deprecate vs. Install Other Version

Posted by Jim Kring on 29 May 2015 - 09:05 PM

Hi James,

 

Here's the reasoning behind the current behavior:

 

- If a user installs a package, it gets added to the package cache (regardless of where it came from: double-clicked from the desktop or downloaded from a repository)

- The package list gets populated from a combination of the repository and what's found in the cache.

 

Now, it might make sense to tweak this behavior, such that deprecated packages (as defined by a repository) are flushed from the cache. I think that this behavior would meet your needs and wouldn't have any negative side-effects (except that people who choose to actively install a deprecated package would need to download it again, since it wouldn't ever be cached).

 

Additionally, it might be helpful if unpublished packages (when we query the repo and we detect that it was in the repo previously but no longer in the repo) were flushed from the cache. This would be a little trickier, since we would have to catch the event at the time the package is unpublished (we would see the package is published and then it disappears from the repository's package list).

 

I'll pass the ideas along to the JKI team.


  • 1