Problem with windows 64 bit dll

[radfor...@gmail.com]

Hi there.  I have been using libplctag for a couple years now with LabView. I just got done finishing some computer hardware upgrades and decided to try running 64 bit applications on them.  (Running windows 10 64 bit, Labview 64 bit, and using 64 bit libplctag dll from releases.  )

I am unable to create any tags with the 64 bit version, i keep getting an error of PLCTAG_ERR_BAD_PARAM (-7).   After that i went back to 32 bit and everything works as expected using the same string.  I know in the past, i have used 64 bit before so i went all the way back to release 2.1.3, and that does work as expected.   Any ideas?

thanks!

Dave

[Kyle]

Hi.  Thanks for bringing this up.   There should not be much difference at all between 2.1.3 and 2.3.7.   That said, the compiler has changed over time.   I build on GitHub exclusively for the distributed binaries now.   I am not sure that I did in 2.1.3.

Is there any way you can run this with debugging enabled?  In the tag string add "&debug=4" to the end of the string or call the plc_tag_set_debug_level() function with an argument of 4 (integer not string).

I have not checked to see if the LabView wrappers are being kept up to date.   I really do not know much about them.   It is possible that there is some difference in them that only shows up with newer 64-bit code?  How are you switching back and forth from 32-bit to 64-bit code?   Different versions of LabView?

Best,

Kyle

[radfor...@gmail.com]

Thanks for the reply. I did try compiling myself and that made no difference. 

Not sure how to capture the debugging output in Labview, i do not have access to stderr.  I did try running one of your examples with the 64 bit .dll and that works fine, so something going on with labview 64 bit I'm afraid.  Strange that the older .dll works though. 

I have not updated the Labview wrappers in a while, i have been meaning to do that.

Yes to switch between 32 bit and 64 bit, i have to run a different  version of Labview. 

Really this is low priority, i don't have to use 64 bit, i was just trying to figure out what was going on.

[Kyle]

If the LabView wrapper allows it, you can use the log callback to push the logs to a file.  Others have used this when they do not have access to stderr.

I do want to get to the bottom of this problem.   I will see if I can find any references on the Internet.

Thanks for trying to recompile.  

Best,

Kyle

[radfor...@gmail.com]

Ok, I will look into it, may be a few days before I can get to it.  I did use one of your c examples in 64 bit and had no issues, so it seems to be something with the 64 bit version of Labview. 

Thanks!

Dave

[radfor...@gmail.com]

After a little bit or reading came across this

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8XJSA0&l=en-US

[Jody Koplo]

As a long time LabVIEW user and also a .NET developer can I recommend trying the libplctag.NET library in LabVIEW?

Unless you're developing for cRIO/Realtime it's a *lot* easier to reference .NET libraries in LabVIEW than C libraries. You might even try using the libplctag.NativeImport library as a thin wrapper around the C library. You can download it here: https://www.nuget.org/packages/libplctag.NativeImport/. Then use a zip tool (nuget packages are just zip files with a different extension) and pull out the files.

With all that being said, 64-bit LabVIEW always seemed like it was stuck in a 'prerelease' state...

Jody

--
You received this message because you are subscribed to the Google Groups "libplctag" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libplctag+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/libplctag/c8127737-a393-415a-8786-bb32c38f337bn%40googlegroups.com.

[radfor...@gmail.com]

Thanks for the reply Jody. Yeah i have been using LabVIEW for about 20 years now... :).  

I have not used .NET libraries before I'll have a look, thanks!

Yes, 64-but LavVIEW always has it's issues, and for this project i don't need to use it. (however in the past i have had to use it for image processing and very large files....)

[Kyle]

Oooh!   You can use .Net directly in LabView?  That has to be better than trying to wrap the C DLL directly!  If one of you can figure this out and write it up, I would be happy to put it onto the main site.

Best,

Kyle

[Jody Koplo]

Yup! I might take a crack at it... 

.NET doesn't work on *all* LabVIEW platforms - just Windows. LabVIEW also runs on desktop Linux, Mac, as well as NI Linux (OpenWRT based), and VxWorks (legacy).

Jody

To view this discussion on the web visit https://groups.google.com/d/msgid/libplctag/182d60f5-f07d-4a30-afde-cad683497d5an%40googlegroups.com.

[Jody Koplo]

Well I poked it with a sharp stick and I learned a few things:

1. LabVIEW doesn't like dealing with generics. This makes sense, but the workaround is either to get rid of generics on the C# side (wrapper lib) or to mess with reflection. I dumped some time into reflection and it didn't get me very far.
2. It appears that the NativeImport library is quite easy to pull into LabVIEW. I didn't have hardware to test with, but I could instantiate a tag and see the errors when it attempted to connect and timed out.
3. I forgot about this, but once LabVIEW's development env has a hold of a DLL it likes to keep it in memory. This means that ForceExtractLibrary would fail since it was trying to overwrite a locked file.

Here's a screenshot:

I was considering making a set of simple/non-generic classes in the libplctag.net library because generics can be confusing (especially to new C# devs). This might hasten that effort.

Jody

[Kyle]

Nice work, Jody!

There is a AB simulator (really dumb, but it works for testing) in the library release.  Look up the ab_server program.  You can use that to simulate hardware when you do not have any.  I wrote it when I was away from my toys.

Thanks for working on this.  I doubt that I will have access to LabView any time soon.   Maybe I can get a license to use with my robotics team if/when that starts up again.

I added the plc_tag_shutdown() function to the library a little while ago to support the LabView use case.   When LabView decides to remove a library, it does not trigger any of the C or Windows clean up routines.   You need to call that function explicitly.   Then it will get rid of the DLL.  At least this works for C.

Best,

Kyle

[radfor...@gmail.com]

I think the community edition of Labview is free (both windows and linux). Maybe not for commercial use i can't remember. 

Yes, without the plc_tag_shutdown() Labview freezes on shutdown with a memory violation.  Glad you added that. 

So far, everything has been working great with 32 bit windows Labview, (and 64 bit linux Labview) using the C dll.  I do wish i could get the callbacks working, hopefully i will have time to figure that out. 

The .NET option looks intriguing, only issue for me would be on Linux but then again not a huge deal, i can have everything running on windows..

I know Zero about .NET so will be following Jody's work :)

Thanks!

Dave

[Kyle]

There are versions of .Net that work on Linux now.   Whether LabView on Linux can load those is a different question!  If it can, that would probably be an easier path than wrapping the C DLL.

There is a reason I added callbacks so late.  I wanted them years ago but I felt that the language wrappers would have a hard time.   They are great in C or C++.   Java, through JNA, handles them pretty well.   Jody and Tim got them working in C# but I do not really know if they were painful or not.

Best,

Kyle