CBus OPC to Citect

Hey all,

I have successfully had Citect and CBus communicating in both directions using OPC, when my computer was connected to the CBus network via a PCI.

Using the same configuration settings in Citect, I can only achieve 1 way communication with CBus from Citect when connected over a CNI. I remember I did have this problem in the previous (PCI) set up, for a while, but then it resolved itself without any specific alterations being made.

Citect is able to write to CBus and change values, however Citect does not respond when values are changed in CBus (using the 'CBus side' OPC client to change values) and constantly displays a #COM error.

Has anyone had a similar issue and managed to resolve it?
Kindest Regards,
Adam

 

Can you generate a detailed log in the C-Bus OPC Server and post that. Make it a short as possible.

The OPC Server was developed with, and tested against, Citect extensively.

Do you have any problems using other C-Gate clients to read/write values? e.g. HomeGate, C-Bus Toolkit etc..

 

Hey Richo.
Thank you for such a swift reply!

I have generated a detailed log, and made it as small as possible, although its still a fair whack! Just for clarity, this is what I have done:

1. deleted existing log file from Clipsal install folder. ...\Clipsal\CbusOpcServer\Logs
2. opened the CBus network via toolkit (opens c-gate)
3. opened and compiled Citect project
4. Opened and ran through CBus OPC Commissioning Application
3x fan points
3x damper points
5. started CBus OPC monitoring application
6. waited for sync (took almost 3 minutes)
7. ran citect project
8. opened OPC client(s) to view values
9. loaded points into OPC clients
(CBus side all = 0)
(Citect Side all = BAD)
10. navigated to citect page. Turned each value to "ON"
fans = 255
dampers = 1
(Citect Side all = BAD)
This worked. I can change the state of the CBus network from Citect, and Citect responds.

note: a citect event I had running to check the conditions automatically turned all these points back to zero.
repeated step 10

11. Turned each value to "0" using OPC client
This doesn't work. I can change the state of the CBus network, but Citect does not respond, and continues to display that everything ins 'on'.
12. Stopped and closed CBus OPC monitoring application

13. The log file has been saved separately using the smart inspect log viewer and can be downloaded from here:

OPC log

I couldn't make a readable .txt file, and there was too much to post in a thread. I hope this proves useful, there are a few
"SendTextToPipe failed due to a closed pipe" errors towards the end!

I have no problem changing the CBus side of the network, and the CBus OPC client updates with comms. It is the link between the CBus OPC server and the Citect.OPC server that fails.

Thank you!
Adam

 

Adam,

Thanks for that information. The log file you provided was great.

I'm still looking through it, but the first thing that sticks out is all the errors "SendTextToPipe failed due to a closed pipe" and "OpenPipe FAILED - GetLastError = 2"

The log shows that the server was started, then shutdown 6 minutes later. During this run, there were none of those errors. When the server was restarted, it immediately had those errors up to the end of the log. This suggests that you closed the Monitoring Application (your step 12) but then restarted the C-Bus OPC Server, presumably through the Commissioning Application. Does that sound right?

I'll keep looking into it.

Darren.

 

Adam,

I have looked closely at the log file, and can see the requests to change the fan and damper values as you described. The request was received in the C-Bus OPC Server, then passed on to C-Gate. C-Gate responded that the change was successful, and the OPC Server wrote the new value back to the OPC clients. The communications between the OPC Server and C-Gate seems fine.

Given that the OPC client connected directly to the C-Bus OPC Server does display the correct values but Citect does not, it seems that there is a problem displaying the values in with Citect or the Citect project.

In the first diagram you sent, it seems to indicate that if a value is changed using Citect then the new value is shown briefly, but then changes back to bad once the change has been made. Is that correct?

Darren.

 

Hey Darren,

The OPC server begins recording again because the process CBusOPCServer.exe continues to run in the task manager, even after I have exited the monitoring application. I have to close this process from task manager before I can delete the log file and start a new one from scratch. I have another log for you, with me running a stopwatch to vaguely split each process up by time and hopefully make it easier.

