PCI Transmission Guarantee?

Discussion in 'C-Bus Wired Hardware' started by PGOLD, Nov 11, 2009.

  1. PGOLD

    PGOLD

    Joined:
    Nov 10, 2009
    Messages:
    22
    Likes Received:
    0
    Location:
    QLD Australia
    Hi

    I have a few questions on PCI transmission commands?

    (a) When I send a application command or response through the PCI interface and I do not recieve the "!" character response (ie all is OK) does that guarantee that my transmission has been sent onto the C-BUS network?

    (b) Following from the above - when I set the PCI to monitor my particular application number by setting parameter 21 or parameter 22 -- does that guarantee that the PCI will always recieve the application messages that have been transmitted onto the bus from (a)?

    Somewhere in the doc's I have read that the C-Bus protocol either guarantee's that ALL or NONE units on the network recieves the message correctly ? - I don't quite understand what that means - could someone explain this?


    thanks Pete
     
    PGOLD, Nov 11, 2009
    #1
  2. PGOLD

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,397
    Likes Received:
    26
    Location:
    Adelaide, South Australia
    I strongly recommend you use the lower-case-letter at the end of each string you send to the PCI. And then, if you don't get back the character indicating all OK, then it means its NOT OK. (I think the all OK character was a dot: "."). You can't make any assumptions. If it comes back with nothing, or not-a-dot, then something is wrong.

    Yes. If you are monitoring then you see everything.

    It means what it says. If something can be sent, then all devices will receive it. If it can't be sent, then nothing receives it.

    thanks Pete[/QUOTE]
     
    ashleigh, Nov 11, 2009
    #2
  3. PGOLD

    PGOLD

    Joined:
    Nov 10, 2009
    Messages:
    22
    Likes Received:
    0
    Location:
    QLD Australia
    thnks Ashleigh

    One final (i hope) question on this topic - can't seem to find answers in docs

    The PCI I think will try to send the command message immediately if the bus is available and I think will re-try to send the message up to three times ?

    (a) is this correct and will then return the "!" response ?

    (b) How long does the PCI wait between re-tries - so I can get an idea of how long I should wait for a response from the PCI that the message has been sent?

    (c) How long does it take for the PCI firmware to reset itself after a cbus power failure (e.g. the C-BUS plug is remove)

    (d) Once PCI sends out its Power Up sequence is it immediately ready to accept a new command - I have noticed sometimes it doesn't?

    thanks again
     
    PGOLD, Nov 11, 2009
    #3
  4. PGOLD

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,397
    Likes Received:
    26
    Location:
    Adelaide, South Australia
    The PCI will send immediately if the bus is available. If the bus is not available it will wait until the bus becomes available using the collision detection and resolution system. This is not something you can predict because you don't know what the other bus traffic will be. But the PCI DOES bump its transmission priority for trying to transmit if it does not get a look in after a while.

    If the PCI tries (I think its 3 times, it might be more) and FAILS to transmit you will get the ! response.

    The period between re-tries is short, and depends on the other bus traffic. The better approach is to say "how long should I wait for a transaction to complete" - where complete might mean that it succeeds or fails but at least you get told something. The answer here is 2 to 4 SECONDS. In practice it will always be much less if things are working OK but you want to trap the wierd-loopy-gaga-abnormal cases so you use a timeout to suit.

    The PCI has a nominal start-up time of 5 seconds after application of power, like other cbus units.

    When the PCI sends its power up sequence out, it is ready to accept commands. However, other devices on the bus may still be in a marginal condition. For example if they all have 5 seconds, there will be small delays (milliseconds or 10's of milliseconds) during which some devices won't be powered up still. So sending commands right after power up is probably not a good idea. I'd suggest a delay of 1-2 seconds after the PCI indicates a power up event, after this is is safe to assume that all devices on the bus that have power are in fact powered up and ready to go.
     
    ashleigh, Nov 11, 2009
    #4
  5. PGOLD

    Don

    Joined:
    Aug 4, 2004
    Messages:
    429
    Likes Received:
    0
    Location:
    Townsville, Australia
    If the PC interface can't accept any more characters because its input buffer is full, you will get the '!' character. if you get this, you KNOW that some characters have been lost. If you are sending one message at a time, it is best to clear the buffer by sending a '?' symbol, and starting over. If you are making use of the double-buffering in the PC Interface, the lost characters will apply to the last message sent. Of course, if you don't react to the '!' symbol immediately, more data could be lost.

    Managing the input buffer overflow condition is not sufficient to ensure that all messages get transmitted on the bus. To do this, as Ashleigh suggests, you should use the lower case alpha character on each message to enable message transmission confirmation.

    If you see a '.' return, then all is well - your message has been successfully transmitted on the bus, and the (all) communication partner(s) acknowledged it.

    If you see a '#', this means that the PC Interface has accepted a message, the bus was operating correctly, and it attempted to transmit but did not get a simple acknowledgement. The PC interface will normally retry again after a delay of 4ms unless higher priority network traffic exists, and will continue to retry a total of three times maximum. If every attempt fails, you will see the '#' character.
    If any transmission attempt was negatively acknowledged because a communication partner was busy (two commands one after the other to store data into EEPROM can cause this because the EEPROM servicing takes time), the PC Interface will hold off for 100ms between retries.
    In addition to these delays, the PC Interface has to wait for access to the bus each time it attempts to transmit. On a typical bus, this will normally be achieved within 200ms, but on a busy network, it could take over 500ms each time, so the delay between sending a message to a PC Interface and receiving the confirm response ('.' or '#'), can vary from 40ms (fastest successful transmission), to over 2 seconds. 4 seconds is a good choice for a maximum timeout here.

    If you see a '%' character, then the C-Bus network clock pulse has not been detected by the PC Interface or the clock pulse has been lost during the transmission attempt. This may occur immediately after power-up, and persist for approximately 10 seconds on a well-designed network with one or two redundant clock generators. If a network has not been configured carefully, there could be many capable clock generators, and it can take tens of minutes for clock resolution to occur immediately after power-up.

    Hopefully this explains your observations, and should help you to manage how to make best use of the PC Interface
     
    Don, Nov 11, 2009
    #5
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Similar Threads

  1. How to run C-Gate under Linux with PCI

  2. Version 4 PCI

  3. Important: Retries and Negative acks from a C-Bus PCI or SIM

  4. Minder PCI - Not compatible with Toolkit

  5. RS232/RJ45 Port on the PCI

  6. Poll: Wireless PCI

  7. PCI Communication with Cbus problem

  8. IR transmission over IP (Ethernet) networks

Loading...