One for the brains trust (C-Gate & OPC)

Hi guys,

Looking to assist a chap who is having problems in a commercial project using OPC server.

Commercial building about 10 networks all connected via a CNI.
Running C-Gate and OPC server 1.1.0
No S+ or Homegate on the project just C-Gate.

Intermittently networks are going into error state - so I have some questions regarding how C-Gate behaves following OPC input for a network in error. (I appreciate there is much to think about re why the networks are going into error state - it is either Ethernet or C-Bus network comms problems - that is another issue)

Does C-Gate accept GA changes to its object model from the OPC server for a network that is in error state ?

If it does, when the network state returns to OK does it set the correct state of the changed GA value in the network.

Now I am thinking of changing the setup to create a distinguishable demarcation line between the C-Bus project and the third party system that is using the OPC server.

I am thinking of introducing (for want of a better description) a "dummy network" for the OPC server to send messages to, then introducing Schedule +, to use these as triggers to do the real messaging to the networks. This way the third party system and the OPC server are not expected to do any real communication into the actual 10 networks. S+ will be doing all the real comms, it can have time schedules etc and can be overridden by the third party system.

Now
If we add a new network to the project (OPC message receiving network) and we make it a serial connection off the SP/Cgate machine do we need an actual working network for C-Gate to sync to etc and receive OPC changes ? - ties back to earlier question.

Is the OPC GA list derived from the C-Gate model or the project.xml ?

Does C-Gate see / and use a C-Bus MMI from a serial connected network.

Even if the above is no - if you had a very small network - say, 12 channel relay and a PCI, and the means of sending various group address values to the network (lets say 50 GA for this net) would this network MMI contain values for all GA's used or would it only contain values for the GA's programmed into the 12 channel relay unit ?

From memory I would also need an input unit to instigate the MMI request ??

Is there a better way you can think of to create a firm demarcation line between the two systems so, if there is comms issues with a C-Bus network or the Ethernet connecting it, the third party system can be sending its commands to a repository, there will be a record / log of the third party messages and there is a clear understanding that the problem lies in the C-Bus install ????

Thanks

PS - I am a bit lazy with the scroll button, just realised this post probably should have gone into the OPC section. Also just read that they should really be using OPC version 1.1.1

 

OPC Server Questions

Hi there,

As you noticed at the end of your question, the customer should be using C-Bus OPC Server 1.1.1. Also, keep an eye on the forums for a newer version which should available soon.

I assume here that "GA changes" are lighting group level changes, because I am not familiar with that terminology.

I have done some testing by disconnecting the serial cable from the PCI, and have observed that there is some delay after removing the serial cable before C-Gate (and therefore OPC) reports the network is in error. (NB: in case you are not aware, OPC exposes the network states through the System.Network Condition variables.)

After disconnecting the cable but before the network was reported as being in error state, I set a lighting group level through OPC. An OPC error "failed to write the value" was reported in the Monitoring Application.

Once the network was reported as being in error state, I set the lighting group level again through OPC, and observed that cgate received the command. After waiting for another "failed to write the value" OPC error, I reconnected the serial cable. Soon after, C-Gate noticed the connection was available again and sent the command to the C-Bus network, and the lighting level was set correctly. After about two minutes (this will vary depending on the units in the network) the network was reported as being OK again.

I suspect this is the behaviour you were hoping for, in terms of C-Gate remembering the levels set while a network is in error state and sending them when the network becomes available again.

--

In regards to a dummy network, if I understand you correcly then I don't believe it would work. I expect that C-Gate would expect to receive a response from the physical network before treating the command as successful. There may be work-arounds for this - such as the 12 channel relay as you discussed - but I am not familiar enough with the details myself to advise you on this.

One think I do know for sure is that OPC will report errors, because the missing network cannot be opened and synchronised.
However these could possibly be treated as warnings because the OPC Server will still pass on write-requests to C-Gate.

The lighting groups available through OPC are based on the project XML files, and selected via the Commissioning Application.

I am not personally able to advise you on ways to separate the systems. I have asked another developer to have a look at this question to see if they have anything to add.

Perhaps, however, enabling an appropriate level of logging in OPC and C-Gate will give enough accountability in this situation.

Best regards,
DarrenH.

 

Hi Darren,

Thanks for your tests and feedback, it has been very helpful.

For the record GA is Group Address and yes usually referenced to lighting application message / level.

MMI is a little discussed aspect of the C-Bus protocol under the hood, from memory it stands for Multipoint to Multipoint Instruction, again from memory is a 128 byte synchronization message per application address - someone will correct me if I am wrong (which I probably am),

Anyway your answers provide valuable insight as to what might the the correct way forward.

When we work out a solution I will post it here as a reference to OPC use in a typical commercial arrangement. The commercial bit is making sure if there is something broken in the chain we can very quickly work out where in the chain it is broke and therefore who's responsibility it is..

Thanks again.

 

Ahh - I was thinking of two MMI's in quick succession

Ashleigh - I think you have imagined the "interchange" bit, don't make me drag out my 14 year old C-Bus training manual..

 

I Call Your Bluff

OK Ashleigh

You may be immensely cleverererer than me, and you may have given me a big and sincere hug at that conference on Lindeman Island, but I have to call your bluff on this one...

Hopefully I have attached the image properly.

Note the version "95.1" eg 1995

Note the "Gerard Industries" at the top.

And you thought I was making it all up...

 

P.S

Your "original definition and design documents" had better go back before 1995.

That's 5 years before the Y2K doom and disaster date...

Over to you old mate

 

Where on Earth do you get "We wuz both wrong" ???

I produce a document where it is written a clear as the nose on your face and you produce some bodgey text that loosely references one instance of an acronym where the letters M, M and I are used.

You are going to have to come up with something more credible than that - old mate

 

I attended the meeting in Ballerup, Denmark on that fateful day in 1989 in which the name Multi-peer to Multi-peer Information PDU was first heard by Australian ears, so I feel that I have some authority in this matter.

Ashleigh wins.

We stopped calling it by that name long before 1994, and just referred to it as 'MMI' fo obvious reasons.

I guess when the sales and marketing people picked it up, they thought different words would suit better. Personally, it's not really important. I always try and avoid the issue and refer to it as a "Status Report"

Whatever you call it, it is an important part of C-Bus; it allows the connection between switch and load to be maintained over time, and makes C-Bus much more robust and reliable than other bus systems systems that don't have it.

 

Ashleigh started out with "MMI = Multipoint to multipoint interchange"

How do we get from "interchange", to Ashleigh wins ???

You guys are just ganging up against me