Jump to content

Rolf Kalbermatter

  • Content Count

  • Joined

  • Last visited

  • Days Won


Rolf Kalbermatter last won the day on April 3

Rolf Kalbermatter had the most liked content!

Community Reputation



About Rolf Kalbermatter

  • Rank
    LabVIEW Aficionado
  • Birthday 06/28/1966

Profile Information

  • Gender
  • Location

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2011
  • Since

Recent Profile Visitors

5,984 profile views
  1. So when you run the VC++ example you get an error! Well that is hardly LabVIEW related isn't it? You must make sure that you pass the right VID (vendor ID) and PIC (product ID) as programmed in the chip. The chips should come with a default VID and PID from FTDI but it can be changed by a utility from FTDI. Check in the Windows device manager for your interface and in the driver settings you can see the VID and PID values, but they are in hexadecimal notation.
  2. Check on stack overflow! These .Net functions can misbehave for certain paths as they do not properly escape all characters (specifically the % character) that should be escaped. But they might work for the OP's use case. https://stackoverflow.com/questions/1546419/convert-file-path-to-a-file-uri new Uri(@"C:\%51.txt").AbsoluteUri; This gives you "file:///C:/Q.txt" instead of "file:///C:/%2551.txt". Also you should probably close the .Net Refnum after use.
  3. As I already mentioned in my first post (after an edit), this Windows API function does not convert to an URI but to UNC. And it does not work for a local path that you shared but only for a local path that was mapped from a network path. So assume you have a network share somewhere on your production server named PRODUCTION with a share TESTDATA then the UNC path to that is \\PRODUCTION\TESTDATA. If you map this path to a local drive P:\Production you can use above function to convert P:\Production\<some path> back into \\PRODUCTION\TESTDATA\<some path>. Nothing more and nothing less. These functions specifically do NOT deal with URI paths but only with UNC paths.
  4. This should be a 32/64 bit safe implementation. Network Path Name 2016.vi
  5. This implementation has a few limitations, one of them being that it will only work for 32 bit systems and also that it makes assumptions about how the buffer is allocated that may not necessarily true. Basically it assumes that the string the pointer in the first 4 bytes is pointing at are directly following the pointer itself in memory. While this is probably usually true there is no guarantee that this is the case as there might be certain memory allocation strategies used in the underlaying function that might place the actual string in some other location in the returned buffer. So beware when using this in your VI and make a notice that it will definitely not work as is for 64-bit LabVIEW. Also the title is indicating that this function is not the correct one to use. URI is the abbreviation for Universal Resource Identifier which usually follows the format (and that matches the example given by the OP) protocol://[gebruiker:wachtwoord@]host(naam)[:poort]/path The mentioned function will instead return the Windows UNC (Universal Naming Convention) path to a network shareable path if it exists, which has the format: //servername/share/path
  6. I'm not really sure! That assumes that you would use key-values that are not representable in 7 bit ASCI. Definitely possible if they are defined by the operator through the UI rather than programmatically, but even then I'm not sure I can easily see the problem there. Things get wonky when you start to mix and match functionality between UTF and non-UTF aware systems but as long as they stay isolated from each other it shouldn't necessarily be a problem. That's why I never really bothered with the UTF-8 functionality in LabVIEW. It's not fully transparently implemented and given the legacy of various LabVIEW parts I'm very much convinced that there is NO possibility to implement it in a way that will not break backwards compatibility in several places quite badly. That's the main reason it never was released as a feature, since they could probably have thrown several dozen programmers at it and still not have a feature that would simply work without badly affecting the working of applications that are upgraded to the new version. The unoffical UTF-8 support in LabVIEW was a proof of concept project (most likely driven by one or two enthusiastic programmers in the LabVIEW team) and it showed that implementing it in a clean and unobstructive way is basically impossible, so there wasn't put anymore effort into it to make it a full feature that could be released. The problem starts at such basic issues like that many LabVIEW functions use exclusivley strings for data elements that are actually byte streams rather than text strings. The Flatten to String or Unflatten from String functions are the most notorious of them. They never ever should have been implemented using strings but byte arrays instead. It goes further with functions like the TCP Read and Write nodes. While the Write node does actually accept byte arrays for several versions now there is no way to change the TCP Read to return Byte arrays too. Same for File Read and Write and VISA Read and Write. Ultimately all those functions (except the Flatten and Unflatten) should probably have variants that allow to use either binary byte arrays and for backwards compatibiliy ASCI strings. Then there should be a also a new string datatype that carries an inherent encoding attribute with it and last but not least a library of nodes to convert various encodings from one to the other including into and from binary byte arrays. Extra bonus points for letting those nodes accept this new string type too and allow the configuration of an automatic conversion to a specific encoding when writing out or reading from. This would solve the problem of being able to write encoding aware code, it still leaves uncountable places in the LabVIEW UI and other internal places including things like the resource format of most of its files that would also need to be improved to allow for full UTF-8 support. And that part is an almost unmanagable construction site.
  7. I'm afraid they aren't. The according palette isn't called "HTTP Client" for no reason. Implementing TLS on a listener (server) isn't that much different when using OpenSSL on C programming level but it does require a bit of a different setup than when implementing it on a client connection. And the glue to map it to a system similar to the standard LabVIEW network functions does get a little more complicated.
  8. Many possibilities. 1) There might be a new and different INI file key that enables the dialog editor. 2) The dialog editor was completely removed in the released LabVIEW source code and only is present in NI internal builds of LabVIEW for testing and debugging. One or two strategically placed #if !RELEASE_BUILD ......... #endif pairs are enough for that. 3) There might be now a seperate NI internal tool (written in LabVIEW or compiled from the LabVIEW C++ source code) that you now have to use when wanting to edit those resource files. I would bet it is either 2) or 3).
  9. Well to be honest LLVM won't be able to process a header file that references other header files with declarations that are used in your header without access to them. It needs access to those referenced headers somehow too and I doubt it comes preinstalled with all Mac OS X, Windows SDK, etc. etc. headers so you end up installing them somehow to your disk too and pointing LLVM to them. The import library wizard has internally this informations too, but once you start going down the path of creating the wrappers with such advanced functionality through scripting you end up in hell. There is simply no way such a "Wizard" can really know how the different information in such structures may or may not interact with each other and with other things in the API so you end up with a overly complicated interface that is very difficult to understand and allows you to still do lots of illegal things. The purpose of a proper LabVIEW DLL wrapper is to simplify the API as much as possible for the user without saddling him with subtleties like if you want this function to return 1000 samples you have to set this numeric to 8000 AND also Initialize an array with 1000 double values in order for the call to not crash. Or to return a string from the function to require the user to even have to specify the size of the buffer as the function documentation specifies that the function requires a buffer of at least 256 characters to fill in. Even such a simple thing as an API where you pass in a buffer that the function should fill in with information and a second parameter that tells the function how big the buffer really is, is already a total nogo for even the most advanced wizard, since there is no way the C syntax can describe the specific dependency between these two parameters. So the wizard will create two controls on the front panel and the uninformed user will wire a 1000 to the buffer size but leave the string control that should now contain 1000 bytes at its default of an empty string and -> boom! We humans after quite some dealings with these kinds of APIs often can infer the correspondence between these two parameters because of a more or less useful naming correlation between the two but even that can often go wrong (is the number in bytes, characters or numeric elements of the array type?). The only real information comes from the documentation, which surprisingly often fails to document these things accurately too, and then the only thing that remains are hopefully sample source code that shows you how these parameters are supposed to be assigned.
  10. Please also note that your quote of NI-IMAQ I/O is probably making you bark up the wrong tree already. This is just the software driver needed to access the I/O on the supported IMAQ cards. If you program the FPGA on those boards yourself you can define your own RT Fifo etc communication method between the FPGA and RT parts. What you try to do however is accessing the camera part as an image aqcuisition device from within real-time which would require support from NI-IMAQdx instead, a completely different type of software driver than NI-IMAQ I/O. (Yes I agree that NI hasn't always been very great in naming their driver architectures in a clear and concise way). I haven't used any of those frame grabber boards but I believe if you want to use them from realtime you would have to treat them as their own FPGA target and develop some FPGA software on it to communicate through some RT FIFO or similar between your frame grabber implementation and your realtime target. The FPGA programming of the camera grabber interface is possible and has been done by several people on here or the NI forum, but is far from trivial.
  11. I only usully install LabVIEW about every 3 years when the old labtop starts to show signs of going soon death. But then I usually do it for at least about 5 or more LabVIEW versions. HAve recently resolved to put rather old versions on a seperate VM as they tend to get tricky to run on the newest OSes and also newer LabVIEW installs tend to trample more and more on older installations.
  12. I thought it was not relevant when trying out things as I did various trials to get this working (The Control Editor has "particular" behaviour and controls easily can get in a weird state where for instance some of the parts end up in places where they seem not selecatable anymore in the customize mode, they still are but the position where you need to click to select them doesn't match the position on the front panel where they really appear.) 2) Right click on it and select Advanced->Customize (or double click) => The path control opens in the control editor 2.5) Change to Customize mode (click on the Allen key which then changes to a pincer) 3) Right click on the browse button and select Advanced->Customize Double click on the Browse button => The browse boolean control opens in the control editor For step 2) double click and step 3) you might need to have the option enabled to open the custom control editor on double click, which is one of the first things I always enable when installing a new LabVIEW version, right after disabling auto tool and auto wire routing 🤢.
  13. Why would you need an Open Sourced LabVIEW for something like that? This was possible in the Control editor since LabVIEW 3!!! (Discloser: the Browse button in the Path control was not added before somewhere around version 6 to 8 but the principle worked in LabVIEW 3). 1) Place a path control on your front panel 2) Right click on it and select Advanced->Customize => The path control opens in the control editor 3) Right click on the browse button and select Advanced->Customize => The browse boolean control opens in the control editor 4) Save this as your Browse Boolean.ctl file or whatever you want to call it. 5) Use as you wish and enjoy that it automatically adapts to the platform style for the system you run it on Browse.ctl
  14. You realize that the Enque Element in the Run VI part is not guaranteed to be executed before you close the VI reference itself? In the CBR case you guarantee to call it before you attempt to close that VI reference.
  15. The root loop is definitely per process. It’s simply the primary thread started up by Windows for a process in which the GetMessage(), TranslateMessage(), DispatchMessage() Windows API calls are made over and over again, with minor LabVIEW specific adaptions. This thread is associated with a hidden window whose window procedure then translates everything into a Platform independant message infrastructure that very much resembles the Mac classic message loop. This is basically the famous root loop with the message procedure in the hidden window being a sort of platform wrapper around it. Under Windows there comes in a potential extra complication as the OLE marshalling hooks into the process GetMessage() API, completely outside the control of LabVIEW. So if you interface with OLE/COM/ActiveX and to some extend even .Net compenents things can get interesting,
  • Create New...

Important Information

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