Jump to content

alleBarbieri

Members
  • Posts

    6
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Modena, Italy

LabVIEW Information

  • Version
    LabVIEW 2016
  • Since
    2007

alleBarbieri's Achievements

Newbie

Newbie (1/14)

3

Reputation

  1. Thanks ensegre for the reply, it is more or less the same approach I am adopting right now. However I would like to avoid to call the file open dialog before knowing the start path, since in some cases (if the start path is not valid anymore) it can freeze the wole application, as highlighted in this thread:
  2. Hello Everybody! I wonder if it is possible to retrieve the starting path of the file dialog express vi before running it. The start path is usually the one opened last time with a file dialog vi instance, but I have not been able to find a way to retrieve it. Anyone has some ideas?
  3. After some search I found the accessory from NI. It's the NI 9972 Backshell for 6-pos connector block (qty 4) Alternatively, I found also a compatible connector from Weidmuller, available with or without screws. You could find it on websites such as Farnell or RS http://catalog.weidmueller.com/catalog/Start.do?localeId=en&ObjectID=1944590000 (without screws) http://catalog.weidmueller.com/catalog/Start.do?localeId=en&ObjectID=1944670000 (with)
  4. Hi all, does someone knows if the connectors of NI-9219 module are standard or it is something custom made by NI? If standard connector, do you know a manifacturer producing compatible models, and the article codes? The picture of the module/connectors is this: http://sine.ni.com/images/products/us/ni9219_l.jpg Thank you!
  5. Having a closer look at the "scan varian from string" I noticed that the strings atre threated as in the picture attached. I think a possible solution to solve my problem is to remove the "scan from string" and put the Input string directly to the variant output. But I am sure the generality of the vi in this case would be compromised.
  6. Hello everybody, I noticed a strange behaviour of the "scan variant from string" openg function, in particular it seems that when the input is a variant associated to a string the "decoded string is truncated after the firs blank space. Attached you can find a simple vi that illustrate this strange behaviour. Could it be due to a bug in the openg "scan variant from string"? Or am I missing something? Do you think it is something easy to fix? Example.vi
×
×
  • Create New...

Important Information

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