Jump to content

dhakkan

Members
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

2

About dhakkan

  • Rank
    LAVA groupie

Profile Information

  • Gender
    Male
  • Location
    Mysuru, India.

LabVIEW Information

  • Version
    LabVIEW 2014
  • Since
    1997

Recent Profile Visitors

1,551 profile views
  1. At the outset, my apologies for the delay in acknowledging your responses - a holiday trip and getting under the weather did not help... Thanks! that helps. A clever way to get the separator, though! Am confused by 'Command Line String To Path.vi'. Under the wrapper it seems to call the native 'String to Path' function except for a Mac OS 32-bit application. In this exception case, not-a-path constant is returned. That doesn't seem to help solve my problem. Now, I'm using the solution candidus provided to build the necessary relative path. Thanks! folks, for your help; and a very Happy New Year to one and all.
  2. Happy New Year to you too! I did a quick check on my machine. Was able to reproduce the problem running LV2015 32-bit on Win10x64. I created a folder called ABCD in 'C:\WIndows\System32'. A Google search led to the following link in MSDN. Do read the embedded link within the first response about file system redirector. That throws more light. I created another folder ABCD, this time within 'C:\Windows\SysWOW64'; and created an empty file there. Re-running my LV sample, which is still coded for 'C:\Windows\System32\ABCD' is now successful; and the empty file does get listed with the List Folder function call! Bottomline: 32-bit apps on Win64 will be redirected to 'C:\Windows\SysWOW64'. Hope this helps. Cheers!
  3. Hello, I'm experimenting with porting my existing LabVIEW application from Windows to Mac OS X. The code uses several instances of 'Build Path' function in 'File I/O' functions sub-palette. The 'Name or Relative Path' input is being connected with a 'string' data type rather than a 'file path' data type. With some quick code change and checks, I've realized that it's better to use the latter data type, so that the separator character '\' in Windows is automatically interpreted as ':' in Mac OS. Some parts of the code, however, build up the string. E.g. a 'Format Into String' is used to output based on a format string, e.g. 'Images\%s.jpg'. Doing a 'String to Path' after this function does not automatically interpret the '\' in Mac OS to ':'. (I can imagine that it would be difficult for the compiler to recognize that a specific character is meant to be a separator and not part of a file/folder name.) I can write more complicated code where the format string is itself concatenated based on the execution platform. Are there any easier or recommended approaches? Also, does LabVIEW have any 'File Constant' that provides the equivalent string character depending on the platform? Thank you.
  4. Hello, First off, kudos on the effort! I did a quick read-up. Overall, a great write-up! Parts 3, 4 and the walkthrough were the most helpful for me (as one who has been struggling to appreciate this implementation of AF). The introduction in Part 1 was also great; however, I got confused by the last paragraph. Will read it again with a clearer head. Cheers,
  5. Sorry about reviving an old thread. However, am hoping this may help... My 2c follows. Consider using LabVIEW's bookmarks and subdiagram labels. I'm beginning to use the former as follows: #TBD for any part of code that needs to be re-visited for any reason. Goal is, by the end of development cycle, no such bookmarks must remain. #<NameOfDev> for any part of code that needs to be re-visited by the named Developer. Goal is, by the end of development cycle, no such bookmarks must remain. #Rationale for any part of code that needs an explanation of why the implementation is so. (This would include info about trying other approaches as stated in earlier posts.) #Info for any part of code that needs an explanation of what it does. This is particularly necessary when Uncommon algorithms are used Complex regular expressions are used. Making specific assumptions not clear from code. #Reference for any part of code based on reference material available to the developers. Rationale: The first two bookmarks above are meant to be on-the-spot reminders for developers to verify or seek additional information when having questions. The remaining bookmarks are meant to aid future developers for easier code maintenance or revisions. The Bookmarks Manager helps with finding the first two prior to release, provided Developers are diligent and consistent enough... Subdiagram labels help me a fair bit. I use them initially to jot the implementation approach; then refactor the verbiage as needed following the hashtags above. Reg. context help... For low-level VIs, if the inputs, VI name and outputs are not not self-explanatory; there is likely scope for improvement in the names. That said, of late, I've started to document non-default VI execution properties in the context help. (E.g. 'Shared reentrant', execution thread, etc.). It would be great if NI would make context help more powerful by displaying these important non-default properties. Lots of people seem to support this in the idea exchange... I've also started to specify a line in context help if VI does NOT provide 'standard error out' functionality. I don't provide separate 'detailed help' documentation unless contractually bound to do so. For higher-level VIs, a paragraph-size explanation of the 'process' (considering the input->process->output paradigm) would should be sufficient. If more information is warranted than the above two points, then it's better to provide 'detailed help' for those VIs. I used to label wires a LOT. Have toned it down as follows. Attach a label to a 'shift register' outside the sub-diagram, if its initial value is not immediately apparent (e.g. a case that's not displayed). Apply a label with direction in case a wire originates at a point beyond the visible part of the block diagram. E.g. 'PSU Object ->'. If a feedback node is used the direction could be right-to-left, in which case '<- PSU Object' would work. Don't label a wire otherwise. It's easy enough for the Developer to open the context diagram and see its source or sink to determine what it is. I label a constant primarily if it is not obvious from nearby labels. Another example of the obvious: Type-def constant should not need labeling given that its info is visible in the context help.)
  6. Gotcha. Thanks for the tips too! (I'm pretty new to posting on discussion forums in general, let alone LAVA.)
  7. Hello Rolf, Not sure where I implied that... Sorry, if the write-up was not clear. I was of a different opinion when I started writing that post as compared to when I finished it a few minutes later. Should I retract or re-write that post? In any case, the rest of your post indicates we are on the same page. Yes, the event name could be considered misleading. Variations of VALUE_ENTER or VALUE_SUBMIT may have helped. But, that's up to the NI gurus, isn't it.
  8. Thanks for the response, Hoovahh. Understood and agreed regarding the 'Val (Sig)' property. In this case, the LV Developer is forcing LV to trigger an event. However, my expectation from the Front Panel standpoint was for LabVIEW to not even trigger the event, i.e. LV checks for value actually changing before deciding to generate the event internally. IMHO, if one is using 'value change' events, the current implementation pretty much defeats the purpose of the minimum and maximum limits set in the Numeric's properties - depending on data validation requirements, the Developer would be forced to perform a check in the event structure to discard further action. To give you a background, my thought process for this started when I realized some subVI was coercing numeric values coming in even though no 'in range and coerce' equivalent functionality was implemented in its block diagram. That led me to realize that it's obviously not a good practice to validate inputs' range via front panel properties, unless some in-code documentation clearly states so. More importantly, as several sources rightly state, coercing values without alerting the user is not a good practice. Then, I wanted to see if this coercion was OK for front panels meant to be direct user interfaces. Ummm, I guess I refuted my own statement... with the event triggered even when there is no value change, it would after all be good programming to alert the user that a 'limit' has been reached and offer alternatives (instead of 'discarding' further action as I mis-stated above). Thanks! for the mini-discussion.
  9. Hello, I searched within this site and via Google for any related queries. Couldn't find any. Hence this post... Example of Situation: I configured an I8 Numeric with non-default limits in its 'Properties >> Data Entry' window... Minimum of -2 (coerced); Maximum of 2 (coerced). I set up a simple event that looks for 'Value Change' of this Numeric. Expectation: No matter what the 'Increment' value and 'Response to value outside limits' are set to, the 'Value Change' must NOT trigger if the numeric is already at the limit and cannot be changed further. To explain, If current value of Numeric is 2 and I try to increment it, its value must remain at 2 and no event should be triggered. Similarly, with current value of Numeric at -2, if I try to decrement it, its value must remain at -2 and no event should be triggered. What I found was that the value does remain at the limit, but an event is still triggered when the 'Increment' setting is non-zero. Is this normal behavior? Test Numeric Event Triggering.vi coded in LV2014
×
×
  • Create New...

Important Information

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