Issue with calling Library from LabVIEW

[radfor...@gmail.com]

Hi there again. I am trying to sort out something i have been noticing when calling the library from LabView.  Everything has been working great for me however, if i ever try to create a tag with a gatewayIP that is incorrect my library call hangs and never returns.  (So for example if my controller is at 192.168.0.5, but I accidentally use 192.168.1.5 (subnet 255.255.255.0) then it hangs.  Maybe its a problem on the Labview side but thought i would ask if you had any ideas.

Thanks!

Dave

[Kyle]

Hi Dave,

Under the covers, the library will keep trying, but if you use the synchronous mode when calling plc_tag_create(), it will fail after your timeout.   If you use the asynchronous mode, you are responsible for managing the timeout.  Once you have a timeout, you need to call plc_tag_destroy() in order to stop the back end of the library.   If you use the synchronous mode (passing a timeout value > 0) for plc_tag_create() you will not need to call plc_tag_destroy() as that will happen when the tag creation fails with a timeout.

Unfortunately, there is no way for the library to tell the difference between a data entry error and a PLC that is temporarily off line.  So it will just keep trying unless you tell it (via a timeout value or via a call to plc_tag_destroy()) to stop.

How is LabVIEW calling plc_tag_create()?  Is a timeout value passed or zero?

Do you have access to the command line tools?  You can try using tag_rw2 to access a tag on that PLC to see if the library is hanging without being called within LabVIEW.  That will test whether there is a fundamental problem on your system when the wrong IP is entered.  Here is what I see when I enter an IP address that is not a valid one:

./tag_rw2 --type=sint32 '--tag=protocol=ab-eip&gateway=10.206.1.34&path=1,4&plc=ControlLogix&name=TestDINTArray[0]'
Library version 2.4.1.
Processing argument 1 "--type=sint32".
Processing argument 2 "--tag=protocol=ab-eip&gateway=10.206.1.34&path=1,4&plc=ControlLogix&name=TestDINTArray[0]".
ERROR: Error creating tag PLCTAG_ERR_TIMEOUT!

Now when I try again with a valid address:

./tag_rw2 --type=sint32 '--tag=protocol=ab-eip&gateway=10.206.1.40&path=1,4&plc=ControlLogix&name=TestDINTArray[0]'
Library version 2.4.1.
Processing argument 1 "--type=sint32".
Processing argument 2 "--tag=protocol=ab-eip&gateway=10.206.1.40&path=1,4&plc=ControlLogix&name=TestDINTArray[0]".
data[0]=10 (a)

I see the data then.

If you can test from the same PC that runs LabVIEW we can remove other factors from the hang.

Best,

Kyle

[radfor...@gmail.com]

Thanks for the reply Kyle.  I have tried both sync and async in Labview and neither returns if i give it an incorrect ip address.  I did try using the tag_rw2 and it times out as expected, so definitely related to Labview.

Thanks!

Dave

[Kyle]

Hi Dave,

This is really odd.   I wonder what LabVIEW is doing here? 

I'd like to get to the bottom of this problem as LabVIEW is not a small part of the "market"!  Is there a way to get log files from LabVIEW?  I mean the log output from the library itself.   From what I remember, LabVIEW wraps all loaded DLLs very tightly and insulates the rest of the system (and probably LabVIEW itself).  It would be interesting to find out just where things are hanging. 

There are several stages that a connection goes through as it starts up.   The first one, however, is the initial TCP connection from the PC to the PLC.   If LabVIEW is somehow doing something to/with the Winsock DLL at that stage, then libplctag is not going to get very far and it will hang.   I may need to look into checking the connect() call results with select() and making the socket non-blocking from the outset.  

If you can find a way to get the log output from libplctag through LabVIEW, that would be very helpful.  With that I can see how far it is getting in the connection process.  In the mean time, I will look into adding more non-blocking behavior to the connection process to see if that helps.

Best,

Kyle

[Jody Koplo]

Are you just using the library on Windows? I really need to wrap the .net version into LabVIEW...

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/e16fad25-c433-4347-a40a-d9453a2471a1n%40googlegroups.com.

[radfor...@gmail.com]

Pretty sure i will need to create a wrapper dll to use the logging callbacks in Labview.  I will give it a shot, will probably take me a while.

I also tried the linux version of Labview and it also hangs with an incorrect IP so not just related to windows/labview.

[radfor...@gmail.com]

I do use the library on linux, mostly at home for development.

[Kyle]

Thanks for the updates, Dave.  That the Linux version also shows the same problem is perplexing.   While it is certainly possible to override various calls within the C library, it is generally less needed there.

I hope you can find a way to get the log information.   This is definitely a problem.  If LabVIEW can do this, other systems might as well!

Best,

Kyle

[radfor...@gmail.com]

So for the short term, i just modified the libplctag library to write the log to a text file. It seems to be working, and i see it trying to connect to the incorrect IP over and over.  What debug level do you want me to use? 

Thanks,

Dave

[Kyle Hayes]

Please set the debug output level to 4.  If you see multiple attempts then something is not timing out.  But where that is...

Best,

Kyle

You received this message because you are subscribed to a topic in the Google Groups "libplctag" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/libplctag/jWVYtXo6thY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to libplctag+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/libplctag/51fef857-b800-4683-a00e-ac9bd678ad62n%40googlegroups.com.

[radfor...@gmail.com]

Well, i feel like an idiot. As you suspected, it was not timing out.  I went back and looked at my wrapper vi's and for plc_tag_create I mistakenly  was passing a pointer to a value, instead of value for the timeout variable.  All the the other functions that accept a timeout input were done correctly, I just messed up this one.  I changed that and now everything is working as expected.  Hope i didn't send you down any rabbit holes!  At least now i have a way of viewing the debugging output which will be helpful. 

Thanks!

Dave

[radfor...@gmail.com]

I should also mention, if you remember i was having a problem with the 64 bit version of Labview, this issue was also resolved by this fix. 

[Kyle]

Ah, that is good news!

There are only two parameters to plc_tag_create() and both will be passed in single machine registers on most platforms.   Thus the pointer will end up being a very large number.  On my Linux box, a pointer to a newly created mutex is 0x4ad4bf0 or 78466032 decimal.   That is 78466.032 seconds or almost 22 hours.   On a 64-bit platform, the value of a pointer will still be passed in one of the machine registers, but then the value will be forced to 32 bits before use.  Still likely to be a very large number.

You did make me realize that plc_tag_create() still triggers some (background) blocking activity when we try to connect().  I have most of the pieces to make that non-blocking now.

First I need to keep beating my head against my new (to me) MicroLogix to get it on my network...

Best,

Kyle