Checking Smart Mode

You have two choices:

1. Always set the modes. THIS IS PREFERRED.

2. find the current mode and then change it if you need to.

The best way to go is to set the PCI into the modes you want EVERY time you connect to it. ie, every time your controller starts up, or every time it detects (if it does such a thing) that it has been connected to a PCI.

By sending the string ~~~ you force the PCI into BASIC mode. From there, the commands you need to use to set the modes are all described in the document "Cbus Interface Requirements".

 

Ok, its not clear...

Do you disconnect your system from the PCI, run Toolkit, and then reconnect?

Or does your system act as some kind of magical "pass-thru" on-sending commands to the PCI.

If the former: a simple system that we use is to periodically poll the PCI - we do it by reading the cbus network voltage. If we don't get an answer to the poll then we know the PCI is not connected any more. In that case we know that when we do a poll and find the PCI has come back again, it's time for a re-initialise.

If the latter: this is more difficult, because when acting as a pass-thru you need to send everything on to the PCI. But... you need to know you have something to send on. We have also done this by detecting that an RS-232 device is plugged in, which means the controller gives up sending its own commands to the PCI, and only sends the pass-thru commands. So, when the serial device is removed, the controller can re-initialise the PCI. In this case, DO NOT try and interleave controller commands with pass-thru commands (from toolkit, or anything else for that matter).


HTH

 

OK, I think I'm beginning to understand.

When using a device such as a controller, and passing commands through from something else (such as Toolkit), it is very important to remember that commands must never be interleaved to a single PCI (or CNI) from several sources.

This means that when toolkit makes its connection, your software MUST detect that and back off.

If your software does not back off, then there exists the possibility that commands sent by Toolkit will have answers coming back that your software does not understand, and there is the possibility that your software will send commands for which the answer is unexpected, leading to C-Gate / Toolkit having a large cow.

So, first things first: you need to detect that a Toolkit (or other device) session has started.

One of the simplest ways to do this is to look for "~" coming in from whatever source you have. If you see that it means there is an external device session starting and you need to enter pass-thru mode. From that time until the session is torn down you must not send your own commands to the PCI.

The second problem you have is to detect that the external connection is no longer needed. Toolkit, and other things, do not sending anything to anywhere to say "I'm all done now", so you have to do this by other means.

There are two methods:

For an RS-232 interface (something plugged into your RS-232 port, should you have one) - most RS-232 interface IC's have a "detect" output that tells if an RS-232 device is connected. You can feed that signal into your controller - when you detect that the RS-232 connector has been pulled out you can exit the pass-thru mode.

It sounds like this is not applicable to you because you are using ethernet / CNI emulation.

In that case its a lot more difficult. You need to detect that the TCP socket connection between C-Gate / Toolkit and your software (which is pretending to be a CNI) has been closed. When the socket is closed it indicates that Toolkit is not present any more.

So...

My recommendation is still to check the state of what is connected to you, and flip an internal mode accordingly.

When you exit the pass-thru mode, go back and re-initialise everything.

This approach is 100% fool-proof.

Anything that relies on a guess (for example: Its OK, my controller will be quiet for a while to let Toolkit traffic go through, and then every now and again I'll send a command to the PCI to check blah blah blah) is not going to be robust.

The point here:

You should not ever need to interrogate the PCI to find out what state it is in, because your software should be the "state master". your software should know what state the connection to cbus via the PCI is in, because your software is in charge and figuring these things out as it goes along.

If you don't do it this way, it will break. Sooner or later, but eventually it will break.

If this is still not clear, then it might be time for you to give us a phone call so we can discuss - we might still be at cross-purposes.