Jump to content

Francois Normandin

Members
  • Content Count

    1,145
  • Joined

  • Last visited

  • Days Won

    31

Posts posted by Francois Normandin


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

    image.png.f9b69e0a3fa3c9136a46304fa0b57612.png

    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.  

    image.png.b93bbadf0543dc32592a3c72b2df59ed.png

     


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

     

    image.png.52200059e4df00b171b4ab42dce2d531.png

    image.png.928e4638ffa6c0e3def574214825f72c.png

    • Like 1

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


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


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


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

     


  7. Hi Diego, 

    to speed things up, you should consider separating the TCP read  and the file writing in two separate loops. For example, if you make two parallel loops: one that reads and adds data to a queue, and a second which reads the queue and writes to file, then you can read multiple datapoints at once and write less frequently to the file.

    Investigate the use of a Producer-Consumer architecture.

    I took the liberty of reorganizing your example to demonstrate the concept. I'd probably approach your task where your Python code is the client that publishes data and LabVIEW would act as a server (instead of the other way around), but I wanted to keep with the spirit of your example.

    image.thumb.png.e47e7d3ae765e7c2240d8bb30b37f57c.png

     

     

    Client.vi

    • Like 1

  8. 6 hours ago, mthheitor said:

    My doubt is about the order of the boolean. In my example there four boolean: 1) "Home", 2) "Ensaio", 3) "Análise" and 4) "Configurações".

    How can I ensure the order of the boolean inside the array?

    I mean, if a user delete the boolean named "Ensaio" (2nd element of the array) and add another one, it will be the second element of the array or will be last one?

    The method you invoke on the Panel reference always returns the Controls in the order that they were created.

    aka. If you delete the second element and create a new one (even with same label), it will be added to the end of the list. 


  9. On 19/10/2018 at 0:12 AM, UnlikelyNomad said:

    That DAQmx template is slick. Definitely not a state machine and definitely already handles some of the features I was thinking of like templating asynchronous background tasks.

    Indeed, not a State Machine... "JKI State Machine Objects" gets its name from the use of "JKI State Machine" as its core "Process.vi", which is not a state machine. It is an Event-driven Queued Message Handler (QMH). State Machine was a misnomer and the name stuck around as it was (still is) a very popular template.


  10. On 19/10/2018 at 0:49 AM, UnlikelyNomad said:

    I'm curious on the effort done to cast DVRs back and forth between an int.Googling doesn't seem to bring anything up so I'm curious how this became a thing and what benefits it provides? Does it stop LabVIEW from doing some tricky thing with DVRS? Does it make the scripting simpler?

    The reason for this typecast is to break type propagation that plagues edit-time performance which occur when you have a large class hierarchy. It is not because it makes scripting easier (on the contrary). In essence, when you edit a class' private member, the class' mutation history is modified and the LabVIEW IDE goes through a series of checks and recompiles to propagate the changes. For very small projects, this is completely trivial and does not affect edit-time performance, but for larger hierarchies (think Actor framework...) it becomes a real issue. One way to reduce this performance lag is to never put typedefs in the class private data... but this is up to the developer to stick to that rule or not. When you use an integer, using typedefs does not affect the edit time performances at all.

    As Rolf mentions, this pattern was popularized by GOOP (now OpenGDS).

    When creating a framework, you can never predict how the developers will use it... Obviously, if you use a framework and it starts to lag as your project's complexity increases, you are quickly going to blame the framework for the performance degradation (just like we blame Windows for running slower after we've bloated our computers with a bunch of apps, but that's another topic...). So it is very tempting to use tricks like this typecast to an integer to break this slow type propagation.

    As was mentioned by Smithd, it is risky... but if it stays in the private methods of your class, it is totally safe.

    In JKI SMO, you'll notice that this is used through two private methods and the DVR type is typedef'ed. You can very well create SMOs that do not use this trick. 

    • Like 1

  11. 21 minutes ago, ShaunR said:

    ... I always needed to have it installed in the LabVIEW vi.lib directory and any time I updated it had to reinstall for the other toolkits.

    Shaun, can you elaborate on why you needed to reinstall the other toolkits when you update your encryption library? If the project-specific librairies all pointed to vi.lib, why did their linkage break?


  12. 5 hours ago, hooovahh said:

    Isn't this already handled by VIPM anyway?  You include the license, and version constrictions in the package.  When you upload code to LAVAG.org you are already authorizing LAVA to store and distribute your code.

    I meant that LAVAG should verify that the code it hosts does not infringe on licenses, or at least have a process to summarily verify.

    You are right that VIPM handles the actual license from the user's perspective.

×
×
  • Create New...

Important Information

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