Jump to content

rdr

NI
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

1

About rdr

  • Rank
    Active
  1. Here is what you get when trying to find this thread through google: https://www.youtube.com/watch?v=4yO8f-fySnQ Now I want a steak. See everyone at the BBQ!
  2. I've also seen this issue on my MBP-R with Parallels 8 and Win 7. I believe you can tweak the VMs settings for scaling to improve the behavior and I've found restarting the VM sometimes helps. It's an odd issue related to scaling for the high resolution used by the VM...
  3. Have you tried renaming/removing your LabVIEW.ini file and restarting LabVIEW to force creation of a new "vanilla" file? -RDR
  4. Change the code? Maybe. I've not gone too deep into the perl script with these tools and basically re-purposed the tool chain from a set of internal tools used by NI tech writers several years back. Is there anything unique about the attribute/name that isn't generated in the parameters file? Is it a standard VI with a fairly normal name or is there something to it that could be throwing off the scripting behind generating the parameters xml file? Does it always occur with the same parameter? As mentioned, I need to seek approval to open the tools as there are some private methods used -- I'll try to just lock down the sections of code R&D does not want me to release and open the rest of it up. -Bob
  5. Hi Tadowden, Sorry for the lack of a reply from my end, I thought I'd set this thread to notify me when a response is posted... You will end up with one .chm file to install into the \help\ directory. This generated .chm will not be linked to from any of the .chm files shipped with LabVIEW, but LabVIEW will auto-populate the 'Help' menu with an entry for your generated .chm. We do not ship the HTML Workshop project file for our help documents with LabVIEW, so I strongly advise against tampering with those files. I am not sure why opening a .chm would ever refer to a .mnu file. Where exactly does this error occur? In the xml files with _pal, make sure your VIs are all listed correctly, there are also log files created when the xml and html files are generated with information about items that were not handled correctly...do your log files show anything? When is the parameters.xml error reported? I'll see if I can post the code unlocked so we can troubleshoot further. -Bob
  6. You will need the x86 version of ActivePerl and not the 64-bit installer (updated the Community doc to indicate this). I just tested with the older version of ActivePerl and it works on 64-bit system (v5.12.4.1205), here: Link -Bob
  7. Ah. The TopLevel = True tag needs to be applied to the xml file created in step 4-3. In your output directory, you will have XML files with the name of your VIs and others for the .mnu file you specified when checking 'XML from Palettes'. There should be an XML for the name of your top level palette file ending in '_pal.txt'; do you see this file or did you not specify a palette mnu in Step 3? If you do not have an mnu file to document (it will create table of contents similar to documentation in the LV help, with tables representing the palette structure), for now create your 'allVIs.xml' with: <?xml version="1.0" encoding="iso-8859-1"?> <allvis> <vi filename="Convert_to_LabVIEW_Array.xml" /> <vi filename="Find_Object_Children.xml" /> <vi filename="Return_Child_Value.xml" /> </allvis> Where you replace the filename with the filename of your VI XML files. Then try the next step. I'll try to resolve this issue in the meantime and put out a new package. -Bob
  8. I've not seen this error before and I adopted this utility and had to "bring it back to life" in a sense, so I'm not surprised these errors will occur. I'd also like to open the code up for you all, but there are internal tagging methods used so I'll need to run it by R&D before I can make that happen. So, I'm sorry for the bugs -- let's move on to resolving this one! For this error, do you see a 'VI errors.txt' or '_errorlog.txt' file in your output directory? Could you post the contents for me if this log file? To be clear, the steps 1-3 you're referring to are steps 4-1 to 4-3, correct? The error is then reported when you click 'Generate Files', which will parse the VIs...what version of the ActivePerl community edition did you install? Thanks, -Bob
  9. User.lib is really intended for customers to store their own code re-use libraries and add-ons/toolkits for LabVIEW should really move to either Addons or one of the other existing palette categories. As for usability, I find it easier to locate related palettes in the same category over having multiple large top-level palette sets, and with some common branding on the palette icons one could clearly identify a subpalette as being part of a suite of libraries like OpenG, LAVA, MGI, etc. However, with the case of OpenG I have gotten used to first looking in the palette/category where I expect to find a function before looking in the OpenG palette, and this has not been frustrating at all... -Bob (the other David_L)
  10. Be sure to ask Saphir about the pictures included on these mousepads -- most are of the Saphir employees "going for walks"!
  11. Good points! We're working with our web teams to improve the LabVIEW Tools Network going forward and have plans for improving the sorting and display of products. The Compatible with LabVIEW Levels require more than just a support requirement, we perform "black box" tests on products with a list of criteria and obtain surveys from users of a product to help determine how well it functions when used in real applications. So we hope to hit on quality as well! The support requirement is not for resolving an issue within 2 days, rather we want to provide customers and users with an expectation for how long they will wait for a response after submitting a support inquiry... My question is more along the lines of what are your thoughts on requiring support for free products like OpenG and other freeware APIs/Add-ons? Is this a feasible requirement for all free products or should we treat free products differently? -RDR I was not intending to take shots at the OpenG library! Definitely not! Your forums are very active and are great for LabVIEW developers! The OpenG libraries are also widely used and we're open to taking these libraries through our Gold product testing; however, with the current program requirement for a 2-day turnaround on support requests we hit a snag for one of the Gold product prerequisites as the turnaround time for support inquiries is not documented and therefore is not guaranteed for a customer/user. http://decibel.ni.com/content/docs/DOC-8981 Perhaps Chris B will chime in with input on the OpenG library as he's our team member who reviewed this product for the Silver level... -RDR
  12. We (NI) revamped the Product Partner and Compatible with LabVIEW programs over the past few years and I wanted to ask the LAVA community for feedback on the support requirements for Compatible with LabVIEW Silver and Gold products. I wasn't sure where to post this topic, so I'm sorry if the Lounge is not the correct forum! Our requirements for this program are for Silver products to have a documented support plan or policy; we want users to have somewhere to go for support for these products! This is a pretty straightforward requirement where we accept pretty much any support offering (email, forums, telephone, etc) as along as it's documented in the product. The purpose of this thread is really intended for feedback on the Gold Product requirements, where we require a documented support policy with a minimum 2-day response time. We're open to companies or organizations having a pay-for-support policy, but it must meet this requirement in order for a product to reach the Gold level. We see a potential issue for free products like the OpenG libraries where they are maintained by a community and no one individual is responsible for support; how can these free products offer a guaranteed 2-day response time on support inquiries? Why is the 2-day response time relevant? Well, we are anticipating these APIs being used by customers in mission critical applications and we don't want these customers to be stuck if a bug or some other issue is found. So, what are your thoughts? Thanks! -RDR NI Partner Program Staff Engineer
×
×
  • Create New...

Important Information

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