Another change I had to make to the CCC functionality was to the CCC Server (ccc_Server.vi) that runs on the cRIO system. When opening the TCP connection, you need to set the input "resolve remote address (T)" to False. There's no benefit to setting it to True that I have ever found, and if you try to connect directly to the cRIO (without going through an intermediate network), the system hangs for about 10 seconds or so until the request for address resolution times out. In the meantime, your app has probably given up internally and thrown an error or an impatient user has already Ctrl-Alt-Deleted and ended the program on the PC-side. Either way, it's no good.
This is a problem that I have encountered many times when developing TCP applications for the cRIO where you need the cRIO app to work both on a network and when connected directly to a computer.
So set resolve remote address to False, and the TCP connection can be made even when connecting directly to the cRIO. This is a nasty bug since you might not notice it until after you deploy your system for the first time.
Noticed a weird bug I received from some code.
The attached project uses a Status Tag4.xml for the Tag set. There is a unbound network tag under the HMI called tag.
Anyway if I don't watch for errors the CCC Client Write vi reports the error only once and the subsequent iterations return no errors. Of course the work around in watch for errors but it was quite hidden. This also affects data from being sent from the client to the server (using Sup Write to turn on ProcRead). Data sent from Server to Client works fine.
I am having issues with my CCC implementation. Here is the background
CRIO in hybrid mode
using CCC, CVT (vs3, modified), AMC, STM, etc. Pretty much the CRIO reference architecture.
I have no problems writing or reading tags on the CRIO but when I began to implement my engine on my HMI computer I am running into this error...
Error 537164 occurred at Group Memory.vi
A group was not found in the CVT.
Group 'CCC_Client Write Group_169.254.181.155:54444'
First off, I am not using any groups right now, but I am wondering if this has something to do with connecting to the server? I see where the error is getting generated but since the CCC doesnt appear to use groups when updating the CVT across the network Im not sure what this error means.
Has anyone seen this error before? I have included my "connection manager" for the HMI side that inits the tags and refreshes the table.
I don't recall that particular error but have you defined the variables you are using with the appropriate read/write permissions on *both* the cRIO and the HMI computer?
Hello paperduck, thanks for the quick response.
I think I am properly defining the read write permissions on the HMI here. the direction should define whether it is "read from RT" or "Write to HMI". However I am not sure about this on the RT side. I thought there were no read write permissions on the server side.
What to you think?
Here is the same section on the server side. When you set up and define the tags properties there is no direction as far as I can see.
Also for clarity in this post and the last one the section of code I am referring to is the for loops where tag information is split from the tag editor file and built into the proper cluster for CCC and CVT.
The CCC uses groups to access the CVT more efficiently. The group name in the error message refers to the group on the client side that contains the tags sent from client to server. The group name contains the server's IP address and the remote port it uses, so make sure "169.254.181.155" is the correct IP address of the server. Would you consider sharing the file that gets read by "Init Tags HMI.vi"? I can take a look at the tags to see if I get the same error with them. Can you identify when the error happens? For example, is it happening when you first call Client Init.vi, or is it inside the loop when you call Client Synchronize Data.vi, and which iteration?
You also mentioned that you are using a modified version of the CVT. Can you elaborate on the modifications you made and which CVT version you started with? Also, which version of CCC are you using?
"so make sure "169.254.181.155" is the correct IP address of the server."
Yes I have drilled in and see that the FG Client Configurations.vi reads the server ID and if the variant is empty fills it up with the correct group names. Do I have to set up or init these groups somewhere? I dont see where that happens so I am starting to think this is why. However even after the first pass through on this VI it seems that the variant stays empty. Since its an FG its a little hard to troubleshoot since I dont know what VI is writing to it.
"Would you consider sharing the file that gets read by "Init Tags HMI.vi"?"
I have included the binary file I read the tags from. I will also include the tag editor that I use to write the file.
"Can you identify when the error happens?"
The error happens after everything is init'd and starts refreshing the CCC, Both the CCC Client Read and Write VIs throw the error because the groups dont seem to have ever been set up. Where would the groups be set up at? I cant find anywhere this happens. It will throw the error everytime. I also have used the client synchronize data.vi and it behaves the same.
So I guess I could write a VI that goes after the Init CCC and reads through the tags again to create the two groups, or maybe I should put it in the init tags HMI.vi... I suppose I just dont fully understand whats happening under the hood yet.
"You also mentioned that you are using a modified version of the CVT"
I guess I should say I rewrote a tag editor since it wasnt available for the new CVT 3.0, instead of modifying the CCC I am only using the old supported datatypes and am using the "information" column to share scaling information and write new tags for each scaled value.
I am using CCC 184.108.40.206, CVT 220.127.116.11
Ok, I was able to manually create the groups and get the error to go away. I am not 100% sure everything is working perfect but now I move forward.
Thanks for helping me work through this.