Components

cancel
Showing results for 
Search instead for 
Did you mean: 

CVT Client Communication (CCC)

Attached is a portion of my acquisition code. My feeling would be it is here that something is wrong. I have tow other loops that read the CCC to display charts and log data.

0 Kudos
Message 51 of 98
(8,380 Views)

What are you using the CVT for? Typically the CVT and CCC will replace global variables, but you are using both. What hardware are you using and what is the purpose of the project?

 

I would suspect that this is not a CCC or CVT problem at all and there is something else going on.


Eric T

0 Kudos
Message 52 of 98
(8,377 Views)

We'd like to direct most future questions to this project location:

https://decibel.ni.com/content/projects/cvt-based-reference-designs-for-machine-control

 

If you believe you will be better served by posting here, feel free to do so. It will still be actively monitored for the forseeable future. The community group above is the preferred location for new discussions.

 

Thanks,

Daniel

0 Kudos
Message 53 of 98
(8,337 Views)

Hello,

 

I tried examples in LabVIEW, client and server, and did very well in the environment. When I turned in stand-alone applications, server generated error 2 "possible reason: memory full". Error was generated by "invoke node" in the VI Start Server in my VI.

I have win7 64bits and LabVIEW13.0.1f2 (64-bit)

I attached the two vi's and two compiled applications.

 

How can I solve this problem?

 

Best Regards,

0 Kudos
Message 54 of 98
(8,305 Views)

I found on the forum, the answer to the problem of compilation. I set the panel's VI server.vi not to be remuved and applications work.
But I did another test. Into the ini file of the applications, I set allowmultipleinstances = true so I can run both server and client in multiple instances by setting different port addresses. A pair client-server uses port 54444 and a second pair client-server port 54445. There's an interesting phenomenon: Client's arguments 54444 generates output value on Client's panel 54445 and vice versa.
CVT is unique on a host computer? A CVT with a tag element is accessed by any other application running on the same computer or connect to a server at the same computer, using the same tag?

 

Best Regards,

 

0 Kudos
Message 55 of 98
(8,299 Views)

Hi folks,

 

I have a large project that is distributed and has parts in Java as well as LabVIEW. I recently was asked about technologies that LabVIEW and Java can use to communicate together.

 

The reason i have come here is to ask if there is a C or even better a Java implementation of the CCC? Alternately, could the CCC API be compiled to a DLL or a SO (we use LabVIEW for Linux) such that the Java side folk could call it as needed?

 

If you have other suggestions about interconnection please PM me! Thanks!

0 Kudos
Message 56 of 98
(8,139 Views)

OPC may be the solyuion you are looking for. OPC implements a client server architecture to share information between applications or programs. They have a LINUX solution called the Unifed Acess (UA). Their typical approach is based on COM/DCOM for windows applications. I have used OPC to talk to PLCs. OPC provides a Shared Variable interface in your LabVIEW code and therefore is easy to use once you get the client and server working. One example of using OPC with Java is listed below.

 

http://www.opcconnect.com/java.php

0 Kudos
Message 57 of 98
(8,130 Views)

I'm having a very hard time getting CCC 3.0.3.9 to connect in a stable fashion.

 

PXIe-8135RT as the server

Windows 7 laptop as the client

 

The server power is brought up and down often so I want the host CCC client to be able to reconnect to the server if:

 

  • It isn't started when the client attempts to connect but comes alive later
  • Drops while the client is already connected then comes back

In either situation, with the current CCC implementation,I see very strange behavior indeed.  Using VI's formulated according the the CCC client and server examples, if the client attempts to connect before the server is available the following happens:

 

  • The server never responds
  • The server sometimes goes into a max-CPU state on one CPU (Even after the server VI and all other VIs close) and a restart is needed

There seems to be some sort of race condition in the TCP connect process that is freaking the server out.  If the server is available on the first connection attempt, everything works great.  But not the other way around.

 

Any suggestions?

0 Kudos
Message 58 of 98
(8,006 Views)

Here's the VI I am using for connecting to my CCC server.

 

CCC_Troubles.png

 

The error seems to occur while running both systems in development mode (Haven't tried standalone).  When I try the client with the server not running, LabView pops up the dialog about the realtime host not responding.  It almost seems as though there is a connection between LabView development system connection to a realtime target and the use of a LabView TCP Connect VI.  If the VI fails, LabView Development System thinks it has lost connection to the development mode of the realtime target.

0 Kudos
Message 59 of 98
(7,998 Views)

@xl600 wrote:

I'm having a very hard time getting CCC 3.0.3.9 to connect in a stable fashion.

 

PXIe-8135RT as the server

Windows 7 laptop as the client

 

The server power is brought up and down often so I want the host CCC client to be able to reconnect to the server if:

 

  • It isn't started when the client attempts to connect but comes alive later
  • Drops while the client is already connected then comes back

In either situation, with the current CCC implementation,I see very strange behavior indeed.  Using VI's formulated according the the CCC client and server examples, if the client attempts to connect before the server is available the following happens:

 

  • The server never responds
  • The server sometimes goes into a max-CPU state on one CPU (Even after the server VI and all other VIs close) and a restart is needed

There seems to be some sort of race condition in the TCP connect process that is freaking the server out.  If the server is available on the first connection attempt, everything works great.  But not the other way around.

 

Any suggestions?


 


@xl600 wrote:

 

 

The error seems to occur while running both systems in development mode (Haven't tried standalone).  When I try the client with the server not running, LabView pops up the dialog about the realtime host not responding.  It almost seems as though there is a connection between LabView development system connection to a realtime target and the use of a LabView TCP Connect VI.  If the VI fails, LabView Development System thinks it has lost connection to the development mode of the realtime target.



Ok, so this seems like a key issue:

"

  • The server sometimes goes into a max-CPU state on one CPU (Even after the server VI and all other VIs close) and a restart is needed"

 

If its railing the CPU, that would be why the host-not-responding dialog pops up. However this is beyond the scope of the CCC library, which just uses the TCP/IP primitives. I'd recommend trying to create a slightly simpler VI to demonstrate the issue (perhaps starting with the normal TCP/IP examples. If you can reproduce, call/email standard support (1-866-ASK-MYNI, or support@ni.com). If you can't, I'd still recommend calling in to see if they can help you narrow down what is causing the CPU to rail. I'll take a look at the CCC code here in a little bit to see if there is anything I think might be causing it.

 

The other thing you could use is the tools>profile>performance and memory window. Make sure you only view data for the RT target application instance. It should show you how much time is spent in each VI. The reason this may be helpful is if there is a hidden function in the background running still, you may be able to see the cpu time go up for that VI which would give us a good place to start.

 

If the server isn't listening yet when the connection is established, the client will either get a message that the connection was refused or it may simply time out. If it is never responding, thats a bit weird. It looks like the default connection timeout is 1 second. Is the client just repeatedly erroring out on every call, or is it something else?

 

When you say the server goes down, do you mean the ethernet connection or that it reboots?

0 Kudos
Message 60 of 98
(7,978 Views)