LabVIEW Information

Recent Profile Visitors

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?

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.

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!

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.

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?

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.

Hi,
I'm in the process of creating an app where the code had previously used the DSC module, that used to be included in LV, just for logging in. The DSC has now been replaced with the OPC toolkit afik. On a new project it doesn't make sense to use DSC nor does getting the OPC and dealing with runtimes when a fraction of the toolkit will be used.
Having looked around I've not found a good replacement. At this point I'm looking at rolling my own & using the Windows logon (Advapi32.dll:LogonUserA) or the .NET System.DirectoryServices.AccountManagment.PrincipalContext
Any suggestions?
The end application is for a regulated environment so the code needs to be extensively tested. Thought I'd ask before diving into a rabbit hole unnecessarily.
Thanks!

Thanks caleyjag. I got the code to work nicely after using your suggestions. It all boiled down to really cleaning up the image and training. The image needed to be rotated until the confidence level was met. i.e. the OCR was trained in a consistent way. Subtleties such a slight twist or how light/dark the value was required manual intervention with a lot of samples. The final result was >98% accuracy across 6.5k images.

It's seems simple enough to read a number that can be 1 or 2 digits and randomly rotated. I've tried to train the OCR but am not getting the expected accuracy.
One neat bit of code was https://forums.ni.com/t5/Example-Programs/Programmatically-Generate-an-Optical-Character-Recognition-OCR/ta-p/3491108
Any suggestions?
Here's an example:

When you've got too many new variables it's nice to know something works as it should (the UA client)! At this point I will not integrate the OPC UA.
You did get me thinking though and I'd look into using the .NET OPC UA Client API for the simple fact the client worked so smoothly. The quality of the API is likely high too. https://www.unified-automation.com/products/client-sdk/net-ua-client-sdk.html
-Peter

Thanks everyone for the insights. After a lot of digging I too found it odd that the Data Change events﻿ weren't handled and the implementation(s) tend to go the binary route where DCOMs had to be configured. Yuck.
As this project will run on an intranet the benefits (or complexities for that matter) of the OPC UA securities are of no real benefit as it'll just be a data pipe in the end.
There's a client from unified-automation.com/ that's free that was an easy install and immediately found the server on the Wago SPS for anyone that looking to do a bit of experimenting.

Hi,
Has anyone gone down the road of evaluating or has experience implementing the OPC UA architecture? There are a couple of toolkits out there so thankfully there is no real need to tackle the OPC .NET API. At this point I'm trying to fetter the tech side of it. What were the unexpected roadblocks you ran into?
If anyone can share their experiences it would be appreciated.
Thanks!