Phantom groups through C-gate

Is there a way to make C-Gate auto-create phantom groups when it sees them requested or changed via PC software (specifically Citect therefore using the CI commands)?

I can see how to make C-Gate create them automatically when it sees them from the network, but not from the PC.

The specific case: I need the Citect application to communicate with a touch screen. If I click a button on the touch screen which changes a group address (which is used nowhere else on the network), C-gate adds it as a phantom group and I can read it from SCADA. However, if I try to read/write it from SCADA before the touch screen makes C-Gate aware of it I get comms errors.

I can manually work around this by creating the phantom groups at the commandline, but this needs doing after every PC (or C-Gate) restart and I can't really have the client running command sessions!

(Using C-gate as supplied with Toolkit 1.5.3 or thereabouts.)

 

You should just be able to create the groups with Toolkit and all should work fine.

 

I think you misunderstood the question Richo...

 

In what way? If the group is pre-created via Toolkit it will be persistant and the problem of having ot redo it on restart won't exist.

 

It sounds like SCADA can NOT create the phantom GA's. It seems that he is polling a C-Bus network using this 3rd party device.

What I think he is trying to say is the comms is one-way, and he would like it two-way.

Creating the group addresses manually does not seem like the idea solution in this case??? For what reason I don't know.

Maybe More-Solutions could expand on this a little more to make it a little clearer for you...

 

I think you MIGHT be partially correct.. (wonders will never cease hey? ) Creating the groups manually in Toolkit probably wont assist.

The model C-Gate has of the Physical Network only contains groups that its seen existing on Output or Input units on the Bus (when it scanned).. You can see this model by executing a "TREE" command for example..

The database model that you create through Toolkit is essentially a seperate view of the universe from the model CGate has dynamically built itself of physical network.

If C-Gate sees activity on the bus for a Group that it didnt "detect" during a scan then it'll create a "phantom" group and match up the tag info from the database if the Group exists in the database.. but the interworking between the physical model and the database model pretty much stops there..

Citect applications really only work with the Physical Model of the scanned Network, and if there's groups programmed on Touch Screens that dont exist on Standard C-Bus Units and on which Network Activity only infrequently occurs then the problem described by "more-solutions" will happen.. Its possibly a defect that CGate doesnt create these when it seems them access from the "PC" as opposed to the Network.

I'm not really familiar with creating/working with Phantom Groups (The Groups that Walk).. It would seem prudent for the Citect Application to create the phantom groups when it starts using the NEW command with the "phantom" switch on it... I havent checked this against CGate 2.x, thats how it was done in 1.5..

 

As described above, creating the groups in the project doesn't help.

The vast majority of the groups used by SCADA are used by physical units (this application has 3000+ groups across 30+ networks), its just the handful (about 12) used only by the touch screens that I have a problem with.

