Jump to content

Recommended Posts

Thanks to the nice work of drjdpowell I was able to easily connect & work with PostgreSQL. Did have to use the 32bit included dll's though.

Now when I try to install & run it on a Win10 IoT machine the dll's are not found and throwing errors. Sorry no screenshot at the moment.

The 64bit of PostgreSQL is installed on both machines & works.

The exe of course works just fine on the dev machine.

Does anyone have any ideas? I'm at a loss at the moment & need to get this running.

Thanks.

Link to post
Share on other sites

If this is an EXE, see if libpq.dll and other dlls are included with the EXE, in its "data" folder.  This should happen automatically (because the dlls are part of the PQ class), but I've seen this fail before.  If they aren't there try using "Always Include" to include them.  The data folder should look like this:

880985272_2019-07-0310_32_46-TestPQProperties.png.5c045053bf59532f8f04a8773dd653a1.png

Link to post
Share on other sites

Correct, the above is exactly the same for the build & works from different directories on the dev machine. It's on the deployed machine it gives errors.

In the Build properties for the exe I've tried to set the destination to a specific path but it didn't help. Perhaps I missed something?

image.png.a02c1101d4a8e779c13c11bd44cb3cbc.png

Link to post
Share on other sites

If those DLLs are there then my only idea is that perhaps there is an additional dll that is needed, one installed on your Dev machine but missing on the deployed machine.  What is the exact error message?

Link to post
Share on other sites

Try your exe on a regular Windows 10 computer that does NOT have Postgres installed.  This is to tell if it is a missing dll in the build, or something about Windows IoT that is the problem.

Link to post
Share on other sites

On a regular Win10 box the exe loads the dll's just fine & then times out as expected without Postgresql installed. So it's looking a lot like a Win IoT issue...

My understanding is that you wrapped 32 bit dll's with a CIN.

Looking at does-windows-iot-support-my-dll

the answer was:

Windows IoT required DLL to be as follows:

  • Compiled using the ARM target
  • Needs to target .NET Core

Those restrictions strictly apply when using UWA you may be able to get away by using a console app but it is not that simple on IoT as everything is sandboxed.

Otherwise the other way to use the DLL on the Pi is to run a nix OS like Raspbian, install the latest MONO and then you can embed DLL's into your projects and it should just run, even if targeted for x86 - Thanks to all the clever stuff mono does.

Edited by FixedWire
typo
Link to post
Share on other sites

Ah, so you need to get DLLs compiled for ARM.  I think I just got those DLLs from the postgres install.  If you have postgres on the ARM, look for those DLLs and replace the current versions with them.

Link to post
Share on other sites

If Postgres is already running on the Win 10 IoT box, I should be able to link the CINs to the same installation C:\Program Files\PostgreSQL\11\bin. Theoretically.

LabVIEW 64bit hung up when linked to these installed dll's. Hence using the 32 bit dll's supplied & going that route in the first place. It just worked. Note that there also some changes such as libint.dll likely replaced by the libintl-9.dll in the \11\bin directory.

Win 10 IoT Enterprise should be able to run regular programs where as the Core version is limited to UWP apps (understanding this requires ARM compiled code). what-s-difference-between-windows-10-iot-versions

I think Win IoT is mulching things somehow where regular Win 10 accepts the dll's.

Looks like the best approach for right now is to remotely get into the database via the localhost/IP address and run things on a laptop. Your help's been very appreciated!

Link to post
Share on other sites

Windows IoT is not a normal Windows installation at all, except the Windows IoT Enterprise version. The others are really just embededded kernels without any real Win32 subsystem. Accordingly many standard Windows DLLs like kernel32.dll, user32.dll and many more are not present there. It is basically a Windows installation with a much smaller embedded kernel that only supports Universal apps from the app store.

Accordingly a normal LabVIEW build application that you created on your dev machine should NOT even be able to be started as they are build for x86 and not ARM and require a fully functioning Win32 subsystem. How do you target your IoT system?

Link to post
Share on other sites

Yes, correct Rolf. The target was the enterprise version & that's why it ran in the first place.

Interestingly enough installing the exe on 3 other machines under Win10 resulted in the 2 working & the 3rd not finding the dll just like the Win10 IoT. With a new build it suddenly didn't find the dll on one that did work. With not having time to debug I created an installation and the program worked since even with new builds. On regular Win10 there shouldn't have been an issue...
At this point I'll try and link the latest 64bit Postgres dll's & try that.

Link to post
Share on other sites

