Jump to content

rdr

NI
  • Posts

    12
  • Joined

  • Last visited

Posts posted by rdr

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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)

  6. Not good at all!

    Downgrading high class community ware like OpenG libraries is a statement in it self. Your grading should be based on itself product quality not the support. Also the basis for your classification can not be easily realized from your web page.

    http://sine.ni.com/n...SWT_L_Standard/

    Well your own support can not always help out with simple problems even in 30days...

    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

    Doesn't LAVA fullfil these requirements?

    1. I'm sure every single post was replied to in much less than 2 days. When I had issues to solve, posted them on lava, I received the support even on public holidays. :thumbup1:

    2. Many of the members in this community also have a brilliant record on helping others on the public NI forums. Very few of the offical NI support team will be able to compete with this on all levels (inside knownledge, number of posts, response time, real-wolrd app experience).

    Just using these two arguments, I think the complete LAVA CR (certified) section should go for Gold. :star:

    Felix

    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

  7. 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

    • Like 1
×
×
  • Create New...

Important Information

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