Jump to content

Rolf Kalbermatter

Members
 View Profile  See their activity

  • Content Count

    3,049

  • Joined

  • Last visited

  • Days Won

    153

 Content Type 

Everything posted by Rolf Kalbermatter

  1. Rolf Kalbermatter
    Well, OpenCV has various parts which were C++ since a very long time, some of them with C wrappers but not everything. And they moved more and more to a C++ API as that makes writing code easier once the proper ground works are defined. So for a pure C API you will need to go back quite a bit. Also while I haven't checked recently the OpenCV library did not remove the classic C API last I checked. Maybe they did in the meantime. But image manipulation is not something you can easily interface to with the Call Library Node anyhow even if the API is pure C. The memory management proble
  2. Rolf Kalbermatter
    You can not call C++ objects with the Call Library Node without going into custom assembly programming. C++ is NOT binary compatible between compilers and often not even between compiler versions so there is no common ground on which the Call Library Node could even start to attempt to provide an interface to that. What you have to do is developing your own shared library wrapper in C++ that exports standard C functions that you can then call with the LabVIEW Call Library Node. In the most simply case you could simply wrap each method of an object with a function like detailed in the labv
  3. Rolf Kalbermatter
    All incantations of the Winutil VIs out there are in fact from that library or its predecessor. Also the VI copies in this Multipanel Example.
  4. Rolf Kalbermatter
    I simply took the library from the NI site and threw out anything that was accessing the DLL and then changed things to work for both 32-bit and 64-bit. I'm guessing it would therefore be under whatever license it was, which I think would be the NI Example Code License, whatever that actually means.
  5. Rolf Kalbermatter
    I find the description of the command syntax in the manual anyhow highly ambigious and unclear. Usually GPIB devices from that time were supposed to state one long list of capabilities in the form of abbreviations. Those were pretty important before IEEE 488.2 was released, since the GPIB bus had many capabilities and most devices only supported a subset of them. IEEE 488.2 defined a minimum set of capabilities that a device had to support in order to claim 488.2 compatibility (in addition to basic command syntax and such) and after that this capability list got almost completely redundandent.
  6. Rolf Kalbermatter
    Just as an extra reference point, this post contains a redone winutil.llb file where all the references to the private winutil DLL have been removed and as far as possible replaced to compatible direct calls to the according Windows APIs. In addition the Call Library Nodes have been updated to be compatible for 32-bit and 64-bit operation and I also added one or two functions from this example into the library as well. In order to support seamless 32-bit/64-bit support one has to make sure to use the new Windows control contained in that lib for everything and modify any other Call Library Nod
  7. Rolf Kalbermatter
    I was refering to the instrument manual. That one has absolutely nothing to do with VISA whatsoever. It has about two half pages of IEEE description and some very limited command description. Not very extensive in any form and flavor. NI VISA on the other hand is very capable of also accessing IEEE488.1 devices, which is the name of the old style IEEE488 interface specification. Doing so is however not trivial as those low level settings can be obscure and not easy to understand without knowing how the GPIB bus works on signal level. And it is usually not necessary since all the modern de
  8. Rolf Kalbermatter
    VISA can access also IEEE488 devices. The relevant settings can almost all be accessed through VISA properties.
  9. Rolf Kalbermatter
    The manufacturing year is irrelevant. When that device was designed in 1981 or before, that’s the technology it uses. Your device may contain a new firmware which fixes a bug or two but certainly not with new improved functionality. As to those settings they absolutely positively must exist in NI-Max. They are functionality of the NI-488.2 driver and have absolutely nothing to do with your specific device. Or are you using something else than a NI GPIB interface to connect to the device? This is what you should see for your GPIB controller in MAX: As you can see there are a num
  10. Rolf Kalbermatter
    Hmmm, that's one old piece of hardware. I found a manual here: https://www.opweb.de/deutsch/firma/Data_Precision/herunterladen/Data_Precision--8200--service--ID8215.pdf and its covere page has a copyright of January, 1981. Instruments from that time do not comply to IEEE 488.2 at all since that standard simply did not exist then. That only was released in 1987. Accordingly GPIB instruments where using all kinds of weird GPIB settings, including instruments from the GPIB inventor HP itself. You may have to actually go into NI-MAX and change settings for the instrument or even the
  11. Rolf Kalbermatter
    This used to be trivial to do up to LabVIEW 5, a little more complicated in up to LabVIEW 7.1 and got really difficult with LabVIEW 8.x. I have never tried to do it with any LabVIEW 20xx version. While it still should be mostly possible for pure software applications that do not use any hardware, both NI and 3rd party, it would be a major pita to try to do it with most of the NI drivers nowadays. Possibly that the application Hooovah proposes can help with that but otherwise I don't really see any possibility to do it reliably. Part of the message does indeed sound like they might refer t
  12. Rolf Kalbermatter
    Well of course does LabVIEW have to retain the HWND of the container where it places the ActiveX Window. And this is simply a specfically allocated window handle for the container since an ActiveX control requires a parent window when being instantiated and LabVIEW for obvious reasons does not want to hand the full front panel HWND as that would give the ActiveX Control every possibility to mess with the LabVIEW owner drawn front panel (as you know LabVIEW controls, except the ActiveX and .Net Container are not implemented using window controls with their own HWND as with other standard Window
  13. Rolf Kalbermatter
    I have a fair amount of experience with SVN and a smaller amount with GIT. At our company we still use SVN, not because it is super perfect but because it simply works. I have not managed to get myself into a real mess with SVN. The worst that can happen in my experience is that some operation doesn't terminate properly and you have to do a manual cleanup to be able to continue. Enter GIT and that changes dramatically. It's very easy to do just about anything in GIT, including mistakes. And I can not count the number of times in which I spend several hours of unraveling some mess I caused
  14. Rolf Kalbermatter
    That's because if you do any overlay of anything in LabVIEW, LabVIEW will be forced to fully redraw the entire control every single time rather than trying to use optimized region update APIs in Windows. And the graphics driver for your video card seems to have some trouble with proper region drawing. Of course full redraw will be usually considerably slower so it isn't a perfect solution at all.
  15. Rolf Kalbermatter
    How would you do HTTPS without TLS? And it depends about use of LabVIEW. For a general in the field IoT application I wholeheartedly agree. Trying to build such a system in LabVIEW is going to be reinventing the wheel using a high end CAD tool while you can take ready made wheels from the shelf. If it is however part of final step during inline testing of a product, with the whole test system controlled by LabVIEW, it may be useful, although calling a Python script would still most likely be much easier and maybe a few milliseconds slower than fully integrated in LabVIEW. But th
  16. Rolf Kalbermatter
    So is your link to the DUT over public internet or an internal network? If the first, the client may want to reconsider if that is the way to do firmware updates, if the second, someone seems to be utterly paranoid. I don't think it is to useful to use the TLS functionality for this. This is on TCP/IP level an are you seriously doing firmware updates over TCP/IP? Or are you rather using HTTPS instead which could have been done with the HTTP(S) client functionality since about LabVIEW 2014 already. If you need more specific control you might have to go with something like the Encrypti
  17. Rolf Kalbermatter
    It could make sense if the PostgreSQL DLLs were compiled with Microsoft Studio 2010 or 2012 or similar (not sure which Visual Studio version is used for compilation of LabVIEW 2015) and set to use dynamic linked MS C Runtime library. It is old enough to not be standard on a recent Windows 10 installation and not new enough to not be tightly coupled with a specific Microsoft Visual C runtime version. Since about Microsoft Studio 2015, the Visual C runtime has stayed at version 14.x and doesnt with each new version require a new runtime. It's still possible that a newer Visual Studio application
  18. Rolf Kalbermatter
    Not really safety precautions. Most C(++) compilers will strip by default all symbols from linked non-debug code, unless these symbols are needed for certain puposes like function export tables. While these functions also return a pointer to some sort of export table, they are not official export tables, just as virtual tables in C++ aren't really export tables. The name is unneeded as far as the compiler is concerned, so they get all stripped. This has certain anti reverse engineering reasons as someone distributing a release version isn't usually interested in letting its users reverse engin
  19. Rolf Kalbermatter
    I'm aware of the limitation with this function. It not only wants to run in the UI thread but also doesn't allow to specify the context it should be running under, so will likely always use the main application context (which could be fine really, as each project has its own context). And that with the missing context is logical since this function existed before LabVIEW 8.0 which introduced (at least publically) application contexts. I think the mentioned C interface has to do with the function GetCInterfaceFunctionTable(), exported since around LabVIEW 8.0, but that is a big black hole.
  20. Rolf Kalbermatter
    Sorry I'm not a curl expert. So you could you explain a bit what all these parameters mean and which of them causes problems?
  21. Rolf Kalbermatter
    I think CallInstrument() is more promising although the documenttion I found seems to indicate that it is an old function that is superseded by something called C Interface in LabVIEW. But I haven't found any information about that new interface. /* Legacy C function access to call a VI. Newer code should consider upgrading to use the C Interface to LabVIEW. */ /* Flags to influence window behavior when calling a VI synchronously via CallInstrument* functions. The following flags offer a refinement to how the former 'modal' input to CallInstrument* functions works. For compatibility,
  22. Rolf Kalbermatter
    They might actually be simply left overs from the LabVIEW developers before the Call Library Node gained the Minimum Size control for string and array parameters in LabVIEW 8.2. The old dialog before that did not have any option for this, so they might just have hacked it into the right click menu for testing purposes as that did not require a configuration dialog redesign, which might have been the main reason that this feature wasn't released in 8.0 (or maybe earlier already). There are many ini file settings that are basically just enablers for some obscure method to control a feature
  23. Rolf Kalbermatter
    A bit of a wild guess but there is a function MgErr FNewRefNum(Path path, File fd, LVRefNum *refNumPtr) exported by the LabVIEW kernel which takes a File, a Path (which could be an empty path as the File IO functions don't really use it themselves) and returns a file refnum that you can then use with the standard File IO functions. Now File is a LabVIEW private datatype but under Windows it is really simply a HANDLE and under Linux and MacOSX 64-bit it is a FILE*. So if you can manage to map your stdio fd somehow to a FILE* using some libc functions FILE *file = fdopen(fd, "w"
  24. Rolf Kalbermatter
    No not really. I mean something quite different. Given a VI create a sort of function wrapper around it that works as a C function pointer. For that we would need something like MgErr CallVIFunc(VIDSRef viRef, int32 numInParams, VIParams *inParams, int32 numOutParams, VIParams *outParams); with both parameters something like an array of typedef struct { LStrHandle controlName; int16 *typedesc; void *data; } VIParams; That way one could do a C function wrapper in assembly code that then converts its C parameters into LabVIEW parameters and then calls the VI as function
  25. Rolf Kalbermatter
    That's a bit ambitious! 😀 I would rather think something in the sense of the Python ctypes package to allow arbitrary function calls to DLLs including callbacks and such. We just need to find a method that does the opposite for this: calling a VI as C function pointer. 😀
×
×
  • Create New...

Important Information

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

  I accept