Looking at the log, I have a few failed openings at the begining, but starts properly at 00:57.937 (3rd start). I also have still managed to record info after terminating the application at 4:23.0787. Basically, adding a minute to the time I have stated below, corresponds to the task I carried out. There are no "SendTextToPipe failed due to a closed pipe" errors between these times. Can I set up a similar log onthe Citect side? I don't want to change the .ini file without knowing exactly what I am doing!

1. Toolkit open, network open, citect running.
hh:mm:ss
00:00:00
2. Start monitoring application. wait to sync. - didn't take very long this time!
00:00:02
00:01:00
3. Load up points on OPC client to view
00:01:15
00:02:00
4. set points to "on" (1 or 255) using citect
00:02:30
00:03:00
5. set points to "off" (0) using toolkit
00:03:15
00:03:20
6. stop recording. close OPC monitoring application. close OPC monitoring process
00:03:30

You are exactly right suggesting that if a value is changed using Citect then the new value is shown briefly, (both in Citect and the OPC client viewing the Citect side) but then changes back to "bad" and "#COM" once the change has been made.

Does this problem have anything to to with the fact that CBus does not communicate the state it is in, but instead only a command to set the state. Is this command is not getting picked up by the Citect.OPC server? Does the issue look like it is between the "Clipsal.CBus_OPC_DA_Server" and the "Citect.OPC" server? As I understand, each system talks to its OPC server, and the servers sync with each other. Is this correct?

Kindest Regards,
Adam

Log File

 

One thing you can try is to use a different OPC client and confirm whether it is Citect or C-bus.

Matrikon's OPC explorer is free and will allow you to connect, view values and change values on the server. So you should be able to see and change any group you like.

You should be able to see if the C-bus OPC server is putting out a bad value or not.

I thought Citect had a driver for C-bus already? Maybe its not a driver for the product you are using.

How old is the CNI? I think there was a firmware update a few years back that made things work better (or was that the PCI?)

It could be a DCOM issue - but I suspect not as the OPC Client to server was working before across different nodes with the PCI.

Mick

 

Hi Adam,

You seem to have a mistaken understanding of the CBusOPCServer.exe process. It is a proper Windows service called "C-Bus OPC Server", and it should automatically start when Windows starts. The Monitoring Application is a separate program, which happens to have the ability to start/stop and receive status updates from the service. The Commissioning Application can also start and stop the service.

So, when you close the Monitoring Application you should not expect the service to stop. Instead, choose the Stop option in the Monitoring Application.

There are plenty of other ways to start and stop the service, including using the Commissioning Application and Windows Control Panel > Administration Tools > Services. It would be interesting if you could check the latter (Windows Services page) to see whether "C-Bus OPC Server" has been configured to automatically restart.

