Jump to content

Rolf Kalbermatter

  • Content Count

  • Joined

  • Last visited

  • Days Won


Rolf Kalbermatter last won the day on February 8

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

10,173 profile views
  1. The underlaying API does not support that and it is quite logical. I2C and SPI are not really designed as bit protocols but as byte protocols. They address typical multiples of 8 or 16 bit per data transfer. The method to do what you want to do involves reading back the full 8 bit port, modify the bit in question and send back everything.
  2. Well you installed the 32-bit version of the the DLL (syswow64 is despite its name NOT for 64-bit DLLs but the 32-bit versions of DLLs on a 64-bit Windows system). Same accounts possibly for the MPSEE.DLL. They all need to be 64-bit in order to be loadable in 64-bit LabVIEW! Best is probably to download the actual MPSEE driver directly from the FTDI site here and use the 64-bit version of the DLL inside under: libMPSSE.zip\libMPSSE__0.6\lib\windows\visualstudio\x64\Release\libMPSEE.dll
  3. The MPSSE.DLL is only a high level DLL driver that depends on the low level D2XX driver from FTDI. You need to have that installed too, and it needs to be present in a location where the Windows DLL Loader can find it. If you download and install the standard driver from the FTDI site, this should be taken care for you. https://ftdichip.com/drivers/d2xx-drivers/
  4. New VIs should simply inherit the default setting you made in your Tools->Options->Environment->General unless you create them from inside a project, in which case they inherit the setting as made in the project properties. The bug mentioned by Yair may be related to the fact that the restoring of auto-saved VIs is not happening in the project context but in the global LabVIEW context and therefore uses the global settings from the Tools menu.
  5. The wrapping may be done anyways even if it is a clean pass through of all parameters. Simply because this was how the VIs always worked and it was actually easier. The lvanlys.dll had to be modified anyways, so just leave the original exports and redirect them wherever necessary to MKL, with or without any parameter massaging. This makes the tedious work of going into every single LabVIEW VI to edit the Call Library Node superfluous. And yes I have experience with wrapping DLLs from LabVIEW and can assure you that the last thing you want to do when changing something is to make a change that
  6. You might be right but please note that those LabVIEW VIs more or less all call "internal" functions in lvanlys.dll. But in reality all they do is massage the parameters from a LabVIEW friendly format into an Intel MKL C(++) API format and then call the actual MKL library. So the fact that a VI calls LV_something in that DLL means absolutely nothing in terms of if it is ultimately executed inside lvanlys.dll or actually simply forwarded to MKL to do the heavy number crunching part. It could be implemented fully in lvanlys.dll, because the MKL doesn't provide this function or not in the way the
  7. No! We used it on a IC 3173 NI Linux RT controller. It should supposedly work on all NI Linux RT hardware.
  8. I'm not exactly privy to the details but most likely NI doesn't even build the MKL themselves. They simply take the binaries as released from Intel and package them with their LabVIEW wrapper and be done with it. And there are a number of issues with this that way: 1) NI can indeed not patch that library themselves anymore but has to wait on Intel to make bug fixes. 2) And NI won't pick a new release everytime Intel decides to make some more or less relevant change to that library. Instead they will likely review the list of changes since the last pick they did and decide if it is wo
  9. Almost certainly. This device does almost certainly not use a standard USB device class and that means you will have to program on NI-VISA USB Raw to emulate the commands that the native Windows driver sends and receives from the device using directly USB device driver calls. Possible? Yes but not easy and pretty for sure. If it wasn't such a pain to use VISA USB Raw on modern OSes, I would have long ago released a driver for the FTDI chips using pure VISA calls.
  10. If you would have used a LabVIEW Realtime controller you could have used the NI Industrial Communication for EtherCAT driver. It does have a learning curve for sure, but I have used it in the past successfully. If you use other libraries you will have to make sure that it is 64-bit compiled in order to interface it through the LabVIEW Call Library Node. LabVIEW for Linux is since 2016 only available as 64 bit version. Both libraries you mention are GPL, so this can have very significant consequences for using it in a project that you can't or will not want to make open source itself.
  11. Actually not exactly. NI set this compile define to make the shared library multi-threading safe, trusting the library developers to have done everything correctly to get this work like it should but somehow it doesn't. Still there is something seriously odd. I could understand that things get nasty if you had other code running in the background also accessing this library at the time you do this test but if this is the only code accessing this shared library something is definitely odd. There is still only one call to the shared library at the time your PQfinish() executes so the actual
  12. What do you mean with "threadsafe CLN"? It is a rather bogus terminology in this context. What you have is "reentrant" which requires the library to be multithreading safe and "UI Thread", which will allow the library to do all kind of non multithreading safe things. That trying to call PGisthreadsafe() from any context is not crashing is to be expected. This function simply accesses a readonly information that was created at compile time and put in the library. There is absolutely nothing that could potentially cause threading issues in that function. That every other function simply cra
  13. Is it? Then there would be indeed a discrepancy between when the front panel update is executed and when the debug mechanism considers the data to be finally going through the wire. Which could be considered a bug strictly speaking, however one in the fringes of "who cares". I guess working 25+ years in LabVIEW, such minor issues have long ago ceased to even bother me. My motto with such things is usually "get over it and live with it, anything else is bound to give you ulcers and high blood pressure for nothing".
  14. Ahhh I see, that one had however no string input at that point. But now it's important to know on which platform this executes!! I don't think this VI is a good method to use in implementing a protocol driver, given LabVIEWs multiplatform nature. The appended EOL will depend on the platform this code runs, while your device you are talking with most likely does not care if it is contacted by a program running on Windows, Mac or Linux but simply expects a specific EOL. Any other EOL is bound to cause difficulties!
  15. You either have a considerably corrupted LabVIEW installation or are executing some external code (through Call Library Node or possibly even as ActiveX or .Net component) that is not behaving properly and corrupts memory! At least for the Call Library Node it could be also an incorrect configuration of the Call Library Node that causes this. Good luck hunting for this. The best way if you have no suspicion about possible corrupting candidates is to "divide and conquer". Start to exclude part of your application from executing and then run it for some time and see if those errors disappea
  • Create New...

Important Information

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