Jump to content

Ton Plomp

Members
  • Posts

    1,991
  • Joined

  • Last visited

  • Days Won

    38

Posts posted by Ton Plomp

  1. No I did something different (but equally far more powerfull).

    First a typedef with some standard data, and a variant:

    2I0Zh.png

    Now I can call a VI with these args, and it will insert the args into the Cluster:

    qq8nY.png

    That's why I added the 'extract variant' into th eJSON parser:

    TnB5J.png

    This Way I can extend my calls with args without having to deal with them. And I still have a nice typedef with the generic information present.

    To be clear, Args was just a normal cluster, nothing Varianty about it.

    Ton

  2. Write to Spreadsheet file, does not produce an Excel file.

    It produces a file that Excel converts into an Excel file (you could open the file with any text editor like Notepad).

    Excel files like you need are build using the Excel ActiveX interface, and the Report Generation Toolkit is a method to control that.

    However I won't be surprised if there isn't some VBA on the internet (Excel code) to merge Excel files into one file with different sheets per source file.

    Ton

  3. I don't really have an opinion on the different errors, but we need to make sure we parse as much as possible.

    On a library/package I think we should look into making this Team LAVA worthy, and thus follow the Guidelines for locations and packaging.

    What should the name be?

    • JSON LabVIEW (as it currently is)
    • JSON API (which I prefer)

    And examples should be placed under the 'Examples' menu

    Ton

    PS For anyone interested in development, James, Shaun and I are totally working on it (see for yourself)

  4. I added another 'mode' for this VI:

    • Maintain phase, dismiss missed

    To show the effect of the three modes I made this table (with a dT of 50 msec), all times are in msec:

    post-2399-0-94357900-1351955966.png

    Graphical this is the representation:

    post-2399-0-67588400-1351956011.png

    Now for the difference between 'Maintain phase' and 'Maintain phase, dismiss missed' some more zooming in:

    post-2399-0-90174100-1351956135.png

    Where at 3.35, 3.36 and 3.51 a call was made.

    All three models will return a True for the first call (the wait time before was > 500 msec).

    When 'Maintain phase' is selected 3.36 returns a True as well, (the wait time was > 1000 msec).

    The 3.51 call returns True for the 'Maintain phase' and for 'Maintain phase, dismiss missed', since the phase is stuck at 3.50. 'Since last' returns a False since the time since the last trigger is < 500 msec).

    Here's my current VI:

    post-2399-0-60739200-1351957411_thumb.pn

    post-2399-0-63964800-1351957453.pngpost-2399-0-07430900-1351957485.png

    Periodic Trigger.vi and the test VI Periodic TriggerTest.vi

    so you can run your own scenarios.

    Ton

  5. I have added feature request to the OpenG tracker for this functionality.

    Some detail on the code change is in this discussion.

    This review has the following options:

    • Do not add a 'Maintain Phase' input
    • Add a 'Maintain Phase' input, defaults to 'False' (means that we don't need to deprecate the old code)
    • Add a 'Maintain Phase' input, defaults to 'True' (means that we need to deprecate the old code)

    Please add your vote (it's public voting), if you have input for this discussion please add it!

  6. OK, I figured out what the essential difference between the two implementation is.

    The original OpenG Periodic trigger resets the phase upon every trigger. Your implementation is maintaining the phase.

    I have a little table showing this:

    post-2399-0-08085700-1351436224.png

    Where I had a Time (ms) of 500 ms and waited 450, 100, 400, 100 and 10 ms. The column Next Trigger is showing the output state of the upper Shift Register which basically contains when the next rollover of the timer will happen.

    I think we should add both implementations, making yours the default for new VIs, the old functionality should be maintained via deprecation. So currently already code isn't changing current behaviour.

    Here's my proposal:

    post-2399-0-80425800-1351437434.png

    And it's documentation:

    post-2399-0-12966800-1351437677.png.

    Losing phase has functionality if you alter the 'Time to wait'. However we might need to auto-reset then as well.

    EDIT:

    Please note that you might get unexpected Triggers with Maintain Phase On:

    post-2399-0-22557800-1351447327.png

    Ton

  7. I am working on a Plugin system for the Code Capture Tool, and one of the plugins I have in mind is a 'LAVA Gallery upload'. Using some kind of authentication (user api-key or something) a user could upload codeshots to LAVA in a specific category.

    I have been digging around on the IP.Invsion page and there seems to little info on this.

    There is mention of an API but no documentation of the upload function (here)

    I allready added a feature request to IPS . But perhaps something like this is allready available.

    Ton

  8. The thing to be careful is not use characters that operating systems don't like i.e. "/" I use this to create a data/time stamp for a file name. This guarantees a unique file name

    How do you make sure this will never run more than once a minute?

    (allright I have a simular one, that adds seconds, and I never make sure it runs just ones a second).

    Ton

  9. So if I understand Stephen correctly one of the things witholding NI from forking the code from LAVAG (amongst others) is the BSD requirement to have the author in the license notes of a binary. I can understand the 'tight coupling' argument by Stephen (NI==LabVIEW). We could create a special version of the BSD that would remove the attribution requirement for binaries.

    It could be (for instance):

    Copyright © <YEAR>, <OWNER>

    All rights reserved.

    Redistribution and use in source and binary forms, with or without

    modification, are permitted provided that the following conditions are met:

    1. Redistributions of source code must retain the above copyright notice, this

    list of conditions and the following disclaimer.

    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND

    ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED

    WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE

    DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR

    ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES

    (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;

    LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND

    ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

    (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS

    SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

    The views and conclusions contained in the software and documentation are those

    of the authors and should not be interpreted as representing official policies,

    either expressed or implied, of the any other organization.

    This would be a '
    ' (see
    ), we could even be more specific about where the license should be placed:
    • Visible part of any FP
    • Visible part of any BD
    • In the VI/Class/Library properties

    I prefer the license in the VI properties, since it allows NI to use BD password protection (or even FP stripping) without breaking the license.

    EDIT:

    Now here's a thought/question for lawyers:

    If I put a license text inside the description of a class, will that cover all the VIs in the class?

    Shaun would it hurt to use such a '1-clause' license for certain products?

    Ton

    • Like 1
  10. I managed to get this working in a build application.

    • Use a conditional case structure to load the NI Resource file in an executable:
      post-2399-0-62353000-1350408685_thumb.pn
    • Place the Option VIs outside of the exe (otherwise I got an error 13)
      post-2399-0-80801900-1350409153_thumb.pn
    • Place all of the dependencies inside of the executable (previous step would add a lot of files to the build result from within %resource%)
      post-2399-0-06448700-1350408987_thumb.pn
    • You get the path by adding the VIs as a static VI members
      post-2399-0-29322600-1350408761.png

    After those steps you can use the Preferences dialog in an executable. However it is slow. Really slow.

    And sometimes the framework will not load the data properly. Not sure why. However the timing (and complexity of the structure seems the culprit).

    Ton

  11. Thanks a lot for your help. I tried to solve this problem with shared variables and it seems to works. But as always there is another problem how to close add_file_to_data_viewer.exe window after it runs data_viewer.exe. I though it would be trivial problem to code but it is not.

    Anyway thanks for your help (if you have any other idea or examples how to solve it would be great)

    I don't know how it would help?

    For closing, you only need to close all the open Front Panels of an EXE, that will close the executable.

    And maybe we didn't understood your problem correctly.

    Ton

×
×
  • Create New...

Important Information

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