Jump to content

ShaunR

Members
  • Posts

    4,939
  • Joined

  • Days Won

    306

Posts posted by ShaunR

  1. I got bit after copying and refactoring a project, then installing the new application on the same PC as the original. The new installer deleted the original app and the old installer would quit when I tried to reinstall it. An NI AE told me how to fix it here.

    Good point......

    Don't forget to press the "Generate" button to regenerate the product code in the version page if your copying an installer.

  2. I'm not sure, but isn't "GetRawSocketFromConnectionID.vi" found in the TCP_NODELAY.LLB of that KB the the same as "vi.lib\Utility\tcp.llb\TCP Get Raw Net Object.vi"?.

    I believe it is (or at least a wrapper for it).

    This is the prototype it (TCP Get Raw Net Object.vi) uses as the call to LabVIEW

    int32_t NCGetRawNetObject(uint32_t nc, uintptr_t *netobject);

    It is just a typecast to get the nc parm from the connection ID.

  3. Well. there is an "Addons" palette. So shouldn't "Addons" be in there? I know your post is against top level folders but I also don't prefer bunching other tools in the labview installed locations as I prefer separation between the standard labview installed software and addons/toolkits.

    It's already a case that we have to drill down 3 or 4 layers of folders to find (for example) the TCPIP vis. It is that that causes menus to roam across the screen rather than having them further up the hierarchy. There is (as I have mentioned) the addons folder. There is also the User Libraries and Favourites on the top level which rarely have much in them...if anything. Better use of the top level palette folders would make more sense. But we are being told that we shouldn't use the User Libraries folder?

  4. Why is it that we do not get the fine-grained thread control for CLNs as we do for VIs - or is it that "execution systems" in LabVIEW are not explicitly threads?

    The execution systems consist of a number of (typically 4...up to 8) threads. In this respect, you are specifying a smaller "pool" of threads that labview should use for a particular VI or set of VIs rather than explicitly defining which threads things run in.

  5. I guess that by saying you are using the "Client Request Waveform" that you are actually polling for the wave forms rather than streaming. This is really bad for performance since you get double the amount of network latency.

    16000 data points (assuming double precision numbers) equates to about 125KB. On a 100Mb connection you should be getting in the region of 60-80 updates per sec (10MB/125kB = 80).

    For an example of streaming waveforms, take a look at Transport.lvlib

  6. Labwindows is (essentially) ANSI C. But it is the packaged libraries you will have to learn since they are proprietary to NI. I would dive straight in with Labwindows (C doesn't have front panels for example) and any good book on C will do for the stuff in-between.

  7. index.php?app=downloads&module=display&section=screenshot&id=196

    Name: Transport.lvlib

    Submitter: ShaunR

    Submitted: 27 Aug 2011

    Category: Remote Control, Monitoring and the Internet

    LabVIEW Version: 2009

    License Type: Other (included with download)

    Transport.lvlib is a LabView API to simplify and accelerate networked communication development.

    It simplifies development by abstracting TCPIP, UDP and Bluetooth and TLS interfaces

    into a single polymorphic vi which is a thin wrapper around the conventional

    open, read, write, close and listener VIs for all the network interfaces.

     

    Features:

    Supports TCP/IP, Bluetooth, UDP (p2p, broadcast and multicast) and TLS.

    Supports symetric encryption (blowfish).

    Supports compression (zlib).

     

    INSTALLATION:

    Run the supplied installer and follow the instructions.

    Click here to download this file

    • Like 2
  8. Ok, so this is an update of the VI based on the above.

    Is everyone happy (e.g. this is the most optimized version for common use case).

    post-10325-0-23005400-1313972541_thumb.p

    These are the relative times (note: Time New and Trim Whitespace+ are now the same BD):

    post-10325-0-09762700-1313972238.png

    Trim Whitespace.zip

    Looks familair ;) . But I think the second 0xD in the arrays needs to be a 0xB if it is considered a white-space (personally, I don't think 0xB and 0xC are...but that's probably a judgement call).

  9. @JG

    Well. Both functions of yours are much faster than on my machine. Not running on a quad core are you? (it does use parallelism).

    Yes I have optimised the order. But for the purposes of your tests; I moved the space char to be the last.

    But in my tests (poor lowly Dual core) it made no difference whether it was in the first frame or last. The original was about 10ms faster, but since your tests are 100 ms faster than mine anyway;that's about a gnats fart :P It's interesting to note that in both our cases, the native LV function is pretty similar. Again I'm coming back to parallelism since the regex functions only use the UI thread (if I remember correctly).

    Note that I don't have the openG libs installed so the old one is disabled (hence zero)

    Still waiting to see the performance improvements in 2011...lol.

    @JK.

    The main advantage of this method (over and above just being faster than the in-built function) is that it is very robust in terms of the length of the string (very similar times for a short string of say 10 chars and one of ..say 10,000 chars-all beginning and end white spaces being equal). Performance is dictated by the number of white spaces only, unlike the other methods that need to iterate over the entire string.

  10. @ JG

    Why have you slowed it down? :P (those arrays were inside the for loops for a reason ;) )

    @JK.

    You are right. The original Trim Whitespace+.vi (thanks for pointing out the two chars I missed JG-are they considered whitespace?) was a direct replacement for the built in Trim [whitespace] function. However. the Fast Trim was more useful on comms strings (especially serial) where you can have all sorts of non-printable chars and not just "whitespace".

    • Like 1
×
×
  • Create New...

Important Information

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