I have checked through the new log file, and it matches when you have said, and all seems to be working fine (apart from the pipe errors when the Monitoring Application is not running, but this doesn't affect the connection to Citect.

I'm sorry but I don't know how to enable logging on the Citect side. You may be able to search on Google about it, otherwise try contacting your Citect distributor, or the Citect customer support - http://www.citect.com/support

Although it is similar to your previous testing with the FactorySoft OPC client, Mick (znelbok) had a good suggestion to try the Matrikon OPC Explorer - http://www.matrikonopc.com/products/opc-desktop-tools/opc-explorer.aspx

It seems unlikely to be a problem between the Citect client and Citect OPC server, because the FactorySoft client has the same problem as the Citect client when connected to the Citect OPC server.

It seems unlikely to be a problem in the C-Bus OPC Server because the FactorySoft client works fine when connected to the C-Bus OPC Server.

I am confident that the problem is with the communication between the Citect OPC server and the C-Bus OPC Server. Interestingly, the Citect OPC server must also be an OPC client, in order to connect to the C-Bus OPC Server. I can see that you are using the latest version of C-Bus OPC Server. Are you using the latest Citect server?

Best regards,
Darren.

 

Hey Mick,

I was previously using the OPC client from the OPC foundation. It was very light, but didn't have much functionality. Just downloaded the one you stated. Its a much bigger application, and doesn't seem to have much more functionality, but it is easier to use, being able to see more than one server in the same window.

I have exactly the same conditions (all points in off/closed state):


I am using the driver that Schneider have supplied us after consultation about the project. This is the "Clipsal.CBus_OPC_DA_Server". The CNI is brand new, supplied to us for this project. Hardware is being installed on site now, and plan to install our Citect system on Monday 24th.

I had exactly the same problem when experimenting with comms using the PCI previously. Communication was fine from Citect to CBus, but nothing came back and "Bad" and "#COM" was constantly displayed. This sorted itself out rather randomly without and specific alterations being made. I think it is more confusing when the communications are half working!

Cheers,
Adam

 

Ignoring Citect as an OPC server, I'm assuming you are having problems displaying the values on a Citect page. Correct?

Have you double checked the Citect configuration is correct? (i.e. not set a write only or something weird).

 

FIXED!

Following Richo's final lead I found this solution to a similar problem.

There had been no entry created in the citect.ini file referring to OPC.

C:\Documents and Settings\All Users\Application Data\Citect\CitectFacilities 7.10\Config > citect.ini

[OPC]
FailOnBadData=0
FailOnUncertain=0
GoOfflineForBadTag=0

Adding the above 4 lines cleared all the "#COM" errors, and the OPC clients state "good quality" instead of "BAD". Communications now work BOTH ways, and Citect updates when CBus values are changed by CBus/CGate etc.



I don't know why, if this appears to be required, it is not automatically created when you run whichever wizard it was where OPC was selected as the protocol. (I had definitely run through this at one stage). Neither is this stated anywhere in the OPC driver help, or the Citect help files.

I'm going to test a little bit now and i'll get back to let you know what happened...

Can anyone explain why these lines in the .ini file are required?

Also, thank you all so much for your help!
Kindest regards,
Adam

 

That is great news, Adam! Let us know how your testing goes.

Thanks to Richo for putting Adam on the right track!

Regards,
Darren.

 

Looking at the names of those flags it is possible that if any tag has a issue, then it fails everything. I would check to see if there is any tags not OK (e.g. unable to be synced) configured in the OPC server.

 

sorry! I've just sent almost exactly the same post because I thought I had failed to post and lost the original success post! didn't realise we were on two pages now...fried!

 

haha no worries... I was tricked by that for a while, too!

I'm glad you have been able to find a solution to that strange problem.

All the best,
Darren.

 

Have a look at he help file, it explains a lot about the ini file and the specific lines that can be added. I am on holidays at the moment so I can't look them up for you or ask my off-sider who does the Citect stuff for me. We use OPC with Citect to other systems (not to C-bus), but could easily set one up if required for testing (assuming the C-Bus OPC server had a trial period)

Good news that you have it working.

Mick

 

It has a "commissioning" mode which doesn't require a licence. Otherwise the normal "production" mode recognises a number of Citect dongles (USB) and treats them as valid licences. I can look up more details on the specific dongles that are supported, if we need to help Adam out further.

Darren.

 

Done some testing and all is still working great. Thank you all!

FailOnBadData was the key parameter. The default value for this is 1:
"FailOnBadData=1 - If the OPC_QUALITY status for data from a tag is BAD, the driver reports a severity error and displays #COM on all tags of the read block."

setting to 0:
"FailOnBadData=0 - If the OPC_QUALITY status for data from a tag is BAD, the driver returns the last known value, and reports no error."

Hopefully not taking this too far, but why is the data back from CBus classed as being "BAD" data? Why does this classification prevent any attempt to communicate back to Citect?

Our system is going out into quite a big site. Our BACnet driver (talking to ALC) requires Citect and the ALC controller to be on the same subnet. Is anyone aware of a similar constraint for the OPC driver between Citect and CBus? Flicking through the help file now for some info...

Cheers,
Adam

 

This is most likely because you network hasn't synced, or if you are using groups that don't exist in output units. If either of these cases exist the Monitor tool should have messages in it about this. It is also covered in the help.

 

I find it strange that the Citect client thinks they are bad, considering the screenshots from the Matrikon client shows the values are good quality. I expect that during startup the values would be bad quality, but from what I could see in the logs they would all have changed to good quality. It is rather strange. As Richo said, check the Monitoring Application to see if any errors are displayed. Having said that, I didn't see any such errors in the logs you've already posted.

btw another way of detecting network problems is to look at the tags under System.Network Condition. They have a boolean for each network to indicate whether the network is considered good or bad.