EtherNet/IP Driver

[BlueCheese]

I'm not sure I completely understand what your code looks like from your description (maybe post a screenshot?). If you are using a session and while an operation is in progress you asynchronously close that session, it is expected that the operation in progress will return an error. It can't simply wait for that operation to complete since the operation might have a very long timeout. This matches the behavior of any other resource such as files, sockets, etc.

You mentioned that you have two VIs that both close the session. Are they using the same session name? If they are, then that might be your problem. You could either use an independent session in each sub-VI or else manage the closing of a session at a higher level than those sub-VIs.

LabVIEW manages closing open resources when it will no longer need them, such as when your program stops. So if you do not have a reason you explicitly want to shut down the session you could also just leave it open. The expected use-case for the EtherNet/IP VIs is to let LabVIEW automatically open a session on-demand (which is why the default session on the VI terminals is "Default") and then automatically close it on demand. The reason we expose the explicit open/close on the Advanced palette is for advanced use cases where you might want to cancel pending operations or disable the EtherNet/IP stack while you program is still running.

Eric

[nonecure]

Eric,

You are right, I did not have the default session name, so that was the problem.

Attached is a screenshot of one of my sub vi’s after adding the session name.  The 2^nd sub vi is very similar and they both run from a main vi. 

So you say it is fine not to open or close the sessions?

I noticed that if I remove the open session and the wire going into the first Attr, the vi will take 4 times longer to execute.  If I wire in a constant for the session name into the first Attr then it runs fine. 

Thanks,

Doug

[BlueCheese]

Doug,

Based on your code, there is likely no reason to explicitly open/close sessions. You could simply let LabVIEW open and close them as needed.

Some things to consider though that will affect performance:

-If there are no open sessions (opened manually or automatically), when a session gets opened it will start up the EtherNet/IP stack. This has some amount of overhead. When the last session is closed, the stack is shut down.

-If you are starting from a fresh state, the first time you send a CIP message to some remote device, a TCP connection must be opened to that device. This also incurs a little bit extra overhead. Our stack will keep this TCP connection open between messages unless it has been idle for too long (around 30 seconds I believe).

Thus, you can see why the explicit Open/Close VIs can give your program some added flexibility if you want to have complete control over when initialization and cleanup happens. Additionally, they provide the equivalent functionality as hitting the Abort button to allow you to cancel a pending operation if you close a session that is waiting for an operation to complete.

Eric

[BlueCheese]

I just wanted to let everyone know that version 1.0.5 was just posted. This new release adds some highly requested features. We now have SLC500 read/write/masked write into Bit register files. Additionally, a Raw type was added for SLC500 so that customers can write to types that are not currently supported or are custom.

Also note that an official support thread has been opened here (http://decibel.ni.com/content/thread/7483) so please leave your feedback there so others can find it easily.

Thanks,

Eric