Jump to content

Manudelavega

Members
  • Posts

    281
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by Manudelavega

  1. Quick off-topic comment: in AddError.vi you unbundle then rebundle the 'status' and 'source' elements of the error cluster. I strongly suggest using In-Place-Element structures when you have this kind of situation, it optimizes the performances and also makes the code more readable. Back on topic: - I think any error or warning should always be logged as it is a very valuable source of information during troubleshooting. So maybe the 6th type of severity rather be "log only" - Your architecture combining priority and 6 types of severity looks nice and powerful, and you coded it well, but like any "fancy" error handling architecture I'm always afraid the over-complication could lead the developers not to use or to misuse them. I'm also in the midst of re-working the error handling in our main application (2000+ VIs) so I sympathize. It's tough!
  2. Hi Shaun, I also see that you use Error code 0 for warnings. However most places in LabVIEW consider 0 as "No error and no warning". Warnings still have an error code, and what differentiates them from errors is the error? Boolean. Am I mistaken?
  3. I like having both systems. In some forums I want to be able to "discuss" best practices, ask about people's experience with a certain technology, and so on. In some other forums I want to be able to ask "What are the key differences between a Timed Loop and a While Loop". People might have different answers, and I'll mark my favorite one as "Best answer". The other people will be able to vote for their favorite ones.
  4. I visit LAVA everyday and either quickly check or thoroughly read all posts, depending of my interest/knowledge in the topic. This is my #1 source for keeping my skills up to date, LAVA must stay!
  5. Wow I should have a closer look at that intensity chart, impress my boss... What is it usually used for? (a bit of a digression from the initial topic...)
  6. I like your "Probably Random" indicator, I should put more of those in my VIs
  7. Believe me or not, I actually made this inadvertently! I'm sure it would have taken me much longer to achieve the same result on purpose!! Anybody has examples of unexpected beautiful graphical renderings made with LabVIEW?
  8. First thing to make sure of is that whatever code creates the DVRs stays alive across the whole application's lifetime. Is that the case?
  9. I also exclusively use XY graphs, even for graphs where the X axis is just the time. It provides so much flexibility...
  10. Also be aware that LabVIEW doesn't like that much overlaying controls in front of a graph, that makes its rendering job much harder.
  11. Thanks for replying. I'll go to the pub directly and see if I can meet fellow CLAs or NI staff!
  12. I am attending the CLA summit for the first time next week. I'd just like to check if anybody here is going as well and if you'd be interested in meeting on Sunday evening and then heading to the Sunday night social together
  13. Thanks. I guess I might have found a particular situation because of nested libraries:
  14. Truly amazing tool. I now have a very visual way to explain the impact of my code refactorization. Jon, where can we find the legend about the colors and shapes for the force diagram and dependency wheel? Also, I originally thought the shape of the leaves on the dependency wheels indicated the direction of the dependency, but it now seems to me that it only depends on the size the libraries takes on the wheel.
  15. Hi, I have contacted NI sales services but it's a great frustration as usual, so I will try to get some support here Basically for a project I need 2 CAN ports and I decided to go with XNET and Compact DAQ. I have 2 solutions I try to choose from: Solution 1 --> One 4-slot chassis with 2 NI-9862 modules (one port per module) Solution 2 --> One 1-slot chassis with 1 NI-9860 module (this module has 2 ports) I am confident that solution 1 will work well since I already had a project in the past with one 4-slot chassis (cDAQ-9174) and one NI-9862 module. But going with solution 2 will allow me to cut cost significantly. I just want to make sure it will be absolutely seamless and transparent for the software. Does anybody have experience with the NI-9860? Can it be considered as the equivalent of 2x NI-9862 as far as the software is concerned (LabVIEW driver) or does it remove some performance/flexibility/other? Thanks!
  16. Thanks, that makes sense. We only work in a executable environment, so I rarely think about the needs of those of us who need to run the sources.
  17. Thanks. Still a bit of confusion: When a VI is started? You don't mean executed, right? To me it's rather "when its front panel is open". Sorry I just find the word "started" very ambiguous here. When would you ever want to do that? I always want to control when a VI runs, either statically as a subvi on a block diagram, or through the proper VI Server method if it's a dynamic call. Do you mean that, for example, you would use a simple "Open FP" invoke node and that will run the VI automatically in addition to opening its front panel? Any other use case?
  18. Reviving this discussion after being surprised by this behavior: (but now that I think of it I shouldn't have been surprised, it kinda makes sense!) The reference I get through the Static reference is different from the one I get through the Open VI Reference even though the VI in question is not re-entrant. Does it mean I have 2 references to manipulate the same VI? It seems it's the reference that gets prepared for asynchronous call and not the VI itself, since the Start Async function gives me an error if I wire Staticref instead of Openref to its input. While on the ACBR topic, I just noticed the subvi can't know which VI called it. In my screenshot, the caller of chart.config.vi calls it through an ACBR node, but the call chains shows that chart.config.vi.ACBRProxyCaller.5180012F was the caller...
  19. One of the significant confusion stone in my understanding of LabVIEW shoe is the difference between "Call", "Launch", "Load", and "Open". I'm not adding "Run" to this list, as it is more self-explanatory, at least I believe. In the Execution window of a VI Properties, we can see the following options: "Auto handle menus at launch" "Run when opened" In the Customize Appearance window, we can see those other options: "Show front panel when called" "Show front panel when loaded" I'm not asking for an explanation of those specific options, but I'd like a more general understanding of what those "Call", "Launch", "Load", and "Open" verbs mean. Thanks!
  20. Definitely. The worst thing about the LabVIEW 1 or 2-button dialogs is they use the root loop, so while displayed, many functions such as Open VI Reference just have to wait their turn to access the root loop, causing very undesirable behaviors! A few months ago I tracked down and replaced all those dialogs with my own standard dialogbox.
×
×
  • Create New...

Important Information

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