Creating the groups via a commandline ("new group 200 phantom" from memory but I don't have the docs to hand and that might be rubbish) solves the problem but isn't persistent across C-gate restarts. Citect does not provide a simple mechanism to send the commands automatically, although its not impossible and I have written some code to do it. It would be nice if this coule be done at the C-gate end though.

If I were to suggest a solution (maybe I'm the only one with the problem so it doesn't matter!) then it would be one of these four:
- Allow 3rd party applications accessing groups through C-gate to create phantom groups in the same way that C-Bus units accessing them does, and as suggested elsewhere in this thread.
- Have the scan of a network which contains a touch screen reveal to C-Gate the groups used by the touch screen, and therefore not treat them as phantom groups at all. This would probably be a good idea as it would prevent those group addresses incorrectly being assumed by C-gate to be unused, but is probably hard to actually achieve.
- Have a mechanism to create phantom groups within C-gate (eg a phantom.txt file)
- Have a mechanism for C-Gate to run a script automatically on startup, which I could use for this or any other purpose I like. (I think this might be useful functionality anyway.) It might need a way to wait until networks have sync'd though, I'm not sure whether creating phantom groups the instant C-Gate starts would work?

 

I suspect the solution is more to make the Database Model of a Network and the Physical Model slightly more intertwined..

 

more-solutions

I have a solution from the old Minder days. If you have a dozen or so GA's in touch screens etc which don't exist in output units etc a quick fix is to put the GA's of interest into the logic blocks of output units then confirm there are not logic boxes ticked. This will mean whenever C-Gate re models a network these groups will be included in the network model. Better to use logic blocks instead of spare channels just in case spare channels get used in the future. Make sure you do this in output units only, not input units.

It's a bit of a work around but a good reliable and fuss free solution none the less...

 

I hadn't thought about using unused logic addresses, but I had considered using unused relay channels.

The more I think about this the more I'm not sure I would want C-Gate to automatically add new groups indiscrimately whenever it sees them from SCADA; at present, where we have a network fault and "lose" half the units on a network I get errors when I try to read from/write to them, but that wouldn't be the case if they were just auto-created as phantom groups. On the other hand I do need the ability to autocreate phantom groups which should exist (or have C-gate pick them up from the touch screens). My existing Cicode solutions will do for now, though.

 

back to old day... CGate 1.5 supports "Startup Network Files"
i wonder why this feature has not been backward-compatible !!!

I have the same problem and use "Simple Is The Best" method by returning to CGate 1.5 and it does work pretty much perfect for integrating 3rd party system requires a fake CBus output unit.

attached herewith cutting from CGate 1.5 User Guide, just add something like this to your startup network files (filename is C:\Clipsal\C-Gate\net\254):

.
.
new phantom 254/56/100 0
new phantom 254/56/101 0
.
.


===========================================
10.8 Network Startup Files
There is a network startup file for each network that is opened. Network startup files are contained in the net directory off the C-Gate base directory. This directory will normally be called C:\Clipsal\C-Gate\net for a standard installation. The network startup file is named the same as the network, so the startup file for network 1 is named 1. Note, this filename has no extension added to it, the filename is exactly the same as the network name.

A network startup file contains a number of commands, particularly the new command to define groups and units.

To define a new group 1 in the lighting application on network 3, use the command:

new group 3/56/1

which would define the group so it could be used in a C-Group definition.

To define units, you need to know the unit type. Common unit types are shown in the table, or they can be retrieved from any unit by using the get <address> type command from a C-Gate Command Interface.

-------------------------
C-Bus Unit - Unit type
-------------------------
4 Channel Dimmer - DIMMER4
4 Channel Relay - RELAY4
1 Channel Relay - RELAY1

Once the type has been determined, a new command can be added to the network startup file, such as:

new unit p/1/3 DIMMER4

This would define a 4 channel dimmer one network 1, unit 3. This would allow the four terminals, p/1/3/1, p1/3/2, p1/3/3 and p1/3/4 to be used in C-Group definitions.

 

I wonder if this feature does exist in 2.x, just isn't documented? I've found a few things that are there but not in the docs (like the Citect CI commands).

I'm not on site to try this myself, but I think I already knew about the 1.5 feature and I can't remember whether I tried it when i was there or not.

 

I agree that this is the only "true" solution, but I'm guessing that the reason that touch screen groups are ommitted was not an oversight but because getting that information isn't straightforward. I would hate to get stuck waiting for the "right" (but technically very difficult) solution when other workarounds (like a phantom group file or startup script) might solve the problem more quickly. Given your (valid) concerns I think that a phantom.txt file would be least ideal; startup script functionality would be a useful addition (and one which was available previously, it seems) allowing the end user to break the physical model to work around a problem, without formally breaking that model within C-Gate.

This argument would be more compelling if I could think of other good reasions why a startup script would be a good idea, but right now none are coming to me....

 

Is there any reason why you have not moved to C-Gate v2.x
It is a different beast, but is has come a long long way.
The phantom groups issue is automatically accommodated in v2

 

We are using 2.x (2.6.0), which is where I'm having the problem. How is it accommodated in 2.x?

I do like 2.x much better than 1.5, maybe I've just had long enough to get used to it now.

 

I decided to go and read all the posts properly. I was referring to C-Gate auto creating phantom groups when it saw messages/groups on the bus. I now see this is no help for you. Interesting how C-Gate does not do this for PC originating messages ???? Where C-Gate auto creates GA's based on messages from the bus, I am aware of a possible issue/fault where the group is created in the first instance and only on the second instance of the new group being transmitted is the group and new level added to the model. Not sure if this has been fixed ???

Earlier I mentioned parking the dozen or so GA's in spare logic blocks of output units. The other benefit of this "workaround" is your values will be kept accurate by the C-Bus MMI process.

 

This is the only work around I'm aware of as well

 

The strategy I'm using at the moment using a script in the SCADA to create phantom groups works well enough for me for the time being, so I'll keep it that way. I don't like the idea of using unused channels as they have a habit (on this job anyway) of becoming used in the future.

We could perhaps justify the cost of a dedicated spare relay unit or two but the phantom groups script is still cheaper

The only downside is that if C-gate is restarted without the SCADA then we get a problem, but realistically I can't see a situation when that is likely to happen at this site.

 

Hi Mark,

You can actually populate the logic section in the output units with the phantom GA's and then remove the tick so it will not control any channels.