Well in that case the remark about the DLLs having to be compiled for ARM was really off. That is for Windows IoT installations on targets like the RPi and similar boards which all have an ARM CPU (and accordingly can't run Windows IoT Enterprise either which is a pure x86/x64 install).

It all depends on which C compiler they used to create those DLLs. Until Visual C 2015 or so each Visual C version come with it's own specific C runtime library that had to be installed on every target on which you wanted to run an executable or DLL created with it. While many parts of Windows are compiled with Visual C too and therefore cause the Windows installation to come with the needed C runtime support already installed this can and will vary depending on the Windows version and the amount of extra tools and utilities that you install. Also any extra custom application you install such as LabVIEW also comes of course with the necessary C runtime support that gets installed if not already present on the system, but depending on all this a particular C runtime version may or may not be present on any particular system.

Basically you should never copy DLLs to a target system but install them with the proper installer for them which hopefully takes care about installing the correct C runtime support too.

Link to post
Share on other sites

Since there's still an issue with 32 working (but not on some machines) & the 64 bit hanging when trying to relink the dll to the installed PQ libraries, I tried to create the CIN wrappers automagically. The process gets stuck and becomes beyond my current knowledge. Don't know how you did it but kudos to you Mr. Powell! I'm sure you wrestled with this a bit. 😬

 

Looks like multiple .h files need to be referenced. libpq.dll needs the libpq-fe.h which in turn needs the stdio.h, postgres_ext.h & pg_config_ext.h according to: https://doxygen.postgresql.org/libpq-fe_8h.html

Just selecting a few basic options like open/close was not successful & returned: "The library specified for this node cannot be found or cannot be loaded."

Do you remember how you did it?

 

image.png.1a004dbf5176688e1eac268ce7c8677e.png

Link to post
Share on other sites

This has nothing to do with a CIN whatsover. CINs were a legacy technology in LabVIEW 3 and 4 before LabVIEW learned to interface to shared libraries (*.dll on Windows and *.so on Unix). What you are doing is not a wrapper either in the sense as it is usually used by me and others who are regularly dealing with this. A wrapper is another shared library written in C/C++ that interfaces to a certain API and translates it into a more LabVIEW friendly shared library interface that can be more easily interfaced with the Call Library Node.

You are trying to create a VI interface library to your shared library. And that is always a tricky business. For one the Call Library Node can't interface to every C feature out there. C++ object interfaces, callback pointers and also complex structures with embedded pointers are all things that can't be done with the Call Library Node (or in the case of complex structures with embedded pointers only with a lot of pain and by handcoding in LabVIEW what a C compiler would normally do mostly automatically).

The import library wizard you are trying to use for this is an amazing piece of software but despite its name NOT a magician. And extracting all the necessary information from a header to safely interface LabVIEW to a C shared library would be a truely magical feat, since the C syntax does not cover all the necessary details about buffer management and such things. This is only documented (if you are lucky) in the prosa library documentation that comes with your shared library. If you are unlucky you have to figure it out by guessing from naming conventions of variable names and lots of trial and error (meaning: crashing, restarting, editing, saving, crashing, goto begin). This is true for using a shared library in C just as much as in any other language including LabVIEW.

So even if the import library wizard can import all your functions you really have to go through each generated VI and manually check that the generated code is actually correct. Also the generated code is in an attempt to be rather safe than sorry often unneccessarily inefficiently programmed, which is another thing you should be changing. Of course this all requires that you know exactly how the shared library should be interfaced and if you really do that you end up very quickly with the constation that creating all those interface VIs from scratch by hand is not only about as fast as going through the import library wizard and then painstakingly check each of the VIs by hand, but also creates more efficient interface VIs with something more meaningful than the ugly standard light blue import library wizard icons and totally unpractical connector panes.

The import library wizard for instance can't know that in a function like:

int32_t MyAwesomeBufferReader(int32_t *buf, int32_t bufSize, int32_t *bufRead)

the second parameter is the size of the passed in buffer and the third is the size of how many data was actually filled in the buffer. It doesn't even know that the first is not just a pointer to a single int value but rather a pointer to an array. The C syntax does not distinguish between a pointer to a scalar and a pointer to an array, except that it allows to usually write 

int32_t MyAwesomeBufferReader(int32_t buf[], int32_t bufSize, int32_t *bufRead)

to show that the first parameter is actually an array, but this is not used by many programmers despite its increased readability (probably because some ancient C compilers didn't know about this syntax with an incomplete array size and some libraries are still written to compile even on computers that you can only see in musea anymore).

The first variant will likely default to a VI with an int32 value "bufSize" as input and two int32 value "buf" and "bufRead" as output and if you select the option to treat return values as error it will enter the return value into the error cluster as an error if it is not 0. It will also corrupt memory (and likely crash at some point) whenever being called with a bufSize value greater than 1!

The proper VI (just going from the somewhat arbitrary naming of the parameters) has however an int32 "number of samples to read" as input that says how much data should be read, and an int32 array output. Before calling the shared library function the interface VI should allocate an array of "number of samples to read" in length and on return of the function should use the "bufRead" value to resize the array to the actually returned data and then pass it back through the array output of the connector pane . The interface VI should hide all the buffer management details from any caller of the VI as otherwise you are going to expect every user of your VI to know not only about C programming details in general but about the actual programming interface of your shared library function. A totally unusable LabVIEW VI as such!

No automatic wizard in the world could be thought this in any way, and even what I just wrote is usually only a reasonable guess based on the parameter naming, which in C has absolutely no meaning in any way. (The actual parameter names can be left away completely in the function prototype without any adverse effect when using the function, and the names in the function prototype can be also completely different to the names in the actual function declaration, if the programmer wants to do that to obfuscate his code even more.) The actual library documentation would hopefully explain in detail what each parameter is meant to mean but you can't point an automated tool at a PDF or HTML file and tell it to extract any exact programming information from the prosa text in there. 

Edited by Rolf Kalbermatter
Link to post
Share on other sites
  • 1 year later...

Hello,
we are experiencing a similar issue. We are using PostgreSQL 0.1.1.9. On dev computers, with Windows 10 Pro, I create an exe with the example PQ Example Many INSERTS provided by drjdpowell. We only modify ipaddress, username and password. Everything works fine.

If I move the build folder (with the data folder) in a Win 10 Education, the exe cannot find the dlls. The attached image explains it all. Basically we get "Missing External function libpq.dll" even if the dll is in the data folder. This computer has NI run-time engine 2019 x86.

Interestingly, if I put the same folder on another Windows 10 Education, where I have installed LV, VIPM and the PostgreSQL vip, the exe runs well. This computer has also NI run-time engine 2019 x86 (and others).

Comparing the 2 Win 10 Education computers, It seems to me they both have the same Microsoft Visual C++ 2015-2019 Redistributable (x64) and Microsoft Visual C++ 2015 Redistributable (x86). I checked this aftert having read rolfk suggestion here 


What could the issue be? We are running out of things to attempt. Thanks for your support!

image.png.5b815a156e2a159b81ea1bf76fd5ee79.png

Edited by MzazM
Link to post
Share on other sites

Only suggestions I have are:

  1. Is the exe in that "builds" folder.  The EXE xpects teh dll at "<EXE's folder>/data".   Your screenshot shows the dll at "builds/data".
  2. Could be a missing dll that libpq.dll calls.  Try downloading a full set of Postgres dlls and place them in the data folder.
Link to post
Share on other sites

Thanks for your answer.

1. The exe is at the correct path

2. I downloaded the latest dll that i found on your repo in bitbucket: https://bitbucket.org/drjdpowell/pq-labview/src/master/Connection/ . No difference.

Important to notice that the same folder containing the exe (in the following screenshot I renamed the folder buildWin10Pro) works immediately in another Win10Education. The difference is that in this second system there is the whole LabVIEW, VI package manager and the Postgresql 0.1.1.9 package installed.
Any follow up on this? Thanks!

Capture.PNG

Link to post
Share on other sites

We finally understood.
We saw that a full LV2019SP1 f3 installation solved the problem. I then noted that Run-time Engine 2015 SP1f13 comes with it. I remembered that drjdpowell mentioned here that he is using LV 2015.
So I removed the whole LV (double-checked that exe couldn't find dlls anymore), installed only the Run-time Engine 2015 SP1f13 and it worked immediately.

Don't know why but it is not automatically installed with the installer.

Edited by MzazM
Link to post
Share on other sites

That doesn't make much sense.  Those DLLs aren't created by me; they are the standard PostgreSQL DLLs that I downloaded.  They can't have any dependencies on any LabVIEW stuff.

Link to post
Share on other sites
16 minutes ago, drjdpowell said:

That doesn't make much sense.  Those DLLs aren't created by me; they are the standard PostgreSQL DLLs that I downloaded.  They can't have any dependencies on any LabVIEW stuff.

Yes, I agree with you. Indeed installing LabVIEW was the last thing I tried after almost 1week of more reasonable attempts (moving dlls, getting dll elsewhere and so on).

When I removed LV the exe was complaining about missing external function. Installed runtime engine 2015 and it worked. I do not know why. I could check tomorrow on another system where I have the same exe running for a long time, if I also have the runtime 2015 installed.

 

Link to post
Share on other sites
4 hours ago, drjdpowell said:

That doesn't make much sense.  Those DLLs aren't created by me; they are the standard PostgreSQL DLLs that I downloaded.  They can't have any dependencies on any LabVIEW stuff.

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 won't work with an older runtime but the opposite works usually without a glitch.

  • Thanks 1
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By maxout
      Hi, 
      I am looking for a toolkit which would allow to connect and modify the hosted db from LV application. 
      What are the options? (excluding the Database Connectivity Toolkit). 
      max
    • By lisam
      I am looking to determine the time it takes to insert each batch (500rows) of data into a database, i.e. the loop execution time. See the block diagram below.
      I've place a timer outside the while loop and subtracted it from the timer inside the loop, using shift registers to carry forward the start time. I place the timer in a sequence structure to make sure it starts before the code runs.
      When I used this method on a simple example - a while loop with wait function, the loop execution time returned the wait time as expected. But in the database application, the loop execution time value continues to increase. Where am I going wrong?
      Thanks in advance,
      Lisa
       
    • By SDietrich
      Name: libpq
      Submitter: SDietrich
      Submitted: 01 Mar 2014
      Category: Database & File IO
      LabVIEW Version: 2009License Type: Other (included with download)



      This is a package containing LabVIEW bindings to the client library of the PostgreSQL database server (libpq).
       
      The DLL version 9.3.2 and its dependencies are included in the package. This DLLs are taken out of a binary distribution from the Postgres-Website and are thread-safe (e.g. the call to PQisthreadsafe() returns 1). As of the moment the DLLs are 32bit only.
       
      The VIs are saved in LabVIEW 2009.
       
      So this package works out of the box if you have a 32bit LabVIEW 2009 or higher on any supported Windows operating system.
       
      Because this obviously is a derived work from PostgreSQL it is licensed by the PostgreSQL license.
       
       
      A few words regarding the documentation: This package is meant for developers who know how to use the libpq. You have to read and understand the excellent documentation for the library. Nonetheless all VIs contain extracts of that documentation as their help text.
       
      What's coming next?
      - adding support for 64bit
      - adding support for Linux (anybody out there to volunteer for testing?)
      - adding support for MAC (anybody out there to volunteer for testing?)

      Click here to download this file
    • By SDietrich
      This is a package containing LabVIEW bindings to the client library of the PostgreSQL database server (libpq).
       
      The DLL version 9.3.2 and its dependencies are included in the package. This DLLs are taken out of a binary distribution from the Postgres-Website and are thread-safe (e.g. the call to PQisthreadsafe() returns 1). As of the moment the DLLs are 32bit only.
       
      The VIs are saved in LabVIEW 2009.
       
      So this package works out of the box if you have a 32bit LabVIEW 2009 or higher on any supported Windows operating system.
       
      Because this obviously is a derived work from PostgreSQL it is licensed by the PostgreSQL license.
       
       
      A few words regarding the documentation: This package is meant for developers who know how to use the libpq. You have to read and understand the excellent documentation for the library. Nonetheless all VIs contain extracts of that documentation as their help text.
       
      What's coming next?
      - adding support for 64bit
      - adding support for Linux (anybody out there to volunteer for testing?)
      - adding support for MAC (anybody out there to volunteer for testing?)
    • By JollyRoger7
      I was very excited to recently find the MySQL connectors for LabVIEW. There was a free/OS one posted on NI, and there was a pay for proffesionally supported one from Safir over in France. (www.safir.fr)
      I think a Lava member developed the free one.
      After I got the PO together for the Safir version, my boss tells me we may be switching to PostgreSQL, and BAM, I am back to square one. Why does it matter? Because our code base is supposed to run the same on Windows, Linux and cRIO depending and need and circumstance.
      Now there is a Sourceforge project for LabVIEW and PostgreSQL, but it relies on DLLs.
      I suppose I could do something weird like write a wrapper in LabWindows CVI and talk to that via LabVIEW?
      Or I could read the prorocol chapter in the postgreSQL manual and do it from scratch in LabVIEW?
×
×
  • Create New...

Important Information

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