FixedWire

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.

Thank you Paul. Nice work. Sweet. Thank you all!

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!

In case someone needs Jack's code here it is resaved to work on the latest LabVIEW.Robust TCP-IP (LV2016).llb

Have a look at the SPI examples on ni.com for the FlexRIOs. Some examples are overly simple and there's a couple well written ones using IPs which would work equally well for you.

Yes Stobber, I hear you. The test equipment needs the STIL format & I need a way to both build and manipulate parameters. e.g. change the MOSI max voltage level. JSON was a thought and I'm open to suggestions. Haven't seen any vector generator source files yet...

If you wanted to take it up a notch, it would be awesome to include the ability to get colours that actually look great together and up the design aspect for all of us. Have you seen https://color.adobe.com/# ? There must be an algo for this...

Not sure if this is the best thread... I'm looking to use the JSON implementation to manipulate STIL files (IEEE 1450). Is an extension of the JSON.lvlib a good use case for this implementation? The format looks like this for SPI (serial peripheral interface bus): Signals { //My SPI Signal - Direction is Relative to Slave CLK In; MOSI In; MISO Out; CS In; } // end DCLevels SPI_Levels { CLK {VIH '3.3V'; VIL '0V'; } MOSI {VIH '3.3V'; VIL '0V'; } MISO {VIH '0V'; VIL '0V'; VOH '2.0V'; VOL '1.8V'; } CS {VIH '3.3V'; VIL '0V';} } Any suggestions on the best way to do this? Not using STIL is not an option. Thanks!

Let's keep in mind that not changing too much is sometimes a good thing. The aerospace industry for example, with all the requirements needs to stay stuck in time for 20 years. I'm currently using LV2011 because of this. NI's HW integration is quite solid and good HW creates good systems. However, NI, your 20 GB updates are just bad news...just say'n.

You may want to test this with the hardware and a scope using the PPS pulse that is available as a wired output on a GPS. The PPS (pulse per second) is a 1 microsecond pulse that is nano second accurate. Run it in a loop and you'll know!

Thank you Rolf. Good insight as always!

Just by adding the constant "immediate" to the TCP Read function fixed the issue here!

Thank you all for posting!

Great example QueueYueue. Interesting how the system spun up the Actor Core Name numbers unexpectedly out of sequence.

We've used Quadtech 4 port devices for USB in the field and they work fine. Just be very careful that there is not too much data coming down the pipe going through a low throughput USB port. This will cause your CPU to work very hard since the controller can't handle it. http://quatech.com/catalog/rs232_sds.php