Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 06/11/2018 in all areas

  1. This is most probably a race condition but I simply can't wait so I had to ask...
    1 point
  2. One extra tidbit: The Timestamp fractional part is AFIK actually limited to the most relevant 32 bits of the 64 bit unsigned integer. For your situation that should not matter at all as you still get a resolution of about 0.1 ns that way. Also while the Timestamp allows a range of +- 263 or +-10E19 seconds (equals ~3*10E12 or 3 trillion years) from the LabVIEW time epoch, with a resolution of ~0.1ns, 99.9% is not even theoretical useful since calendars as we know it only exist for about 5*10E3 years. It's pretty unlikely that the Julian or Gregorian calendar will still be used in 1000 years from now.
    1 point
  3. Mark has already uploaded them to: frc.tecnova.com
    1 point
  4. On a related note, when making architecture framework code that includes User/Dynamic events..... A little known fact is that you can register multiple Event Registration Refnums to an individual Event structure. So you ask, "What does this mean to us and why do we care?" First this is what it looks like What is happening here does not show the full power or reason I bring it up. But rather it shows the base Mechanics. This little piece of code registers a different Event Registration Reference for a user event that just got fired.... With a little creativity, you could to a TON of things with that idea (but it's still not why I bring this up. The reason that this technique is so important to event based architectures is that dynamic events do not all need to be lumped together within 1 DynEvent Registration Reference. You can Separate them better based upon functionality. In particular, if you make an architecture that you want someone else to take advantage of, you can isolate your architecture/framework events and registrations and other functionalities within your own framework code and not need to have them modify or tweak their own RegEventRef just because you may have changed or added something to the framework. A great example of this is the ever elusive "Initialization Event" So many people have skinned this cat, it's starting to chafe some. This is a typical way to have an event case fired at startup. But it makes this portion of code a bit bloated and it's just not as elegant as it could be. Now the mechanics of this flow still need to happen. But watch what we can do if we take advantage of the previous technique. The top VI now is a framework level VI that I can drop in any VI that I want to run an INIT case on, without disturbing the definition of the Event Registration Refnum of the rest of the program. The bottom VI just did the same thing by taking that registration process and made it an individual VI that prevents the end user from needing to wire up a bunch of stuff they should not need to worry about. Hopefully this technique (which you can do in 8.6) will aid your architecture
    1 point
×
×
  • Create New...

Important Information

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