Jump to content

Francois Normandin

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Francois Normandin

  1. I typically use a second lvproj file, not for installers, but for the unit testing. The benefit is that I can segregate the dependency on the unit test framework (i.e. Caraya) from the source file that runs the build specs. Although, I don't know if that's super useful if you use a CI server to run both UTs and perform your builds...
  2. Networks Streams implement (and abstract) the concept of Quality of Service without the developer needing to add code for managing intermittent connections. A handshake ensures that all the data transmitted has reached the other endpoint in the order they were sent. Yes, it is probably just a buffer on the sender's side and some ACK replies from the receiver (and incoming buffer), bundled into a seemingly unidirectional stream. For sure there's an overhead compared to straight TCP, but I'm not sure the overhead is that large if you take into account the handshaking that you would need to reproduce the same QoS feature. TCP is more flexible and interoperable. If you need to add QoS to your app, and your app is all LabVIEW on both sides, then Network Streams make sense for reliable 1-to-1 high speed data transfers. If you send lots of small messages, an IoT protocol over TCP is probably more suited for the task (MQTT, etc.).
  3. Right-Click on the "Read From Text File" method and unselect "Convert EOL". The number "13" (0xD or Carriage Return) gives it away. If you look at the HEX representation of what you save and what you read from file, you'll notice the 0xD gets converted to 0xA unless you uncheck that box. Tip: If you deal exclusively with HEX/binary data, you might want to save it using byte arrays instead. The result will be the same in your file, but you won't get bitten by hidden config parameters in your node...
  4. Gave me a good laugh as well... but apparently this image is fake. Once you know it, you wonder why the medals on the sleeves are all pinned towards the down direction with the ribbon stying straight even though one general has his arms bent and the other one not...
  5. and perhaps even getting paid for it...
  6. We've been calling 3.9 with LabVIEW 2019 without a glitch. Not exactly sure what "support" means in this context. _ _ _ Different topic... If the statement below were a regular expression, wouldn't a "?" be more appropriate? It would stand a better chance of matching at least one element 😉
  7. I'm pretty sure I reported something along those lines during beta testing of LV2020, but it was, if memory serves well, when using malleable with interfaces.
  8. I've seen a similar error dialog accompanied with a crash report. From those logs, I gathered it might also mean that there is not enough contiguous memory available. Perhaps "Largest Available Memory Block" can be of interest as well.
  9. By all means! And may I suggest you look at the events page on LabVIEW Wiki. You can check out many presentations on a wide variety of topics, including scripting and design patterns. https://labviewwiki.org/wiki/Events
  10. The other account you are referring to (previous NI Weeks)... might that be the presenter account? I too remember having had to use a different account to submit abstract and upload presentation material.
  11. Hi Makrem, my guess is that your top-most VI is set to be "modal". https://labviewwiki.org/wiki/VI_class/Front_Panel_Window.Behavior_property To change the behavior, go to the VI's properties and chose "Windows Appearance". Then select the "default" behavior.
  12. I'm a bit perplexed by this one: source: https://www.ni.com/fr-ca/events/niweek/faq.html
  13. It's not listed on the repo, but it is under the MIT license. (It's now been added to the repo)
  14. I assumed Messenger did this too, although I don't use it. 🙂 In SMO, it's a settable parameter by the user based on their needs. The SMO process itself actually should abort in a few milliseconds, so it is heavily dependent on the process overrides. (edit for clarity) The STOP call is a last resort in case the "autoshutdown" message does not work. Even if enqueued at the front, when the actor loop is locked because a "do" is performing a blocking action, stop will kill the thread. Also, Stop will effectively handle a parallel loop that is running concurrently to the actor message handling loop and does not implement correctly the shutdown messages. I daresay it should never happen in production code. The onProcessKill override is provided to have a way to log this event when it occurs. If the developer killed the caller in development mode, that's fine and can be ignored. If it happens in production code, it should be a concern.
  15. You might want to inspect JKI SMO's way to handle this. The SMO Process has a "passive watchdog" that monitors a single-element queue and gracefully exits if the asynch process completes normally... but it will stop the whole asynch thread if the queue reference goes idle. Note that you should use such a mechanism only if you always want your asynch process to get killed in case of a caller going out of memory. (This should be an ultimate way to exit, not a normal way...) SMO process still tries to abort before it ultimately kills the thread. (This is a screenshot from SMO:Process.vi)
  16. 1. Nowadays, Git 100%. 2. Love it. 3. I forced it on my team, but even for my hobby coding, I use SCC. Those closer to retirement are having a hard time. For the younger folks fresh out of school, they'd be surprised if we didn't use Git. I wouldn't bet that all of them know what SVN means. 4. Pros: Large support community online. When stuck, I just spell it out in the search engine and I find a post on stackoverflow that solves my problem It allows enforcement of a workflow that achieves modularity by design, through submodules. Easy to deploy a repo through a usb stick for offline instruments, and to merge offline changes back to server No one can reserve a file and accidentally prevent others to work Cons: No LV integration for visualizing changes 5. SCC never screws up, the developer or the client app does. The app client I use (SourceTree) has a tendency to show "detached heads" that magically disappear when I close the app and open it back again. Detached heads are very confusing and every time I see one, I'm extra careful not to lose any work done. They never occur in a simple repos: only when dealing with submodules. That's a buggy behavior of the app, not a failure of SCC itself.
  17. Whenever it's been used in a project that I knew would persist more than for a simple demo, I've always wrapped the IMAQ API into an image class that handles the name generation with GUIDs to avoid collisions. Sometimes I'll add a singleton registry to keep track of references, but my IMAQ-flavored apps have generally been of low complexity, so I typically maintain a list of objects in the process' private data. When I need to leak the images across multiple processes, it is generally a delegation pattern, and the caller is still responsible for the reference's lifetime.
  18. @pajaramillo1 You can open VIs from previous years at any time. LabVIEW is going to compile it for your version and once you save them, you will not be able to open them in a previous version unless you back save them. Download the file you need from this thread and it will work in LV2015.
  19. As a publisher of packages myself, I really like the interface and how easy it is to have a package of mine find its way to the Community repository. It was always nice to have the LAVAG code repository (same info, direct ungated access), but having the packages accessible to anyone just by virtue of refreshing the VIPM package list is really a nice feature. @Antoine Chalons, sure I'll move the Controls Addon to VIPM Community... Already put in the request!
  20. This control seems to have been set as a private member of the library, which means you cannot use it outside of the library itself. If this controlID is available on a public method, it should also be made public. Two things can happen: 1- The library is repackaged with this control set to be public 2- Disconnect the type definition. (Right-click on Controller ID and choose "Disconnect from type definition". Solution 2 is your best choice right now, unless someone ants to repackage the library and expose the control publicly
  21. fixed and pre-released as 1.0.2 build. pushed to default branch https://github.com/LabVIEW-Open-Source/LV-MQTT-Broker/releases/tag/1.0.2
  22. @Neil Pate I thought I had fixed this bug. It dates from my NIWeek 2019 demo when I made a last minute change from "Destroy" public method to "onDestroy" protected method. You see what happens when you do a TDD project and you skip the tests "JUST ONCE" because you're in a hurry and the boss wants this code deployed ASAP??? Hahaha! I'll do a fix this weekend... Edit: Was fixed in the Develop branch... I'll test, bring to master branch, build and release a new package.
  23. I had not realized either it was so simple to add TLS. I didn't plan to upgrade my broker to 2020, but multiplatform TLS is tempting. (shameless plug for my project: https://github.com/LabVIEW-Open-Source/LV-MQTT-Broker)
  • Create New...

Important Information

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