Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 06/10/2019 in all areas

  1. 3 points
    Hey folks. this year we're trying something new. All Videos for NIWeek 2019 can be found here: https://labviewwiki.org/wiki/NIWeek_2019 Feedback welcome. Thanks to @Mark Balla and other volunteers for recording the videos. Edit: We're starting to add the back catalog to YouTube. NIWeek 2018 videos are also up.
  2. 2 points
    One possible option with a bad hardware driver is to make your actor an independent exe, using the NetworkMessenger for communication Then you can kill the entire exe and restart cleanly. I've never done that, though.
  3. 1 point
    The link at the bottom will bring you to this page http://www.ni.com/en-us/support/downloads/software-products/download.labview.html#305508 You just have to select 2018 SP1 Patch and click download. This will download the f4 (latest) patch. The en-us version is pretty stable in my experience (except for a few dead links here and there). Can't say much about the others. I'm still surprised they bother to check the associated SSP. Considering that the License Manager checks it anyway.
  4. 1 point
    We're starting to add the back catalog to YouTube. NIWeek 2018 videos are also up.
  5. 1 point
    Hi Max, Recovering from a stuck hardware actor is often impossible, as it is some dll call that is stuck and LabVIEW cannot abort the call. Nor can the dll be reloaded without restarting the entire application. However one still needs to recognise and report the problem. I use the "Timeout Watchdog" recently added to the library. The main actor uses that on the handling of some message that periodically comes from the hardware actor. Now, another unreliable actor is one that handles potentially large blocks of memory. An out-of-memory error will abort the actor, invalidating it's address, and you can use an "Address Watchdog" to notify Main. In that case you probably can restart the actor and recover.
  6. 1 point
    Dr Powell, First of all thank you for developing a dream library (framework), I've been using it for 2 years already. It is incredibly powerful and elegant. There are no words to express my admiration of your work! For couple of days I've been thinking about one scenario: Imagine there are 5 actors, each of them is dedicated to one particular piece of hardware or software component. They are launched by Main actor. Each of 5 actors has a state and it is updated once action is performed. Now, what if one of the actors gets into an infinite loop (or an action that will make it stuck). In this case it won't be able to update it's state. However my Main actor doesn't know about it, it only remembers that the last state of that frozen actor was, for example "good". 1. How to make the Main actor realise that one of its sub-actors is frozen? 2. What to do in this case with a frozen actor? How to restart it? P.S. I've been thinking about using the "Watchdog" actor. Create 5 of them in Main actor and share with subactors. Then inside of subactors constantly reset the Watchdogs. If watchdog wasn't reset, Main actor gets a message. Not sure if this is the most elegant solution. And there is still question 2 left. It would be great if you could share your thoughts about this. Thank you! Kind regards, Max
  7. 1 point

    Version 1.0.0

    104 downloads

    There it is. The complete library for the MCP2221A. I2c adapter, I/O in a single IC. I love that one. Let me know if any bug is found. I try to make that library as much convenient as possible to use. Two version available 32 bit and 64 bit. little note: to open by serial number, the enumeration need to be activated on the device first. (open by index, enable the enumeration) It needs to be done only once in the life time of the device. PLEASE do not take ownership of this work since it is not yours. You have it for free, but the credit is still mine... I spent many hours of my life to make it works.


×
×
  • Create New...

Important Information

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