Jump to content

Francois Normandin

Members
  • Content Count

    1,146
  • Joined

  • Last visited

  • Days Won

    32

Francois Normandin last won the day on September 16

Francois Normandin had the most liked content!

Community Reputation

157

1 Follower

About Francois Normandin

  • Rank
    Son of Scotland
  • Birthday 02/26/1975

Profile Information

  • Gender
    Male
  • Location
    Montreal, Canada
  • Interests
    LabVIEW (!!!), Astrophysics, Science-Fiction, Kilts.

LabVIEW Information

  • Version
    LabVIEW 2017
  • Since
    1999

Contact Methods

Recent Profile Visitors

8,183 profile views
  1. I'll be there as well. Since this will officially kick off my vacations, I will not be presenting this year 🙂. I'm eager to sit back, relax, learn and chat with all you guys & gals.
  2. Remember that the DVR is a container which contains the class. Since your class is privately scoped, only library members can act on it. No terminals containing the DVR will allowed unless your class itself is accessible to the caller. You can still achieve exactly what you want by moving your interface methods (DVR terminals) inside your class as public members of the class. As @smithd suggested, make all your current class members be protected (if dynamic dispatch methods) or private (for your static dispatch methods) and set your class' scope to Public. In addition, you don't need a lvlib to wrap your public interface as the class is already a library.
  3. @donk you haven't overlooked anything. Unfortunately, somewhere in the past (was it 2011?), LAVAG experienced a massive failure and most attachments from that time were lost, or at least the links could not be recovered programmatically from old thread backups.
  4. The LWZ Unpack algorithm is very slow in the OpenG implementation. I found this post over in the NI forums and tested it with your image... much faster. https://forums.ni.com/t5/Example-Program-Drafts/Read-GIF-File/ta-p/3514726 Edit: Set image to "-1" to load them all:
  5. Version 1.2.0.6 released. https://github.com/LabVIEW-Open-Source/DataManipulation/releases/tag/1.2.0.6 Added support to return a list of Event reference types (class of event) for Event Registration Refnums Controls, Panes, Splitters, VI References and Application References. Array is empty for all other datatypes. ** Please note that this does not drill into clusters of Event Registration Refnums. This is only one-level deep. I have not tried, but I assume that getting the cluster elements and then looping on those should work...
  6. They show up as Generic Refnums. (0x08) If they are named refnums, they should show up as in this example where "This VI" is the label. You can tell if they are named references by the 0x40 flag. If your events are named, they will show up in the list. The type of event is set in the last long byte in the "First Element" highlighted in green in the screenshot. (xA4 10) xA4 = VI reference, x10 = Key Down. I'll add this support to the OpenDescriptor. That is definitely useful info to get! I'll report here when done.
  7. The ~5% slower Map vs Variant Attributes is consistent with what @altenbach reported in his NI Week presentation, for very large datasets. Since one set is ordered, the other is not, it might be interesting to benchmark the "delete" operation and see if it is symmetrical. My intuition here would be that finding the key and deleting it would be ~5% faster in favor of Maps (for large datasets). Since I rarely deal with large sets, I'm egotistically happy with NI's choice to make those sets and maps ordered.
  8. You can extract the labels from the type descriptor, once you know where to find them in the array. I added support for it in this open source DataManipulation library. Check out the OpenDescriptor palette. You can install the latest release (1.1.0.5) from here: https://github.com/LabVIEW-Open-Source/DataManipulation/releases/tag/1.1.0.5 (download VIP file and install with VIPM). Once installed, you'll find the "List Element Names" method under Addons>DataManipulation>OpenDescriptor palette. (It can list enums and cluster elements as well, although those are natively supported under the Variant Utilities palette.)
  9. I don't have a scoop on that, other than they extended the conference by half a day and there will be a public Engineering Impact Award ceremony (whereas before it was a closed event for the nominees only). I don't know if there are more changes to the formula.
  10. Not sure that's the issue, but lags can sometimes occur because the installed code is not compiled for the current version you're using. If you're using VIPM to install the package, make sure your options are set not to prevent compiling after installation. Alternatively, browse to the installed package folder and force it to mass compile. I've seen this behavior for code that installed under Tools menu (under LabVIEW 20xx/project) which were not compiled, so there was always a lag the first time you load it in memory. Being being installed in a non-write accessible folder, it would cause the same issue the next time you'd open LabVIEW and brought the code back into memory.
  11. I agree with James. That could be achieved through composition and adding an abstraction layer. (Sink and Source in the diagram below)
  12. Bonjour Antoine, I'll take a look at this. Can you tell me which version you've installed?
  13. If you need to track frequency in a noisy realtime environment, I've seen Kalman-based filtering being used. Unfortunately, I don't have an implementation example to provide. NI has this discrete filter in the Control Design and Simulation toolkit... which does not come cheap.
  14. It's been moved to another website: http://vfpsoft.com/aes/aes_home.html
  15. The Message Enqueuer instance is created within Actor.vi and encapsulates the receiving queue of the actor. The Actor launcher does not expose any way to specify a more specific type of message enqueuer, so I'm afraid that even though you wish to extend this class, it is impossible to instantiate it with your child type. The reason the Message Enqueuer does not let you access its private data is that it is specifically meant as a wrapper to prevent anyone from accessing the Priority Queue class. I assume the intent is to make sure you cannot mess with the message delivery principles such as rerouting messages before they arrive at the Actor Core. If it were allowed, it could cause thread safety problems, security issues (possible hacking target) or mess with the #1 feature of actors: trust that messages are processed by the core in the order the messages were enqueued.
×
×
  • Create New...

Important Information

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