Automation in Motion Blog created by Domedia to share experiences about automation products and audiovisual integration.

17 March 2009

[lang_fr]Crestron sort un streamer vidéo PoE[/lang_fr][lang_en]Crestron releases PoE video streamer[/lang_en]

CEN-NVS100

CEN-NVS100

[lang_en]Crestron releases a network video streamer for use with its important range of touchpanels MJPG compatible. The CEN-NVS100 will allow you to display in these touchpanels video feedback from a remote camera easily through the network. The streamer is self-powered throught the PoE Ethernet connection so no need for local power supply. It accepts video composite signal (Either NTSC or PAL) and streams it either in MJPG or MPEG4 format for more compatibility. You can now easily monitor on your Crestron touchapenls remote door entry cameras, nursery or any video feed.

Most recent touchpanels compatible with signal from the streamer includes TPMC-8L, TMPC-8X, and TPMC-4XG.

Text and time can be overlayed on video signal, and privacy masking to avoid video view of private part of image. Up to three motion detection windows can be defined, enabling automated events in response to movement within specific onscreen areas. Events can also be triggered when a loss of signal is detected.

It can also control a pan/tilt/zoom camera via RS-485.

P-S: Audio connectors you can see on pictures are not usable for now (future functions !).[/lang_en]

[lang_fr]Crestron sort un streamer vidéo sur réseau compatible avec sa large gamme de panels supportant le format MJPG. Le CEN-NVS100 vous permet d’afficher dans ces écrans tactiles un retour vidéo d’une caméra distante via le réseau. Le streamer est auto-alimenté via sa connexion Ethernet compatible PoE évitant ainsi toute nécessité d’une alimentation locale. Il est compatible avec les signaux vidéo composite au format NTSC ou PAL et le streame au format  MJPG ou MPEG4 pour plus de compatibilités. Vous pouvez désormais aisément surveiller sur votre écran tactile Crestron les caméras distantes de la porte d’entrée, ou les caméras dans la chambre de bébé ou toute autre source vidéo.

Les écrans tactiles les plus récents compatibles avec ce streamer sont par exemple le TPMC-8L, TMPC-8X, et TPMC-4XG.

Un texte et l’heure peuvent être ajoutés en surimpression sur le signal vidéo, et le masquage privatif est possible pour éviter l’affichage d’une partie de l’image. Jusqu’à trois zones de détection de mouvement peuvent être paramétrées, pour déclencher des évènements automatiques en réponse à des mouvements dans des zones bien définies. Des évènements peuvent aussi être déclenchés sur la perte du signal vidéo.

Un port RS-485 permet aussi le contrôle local du mouvement de la caméra.

P-S: Les connecteurs audio visibles sur les photos ne sont pas utilisés actuellement (fonctionnalité future !).[/lang_fr]

16 March 2008

[lang_en]Easy Modbus interface with HVAC system of Sauter :)[/lang_en][lang_fr]Interfaçage Modbus aisé avec une régul. de clim Sauter[/lang_fr]

Filed under: AMX — Tags: , , , , , , , , , , , , — vincen @ 9:24 am

[lang_en]So today I went on site for interfacing a NetLinx AMX system with Sauter HVAC system. The HVAC system is interfaced through a PC that translates internal bus to more regular Modbus/Jbus protocol.

