Jump to content

Ton Plomp

Members
  • Posts

    1,991
  • Joined

  • Last visited

  • Days Won

    38

Posts posted by Ton Plomp

  1. Electrical circuit design can use either schematic or HDL. They are equivalent representations of the same thing. The designer can choose the best solution. Why does G have to be graphical only?

    What you are implying is a graphical IDE for C, .NET or ........? I don't think there's a market that is economically valid for NI, the LabVIEW language is pretty good covered by patents, while other languages are more open.

    And in fact LabVIEW code is converted to text, Machine Code to be more precise.

    Ton

  2. Would it be useful if I generated a LabVIEW-only AES128/256 solution? I am thinking of making it one of the 'student challenges' next quarter; see what they come up with.

    -Justin

    Hello Justin,

    that sounds really cool. I am looking into AES right now and the different steps are puzzling (if you only use the NIST standards).

    I have a HMAC/SHA libarary online (bitbucket source) and would love to add an AES into that package.

    Ton

  3. Perhaps you are maxing out on handles. Windows can only give a dedicated number of handles for each application (link, I have not studied it). But it sound to me that even if you close all references, you will get errors eventually, so be very careful in case of opening handles in a loop. Perhaps you can create your own handler of handles.

    Ton

  4. What would be even cooler than uploading snippets to the site would be some sort of snippet browser available from the IDE.

    [plug]

    The code capture tool supports Imgur as an upload target.

    [/plug]

    Chrome, Firefox and Safari treats images differently than IE. When you drag to the block diagram you will just get a URL where IE will let you drag the raw image data from the browser. This is not a limitation of the snippet that can be fixed (that I'm aware of)

    Neither is Opera working.

    I think that NI puts someone on this issue it can be fixed rather fast. I assume that you need to look at some different drag and drop info.

    I have submitted an idea at the NI LabVIEW Idea exchange on this subject.

    Would it be possible to have simple POST methods for the VI snippets site?

    Ton

  5. Hello LabVIEW Community.

    I'm gathering some research and would like to know the following:

    1. Do you use LabVIEW Snippets?

    2. How often do you create new snippets?

    3. How do you organize your snippets?

    Just general answers. I'm just getting a feel for how the community is using this feature.

    Thank you in advance.

    Ryan

    Apart from saving snippets for use in the NI/LAVA forums I use them as a documenting tool on our internal WIKI on bugs, code constructs etc.

    I think I create snippets on a daily basis, for this the NI tool is absolutely not adequate, hence I use the Code Capture Tool. This provide the followin advantages:

    -Adding a configurable header to add some info on the VI and LabVIEW version

    -Adding notes and description (arrows, rectangles) for high-lighting

    -Saving them in a configurable location

    -Keep property notes connected

    -Include the front panel image as well.

    -Copy the file path to the clipboard

    -For computers directly connected to the internet it can save the image on Imgur

    Ton (co-author of the Code Capture Tool)

  6. When I look at the LAVA page I have several options for RSS feeds to subscribe to that are empty:

    Lava Community blog feed (http://lavag.org/rss/blog/)

    Articles (http://lavag.org/rss/ccs/1-articles/)

    Media Demo New features (http://lavag.org/rss/ccs/2c9-new-features/)

    Media demo - other (http://lavag.org/rss/ccs/2c10-other/)

    Report center RSS feeds (http://lavag.org/index.php?app=core&module=global&section=rss&type=core&member_id=2399&rss_key=a6e1bb31db3901678f095f895be06880)

    Is this intentional?

    To

  7. Here I would disagree. There is a very important difference between data-flow languages and all other languages.

    At first, this is a bit hidden in the compiler (there are some good explanations in wikipedia, and of course some pretty detailed issues posted mainly by AQ):

    In a text based language I can write

    i=i+1

    where the data before and after this operation is stored at the same memory location.

    In LV you can't. Each wire (upstream and downstream of the +1 prim) is pointing to a unique memory location.

    NO!

    If you program in such a way that the wire before the +1 primitive isn't branched at all the LabVIEW compiler will reuse that memory location.

    Likewise it's important to remember that if you are adding a scalar and an array using the '+' primitive you need to wire the array to the upper input of the +, the compiler tries to use the same memory location for the output as for the upper input (-/* likewise).

    Ton

  8. I've been thinking a little bit more about this, and I would say it's pretty good doable!

    We should deprecate all of our current VIs and we should add some things to our deprecation process:

    -Each VI that is deprecated should have a boolean tag 'Deprecated ==True'

    -If a VI is deprecated there should be a relative path tag 'Replaced by' that contains the path of the VI it's replaced by.

    Now we could write a tool that goes over all the VIs in a folder or hierarchy to update the code to the latest version.

    Ton

  9. In theory:

    YES

    I would opt for a library name with the following naming theme: OpenG.String.lvib, on the actual VIs we could lose the name mangling (__ogtk).

    Now for real, I think this is a hard one to do. It would mean deprecating all of out VIs and wrapping them in complementary libraries. Our could we hack some update code in congregation with NI?

    I think it's doable to write some 'wrap and deprecate' tool to do this and regenerate our palettes.I wouldn't want the polymorphic VIs to be public and make the specific instances private, main reason is that Real-time cannot cope with variants, and you couldn't bypass the public polymorphic VI by calling directly into the specific instance you need.

    Ton

  10. I was trying to get organized.

    3) I created a Library and used Folder(Snapshot) to add all my dependent files to the Library (to prevent cross linking from a branched project where some of the TypeDefs and SubVIs might have the same name).

    4) I went to save my Library into SCC but LabVIEW asked me to save all my SubVIs in memory. I happened to NOT have my entire directory checked out in Perforce (so I was denied and had to not save).

    The strange part about this that the LabVIEW Prompt says "Loading.." and show the 100% correct absolute path of file that I have to go manually browse for and select.

    What is even stranger is that my inital VI that was checked-in in Perforce is acting the same. (Even though this VI is one revision before I created this Library).

    What happens a 3. is that by placing all the VIs in the library the canonical names (not paths) of the VIs are altered. LabVIEW basically relies on VI names (not paths).

    You did this with the functions calling into these VI in memory, LabVIEW can detect this and probably showed a dialog 'foo.vi is being altered do I need to check out?' (or you disabled this option in the SCC options dialog. You didn't check out, but you couldn't save your changes.

    If LabVIEW tells you you need to save, you probably do, it's pretty good at this. (at 4. you actually had to save).

    So any VI linking to a VI moved into the library is looking at the right spot for the wrong VI.

    The easiest way to fix this is by manually opening the VIs and select the VI you need.

    Ton

  11. I have a problem with your request. If you generate one combo box , you can't modify it another time ussing State editor. Or i need to detect-it and and convert it to string constant.

    No you don't have to!

    I was worried about this as well, but it turns out that the combo-box constant is a sub-class of string constant (which you are registring for), so the tool keeps working the same way!

    It might be nice to set the checkmark if the string constant is a combo-box so the drop-down list gets updated when running the State Editor.

    Ton

  12. Feature request:

    Optionally change the constant into a ComboBox constant:

    <object id="scPlayer" width="225" height="290" type="application/x-shockwave-flash" data="http://content.screencast.com/users/TonPlomp/folders/Jing/media/1248a53e-b04e-4b98-a790-d3a3732d611e/jingswfplayer.swf" > <param name="movie" value="http://content.screencast.com/users/TonPlomp/folders/Jing/media/1248a53e-b04e-4b98-a790-d3a3732d611e/jingswfplayer.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/TonPlomp/folders/Jing/media/1248a53e-b04e-4b98-a790-d3a3732d611e/FirstFrame.jpg&containerwidth=225&containerheight=290&content=http://content.screencast.com/users/TonPlomp/folders/Jing/media/1248a53e-b04e-4b98-a790-d3a3732d611e/State-dropbox.swf&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.screencast.com/users/TonPlomp/folders/Jing/media/1248a53e-b04e-4b98-a790-d3a3732d611e/" /> Unable to display content. Adobe Flash is required.</object>

    Here's the code I used in the JKI state editor:

    post-2399-0-72271900-1301402506_thumb.pn

    Ton

  13. John - I don't have a pre/post build action option in my app builder, is that a new thing? (I'm on LV 8.6)

    Ton - Is there any way to make the version of the lvlib library auto-increment? My llb file already contains the lvlib associated with the plugin VI, so I could potentially use that....

    Thanks for your help.

    Paul

    I have a tool that acts like a pre-build tool, and after that calls the NI-builder.

    Ton

  14. I can see your point, however how likely is it that you don't know by forehand wheter you have large attributes (thus need the enumeration) or have large attribute-names (thus need indexing)?

    If you develop your code you'll probably know which one of the two is most likely, or you could add an attribute called 'Style' that tells the code to either index or enumerate.

    However you can index attributes, by placing the attribute inside a variant inside an attribute, this attribute gets a short name. The footprint will reduce however but will be dominated by the size of number of variants.

    One other question, have you also played with small attributes with long names (the inverse of the first case)?

    Isn't it possible to use the 'Get attributes' without a name, but with a type (thus eliminating the 'variant to data' for the first code)? I think it is possoble, or should be in the LabVIEW Idea Exchange.

    Ton

×
×
  • Create New...

Important Information

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