Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/21/2014 in all areas

  1. Okay so I have a working test of what I was talking about with the Pre Build action. Attached is a project with a VI in it that gets the text of a Formula Node in the development environment. It also has a string constant that is blank, but before building the EXE it will take the value from the expression node and put it in the string constant. Build the EXE and you'll see that the value of the string constant will change to the value in the expression node. Not ideal but it can be done with minimal engineering effort, and using all built in tools. Formula Node Test.zip
    2 points
  2. Yup I totally agree with drjdpowell. I don't have a type def for my BFCluster and just bundle constants of the things I want in there. It is faster to add an item this way then to have to open the type def and add it there anyway. I also only take the things I need for the functions I want. I don't think having a type defed cluster is wrong it's just not how I prefer to develop my code. This is sorta like private data to this QMH anyway so having all the data available to some other function feels wrong. I only need to give it the data it needs, which maybe a typed cluster within that cluster but most the time is isn't.
    1 point
  3. Below the top-level cluster I tend to have objects (or arrays of objects) whose methods do the “heavy lifting”. The typical “state” will unbundle only a couple of things and call a couple of methods. So I am doing something similar to what you do. But the problem with the top-level cluster is that it is a grab-bag of everything; UI details mixed with INI file details mixed with analysis details. It’s not cohesive. Because the objects/typedefs that make up the top-level cluster ARE chosen to be cohesive, it is rare to need more the a couple of them. If you find you’re unbundling six things, that’s a good reason to stop and consider if some of them really should be a class/typedef. But because they really naturally go together.
    1 point
  4. So what do you do when you need to execute a reasonably complicated bit of code which requires various bits of "data" in this cluster (i.e. a portion of code that screams out to be made into a sub-VI, which in my opinion is virtually anything non-trivial)? Do you unbundle the specific elements and pass them into a sub VI? I know it may be frowned upon, but by having the cluster typedef'd I then just pass the whole thing into/out of a sub-VI. Of course you could pass in a non-typedef cluster but we know how that is going to end...
    1 point
  5. I can't figure out where the VI to write to the console is. They deprecated the old RT Utilities API and Sys Config doesn't seem to have this function. I know I can watch a virtual console using the web admin interface, though. How do I write to the console from my application?
    1 point
  6. In my LV2013 installation I still have the "Real-Time->RT Utilities - RT Debug string.vi" that can write to the console interface. I haven't had time to test it, but it looks to be the same as before. /J
    1 point
×
×
  • Create New...

Important Information

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