Modbus is a pretty simple protocol but its implementation is not so simple due to three facts:

  1. It uses a pretty complex system to calculate a mandatory checksum at end of each message. But with help of a friend Jon, and also piece of code made by Crestron for their Modbus module, I was able to automate creation of Modbus messages in my NetLinx program. Here is result for exemple for a read command:
  2. STACK_VAR
    CHAR TEMP[6]
    CHAR INTERRO_A_ENVOYER[8]
    LONG TEMP_1
    LONG XFLG
    LONG I
    LONG J
    LONG CRC
    {
    TEMP = “1,3,0,((ETAPE-1)*4),0,2”
    CRC = $FFFF
    FOR(I=1;I<7;I++)
    {
    TEMP_1 = TEMP[I]
    FOR(J=1;J<9;J++)
    {
    XFLG = (CRC^TEMP_1) & $0001
    CRC = CRC >> 1
    IF(XFLG<>0)
    {
    CRC = CRC ^ $A001
    }
    TEMP_1 = TEMP_1 / 2
    }
    }
    I = CRC / 256
    J = CRC – (I*256)
    INTERRO_A_ENVOYER = “TEMP,J,I”
    SEND_STRING dvCLIM,INTERRO_A_ENVOYER
    }

    That sample computes automatically checksum for a read message of two bytes :)

  3. Second problem is for answer you get back from HVAC as temperature value is coded with IEEE system. I looked at it on internet but it looks pretty complex to encode, so for now I just do a comparison between know values and it allows me to get correct value, at price of extra comparison work but it functions perfect :) If someone already did a piece of code in NetLinx to encode/decode IEEE value, I’m interested in !
  4. Last point very important with Modbus protocol is that it doesn’t speak by itself :( So each time you want to know something you have to issue a read command. So best way is to use a timeline you run in background that continuously asks values at system so you keep always value up to date :)

Hope it helped you, and feel free to ask questions you might have in comments ![/lang_en]

[lang_fr]Je me suis donc rendu aujourd’hui sur site pour la mise en route de l’interfaçage d’un système NetLinx AMX avec une régulation de climatisation fabriquée par Sauter. La clim. Sauter est équipé d’un ordinateur de type PC qui sert de passerelle entre le bus interne du système Sauter et le protocole à la norme Modbus/Jbus.

Modbus est un protocole relativement simple mais son implémentation n’est pas si simple pour trois raisons:

  1. Le protocole utilise un système plutôt complexe de calcul du checksum qui est obligatoire à la fin de chaque message transmis. Mais avec l’aide d’un ami, Jon, et avec l’aide également d’un bout de code fait par Crestron pour leur module Modbus, j’ai réussi à automatiser la construction des trames Modbus dans mon programme NetLinx. Voilà le résultat pour une commande de lecture:
  2. STACK_VAR
    CHAR TEMP[6]
    CHAR INTERRO_A_ENVOYER[8]
    LONG TEMP_1
    LONG XFLG
    LONG I
    LONG J
    LONG CRC
    {
    TEMP = “1,3,0,((ETAPE-1)*4),0,2”
    CRC = $FFFF
    FOR(I=1;I<7;I++)
    {
    TEMP_1 = TEMP[I]
    FOR(J=1;J<9;J++)
    {
    XFLG = (CRC^TEMP_1) & $0001
    CRC = CRC >> 1
    IF(XFLG<>0)
    {
    CRC = CRC ^ $A001
    }
    TEMP_1 = TEMP_1 / 2
    }
    }
    I = CRC / 256
    J = CRC – (I*256)
    INTERRO_A_ENVOYER = “TEMP,J,I”
    SEND_STRING dvCLIM,INTERRO_A_ENVOYER
    }

    Ce bout de code calcule automatiquement le checksum pour un message d’interrogation de deux octets :)

  3. Le deuxième problème est la lecture de la réponse obtenue du système de clim car les valeurs sont codées au format IEEE. Je me suis renseigné sur Internet mais ce système a l’air plutôt complexe pour l’encodage, donc pour le moment, j’ai réalisé un test en dur dans mon programme avec des valeurs connues pour savoir par approximation la valeur retournée par la clim. Cela nécessite un traitement un peu fastidieux mais ça fonctionne parfaitement :) Si quelqu’un a déja fait un bout de code en NetLinx pour encoder/décoder des valeurs IEEE, je suis intéressé !
  4. Le dernier point très inportant avec le protocole Modbus est qu’il ne parle pas par lui-même :( Donc chaque fois que vous voulez savoir quelque chose vous devez émettre une commande de lecture. Donc la meilleure façon de travailler est de faire tourner une timeline en tâche de fond qui périodiquement interroge les valeurs du système de clim afin de garder l’AMX synchrone avec le système de clim :)

En espérant que cela vous ait aidé, et n’hésitez pas à poser des questions dans les commentaires si besoin est ![/lang_fr]

Powered by WordPress