Anforderungssammlung CAN Hausbus mit PIC µC

[Timo E. (tien)]

Hallo Zusammen,

natürlich gibt es schon etliche Eigenbau Hausbussysteme. Trotzdem 
eröffne ich diesen Thread :-)

Es soll eine Ideen- und Lösungssammlung werden, aus der man sich frei 
bedienen kann. Es steht zunächst nicht die Zielsetzung dahinter EIN 
gemeinsammes System zu entwickeln. Viel mehr sind alle eingeladen 
Erfahrungen und Ideen einzubringen. Jeder darf sich dann an den 
Ergebnissen bedienen.

Die Idee die Anforderungen hier in einem eigenen Thread zu sammeln 
stammt aus folgendem Thread 
Beitrag "Dimmer für den Verteilerschrank mit Steuerinterface"

Grundanforderungen sind:

- CAN Bus
- PIC 18Fxxx µC
- CAN Bootloader

Dies ist gesetzt, alles weitere ist offen.

Erstes Ziel soll das Sammeln von Anforderungen für eine Basisplatine zur 
Busankopplung sein.


Grüße Timo

[Timo E. (tien)]

Na dann fang ich gleich mal an:

Ich stelle mir den Buskoppler folgendermassen vor:


Dimensionen/Mechanik:
---------------------
- klein, dass die Platine in eine Doppeltiefe UP Dose passt
- max zwei Layer, so dass Platinen auch selbst geätzt werden können 
(Prototypen)


OnBoard:
--------
- Schaltregler für min. 24Volt
- Schutzbeschaltung Versorgung und CAN gegen Überspannung und 
Fehlbeschaltung)
- Quarztakterzeugung
- LowCurrent LED zur einfachen Meldung von Betriebszuständen (eher für 
Debug Zwecke)
- ICSP Anschluss zur Programmierung in der Schaltung (eventl. auch nur 
Lötpunkte)
- CAN Tranceiver (Typ?)
- Bestückungsmöglichkeit für Abschluß R für CAN Bus
- EEProm optional bestückbar (?)


Pheripherie:
------------
- Erweiterungsfähig, d.h. so viel wie möglich µC Pins sollten auf 
Steckerleisten geführt sein, so dass man eine weitere Platine mit z.B. 
SSR Huckepack aufstecken kann.
- direkte Anschlussmöglichkeiten für Taster, so dass man für den Betrieb 
in UP Tastergruppen keine weitere HW benötigt
- direkte Anschlußmöglichkeiten für LEDs


Software:
---------
- Sprache: C (ich nutze PicC von MikroE)
- CAN Bootloader
- Eindeutige ID je Buskoppler
- Energiesparoptionen sollten von Anfang bedacht werden




Grüße Timo

[Max M. (maxmustermann)]

Timo E. schrieb:
> OnBoard:
> --------
> - Schaltregler für min. 24Volt
Das hab ich mir auch schon überlegt. Bin beim MAX5035 gelandet 
(http://datasheets.maxim-ic.com/en/ds/MAX5035.pdf).

> - CAN Tranceiver (Typ?)
Hier könnte ich den MCP2551 
(http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf) empfehlen. 
Habe mit diesem bisher gute Erfahrungen gemacht.

> - Bestückungsmöglichkeit für Abschluß R für CAN Bus
Bestückungsmöglichkeit reicht wahrscheinlich, sollte man ja nicht allzu 
oft ändern müssen. Auf meinen Evaluationboards hab ich dies jedoch mit 
einem Jumper realisiert.

> - EEProm optional bestückbar (?)
Finde ich sinnvol, jedoch könnte man auch den internen EEProm verwenden 
oder? Fallen mehr Daten an, dann könnte man einen I²C EEProm vorsehen.

> - Eindeutige ID je Buskoppler
Dies könnte man entweder im EEProm speichern oder via DIP-Switches oder 
Drehcodierer konfigurieren?

lg Max

[Timo E. (tien)]

>> - Schutzbeschaltung Versorgung und CAN gegen Überspannung und
>> Fehlbeschaltung)
> Das hab ich mir auch schon überlegt. Bin beim MAX5035 gelandet
> (http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf).

Schaut gut aus. Dein Link ist ausserdem falsch :-)
http://datasheets.maxim-ic.com/en/ds/MAX5035.pdf


>> - CAN Tranceiver (Typ?)
> Hier könnte ich den MCP2551
> (http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf) empfehlen.
> Habe mit diesem bisher gute Erfahrungen gemacht.

Den hab ich glaub ich auch im Einsatz, müßte ich mal schauen.

>> - EEProm optional bestückbar (?)
> Finde ich sinnvol, jedoch könnte man auch den internen EEProm verwenden
> oder? Fallen mehr Daten an, dann könnte man einen I²C EEProm vorsehen.

Im Normalfall sollte das interne EEPROM reichen. Die Frage ist ob es 
notwendig ist eine Bestückungsoption bereits auf der Basisplatine zu 
haben, benötigt halt kostbaren Platz

>> - Eindeutige ID je Buskoppler
> Dies könnte man entweder im EEProm speichern oder via DIP-Switches oder
> Drehcodierer konfigurieren?

Ich bin für die SW Lösung um Platz zu sparen. Das bedeutet dann halt, 
dass man jede Platine vor Inbetriebnahme individualisieren muss. Aber 
der Bootloader muss ja auch drauf. Irgendwie war ich der Meinung, der 
PIC hat auch ein paar Fuses für eine ID - muss ich mal nachlesen.


Was ich noch vergessen habe:
- Eine Bestückungsmöglichkeit für einen DS1820 1 Wire Temp sensor.
Wäre mir wichtig, da ich bei allen Modulen die Temperatur überwachen 
will.

Grüße Timo

[Max M. (maxmustermann)]

Timo E. schrieb:

> Schaut gut aus. Dein Link ist ausserdem falsch :-)
> http://datasheets.maxim-ic.com/en/ds/MAX5035.pdf
Sorry, habs kurz danach gemerkt und korrigiert. Copy-Paste Fehler.

>>> - Eindeutige ID je Buskoppler
>> Dies könnte man entweder im EEProm speichern oder via DIP-Switches oder
>> Drehcodierer konfigurieren?
>
> Ich bin für die SW Lösung um Platz zu sparen. Das bedeutet dann halt,
> dass man jede Platine vor Inbetriebnahme individualisieren muss. Aber
> der Bootloader muss ja auch drauf. Irgendwie war ich der Meinung, der
> PIC hat auch ein paar Fuses für eine ID - muss ich mal nachlesen.
Stimmt, der PIC hat einen 4Byte ID Memory, den man beim Programmieren 
festlegen kann.

> Was ich noch vergessen habe:
> - Eine Bestückungsmöglichkeit für einen DS1820 1 Wire Temp sensor.
> Wäre mir wichtig, da ich bei allen Modulen die Temperatur überwachen
> will.
Klingt gut! Dann kann man super die Raumtemperatur messen.

lg MAX

[Ein Gast (Gast)]

Übrigens,

wenn ihr den DS1820 auf jeden Fall bestückt, könnt ihr auch den als 
ID-Chip verwenden. Die DSxxxx haben alle schon eine eindeutige ID.

[Timo E. (tien)]

Stimmt, das wäre ein Alternative, danke für den Tipp!
Allerdings ist ein DS1820 auch nicht gerade ein Cent Artikel.

Ich werde ihn bestimmt bestücken, da ich den Temperaturgradienten 
überwachen will und dann ggf. den Strom abschalten will (LED Notlicht 
geht dann trotzdem) und Alarm geben will.

Aber eventl. will das nicht jeder machen. Daher würde ich die interne ID 
des PICs nehmen. Weiterer Vorteil: Man kann einen Knoten auch durch 
andere eine Hardware ersetzen, z.B. wenn mal eine Platine defekt ist. 
Durch das Programmieren der ID auf die gleich wie die defekte Platine 
kann die Platine komplett ersetzt werden, ohne das das System 
umkonfiguriert werden muss.

Das führt mich zu einer weiteren, aber eher zeitlich weiter entfernten 
Forderung:

- Beim Anschluss eines Knotens mit leerem EEPROM sollte dieser 
automatisch bei einem zentralen Massenspeicherknoten seine EEPROM Konfig 
abholen.

[Max M. (maxmustermann)]

Ein Gast schrieb:
> Übrigens,
>
> wenn ihr den DS1820 auf jeden Fall bestückt, könnt ihr auch den als
> ID-Chip verwenden. Die DSxxxx haben alle schon eine eindeutige ID.

Finde die Idee ansich auch gut um eine eindeutige ID zu bekommen. Jedoch 
fänd ich es besser wenn man die ID frei programmieren kann. So kann man 
dem ganzen Bus eine Struktur geben und diese in die ID kodieren. Glaube 
das die Adressierung und somit die Vergabe der IDs ein wichtiges Thema 
sein sollte. Man kann z.B. den Node-Type (Sensor, Aktor, Taster etc), 
einen Raumcode oder z.B. auch das Stockwerk in die ID kodieren. So 
könnte man Knoten zu Gruppen zusammenfassen.

gruß Max

[Wissender (Gast)]

...den Controller zu setzen wird dir nicht unbedingt helfen Mitstreiter 
zu finden. CAN ist OK; aber auf einen Controllertyp festlegen halte ich 
für keine gute Idee. Man kann das losgelöst davon tun, dann erhält man 
auch breites Feedback und erhält einen breiten, nicht spezifischen Pool 
mit Lösungsansätzen, die man dann wieder auf ein festes System umsetzen 
kann.

Das sind meine Gedanken dazu - überleg dir's.

Von einem der bereits seit 2 Jahren ein CAN-basierten Eigenbau-Hausbus 
am laufen hat!

[Max M. (maxmustermann)]

Wissender schrieb:
> ...den Controller zu setzen wird dir nicht unbedingt helfen Mitstreiter
> zu finden. CAN ist OK; aber auf einen Controllertyp festlegen halte ich
> für keine gute Idee. Man kann das losgelöst davon tun, dann erhält man
> auch breites Feedback und erhält einen breiten, nicht spezifischen Pool
> mit Lösungsansätzen, die man dann wieder auf ein festes System umsetzen
> kann.
>
> Das sind meine Gedanken dazu - überleg dir's.
>
> Von einem der bereits seit 2 Jahren ein CAN-basierten Eigenbau-Hausbus
> am laufen hat!

Stimmt, du hast recht! Der Controllertyp sollte keine Einschränkung für 
die Sammlung von Anforderungen und Ideen sein. Genausogut könnte man 
auch einen AVR + MCP2515 nehmen. Hoffe du fühlst dich durch dies nicht 
abgeschreckt und willst trotzdem deine Erfahrungen mit uns teilen, wäre 
sonst schade. Ich glaube diese Anforderung ist entstanden, da Timo und 
ich mit dem PIC18F und integriertem CAN bereits experimentieren. Deshalb 
war das für uns klar. Kann aber jeder machen wie er will :-)

Grüße Max

[helmut (Gast)]

Platine für Schalterdosen ist schon fertig, Steuerung in MikroeBasic 
(hättest du schon im Mikroeforum finden können),
auch mit 18B20:
helmutholm.de etwas runterscrollen.
Gruß Helmut

[Timo E. (tien)]

Hallo Wissender,

der PIC ist für mich persönlich gesetzt, da ich die dafür ein DevBoard 
und Compiler zu Hause habe (EasyPic5 + PicC von MikroE). Eigentlich habe 
ich AVRs programmiert und beruflich den TriCore, aber für den Hausbus 
erscheint mir der PIC ideal, da der CAN Controller integriert ist. Für 
die Anforderungssammlung ist das in weiten Bereichen aber egal. Wenn es 
dann um die Schaltung und ums Layout geht wird es dann schon 
spezifischer.

Aber ich nehme diese Einschränkung zurück, denoch werde ich meine Lösung 
PIC basiert machen.

AVR Lösungen gibt es ja bereits einigeim Netz, PIC basierte kenne ich 
bisher nur die von Helmut.


Grüße Timo

[Timo E. (tien)]

Hallo Helmut,

ich habe heute Deine Lösung in einem anderen Thread gefunden. Du bist 
tasächlich schon einige Schritte weiter. Ich habe es mir noch nicht 
komplett angeschaut, werde ich aber noch machen. Hast Du einen CAN 
Bootloader am laufen? Für mich ist das einer der wichtigsten Punkte 
bevor ich mit der Hardware anfange.

> Platine für Schalterdosen ist schon fertig, Steuerung in MikroeBasic
> (hättest du schon im Mikroeforum finden können),
> auch mit 18B20:
> helmutholm.de etwas runterscrollen.
> Gruß Helmut

Grüße Timo

[helmut (Gast)]

Bootlader sind auch schon da, wer ihn denn braucht.

http://mrmackey.no-ip.org/elektronik/ds30loader/index.php

Man muß sich in Mikroe C oder auch Basic mit dem Flash-Schreibbefehl 
auseinander setzen.

http://www.mikroe.com/forum/viewtopic.php?f=10&t=5038&p=27367&hilit=flashwrite#p27367

Meine Empfehlung:
Was soll der CAN-Bus-Knoten denn immer verschiedenes machen?
Die paar Male kann man ihn auch einfach per Prommer programmieren.
Wenn man 8 Bytes im Protokoll hat, viel Romspeicher, dann gehen auch 
fertige, per Befehlsbyte aufrufbare Progrämmchen ins ROM.

Ansonsten braucht man eigentlich ihm nur DIE NodeID geben, auf die er 
WIE arbeiten soll.
Zum Beispiel steht im ersten Byte die Befehlsverschlüsselung, dann die 
Parameter in ein bis 3 Byte, 'ne Checksumme ev. noch und gut ist.

Hier ist eine Anregung:
http://koervernet.de/joomla1.5/index.php?option=com_content&view=article&id=47&Itemid=65
ca in der Mitte der Seite.

Gruß Helmut

PS: ich poste nachher mal meine Umsetzung von dem Beispiel von Hugo

[helmut (Gast)]

Ein Code-Beispiel um auf dem CAN-Bus zu lauschen und es in einem 
grafischem Display anzuzeigen.
(Glaube sogar, dass es mit der Demoversion übersetzbar ist.)

D.h. es werden alle CAN-Bus-ID empfangen, also kein Filter gesetzt:


'####################################################################### 
##############
'                   in this File ist CANWrite LongInt of CAN_ID ok,
'                         the Display is now showing each data.
'####################################################################### 
#############

program Touch_UNI_Board_CAN_BUS_V1

' Declarations section
' fuer den CAN BUS:
dim aa, aa1, aa2,id,Can_Init_Flags, Can_Send_Flags, Can_Rcv_Flags as 
byte  ' can flags
    Rx_Data_Len as byte                             ' received data 
length in bytes
    RxTx_Data as byte[8]                            ' can rx/tx data 
buffer
    Msg_Rcvd as byte                                ' reception flag
    ID_1st, ID_2nd, Receiver as longint                       ' node IDs
Text as String[11]   ' brauche ich zum Text schreiben
Text1 as byte[11]
Textbyte as String[1]
' fuer das Display:
' Die GLCD-Port's sind nur auf meinem selbstgebauten Board so,  also 
ANPASSEN !!!
               'cs1, cs2, rs, rw, rst, en
'Glcd_Init(PORTB, 7,   6,  5,  4,   1,  0, PORTD)   'bei 
Helmuts_UNI_platine
'Glcd_Init(PORTB, 0, 1, 2, 3, 5, 4, PORTD) easy_pic5
dim GLCD_DataPort as byte at PORTD

dim  GLCD_CS1 as sbit at LATB7_bit
     GLCD_CS2 as sbit at LATB6_bit
     GLCD_RS  as sbit at LATB5_bit
     GLCD_RW  as sbit at LATB4_bit
     GLCD_RST as sbit at LATB1_bit
     GLCD_EN  as sbit at LATB0_bit

dim GLCD_CS1_Direction as sbit at TRISB7_bit
    GLCD_CS2_Direction as sbit at TRISB6_bit
    GLCD_RS_Direction  as sbit at TRISB5_bit
    GLCD_RW_Direction  as sbit at TRISB4_bit
    GLCD_RST_Direction as sbit at TRISB1_bit
    GLCD_EN_Direction  as sbit at TRISB0_bit

' Hauptprogramm initialisieren
main:
  PORTA  = 0x00
  TRISA  = 0x03
  ADCON1 = 0x06
  CMCON = 0x07      ' Compare Einstellung, boese Falle !!!
  TrisC.0=0         ' gehoert zur Display Beleuchtung
  PortC.0=1         ' Display Beleuchtung "Ein"

 Glcd_Init()                            ' Initialize Glcd
  Glcd_Fill(0)                        ' Clear Glcd
  Glcd_Set_Font(@font5x7, 5, 7, 32)       ' Change font
  Glcd_Write_Text("Hallo Helmut!", 5, 1, 1)         'sag Hallo 
erstmal....
  Can_Init_Flags = 0                                '
  Can_Send_Flags = 0                                ' clear flags
  Can_Rcv_Flags  = 0                                '
  aa    = 0 ' ist bei BasicPro CAN_Init_FLAGS
  aa1   = 0 ' ist bei BasicPro Can_Send_Flags
  aa2   = 0

  Can_Send_Flags=   _CAN_TX_PRIORITY_0 and           ' form value to be 
used
          _CAN_TX_STD_FRAME and            '     with CANSendMessage
          _CAN_TX_NO_RTR_FRAME

  Can_Init_Flags =   _CAN_CONFIG_SAMPLE_THRICE and     ' form value to 
be used
          _CAN_CONFIG_PHSEG2_PRG_ON and    '     with CANInitialize
          _CAN_CONFIG_STD_MSG and
          _CAN_CONFIG_DBL_BUFFER_ON and
          _CAN_CONFIG_VALID_STD_MSG and
          _CAN_CONFIG_LINE_FILTER_OFF ' CAN-Filter AUS  !!!!!

  ID_1st = 118
  ID_2nd = 150

  RxTx_Data[0] = 1'     PortC ' Kompletter Port mit 8 Bit in RxTx_Data 
Byte 0
  RxTx_Data[1] = 2
  RxTx_Data[2] = 4
  RxTx_Data[3] = 8
  RxTx_Data[4] = 16
  RxTx_Data[5] = 32
  RxTx_Data[6] = 64
  RxTx_Data[7] = 128
  'ID = -1
  ''CANInitialize( 1,4,3,3,1,aa)              ' initialize CAN  aus 
Piccy
  CANInitialize(1,4,3,3,1,Can_Init_Flags)                    ' 
Initialize CAN module auf 125kboud(4Mhz)
' CANSetOperationMode(CAN_MODE_CONFIG,True)'war 0xFF)                 ' 
set CONFIGURATION mode
' CANSetMask(CAN_MASK_B1,-1,CAN_CONFIG_XTD_MSG)            ' set all 
mask1 bits to ones
' CANSetMask(CAN_MASK_B2,-1,CAN_CONFIG_XTD_MSG)            ' set all 
mask2 bits to ones
' CANSetFilter(CAN_FILTER_B1_F1,3,CAN_CONFIG_XTD_MSG) ' aus alter 
VersionsHilfe
' CANSetFilter(CAN_FILTER_B2_F4,ID_2nd,CAN_CONFIG_XTD_MSG) ' set id of 
filter B2_F4 to 2nd node ID
' CANSetOperationMode(CAN_MODE_NORMAL,True) 'war 0xFF)                 ' 
set NORMAL mode

'###########################   Ich empfange jetzt alle ID`s 
'####################################
  CANWrite(ID_1st, RxTx_Data, 8, Can_Send_Flags)             ' send 
initial message
  Glcd_Write_Text("Hallo Helmut!", 5, 1, 1)                  'sag Hallo 
erstmal....
' ###################################   HAUPTSCHLEIFE 
###########################################
  while TRUE
  'ID_1st=(ID_1st)   ' Test

  delay_ms(1000)
       ' ist eine CAN-Bus-Mitteilung da?
      Msg_Rcvd = CANRead(Receiver, RxTx_Data , Rx_Data_Len, 
Can_Rcv_Flags)

       ' wenn ja, dann schicken wir was zurück......
     ' ich empfange jetzt alle CAN-ID`s
      if Msg_Rcvd  <> 0 then 
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 
'''''''''''
          Glcd_Write_Text("Empfangene CAN ID:", 5, 2, 1)
          LongintToStr(Receiver, Text)
          Glcd_Write_Text(Text, 1, 3, 1)
          Glcd_Write_Text("Erstes Datenbyte 0:", 5, 4, 1)
           ByteToStr(RxTx_Data[Rx_Data_Len-1], Textbyte)
                     Glcd_Write_Text(Textbyte, 1, 5, 1)
           ByteToStr(RxTx_Data[Rx_Data_Len-2], Textbyte)
                     Glcd_Write_Text(Textbyte, 27, 5, 1)
           ByteToStr(RxTx_Data[Rx_Data_Len-3], Textbyte)
                     Glcd_Write_Text(Textbyte, 47, 5, 1)
           ByteToStr(RxTx_Data[Rx_Data_Len-4], Textbyte)
                     Glcd_Write_Text(Textbyte, 74,5, 1)
           ByteToStr(RxTx_Data[Rx_Data_Len-5], Textbyte)
                     Glcd_Write_Text(Textbyte, 1, 6, 1)
           ByteToStr(RxTx_Data[Rx_Data_Len-6], Textbyte)
                     Glcd_Write_Text(Textbyte, 27, 6, 1)
           ByteToStr(RxTx_Data[Rx_Data_Len-7], Textbyte)
                     Glcd_Write_Text(Textbyte, 47, 6, 1)
           ByteToStr(RxTx_Data[Rx_Data_Len-8], Textbyte)
                     Glcd_Write_Text(Textbyte, 74, 6, 1)
           Delay_ms(10)
      end if
           delay_ms(500)
           ID_1st=ID_1st+1
          RxTx_Data[0]=RxTx_Data[0]+1' Sende was als Quittung zum 
Absender zurück
          CANWrite(ID_1st, RxTx_Data, 8, Can_Send_Flags)     ' send 
incremented data back
          delay_ms(10)
          'Glcd_Write_Text("Was abgeschickt", 5, 1, 1)
  wend
end.

[helmut (Gast)]

Und ein Beispiel von einer Schalterdose mit festen Node-Adr, angelehnt 
an den Code von Hugo und vom Mikroe-Compiler-Beispiel:

'#################################################################
'              Helmut`s CAN-Bus-Test                             '
'#################################################################
'             Der erste Teilnehmer soll  zB 150 als ID haben
'                        und der zweite 118
'           Vor Programmierung der Bausteine die ID`s anpassen
program CAN_BUS_MADE_BY_HELMUT
' Declarations section
dim Can_Init_Flags, Can_Send_Flags, Can_Rcv_Flags as byte  ' can flags
    Rx_Data_Len as byte                             ' received data 
length in bytes
    RxTx_Data as byte[8]                            ' can rx/tx data 
buffer
    Msg_Rcvd as byte                                ' reception flag
    ID_1st, ID_2nd as longint                       ' node IDs
    Rx_ID as longint
' Hauptprogramm initialisieren
main:
  TRISB.7=0
  TrisB.6=0
  PORTC = 0                                         ' clear PORTC
  TRISC = 255                                       ' set PORTC as input
  PortB.6=0           ' CAN CS
  Can_Init_Flags = 0                                '
  Can_Send_Flags = 0                                ' clear flags
  Can_Rcv_Flags  = 0                                '

  Can_Send_Flags = _CAN_TX_PRIORITY_0 and           ' form value to be 
used
                   _CAN_TX_XTD_FRAME and            '     with CANWrite
                   _CAN_TX_NO_RTR_FRAME

  Can_Init_Flags = _CAN_CONFIG_SAMPLE_THRICE and    ' form value to be 
used
                   _CAN_CONFIG_PHSEG2_PRG_ON and    ' with CANInit
                   _CAN_CONFIG_XTD_MSG and
                   _CAN_CONFIG_DBL_BUFFER_ON and
                   _CAN_CONFIG_VALID_XTD_MSG

  ID_1st = 118' das sollte mal der Test für Ricks Taster Felix
  ID_2nd = 150' ist das großere Board, falls es was zurueck sendet
  RxTx_Data[0] = PortC ' Kompletter Port mit 8 Bit in RxTx_Data Byte 0
  RxTx_Data[1] = 2
  RxTx_Data[2] = 4
  RxTx_Data[3] = 8
  RxTx_Data[4] = 16
  RxTx_Data[5] = 32
  RxTx_Data[6] = 64
  RxTx_Data[7] = 128

  CANInitialize(1,2,3,3,1,Can_Init_Flags)                    ' 
Initialize CAN module auf 125kboud(4Mhz)
  CANSetOperationMode(_CAN_MODE_CONFIG,0xFF)                 ' set 
CONFIGURATION mode
  CANSetMask(_CAN_MASK_B1,-1,_CAN_CONFIG_XTD_MSG)            ' set all 
mask1 bits to ones
  CANSetMask(_CAN_MASK_B2,-1,_CAN_CONFIG_XTD_MSG)            ' set all 
mask2 bits to ones
  CANSetFilter(_CAN_FILTER_B2_F4,ID_2nd,_CAN_CONFIG_XTD_MSG) ' set id of 
filter B2_F4 to 2nd node ID
  CANSetOperationMode(_CAN_MODE_NORMAL,0xFF)                 ' set 
NORMAL mode

  CANWrite(ID_1st, RxTx_Data, 8, Can_Send_Flags)             ' send 
initial message
' ###################################   HAUPTSCHLEIFE 
###########################################
  while TRUE
       ' ist eine CAN-Bus-Mitteilung da?
      Msg_Rcvd = CANRead(Rx_ID , RxTx_Data , Rx_Data_Len, Can_Rcv_Flags)
       ' wenn ja, dann schicken wir was zurück......
      if ((Rx_ID = ID_2nd) and (Msg_Rcvd <> 0)) <> 0 then
          portB.7= RxTx_Data[0].0     ' Zeige den PORTC-Pin0 vom Sender 
an
          Delay_ms(10)
          RxTx_Data[0]=PortC ' Sende den PortC vom Empfänger mit allen 8 
Bit zum Sender zurück
          CANWrite(ID_1st, RxTx_Data, 1, Can_Send_Flags)     ' send 
incremented data back
          delay_ms(10)
          PortB.7=RxTx_Data[0].1
      end if
  wend
end.
'HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH 
HHHHHHHHHHHHHHHHHHHHHHHHHhh

[Timo E. (tien)]

Hallo Helmut,

zunächst Danke für Deine Links und Tips!

> Meine Empfehlung:
> Was soll der CAN-Bus-Knoten denn immer verschiedenes machen?
> Die paar Male kann man ihn auch einfach per Prommer programmieren.
> Wenn man 8 Bytes im Protokoll hat, viel Romspeicher, dann gehen auch
> fertige, per Befehlsbyte aufrufbare Progrämmchen ins ROM.

Das mit dem Bootloader muss sein, ich habe im Ziel locker 25 bis 30 
Knoten, da will ich nicht immer die Dosen aufschrauben. Auch kann es gut 
sein, das ein Knoten hinter einem Schrank ist, den ich erstmal 
wegschieben müßte.
Aber das ist eben auch Gewohnheit, in Kfz Steuergeräte ist eben ein 
Bootloader üblich und man schiebt dann halt recht schnell eine neue SW 
zum Kunden wenn was nicht passt. Und so soll es auch im Haus sein, ich 
will nicht abwägen müssen ob ich nun den Bug mit viel Aufwand beseitige 
oder nicht. Mit Bootloader wird die neue SW eben einfach ausgetauscht.

Liebe Grüße Timo

[helmut (Gast)]

Schaltplan von Hugo ist hier:
Beitrag "Eingabepanel mit CAN-Bus Entwicklung"

Das Aufwecken über den PortB-Interupt habe ich nicht übernommen, den 
Rest schon ;-)

Raupe machte was ähnliches:
Beitrag "Can-Bus"

Gruß Helmut

[Max M. (maxmustermann)]

Hallo Helmut!

helmut schrieb:
> Bootlader sind auch schon da, wer ihn denn braucht.
>
> http://mrmackey.no-ip.org/elektronik/ds30loader/index.php
>
> Man muß sich in Mikroe C oder auch Basic mit dem Flash-Schreibbefehl
> auseinander setzen.

Hast du die ds30 loader GUI schon ausprobiert? Als ich die GUI gestartet 
habe, bekam ich die Fehlermeldung "Loading port plugin 
ds30LoaderPortIxxat:invocation of GetPorts() failed". Ist für mich 
leider nicht so einfach herauszufinden wo der Fehler liegt, aber es 
scheint ein Problem mit dem Hardware-Plugin zu geben. Vielleicht liegt 
es auch an meinem Windows 7 64bit. Hast du vielleicht einen Tipp für 
mich? Des weiteren weißt du, was für eine Serial-to-CAN-Bridge man für 
das Interface braucht?

lg Max

[helmut (Gast)]

Hallo Max,
nein, ich habe keinen Bootlader.
Ich habe ein 18F458 auf einem Uniboard mit GLCD, CAN und RS232.
Auf dem Prozessor werden ganz einfach die 8 Byte CAN-Bus-Daten, die 
empfangen werden, über den RS232-Bus gesendet, so dass es quasi auch auf 
dem RS232 Com-Port ankommt.

In meinem CAN-Hausbus-Beispiel ist von Hugo auch genau sowas vorgesehen 
gewesen, war aber nicht implementiert.
Ich habe dann für die Visualisierung in der I2C-Routine eine RS232 
ausgabe reinprogrammiert.

Hier das Schalterdosenlayout in Target-Format:

[helmut (Gast)]

Und Max:
ich glaube du must auch das entsprechende Firmware-File für DEINEN 
Prozessortyp in's IC programmieren.
Siehe:
http://mrmackey.no-ip.org/elektronik/ds30loader/downloads.php

[Max M. (maxmustermann)]

helmut schrieb:
> Hallo Max,
> nein, ich habe keinen Bootlader.
> Ich habe ein 18F458 auf einem Uniboard mit GLCD, CAN und RS232.
> Auf dem Prozessor werden ganz einfach die 8 Byte CAN-Bus-Daten, die
> empfangen werden, über den RS232-Bus gesendet, so dass es quasi auch auf
> dem RS232 Com-Port ankommt.
>
> In meinem CAN-Hausbus-Beispiel ist von Hugo auch genau sowas vorgesehen
> gewesen, war aber nicht implementiert.
> Ich habe dann für die Visualisierung in der I2C-Routine eine RS232
> ausgabe reinprogrammiert.
>
> Hier das Schalterdosenlayout in Target-Format:

Hallo Helmut!

Danke, aber ich weiß leider nicht wie ich die Datei in deinem Archiv 
öffnen soll :-)

Ja so eine CAN Bridge hab ich mir auch schon zum Debuggen gebaut. Kann 
so CAN Messages vom PC mit grafischer Oberfläche senden. Hab mal ein 
Bildchen angehängt.

>Und Max:
>ich glaube du must auch das entsprechende Firmware-File für DEINEN
>Prozessortyp in's IC programmieren.
>Siehe:
>http://mrmackey.no-ip.org/elektronik/ds30loader/do...

Ja, das hab ich auch schon gelesen, dass ich den entsprechenden 
Bootloader in den zu programmierenden PIC programmieren muss. Was ich 
suche ist ein Schaltplan bzw. ein hex File von dem verwendeten Interface 
für die GUI.
Von Microchip gabs mal eine Appnote für einen CAN Bootloader incl 
Sourcecode (http://ww1.microchip.com/downloads/en/AppNotes/00247a.pdf). 
Jedoch haben sie den Source wieder vom Netz genommen da er Bugs 
enthalten hat und sie diese nicht beheben wollten. - Schade wie ich 
finde!

Tja, deshalb hoffe ich auf den ds30 loader :-)

lg Max

[helmut (Gast)]

Schreib den Autor doch mal an.
Welchen Prozessor verwendest du?

Ehrlich gesagt weiß ich nur das über den CAN-Bus, was ich für dieses 
Husbus-Projekt brauchen kann.

Der CAN-Bus ist eine Religion für sich, ich will aber kein Fahrzeug 
Bauteil basteln, wo es auf Attribierung usw ankommt.

Erkenne ich schon an deinem Programm, dass du da viel kompetenter ist.

Wenn ich das brauche erlese ich mir das, hier ist es fast so Einfach mit 
dem Leit-Gedanken:

Lasse alle Node-ID durch, erkenne die NodeID in dem ersten Byte der 
CAN-Botschaft als Absender, mache das was der Befehl im 2. Byte der 
CAN-Botschaft verschlüsselt ist, mit der Node-ID, die z.B. in dem letzen 
Byte steht.

Gruß Helmut

[Max M. (maxmustermann)]

helmut schrieb:
> Schreib den Autor doch mal an.
Hab ich gemacht und auch grad vor 5 min eine Antwort bekommen. Er 
meinte, dass diese Fehlermeldung bedeutet, dass die Hardware nicht 
gefunden worde und dass bisher nur folgende Interfaces unterstützt 
werden: Vector, IXXAT, Kvaser. Schaut also eher schlecht aus mit einem 
Eigenbauinterface wenn man den ds30 loader verwenden will. Ich wollte 
genau das vermeiden, dass ich mich mit dem ganzen Bootloader Protokoll 
auseinandersetzten muss. Wollte eigentlich nur den Download Button 
drücken müssen :-)

> Welchen Prozessor verwendest du?
Ich verwende den PIC18F2865 bzw den PIC18F4680.

> Der CAN-Bus ist eine Religion für sich, ich will aber kein Fahrzeug
> Bauteil basteln, wo es auf Attribierung usw ankommt.
Das mit der Arbitrierung sollte ja das CAN Modul im Chip übernehmen.

> Erkenne ich schon an deinem Programm, dass du da viel kompetenter ist.
Das scheint glaub nur so, mach das wirklich nur als Hobby Jedoch wenn 
ich was mache, dann soll es auch was gscheites sein :-)

> Lasse alle Node-ID durch, erkenne die NodeID in dem ersten Byte der
> CAN-Botschaft als Absender, mache das was der Befehl im 2. Byte der
> CAN-Botschaft verschlüsselt ist, mit der Node-ID, die z.B. in dem letzen
> Byte steht.
Ist auch eine Möglichkeit. Du hast die Adressierung in die Datenbytes 
gepackt. Ich mache es über die Adressierungsbits und selektiere die 
interessanten Nachrichten per Masken und Filter. Kann aber auch alles 
durchlassen und dann per Software entscheiden was mit dem Packet 
passieren soll. So hatt man mehr Platz für Daten, sofern man den 
braucht.

sg Max

[Timo E. (tien)]

Hi Max

> gefunden worde und dass bisher nur folgende Interfaces unterstützt
> werden: Vector, IXXAT, Kvaser. Schaut also eher schlecht aus mit einem
> Eigenbauinterface wenn man den ds30 loader verwenden will. Ich wollte
> genau das vermeiden, dass ich mich mit dem ganzen Bootloader Protokoll
> auseinandersetzten muss. Wollte eigentlich nur den Download Button
> drücken müssen :-)

Gib nicht auf :-)
Ich hab Zugriff sowohl auf Vector als auch auf Kvaser Hardware :-)
Und wenn das mal damit läuft und somit die Funktion des µC Bootloaders 
sichergestellt ist wäre eine Eigenbaulösung kein Problem, da die Quellen 
ja offen sind.

>> Der CAN-Bus ist eine Religion für sich, ich will aber kein Fahrzeug
>> Bauteil basteln, wo es auf Attribierung usw ankommt.
> Das mit der Arbitrierung sollte ja das CAN Modul im Chip übernehmen.

Ich will über die Arbitrierung die "Wichtigkeit" der Nodes abbilden. 
Irgendwelche Botschaften wie "schalt den Strom aus" oder "dreh das 
Wasser" ab sollen die höchste Prio bekommen. Dann alles wo ein User eine 
Reaktion erwartet und zuletzt die Statusmeldungen wie Uhrzeit, 
Temperaturen, usw.

> Ist auch eine Möglichkeit. Du hast die Adressierung in die Datenbytes
> gepackt. Ich mache es über die Adressierungsbits und selektiere die
> interessanten Nachrichten per Masken und Filter. Kann aber auch alles
> durchlassen und dann per Software entscheiden was mit dem Packet
> passieren soll. So hatt man mehr Platz für Daten, sofern man den
> braucht.

Was hälst Du von 29Bit Ids?
Damit könnte man die Empfänger ID mit in die ID packen.
Eventl. auch die Art der Nachricht.

Grüße Timo
(der heute Nachmittag ganz Handfest mit Beton und Steinen gearbeitet hat 
:-)

[Timo E. (tien)]

Schau Dir das mal an:
http://www.canathome.de/Konzept2/Dokumentation/Nachrichtentypen.htm

[Max M. (maxmustermann)]

Hi Timo

> Gib nicht auf :-)
> Ich hab Zugriff sowohl auf Vector als auch auf Kvaser Hardware :-)
> Und wenn das mal damit läuft und somit die Funktion des µC Bootloaders
> sichergestellt ist wäre eine Eigenbaulösung kein Problem, da die Quellen
> ja offen sind.
Nein nein, so schnell gebe ich nicht auf! Klingt gut, wenn du Zugriff 
auf die Dinger hast!

>>> Der CAN-Bus ist eine Religion für sich, ich will aber kein Fahrzeug
>>> Bauteil basteln, wo es auf Attribierung usw ankommt.
>> Das mit der Arbitrierung sollte ja das CAN Modul im Chip übernehmen.
>
> Ich will über die Arbitrierung die "Wichtigkeit" der Nodes abbilden.
> Irgendwelche Botschaften wie "schalt den Strom aus" oder "dreh das
> Wasser" ab sollen die höchste Prio bekommen. Dann alles wo ein User eine
> Reaktion erwartet und zuletzt die Statusmeldungen wie Uhrzeit,
> Temperaturen, usw.
Die Priorität wird ja über die IDs festgelegt, je mehr logische Nullen 
in der ID desto höher die Priorität, wenn ich mich noch recht erinnre.

> Was hälst Du von 29Bit Ids?
> Damit könnte man die Empfänger ID mit in die ID packen.
> Eventl. auch die Art der Nachricht.
Ja, ich würde auch alle 29bits benutzen. Und wieder mal ein Link zu 
einer Appnote von mir: 
http://ww1.microchip.com/downloads/en/AppNotes/00816b.pdf auf Seite 5 
ist ein Beispiel für eine Adressierung angeführt. Ich würde es so 
ähnlich machen!

> (der heute Nachmittag ganz Handfest mit Beton und Steinen gearbeitet hat
> :-)
Ich wäre froh, wenn ich mal zur Abwechslung ein wenig körperliche Arbeit 
verrichten könnte ;-)

gruß Max

[helmut (Gast)]

Ich zolle euch Respekt, wenn ihr es ausführlich und gut durchdacht 
machen wollt.

Ich meine aber, der normal sterbliche Bastler, der das wirklich nur als 
Hausbus haben möchte, dem ist das wurscht, ob bei einen vermeintlichen 
NOT AUS, 20 ms vorher, doch noch eine Leuchte angesteuert wird, die dann 
sowieso wieder ausgeht.

Wenn man HAP sieht oder CAN@home, dann erschrickt man sich schon von dem 
Umfang und den Möglichkeiten.

Und Das ist schon sehr gut, sodass man nix Neues anfangen muß!!

Das Schalterdosen CAN-Hausbus-Modul, nur so, kann schon, mit der 
Demoversion von Mikroe programmiert werden, dass ein Schalterdosen-Node 
ein anderes Schalterdosenmodul sagt:

mach PortB.7 auf High, sodass eine Leuchte angeht.

Noch eine RS232-Stringausgabe parallel zum PC könnte eine Viso 
betütteln.

Und das was ich mit Hugos Platinen- und Code-Beispielen gebaut habe, 
schafft auch ein Nichtstudierter "noch nicht Bleifreilöter".

Aber es ist auch hier nur ein Ideensammlungstread, der hoffentlich in 
einem Bauvorschlag enden wird. Jedem kann man es sowieso nicht Recht 
machen.

Gruß Helmut

[Timo E. (tien)]

helmut schrieb:
> Ich zolle euch Respekt, wenn ihr es ausführlich und gut durchdacht
> machen wollt.

Danke :-)

> Ich meine aber, der normal sterbliche Bastler, der das wirklich nur als
> Hausbus haben möchte, dem ist das wurscht, ob bei einen vermeintlichen
> NOT AUS, 20 ms vorher, doch noch eine Leuchte angesteuert wird, die dann
> sowieso wieder ausgeht.

Da hast Du bestimmt recht. Aber Murphy sagt: "Just in solch einem 
(Not)Fall sendet ein dummer, fehlerhafter Knoten dauerhaft hochpriore 
Nachrichten und die "Schalt den Strom aus" Nachricht wird dauerhaft 
verdrängt..." Ich denke wenn in einer Steckdose mit SSR die Temperatur 
sehr schnell ansteigt ist ein schnelles Abschalten schon sinnvoll. Und 
da ich ja nicht sicher sein kann, dass dies allein durch ein Abschalten 
der SSR Ansteuerung funktioniert ist eine komplette Notabschaltung der 
Versorgung sinnvoll. (ohoh, ich sehe schon vor meinem geistigen Auge die 
Mailflut - "was dabei alles schief gehen kann und und und"... dazu sei 
angemerkt: es ist nur ein winziger Aspekt und nur eine kleine Paranoia 
Funktion)

> Wenn man HAP sieht oder CAN@home, dann erschrickt man sich schon von dem
> Umfang und den Möglichkeiten.
> Und Das ist schon sehr gut, sodass man nix Neues anfangen muß!!

Ja, aber es machht ja auch Spass so was neu zu entwickeln und sich aus 
den vorhandenen Projekten das beste zu nehmen.
Mit Vernunft läßt sich das nicht Erklären, es ist halt Hobby :-)
Sieh es so: Ein Hobbyangler kauft auch nicht seinen Fisch, er angelt ihn 
lieber selber...

> Und das was ich mit Hugos Platinen- und Code-Beispielen gebaut habe,
> schafft auch ein Nichtstudierter "noch nicht Bleifreilöter".

Naja, es ist halt mein Job Lastenhefte zu analysieren, Pflichtenhefte zu 
schreiben, das SW Design zu definieren und dann die Implementierung zu 
machen, das färbt eben aufs Hobby ab :-)
Aber ich habe auch schon mehrfach erlebt, dass man mit dem Mozart Ansatz 
(direkt vom Kopf in die Tastatur) bei größeren Projekten schnell an eine 
Stelle kommt, an der man nicht mehr ordentlich weiterkommt. Und dann 
fängt man an Balkone zu bauen und solch eine Software über Jahre hinweg 
zu pflegen ist nicht sehr angenehm.
Andererseits gebe ich Dir recht, man kann sich auch in der Theorie 
verlieren und kommt nie zu einem praktischen Ergebnis. Die Mischung 
machts, und ich hoffe das dies bei uns hier so laufen wird.

> Aber es ist auch hier nur ein Ideensammlungstread, der hoffentlich in
> einem Bauvorschlag enden wird. Jedem kann man es sowieso nicht Recht
> machen.

Genau! Ich werde in den nächsten Wochen meine sehr bescheidene Freizeit 
in die Inbetriebnahme des ds30 Bootloaders stecken. Wenn das geht könnte 
man sich ein USB<->CAN Selbstbauinterface basteln, so dass man kein 
teures Interface (Vector usw.) benötigt. Eventl. wäre hier auch eine 
parallele Vorgehensweise sinnvoll, der eine nimmt den Bootloader in 
Betrieb, der andere entwickelt ein USB2CAN Interface. Bestimmt gibt es 
hier im Netz auch schon eine Grundlage. Und dann gehts mit der Hardware 
der Basisplatine weiter (und spätestens da sollte man sich auf einen µC 
festgelegt haben :-)

Lebe Grüße Timo
(und DANKE fürs mitdenken und schreiben!!!)

[Dirk L. (c-si)]

Timo E. schrieb:
> AVR Lösungen gibt es ja bereits einigeim Netz, PIC basierte kenne ich
> bisher nur die von Helmut.

da hab ich was gefunden... -> 
Beitrag "Frage zum Gira Tastsensor 2plus"

diese hausbuslösung basiert auch auf PIC-Microcontrollern...

Gruß c-si

[helmut (Gast)]

@Timo
wieviel Aufwand ist denn so ein CAN-PC-Interface im Selbstbau?

Gruß Helmut

[Timo E. (tien)]

helmut schrieb:
> wieviel Aufwand ist denn so ein CAN-PC-Interface im Selbstbau?

Hallo Helmut,

ich würde das so anstellen (auch wenn es noch viele andere Wege geben 
könnte):
Ein PIC18F mit CAN, z.B. den PIC18F4585 mit dem CAN Transiver auf der 
einen Seite, und einem FTDI USB Chip auf der anderen Seite:
http://www.ftdichip.com/Products/ICs/FT232R.htm
Im PIC dann einfach die Daten von der TTL UART Richtung CAN schaufeln 
und umgekehrt. Für unsere bescheidenen Datenraten reicht das locker.
Im PC dann entweder per virtueller RS232 die Daten auf den USB legen, 
oder mit dem FTDI D2XX Treiber, der ist dann eventl. etwas flotter.
Auf der PC Seite kann man dann z.B. mit VC# oder VB# ein kleines 
Programm schreiben, was die Daten visualisiert bzw. bei Bedarf Komandos 
schickt.
Für den Bootloader müsste das Programm halt ein Hex File so in Stückchen 
aufteilen, dass es der Bootloader "verdauen" kann.

Derzeit beschäftige ich mich aber mit der PIC Seite, da ich ja versch. 
CAN Interfaces hier rumliegen habe (Kvaser leihweise und ein eigenes 
Peak).

Da der ds30 in Assembler geschrieben ist will ich mal den MikroE RS232 
Bootloader anschauen und dann eventl. die Kommunikation in Richtung CAN 
ändern - mal sehen.
Die CAN Kommunikation hab ich gestern Abend in Betrieb genommen, 
nächster Schritt ist den RX in einen Interrupt zu legen.
Ich melde mich, wenns was neues gibt.

Grüße Timo

[helmut (Gast)]

Timo E. schrieb:
> könnte):
>
> Ein PIC18F mit CAN, z.B. den PIC18F4585 mit dem CAN Transiver auf der
>
> einen Seite, und einem FTDI USB Chip auf der anderen Seite:
>
> http://www.ftdichip.com/Products/ICs/FT232R.htm
>
> Im PIC dann einfach die Daten von der TTL UART Richtung CAN schaufeln
>
> und umgekehrt. Für unsere bescheidenen Datenraten reicht das locker.
>
> Im PC dann entweder per virtueller RS232 die Daten auf den USB legen,
>
> oder mit dem FTDI D2XX Treiber, der ist dann eventl. etwas flotter.

Naja, das hab' ich schon, nur ohne Ftdi, direkt RS232.

So mit einstellbaren CAN-Baudrate und alle Flags, die es bei CAN so gibt 
(siehe das GUI von MAX MUSTERMANN weiter oben)

Gruß Helmut

[Timo E. (tien)]

helmut schrieb:
> Naja, das hab' ich schon, nur ohne Ftdi, direkt RS232.
> So mit einstellbaren CAN-Baudrate und alle Flags, die es bei CAN so gibt
> (siehe das GUI von MAX MUSTERMANN weiter oben)

Das ist ja dann schon richtig profesionell.
Bis zu diesem Stand werde ich wohl noch einige Zeit benötigen :-)

Ich habe gerade eine alte Platine von 2008 rausgekramt. Damals habe ich 
mit der Hausbusentwicklung angefangen und wollte eigentliche vor dem 
Hauskauf mit dem Grundsystem fertig sein. Ich wurde von der Realität 
überholt - es kommt halt eben alles anders als man denkt :-)
Nun haben wir ein Haus und ich fange erst jetzt an zu entwickeln. Aber 
es sind ja alle Vorbereitungen (Kabel usw.) getroffen und so war auch 
von vornherein klar, dass die grundlegende Technik auch ohne Bus 
funktionieren muss.

Zurück zur Platine:
Das ist ein kleines selbst gebasteltes PIC Board mit CAN und RS232, ein 
paar Taster und LEDs. Das ganze war der erste Platinenversuch mit 
Thermotransfer- / Laminiermethode. Und nun kann das EasyPIC Board und 
das Selbstgebaute Board über den CAN kommunizieren. Ein kleiner Schritt, 
aber es macht trotzdem Spass, wenn es funktioniert.

Grüße Timo

[helmut (Gast)]

Hallo Timo,
in dem Link:
http://www.mikrocontroller.net/attachment/25804/can.zip
sind alle Files drin. Auf dieser Grundlage sind auch meine Files 
entstanden.

Ich hatte zwar die Eagle-Files nach Target konvertiert, aber 
grundsätzlich ist es der gleiche Aufbau.

Und das hat der Autor nunmal echt gut und, nach meiner Ansicht, auch 
nachbaubar EINFACH gemacht.

Das sich die PIC-Compiler Software weiter entwickelt hat und die 
Orginal-Files angepasst werden mußten, hat das Verständniss für den Code 
nur erhöht.

Wenn du dir das AktorMainboard anschaust wirst du auch die serielle 
Schnittstelle entdecken.

Die war sicherlich für einen Bootlader, oder was ich gemacht habe: eine 
parallele Ausgabe der Relaisansteuerung auf RS232, gedacht.

Damit kannst du schon komplett eine zentrale CAN-Hausbus Steuerung in 
Betrieb nehmen.

Kleiner Aktoren in der Schalterdose, angesteuert durch so ein 
Schalterdosen-Node, sind bei mir noch drin.

Ein 21 bis 24-fach 18B20 Temperaturmodul ( für Heizung, Solar, 
Radiatoren und Fußbodenkreisläufe).

So 'ne kleinen Wandviso, mit und ohne Touchscreen, siehst du ja schon 
auf meiner Webseite.

Was man zwar bestimmt gut findet: ein Bedienfeld mit allen steuerbaren 
und abrufbaren Daten und Schaltmöglichkeiten auf einen Tochscreen ist da 
auch als aP Gerät zu sehen.

Das möchte ich gerne mit Farbe füllen, Touch mit TFT ist schon da, Zeit 
noch nicht....und leider auch keine Demo-Beispiele von Mikroe (seit Mai 
!!!)

Ist aber alles auf Grundlage von "Hugo" entstanden (ich hoffe er liest 
mit und meldet sich mit neuen Erkenntnissen)

Gruß Helmut

[Tien (Gast)]

Hallo Helmut,

> Was man zwar bestimmt gut findet: ein Bedienfeld mit allen steuerbaren
> und abrufbaren Daten und Schaltmöglichkeiten auf einen Tochscreen ist da
> auch als aP Gerät zu sehen.
> Das möchte ich gerne mit Farbe füllen, Touch mit TFT ist schon da, Zeit
> noch nicht....und leider auch keine Demo-Beispiele von Mikroe (seit Mai
> !!!)

Das werde ich per PC lösen. Im Keller wird ein Rechner stehen, der einen 
in der Wand eingebauten 10" Touch versorgt. Das hat den Vorteil, dass 
man auch mal ins Internet kann oder Emails abholen. Ich bin der Meinung, 
dass auf einem PC komplexere Visualisierungen leichter umzusetzen sind.

Aber Deine Lösung hat natürlich auch seinen Charm - keine Bootzeiten, 
weniger Stromverbrauch,...

Grüße Timo

[Timo E. (tien)]

Hallo Helmut,

ich finde irgendwie nicht mehr den Link zu DEiner Homepage. Kannst Du 
den nochmals hier posten? Danke!

Grüße Timo

[lrlr (Gast)]

>ins Internet kann oder Emails abholen. ...komplexere Visualisierungen

und dafür willst dich ernsthaft (minutenlang) an die wand stellen..

[Timo E. (tien)]

lrlr schrieb:
>>ins Internet kann oder Emails abholen. ...komplexere Visualisierungen
>
> und dafür willst dich ernsthaft (minutenlang) an die wand stellen..

Nö, wer sagt das?
Ich sitze entspannt an meinem Tresen und schlürfe dazu eine gute 
Tasse...

[Max M. (maxmustermann)]

Hallo Timo!

Ja, das mit dem Touch-Display und einem kleinen ITX PC mit Intel Atom 
habe ich mir auch schon überlegt. Man bekommt die LCDs mit Touch schon 
um die 200€ und ein ITX um ca 100€ :-). Dein Foto sieht echt cool aus! 
Was hast du da für ein Display (Größe?) verbaut und wo hast du den 
Alurahmen her? Ich nehme an, dass du den PC dazu irgendwo anders stehen 
hast? Vorzugsweise würd ich so eine Visualisierung in der Nähe des 
Wohnzimmers bzw der Küche anbringen.

Grüße,
Max

[Timo E. (tien)]

Hi Max,

> Dein Foto sieht echt cool aus!
Danke :-)

> Was hast du da für ein Display (Größe?) verbaut
Es ist ein FAYTECH T10 SW Display,
Ich hab meines von Reichelt:
http://www.reichelt.de/?ACTION=3;ARTICLE=87454;PROVID=2402

Das ganze sitz in einem nicht mehr benötigten Unterverteilerkasten von 
Hager, den ich auf die benötigte Größe zurechtgestutzt habe. Aber ich 
denke da gibt es auch Alternativen.

> und wo hast du den Alurahmen her?
Das ist ein Edelstahlrahmen. Ich habe ihn von der Firma
http://www.metal-designer.de/
Ich kann die Firma empfehlen, man sendet einfach eine Anfrage mit den 
Maßen hin und bekommt ein Angebot. Wir haben da unsere Hausnummer machen 
lassen. Die Qualität und die Kundenkommunikation ist sehr gut.

> Ich nehme an, dass du den PC dazu irgendwo anders stehen
> hast?
Ja, im Keller, fast direkt unter dem Bildschirm. Dort wird dann auch die 
Verteilung für Netzwerk, Sat und Telefon hinkommen.

Grüße Timo

[Max M. (maxmustermann)]

Aja, anbei ein Bild von meiner CAN-Serial Bridge mit der ich meinen CAN 
Monitor (siehe Beitrag weiter oben) verwende. Ganz einfach mit einem 
PIC18F2685 und einem MCP2551.

Das zweite Bild zeigt ein Demoboard mit einem MCP25055 CAN I/O Expander 
das ich letzte Woche gebaut habe. Es besitzt einen analogen 10bit 
Eingang an dem ein lichtempfindlicher OP angschlossen ist um Helligkeit 
zu messen. Des weiteren einen Reedkontakt der eine Message verschickt, 
sobald sich der Kontakt öffnet oder schließt, z.B. als Fensterkontakt 
nutzbar. Ebenso wird der PWM Ausgang benutzt um einen Piezotongeber 
anzusteuern, 2 LEDs und 2 Taster, die ebenfalls eine Message beim 
Tastendruck versenden. Ich denke für einfache Anwendungen ist dieser I/O 
Exander eine sehr gute und schnelle Lösung. Die CAN Bus Einstellungen 
(Baudrate etc) werden sind programmiert, alles andere kann aber zur 
Laufzeit auch umkonfiguriert werden. Vielleicht kann jemand ja sowas 
brauchen ;-)

Lg Max

[Max M. (maxmustermann)]

Hi Timo!

>> Was hast du da für ein Display (Größe?) verbaut
> Es ist ein FAYTECH T10 SW Display,
> Ich hab meines von Reichelt:
> http://www.reichelt.de/?ACTION=3;ARTICLE=87454;PROVID=2402

Hast du beim Einbau das Gehäuse entfernt? Die Tasten sind ja so nicht 
nutzbar, braucht man aber wohl nicht? Sonst bist du zufrieden mit dem 
Display und würdest es wieder kaufen?

Lg Max

[Timo E. (tien)]

Nein, das Gehäuse ist weiterhin vorhanden. Aber die Tastenkappen habe 
ich aus dem Gehäuse entnommen. Alle Funktionen sind mit der 
mitgelieferten IR Fernbedienung verwendbar. Allerdings muss entweder in 
die Blende ein Loch für den Empfänger oder man baut den Empfänger aus 
und an anderer Stelle ein (so werde ich es machen). Die Blende ist dann 
einfach auf das Gehäuse per Powerstrip aufgeklebt. Das ganze wird dann 
ins Gehäuse gesetzt und hält dort mit vier Powermagnete (derzeit bei mir 
noch nicht umgesetz, der Monitor liegt/steht derzeit nur im Wandgäuse 
drin). Eine andere Möglichkeit wäre die Verwendung von selbstklebenden 
Klettstreifen.

Das Display ist ok. Bzgl. Auflösung ind Brillianz natürlich kein 
Vergleich mit iPad & Co, aber fürs Lesen von Mails und kurz mal nach dem 
Wetter oder den Nachrichten surfen ok. Man kann es mit den üblichen 
digitalen Diarahmen vergleichen. Ich habe mir das kleine 8" und dieses 
10" bestellt beide (vorsichtig) getestet und mich dann für das 10" 
entschieden, weil man dies auch ohne Stift relativ gut bedienen kann.

Grüße Timo

[helmut (Gast)]

helmut schrieb:
> Datum: 21.10.2010 16:52

> Platine für Schalterdosen ist schon fertig, Steuerung in MikroeBasic
>
> (hättest du schon im Mikroeforum finden können),
>
> auch mit 18B20:
>
> www.helmutholm.de etwas runterscrollen.
>
> Gruß Helmut

[Tien (Gast)]

Hallo Max,
Hallo Zusammen,

ein Kollege hat mich auf folgendes hingewiesen:

http://www.seeedstudio.com/depot/dso-nano-v2-p-681.html?cPath=104_108
..und der dazugehörige Thread auf microkontroller.net :-)
Beitrag "DSO Nano Opensource!"

Nun wäre das eventl. eine nette Lösung um eine Visualisierung/Steuerung 
im Raum umzusetzen. Ich hab ja in jedem Raum am Eingang in 1,5m Höhe 
eine Dose um dort eine einfache Raumbezogene Visualisierung (Temperatur, 
Feuchte, Uhrzeit, usw.) und Steuerung für spezielle Dinge z.B. 
Lichtszenen od.ähn. zu ermöglichen. Nun wäre hier solch ein DSO Teil ja 
auch nicht übel. Einziger Nachteil: kein Touchscreen!

Naja, wollte ich nur mal Euch weitergeben.


Grüße Timo

[Helmut (Gast)]

Hat jemand interesse an TFT-Displays von Mikroe?

http://www.mikroe.com/eng/products/view/585/mikrommb-for-pic18fj-board/

Ich möchte mir eine Bedieneinheit auf dieser Basis erstellen.
Es kommt ein Grundriss ins Bild und über SPI mit einem CAN-Tranceiver 
geht es auf den CAN-Bus (auf meinem System und meinen Parametern).

Ich brauche vorerst nur 2, da die Versandkosten von 25 Dollar sehr hoch 
sind, wäre es schön wenn man sich Die teilen könnte.
Gruß Helmut

[Thomas W. (tomiondrums)]

Hi Timo, Helmut, Max,
ich bin im Moment auch dran, mir ein Hausbus-System auf CAN-Basis zu 
implementieren. Weil ich meine Ideen zur Neuerfindung des Rades nicht 
gleich in die Tat umsetzen wollte, sondern lieber erst mal nachforsche, 
was es noch für ähnliche Überlegungen bzw. Produkte gibt, bin ich auch 
auf diesen Thread gestoßen.

Wie weit sind eure Arbeiten (hinsichtlich eurer Bussysteme) schon 
gediehen?

Mein Ziel ist z.Zt. nicht einfach was zu bauen, was in meinem speziellen 
Fall gut funktioniert (bitte aus der Formulierung jetzt keine falschen 
Unterstellungen ableiten), sondern die Sache etwas generischer 
anzugehen. Konkret bedeutet das:

+ Ich möchte ein zentralistisches System (auch wenn sich daraus ein SPOF 
ergibt),
+ bei dem die Nodes nicht direkt untereinander, sondern per 
CAN2PC-Gateway (zB. via Ethernet/USB) Messages mit einer 
'Server-Anwendung' austauschen. (Ggf. redundante Gateways/Zentralrechner 
zur Verringerung des SPOF-Problems)

+ Jede Node bekäme eine eigene (eindeutige) Adresse (dazu mißbrauche ich 
einfach die CAN-MessageID [Erläuterungen dazu bei Interesse auf Anfrage 
;-) ].

+ Das Adressierungsschema würde ich einfach (mit einigen 
Vereinfachungen) vom IP-Protokoll ableiten. Genauso würde ich auch mit 
dem Routing zw. CAN-Netzsegmenten verfahren (Netmask+Netzadresse, 
vereinfachte Routing-Tabelle,...) die Segmentierung größerer Pakete 
würde ich auch zum Teil von dort abkupfern.

+ Der Layer 7 könnte so aussehen: Jeder Busknoten repräsentiert (aus 
Sicht der Verwender-API) ein zustandsbehaftetes Objekt (im Sinne von 
OOP), mit Attributen (aber ohne Methoden), das ggf. zusätzlich (über 
höhere Protokollebene) als Daten-IO-Stream agieren kann (für Gateways zu 
anderen Bussystemen bzw. Multimedia-Streams für 
Haustür-Nebensprechstelle).

+ Dieses Projekt auf OpenSource-Basis (GPL etc.), bestehend aus
  - der HW-Schnittstellenbeschreibung (Layer0 [d.h. einfach Festlegung 
von ein paar zulässigen Busfrequenzen,...],... Layer3),
  - einer überschaubaren Server-API + Layer7-Spec für die Busknoten,
  - einer anständigen Doku
  - ein paar Referenzimplementierungen für einfache Busknoten (wie 
Tasterankoppler, CMOS-Digitalein-/ausgang, Relaisausgang, 
Temperaturfühler), Netzsegmentrouter und Gateway, möglicherweise sogar 
auf Basis unterschiedlicher Mikrocontrollertypen (PIC, AVR, MC68HC***, 
etc.)
schwebt mir z.Zt. so vor. Allerdings hat's keinen Sinn, wenn sich 
niemand dafür interessiert...

Das Konzept soll einerseits leicht verständlich, andererseits aber auch 
flexibel sein. Vor Allem aber solls eine Entwickercommunity geben. 
Wenn's gut wird, findet sich vielleicht sogar jemand, der die 
Hardwarekomponenten industriell herstellt...

Deshalb wollte ich hier mal fragen, was Ihr so davon haltet. Gebt Ihr 
der Idee eine Chance? Hättet ihr vllt. sogar selber Interesse 
[mitzumachen]?

Danke für's Lesen und für eventuelle Antworten!
MfG
 Tom

[Timo E. (Gast)]

Hi Tom!

Thomas W. schrieb:
> Wie weit sind eure Arbeiten (hinsichtlich eurer Bussysteme) schon
> gediehen?

Zum Stand des Projektes: Derzeit entwickeln ein Kollege von mir und ich 
die Basis SW (um genau zu sein macht mein Kollege fast alles, da ich 
etwas knapp an Zeit bin :-)
Das RTOS, der Bootloader, der CAN Treiber sind schon recht weit. Morgen 
abend treffen wir uns wieder um die SW mal am realen Objekt zum Laufen 
zu bekommen. Parallel dazu habe ich mal im Wiki das geplante CAN 
Protokoll dokumentiert:
http://code.google.com/p/tech-home-automation/wiki/CanCommunicationProtocol
In den nächsten Wochen/Monaten gibt es im Wiki das ein oder andere 
weitere zu lesen.

Thomas W. schrieb:
> Mein Ziel ist z.Zt. nicht einfach was zu bauen, was in meinem speziellen
> Fall gut funktioniert (bitte aus der Formulierung jetzt keine falschen
> Unterstellungen ableiten), sondern die Sache etwas generischer
> anzugehen. Konkret bedeutet das:

> + Ich möchte ein zentralistisches System (auch wenn sich daraus ein SPOF
> ergibt),
> + bei dem die Nodes nicht direkt untereinander, sondern per
> CAN2PC-Gateway (zB. via Ethernet/USB) Messages mit einer
> 'Server-Anwendung' austauschen. (Ggf. redundante Gateways/Zentralrechner
> zur Verringerung des SPOF-Problems)

Gibt es einen Grund dafür?
Wir planen das System derzeit als ein verteiltes System, in dem aber 
komplexere (Komfort) Funktionen zentral bearbeitet werden. D.h. jeder 
Node hat Grundfunktionen, die den Basisbetrieb gewährleisten. Z.b sendet 
ein ButtonNode ein Event "PushButtonXY", ein AktorNode reagiert auf 
diesen Event mit einer Aktion z.B. Licht an. Auch etwas komplexere Dinge 
wie "Schalte Ausgang X bei Event Y und Zustand Z" Oder "Schalte Ausgang 
X 10min nach Event Y" werden die Nodes beherrschen.
D.h. die Sensoren (Taster, Temperatur, Bewegung, usw.) sollen keine 
eigene "Intelligenz" haben sondern nur Events verschicken bzw. 
Statusanfragen beantworten. Die Aktuatoren hingegen sollen je nach 
Zustand bestimmte Aktionen ausführen. In den Aktuatoren sind also 
Tabellen abgelegt, die zyklisch oder beim Empfang von Events 
abgearbeitet werden.
Natürlich läßt sich damit auch ein zentrales System implementieren. Dann 
ist der Aktuator entsprechend einfacher und reagiert nur auf den 
zentralen Knoten.

> + Jede Node bekäme eine eigene (eindeutige) Adresse (dazu mißbrauche ich
> einfach die CAN-MessageID [Erläuterungen dazu bei Interesse auf Anfrage
> ;-) ].

Wieso missbrauchen, das ist doch der Sinn und Zweck der CAN IDs.
Oder wie meinst Du das?

> + Das Adressierungsschema würde ich einfach (mit einigen
> Vereinfachungen) vom IP-Protokoll ableiten. Genauso würde ich auch mit
> dem Routing zw. CAN-Netzsegmenten verfahren (Netmask+Netzadresse,
> vereinfachte Routing-Tabelle,...) die Segmentierung größerer Pakete
> würde ich auch zum Teil von dort abkupfern.

Das haben wir nicht so gemacht, siehe CanCommunicationProtocol im Wiki.
Hier haben wir das Protokoll auf die für uns wichtigen Dinge reduziert.

> auf Basis unterschiedlicher Mikrocontrollertypen (PIC, AVR, MC68HC***,
> etc.) schwebt mir z.Zt. so vor.

Wir haben uns auf den PIC18F für die Nodes festgelegt. Am Gateway 
arbeitet mein Kollege auch schon etwas, der soll dann auf einem PIC32 
laufen. Weitere Controller werden wir (vorerst) nicht unterstützen. 
Nicht weil wir nicht wollen, sondern weil dazu einfach die Zeit fehlt. 
Allein die BasisSW benötigt einige Zeit um auf einem Controller zu 
laufen, dann benötigt man natürlich auch unterschiedliche HW und etwas 
Hintergrundwissen über die Controller müssen auch erlernt werden.
Ziel ist es in ein bis zwei Jahren die EIB Leitungen in meinem 
umgebauten Haus einem sinnvollen Zweck zuzuführen. Das bedeutet aber, 
dass man erst mal ein lauffähiges System benötigt. Und da muss man sich 
auf das wesentliche konzentrieren.

> Allerdings hat's keinen Sinn, wenn sich
> niemand dafür interessiert...

Naja, Du interessierst Dich ja dafür :-)

> Das Konzept soll einerseits leicht verständlich, andererseits aber auch
> flexibel sein.

Guter Ansatz.

> Vor Allem aber solls eine Entwickercommunity geben.

Die kommt dann, wenn die Grundlage gut ist und Du das Ganze 
veröffentlichst von alleine. Oder eben nicht, wenn es bessere 
Alternativen gibt. Aber von 0 auf werden nur wenige daran teilnehmen.

> Deshalb wollte ich hier mal fragen, was Ihr so davon haltet.

Ich finds gut.

> Gebt Ihr der Idee eine Chance?

Wie gesagt, ich gehe davon aus, dass Du zunächst in Vorleistung gehen 
musst um Mitstreiter zu finden.

> Hättet ihr vllt. sogar selber Interesse [mitzumachen]?

Unser Konzept steht schon relativ fest, daher wird sich eine 
Zusammenarbeit vermutlich auf den Gedankenaustausch beschränken. vermtl. 
kann man auch Detaillösungen austauschen. Wenn Du Dich mit unserem CAN 
Protokoll anfreunden kannst wäre auch mehr drin. Wobei wir hier auch 
noch kleinere Anpassungen machen könnten, falls es nur Details sind, die 
Dir nicht gefallen.


Grüße Timo

[Markus B. (mbp-bayern)]

Hallo Tom,

Die Steuerung / Virtualisierung an/mit einem PC,
die soll es auch bei mir geben.
Aber dass ein Kompletter Computer-Server dies übernimmt,
das habe auch ich nicht vorgesehen.

Wobei die Unterschiede auf der Firmware-Seite
zwischen "manuell steuern + visualisieren"
und "Computer im zentralen Server-Betrieb"
unter Umständen garnicht mal so groß sind.

Bei mir ist der Anfang die Hardware-Entwicklung.
Jedoch habe ich selbst noch keine Software-Grundlagen.

Eine zentrale Rolle an meiner Hardware
wird eine kleine Platine mit PIC18 spielen.

Diese kann einzeln bis zu 4 Schalter und/oder 4 Relais steuern.

Die Platine kann auch in andere Module als "CPU" eingesetzt werden.

Ein Zentral-IO-Modul und ein kleines Tochpanel-LCD-Modul
befinden sich in der Layoutphase. (Abschlussarbeiten / Verbesserungen)
Dann wird es hoffentlich bald Harware zum Testen geben.

Bei Interesse an meiner Hardware siehe Thread:
Beitrag "Konzept zu einem Hausbus auf CAN-Bus Basis und die Enstehung des Konzeptes"

MFG:MBP
Markus.

[Thomas W. (tomiondrums)]

Hallo Timo,
> Gibt es einen Grund dafür?
Selbstverständlich gibt es den und er heißt ganz einfach 
'Komplexitätsreduktion'. Das ganze dachte ich mir folgendermaßen
(hier wird von einem einzigen Netzsegment ausgegangen, d.h. das Netz ist 
nicht strukturiert und braucht daher auch noch keine 'Router'):

                 [SA] [SB]  [RA]   [RB]   [SC]  [RC]   ...
                  |    |     |      |      |     |
CAN   ------+-----+----+-----+------+------+-----+--   ...
            |
          [GW]
            |
            | (ethernet)
            |
          [ZR]

* Ein aktiver Senderknoten (SA), wie z.B. ein Binäreingang 
(Lichtschalter etc.) ist mit einer verhältnismäßig primitiven Firmware 
ausgestattet, die die Eingangspins des µC entweder durch zyklische 
Abfrage oder eben per Flanken-Interrupt überwacht. Verzeichnet er an 
mindestens einem seiner Pins eine Zustandsänderung, so entscheidet er 
anhand eines in seinem EEPROM/FLASH etc. abgelegten Parametersatzes, ob 
und in welcher Form er diese Zustandsänderung auf den Bus melden soll.
Angenommen, alle hinreichenden Bedingungen zum Senden wären erfüllt 
(z.B. Parametersatz sagt
 *** 'signalisiere pos. Flanke an Eingang0 mit der Nachricht 'xyz' auf
     Port 27' und
 *** eine pos. Flanke lag auch am Eingang0 des µC vor)
so würde SA ein Frame
 *** mit einer ID, bestehend aus seiner eigenen Adresse[erste 24 bit]
     (steht auch im Parametersatz) und der Portnummer [übrige 5 bit]
     '27'
 *** und mit dem Datenfeldinhalt 'xyz'
absenden.

* Andere Knoten (außer dem Gateway) im Netz interessieren sich aufgrund 
ihrer Acceptance-Filter/-Masks nicht für Nachrichten, die nicht ihre 
eigene (eindeutige!!) Adresse als Identifier tragen, also auch nicht für 
die eben von SA gesendete Message.

* Der Gateway (GW) hört den Bus ununterbrochen ab und empfängt deshalb 
auch die Nachricht, die SA soeben losgeschickt hat. Soweit kein 
Busfehler aufgetreten ist, verpackt GW diese Nachricht um und sendet sie 
per Netzwerk (ggf. auch RS232 oder was auch immer) an die Software auf 
dem zentralen Rechner (ZR). Diese Software baut im Wesentlichen auf 
einer sehr simplen Plug-In-Architektur auf. Mit solchen Plugins kann der 
Programmierer das Verhalten des eigentlichen Systems festlegen, nennen 
wir sie deshalb 'Behavior'-Objekte.

* Angenommen es wurde ein Behavior Objekt angelegt, das sich für das 
Ereignis [<Addr_von_SA>,Port 27,'xyz'] interessiert: Dieses Plugin 
könnte bspw. im allereinfachsten Fall zwei Lampen an RA und RB 
umschalten (an->aus, aus->an).
Man könnte damit aber auch, wenn man denn wollte, ohne größeren Aufwand, 
basierend auf dem Gesamtzustand des Systems oder andere äußere Faktoren, 
wie Uhrzeit, Vorhersage vom Online-Wetterdienst, Veränderungen im Kurs 
des eigenen Aktiendepots (der Phantasie wären hier keine Grenzen 
gesetzt),..., völlig andere (Re-)Aktionen festlegen.
Bleiben wir aber mal beim geschilderten Umschalten der Lampen RA,RB: Es 
gibt einfach eine boolesche Zustandsvariable, die bei jedem eintreffen 
der Nachricht invertiert wird. Ist sie danach 1 wird
 *** [<Addr_von_RA>,Port 23,'0xff'] und [<Addr_von_RB>,Port 23,'0xff']
     ("Strom an") an den GW gesendet, andernfalls
 *** [<Addr_von_RA>,23,'0x00'] und [<Addr_von_RB>,23,'0x00']
     ("Strom aus").

* Der GW empfängt die Messages vom ZR, macht jeweils eine Busnachricht 
draus und legt selbige auf den Bus.

* Die Empfängerknoten RA bzw. RB nehmen die Nachrichten an und reagieren 
entsprechend (Parametersätze...), d.h. sie schalten den Strom jeweils 
entweder an oder aus.

Der Ablauf ist zusammengefasst also folgender:
 1. Taster-Kontakt schließt
 2. RA sendet
 3. GW nimmt Message entgegen, sendet an ZR
 4. ZR: Server-SW delegiert Ereignis an entsprechendes Behavior-Modul
 5. Behavior-Modul aktualisiert interne Zustandsvariable und sendet
    Nachrichten an GW
 6. GW legt Nachrichten auf den Bus
 7.1 RA empfängt Nachricht und reagiert
 7.2 RB empfängt Nachricht und reagiert
  (oder eben andersrum, is ja auch wurscht)

(Selbstredend, soll's in meinem System auch sowas wie passive Sender 
(also solche, von denen man einen Wert erst auf explizite Anfrage hin 
bekommt) und auch Mischknoten mit Ein- UND Ausgängen geben)

Man könnte jetzt argumentieren: 'was du mit drei Messages machst, kann 
ich mit einer!' Nur wenn man sich den Fehlerfall mal anschaut, dann 
sieht die Welt ganz anders aus: Angenommen, entweder RA oder RB überhört 
die direkte Nachricht von SA. Die Folge wäre, z.B. daß eine Lampe (A) an 
ist, die andere (B) aus. Bei nochmaligem Drücken des Tasters wäre B an 
und A aus.
Faktisch gäbe es keine Möglichkeit (außer dem manuellen Eingreifen auf 
RA oder RB) wieder beide Lampen gleichzeitig ein bzw. aus zu schalten.
Das Problem und viele andere Proleme einer völlig dezentralen Lösung 
verschärfen sich noch drastisch bei einer steigenden Anzahl, der an 
einem bestimmten Schaltvorgang beteiligten Anzahl von Busknoten. Dann 
braucht man verteilte Agreement-Algorithmen und kriegts mit jeder Menge 
an Concurrency-Problemen zu tun. Viele dieser Concurrency-Probleme sind 
heutzutage noch nichtmal wissenschaftlich erforscht, geschweigedenn 
gibt's ordentliche Lösungen.

Ein weiterer wichtiger Punkt ist, daß die Entwicklung von Software für 
die Busknoten erheblich aufwendiger ist, als z.B. ein Behavior-Modul in 
Java zu tippen. Bootloader hin oder her. In der Praxis ist's alles 
andere als selten, daß der Firmwareupload per Busleitung einfach mal 
schiefgeht, was zur Folge hätte, daß man ggf. sogar wieder direkt 
physisch an die Busknoten ran muß...

Drum ist mein Credo: "concurrency vermeiden", Komplexität da ansiedeln, 
wo sie leicht(er) handhabbar ist, modularisieren, modularisieren und 
nochmal modularisieren...



> Wieso missbrauchen, das ist doch der Sinn und Zweck der CAN IDs.
> Oder wie meinst Du das?
Nein, das wäre so nicht ganz richtig. Die originale Spezifikation des 
CAN-Buses (PHY und MAC Layer) von der Fa. Bosch sagt, daß der Identifier 
einen Nachrichtentyp (wie z.B. 'Öldruck', 'Temperatur XY', 
'Motordrehzal',...) identifiziert. Eine Nachricht mit dem Identifier 
'12345' kann theoretisch von jedem beliebigen Knoten versendet worden 
sein. Außerdem darf jeder Knoten die Nachricht auch entgegennehmen. Er 
ist deshalb !keine! Adresse. Eine Adresse Identifiziert ein 'bestimmtes 
Etwas' (Entität) eindeutig. -> Ergo mißbrauche ich den CAN-Identifier, 
wenn ich ihn als Adresse verwende.


> Die kommt dann, wenn die Grundlage gut ist und Du das Ganze
> veröffentlichst von alleine. Oder eben nicht, wenn es bessere
> Alternativen gibt. Aber von 0 auf werden nur wenige daran teilnehmen.
Das mit der guten Grundlage war mir schon bewusst, nur fürchte ich, daß 
zum 'Erfolg' eines solchen Projekts noch vielmehr eine ganze Menge Glück 
(Stichwort Nachahmer) erforderlich ist.


> Unser Konzept steht schon relativ fest, daher wird sich eine
> Zusammenarbeit vermutlich auf den Gedankenaustausch beschränken. vermtl.
> kann man auch Detaillösungen austauschen.
Das war mir eben leider noch nicht so richtig bewusst. Aber einem 
Gedankenaustausch gegenüber bin ich, wie man sieht, aufgeschlossen ;-)

vielen Dank für die Antworten und hoffentlich bis bald!
 Tom

[Max M. (maxmustermann)]

Hallo Thomas,
schön zu hören, dass sich noch jemand mit der Thematik beschäftigt! Ich 
bin derzeit auch dabei es mit einer zentralen Steuerung, sprich einem 
PC, zu versuchen und zu schauen wie es funktioniert. Ich wollte anfangs 
auch die Knoten so einfach wie möglich halten und die eigentliche 
Intelligenz in die zentrale Steuerung packen, damit ich Sachen auch 
einfach änderen kann. Die Zuverlässigkeit macht mir hir noch am ehesten 
Sorgen, da alles von einem Superknoten abhängt. Ich wollte es aber so 
machen, dass die Grundfunktionen immer funktionieren und der PC 
lediglich Komfortfunktionen steuert.

Hatte die letzten Wochen wegen ein paar Prüfungen leider etwas wenig 
Zeit weiter zu machen. Zum Glück stehen jetzt die Semesterferien vor der 
Tür :).
Hast du schon irgendwas aufgebaut oder existiert bisther nur das 
Konzept?

lg Max

[Timo E. (tien)]

Hi Thomas W.

> Man könnte jetzt argumentieren: 'was du mit drei Messages machst, kann
> ich mit einer!' Nur wenn man sich den Fehlerfall mal anschaut, dann
> sieht die Welt ganz anders aus: Angenommen, entweder RA oder RB überhört
> die direkte Nachricht von SA. Die Folge wäre, z.B. daß eine Lampe (A) an
> ist, die andere (B) aus. Bei nochmaligem Drücken des Tasters wäre B an
> und A aus.
> Faktisch gäbe es keine Möglichkeit (außer dem manuellen Eingreifen auf
> RA oder RB) wieder beide Lampen gleichzeitig ein bzw. aus zu schalten.

Das ist bei einer stupiden Implementierung natürlich korrekt. Aber 
hierfür gibt es ja durchaus mögliche Lösungen.
- Zum Beispiel könnte der Zustand einer zweiten Lampe vom Zustand der 
ersten abhängig sein. D.h. der erste Aktor empfängt den PushButton Event 
per Broadcast und erzeugt seinerseits einen Event mit dem aktuellen 
Zustand der Lampe. Diesem Zustand folgen alle SlaveLampen, die 
gleichzeitig geschaltet werden sollen. Je nach Buslast und Prio könnte 
das Negative an dieser Lösung sein, dass die SlaveLampen zeitversetzt an 
gehen (wobei ich nicht glaube, dass man das wahrnehmen kann).
- Sollte tatsächlich eine zeitgleiche Steuerung notwendig sein wäre es 
auch möglich in einem Aktor den PushButton Event zu empfangen, den 
Status intern zu invertieren und den Status auf den Bus zu legen und 
sonst keine Aktion zu tätigen. Jeder der nun an diesem Status hängt 
folgt dem Status. Sollte eine Botschaft überhört werden wird beim 
nächsten Schaltvorgang wieder synchronisiert. Das wäre vom Prinzip Deine 
Lösung, allerdings wäre die Zustandshaltung im Netz verteilt.
- Man könnte auch Deine Lösung der zentralen Zustandshaltung nehmen aber 
durch weitere Knoten redundant auslegen.

> Das Problem und viele andere Proleme einer völlig dezentralen Lösung
> verschärfen sich noch drastisch bei einer steigenden Anzahl, der an
> einem bestimmten Schaltvorgang beteiligten Anzahl von Busknoten. Dann
> braucht man verteilte Agreement-Algorithmen und kriegts mit jeder Menge
> an Concurrency-Problemen zu tun. Viele dieser Concurrency-Probleme sind
> heutzutage noch nichtmal wissenschaftlich erforscht, geschweigedenn
> gibt's ordentliche Lösungen.

Ich denke, für meine bescheidenen Dinge die ich tun will wird das kein 
Problem werden. Der Vorteil ist hier, dass wir recht entspannte 
Anforderungen bzgl. Zeit haben.
Aber wie bereits irgendwo hier mal erwähnt ist geplant die 
Komfortfunktionen auch zentral zu bearbeiten. Hier wäre das Gateway ein 
möglicher Platz. Dort ist ein Pic32 geplant, der hätte genug 
Rechenleistung und Speicherplatz für solche Dinge.

> Ein weiterer wichtiger Punkt ist, daß die Entwicklung von Software für
> die Busknoten erheblich aufwendiger ist, als z.B. ein Behavior-Modul in
> Java zu tippen. Bootloader hin oder her.

Naja, so viel aufwendiger ist nun Embedded Code auch wieder nicht - 
zumindest wenn man jeden Tag darin codiert. Was nicht bedeuten soll, 
dass ich nicht gerne in C# oder einer anderen Hochsprache codiere. Aber 
ich will nun mal kein PC oder ähnliches 24/7 durchlaufen lassen. Auch 
wenn es da inzw. recht sparsame Geräte gibt. Und ich bin weiterhin der 
Meinung, das eine dezentrale Lösung auf simplen 8Bit µCs stabiler läuft 
als jede zentrale Steuerung per PC.

Ich verstehe Deine Argumente bzgl. zentraler Steuerung. Und es wird 
damit bestimmt etwas einfacher und übersichtlicher. Aber unsere 
Zielsetzung ist es die grundlegenden Funktionen, welche sich einfach 
beschreiben lassen und vielleicht 70% ausmachen in das Netz zu 
verteilen. Es sollen in den Aktoren Tabellen abgearbeitet werden, welche 
im EEPROM gespeichert sind. In diesen Tabellen werden Wenn-Dann Aktionen 
beschrieben.
Also z.B. "Wenn Event A und Zustand B dann Aktion C". Hiermit kann man 
relativ viele Dinge abhandeln.

Z.B. könnte eine Zeitverzögertes schalten so abgebildet werden:
Wenn Event PushButtonA dann Speichere in Zustand B aktuelle Zeit + X.
Wenn Zustand B gleich Aktuelle Zeit dann Aktion Licht aus

Dies läßt sich dann auch recht einfach grafisch darstellen. Die 
Aktuatoren arbeiten nun bei jedem Event die Liste ab und ändern bei 
Bedarf ihren Zustand.
Alles andere, was sich darüber nicht lösen läßt wäre ein Fall für die 
Zentrale Komfortsteuerung.

> In der Praxis ist's alles
> andere als selten, daß der Firmwareupload per Busleitung einfach mal
> schiefgeht, was zur Folge hätte, daß man ggf. sogar wieder direkt
> physisch an die Busknoten ran muß...

Nö, der Bootloader wird ja nicht gelöscht oder verändert. Das wäre also 
nur bei HW Defekt notwendig oder wenn der Bootloader einen Bug hat.
Funktioniert ja im Kz genauso, wäre ja schlimm, wenn in einem Fahrzeug 
jemand per JTAG ans ESP müsste, weil der Bootloader nicht erreichbar 
ist.
Und zur Änderung der Funktion muss ja eigentlich nicht die Firmware 
geändert werden, sonder die Konfiguration im EEPROM.

>> Wieso missbrauchen, das ist doch der Sinn und Zweck der CAN IDs.
>> Oder wie meinst Du das?
> Nein, das wäre so nicht ganz richtig. Die originale Spezifikation des
> CAN-Buses (PHY und MAC Layer) von der Fa. Bosch sagt, daß der Identifier
> einen Nachrichtentyp (wie z.B. 'Öldruck', 'Temperatur XY',
> 'Motordrehzal',...) identifiziert. Eine Nachricht mit dem Identifier
> '12345' kann theoretisch von jedem beliebigen Knoten versendet worden
> sein. Außerdem darf jeder Knoten die Nachricht auch entgegennehmen. Er
> ist deshalb !keine! Adresse. Eine Adresse Identifiziert ein 'bestimmtes
> Etwas' (Entität) eindeutig. -> Ergo mißbrauche ich den CAN-Identifier,
> wenn ich ihn als Adresse verwende.

Ok, damit hast Du natürlich recht. Zu beachten ist allerdings, das nur 
ein Teilnehmer die ID sendend nutzen darf, sonst kann es Konflikte 
geben. Damit ist es implizit auch eine Adresse des Senders (eben 
eindeutig). Das der Sender weitere Adressen für andere Daten haben kann 
ist klar.


Grüße Timo

[Timo E. (tien)]

Max Mustermann schrieb:
> Hatte die letzten Wochen wegen ein paar Prüfungen leider etwas wenig
> Zeit weiter zu machen. Zum Glück stehen jetzt die Semesterferien vor der
> Tür :).

Hi Max,

schön von Dir zu lesen, hoffe die Prüfungen ware ok!
Wenn Du willst kannste mal ins Wiki auf diese Seite einen Blick werfen 
und kommentieren:
http://code.google.com/p/tech-home-automation/wiki/CanCommunicationProtocol


P.S. derzeit entwerfe ich ein USB2CAN Interface, welches gleichzeitig 
als DevBoard genutzt werden kann. Mein Kollege hat kein Interface und 
bisher auch kein DevBoard, so dachten wir ist das eine gute Gelegenheit. 
Wenn es was brauchbares an Schaltplan gibt stell ich das mal auf die 
Projktseite.

Grüße Timo

[Markus B. (mbp-bayern)]

Hallo Timo.

5V/50 mA linear aus 24V wären schon fast 1W Verlust am Regler.
Da hast Du also völlig recht mit der Auslegung auf Wärme.

Wenn man bedenkt, dass die UP-Dose doch einigermaßen luftdicht ist,
so kann man sich sicher sein, dass die Temperatur der Platinen steigt.
Ob man das in Kauf nimmt, das ist geschmackssache - ich bin dagegen.

Wenn man 24V mit TVS-Dioden absichern möchte,
wie wir schon geschrieben haben, so ist zu bedenken:
Die Spannung an den TVS Dioden kann locker über 30V steigen,
bis ein kräftiger Strör-Impuls begrenzt wird.

Ein Regler, der dauerhaft 30V und kurzfristig min. 40V aushält,
das dürfte daher Pflicht sein - egal, ob Linear oder getaktet.
Der bei mir vorgesehene LT1121 ist dazu nicht im Stande.

Im Datenblatt zum LT3012 habe ich eine Lösung gesehen:
Eine dual ausgeführte Regelung, bei welcher mit einem Digitalpegel
von einem 5V Linearregler für "Standby-Versogung"
auf einen 5V Schaltregler für mehr Strom umgeschalten wird.
 - Es handelt sich nicht um 2 getrennte 5V
 - Die aufgeführte Skizze stellt von
   5,5V bis 60V max. 1A bei 5V zur Verfügung.

Allerdings ist der Preis dafür heiss...
Beide IC's zusammen ca 10€ bei kleinen Stückzahlen.
Mal sehen was es an alternativen gibt.

Im Fall, dass vor dem Einbau klar ist,
ob immer viel strom, oder immer wenig Strom nötig ist,
so kann man das als Bestückungsvariante ausführen.

Um genug Platz für die dual ausgelegte Stabilisierung zu bekommen,
so werde ich die µC-Schaltung komplett überarbeiten.

- Schalter-Anschluss weg
- FET's für Relais weg
- Schraubklemmen + Eingangsschutz weg
- Linear-IC austauschen - gegen einen, der die Anforderungen erfüllt.
- Schaltregler und Befilterung hinzu
- Referenz-Diode für A/D hinzu.
- Frei gewordene Pins auf Stiftleisten legen.

Villeicht ändere ich die Stiftleisten auf SMD,
der RM 2,54 soll aber bleiben.

Dadurch wird das Modul universeller,
der Einbau in meine Hutschinen-Module wird eleganter,
bei 24V und mehr kann das System auch sparsam arbeiten.

An einzelne Schalter anbinden kann ich das dann wieder über eine eigene 
Platine, die dann noch die die weggefallenen Schraubklemmen und den 
Eingangsschutz aufnimmt.

Wenn man sich das genau überlegt überwiegen doch die Vorteile von 24V.
Da ich noch keine Relais gekauft hab, so werde ich auf 24V umplanen.
Ob das bisherige Layout zum Hersteller geht ist also fragwürdig.

Die Zeit, die ich in die Layouts gesteckt hab,
war wenigstens lehrreich, was den Umgang mit Target angeht.

Ich werde Relais auf Hutschine setzen und keine SSS verwenden.
Als Halte-Spannung kann ich dann von 24V auf die VCC umschalten.

Für den Außenbereich habe ich mit enem Schütz
eine Komlett-Abschaltung aller Steckdosen vorgesehen.
Dann muss ich keinen 230V Schütz nehemen,
der seinerseits von einem Relais geschaltet wird.
24V Versionen gibts massig, 12V eher selten bis garnicht.

Falls Du dann auch das µC-Modul für Knoten nehmen möchtest:
Auf einer externen Platine, wie für meine Schalter,
kann man auch die Messung der Stromufnahme pro Knoten
und einen gesteuerten Schaltregler für 12V etc. unterbringen.

MFG:MBP
Markus

[Tien (Gast)]

Hi Markus,

> Wenn man 24V mit TVS-Dioden absichern möchte,
> wie wir schon geschrieben haben, so ist zu bedenken:
> Die Spannung an den TVS Dioden kann locker über 30V steigen,
> bis ein kräftiger Strör-Impuls begrenzt wird.
>
> Ein Regler, der dauerhaft 30V und kurzfristig min. 40V aushält,
> das dürfte daher Pflicht sein - egal, ob Linear oder getaktet.
> Der bei mir vorgesehene LT1121 ist dazu nicht im Stande.
>
> Im Datenblatt zum LT3012 habe ich eine Lösung gesehen:
> Eine dual ausgeführte Regelung, bei welcher mit einem Digitalpegel
> von einem 5V Linearregler für "Standby-Versogung"
> auf einen 5V Schaltregler für mehr Strom umgeschalten wird.
>  - Es handelt sich nicht um 2 getrennte 5V
>  - Die aufgeführte Skizze stellt von
>    5,5V bis 60V max. 1A bei 5V zur Verfügung.
>
> Allerdings ist der Preis dafür heiss...
> Beide IC's zusammen ca 10€ bei kleinen Stückzahlen.
> Mal sehen was es an alternativen gibt.

Schau Dir mal den Recom R-785.0-0.5 an.
Der liegt im gleichen Preissegment:
http://www.voelkner.de/products/82214/DC-DC-Wandler-Innoline-R-785.0-0.5-Sip3.html
Eventl. bekommt man das Ding sogar günstiger:
http://de.futureelectronics.com/de/technologies/electromechanical/power-supplies/dc-dc/Seiten/2793859-R-785.0-0.5.aspx
Allerdings ist mir nicht klar was die mit "Americas Only" im Produkttext 
meinen.

Vorteil dieser Lösung:
Man könnte bei niedriger Busversorgungsspannung einfach einen 7805 
reinlöten. Oder man nimmt eine kleine Platine im 7805 Format mit einem 
Schaltregler drauf, davon gibt es schon Layouts im Netz. Man wäre also 
variabel.
Einzig der Preis ist das negative.

> Um genug Platz für die dual ausgelegte Stabilisierung zu bekommen,
> so werde ich die µC-Schaltung komplett überarbeiten.
>
> - Schalter-Anschluss weg
> - FET's für Relais weg
> - Schraubklemmen + Eingangsschutz weg
> - Linear-IC austauschen - gegen einen, der die Anforderungen erfüllt.
> - Schaltregler und Befilterung hinzu
> - Referenz-Diode für A/D hinzu.
> - Frei gewordene Pins auf Stiftleisten legen.
>
> Villeicht ändere ich die Stiftleisten auf SMD,
> der RM 2,54 soll aber bleiben.

Das wäre mir auch wichtig!

> Dadurch wird das Modul universeller,

Ja.

> An einzelne Schalter anbinden kann ich das dann wieder über eine eigene
> Platine, die dann noch die die weggefallenen Schraubklemmen und den
> Eingangsschutz aufnimmt.

Ich werde keine Schraumklemmen nutzen. Ich werde einfach 0,8mm² Adern 
auf die Platine löten und direkt an die Taster ran. Das kostet nix und 
spart Platz. Da das ganze ja nicht bewegt wird sollte es kein Problem 
sein.

Genauso wird die Busankopplung stattfinden. Derzeit sind in jeder Dose 
vier MiniWago Klemmen drin auf die Adern der EIB Leitung aufgelegt sind. 
Daher auch hier 0,8mm² Adern auf Platine löten, Platine in 
Schrumpfschlauch, anschließen und fertig.

> Die Zeit, die ich in die Layouts gesteckt hab,
> war wenigstens lehrreich, was den Umgang mit Target angeht.

Ich habe nun mit KiCAD angefangen. OpenSource und auch net schlecht.

> Ich werde Relais auf Hutschine setzen und keine SSS verwenden.
> Als Halte-Spannung kann ich dann von 24V auf die VCC umschalten.

Ok, eine mögliche Lösung, aber wie gesagt, ich will, wo möglich für 230V 
kommerzielle Ware mit CE usw. einsetzen. Und die SSS und Dimmer sind ja 
schon eingebaut.

> Für den Außenbereich habe ich mit enem Schütz
> eine Komlett-Abschaltung aller Steckdosen vorgesehen.
> Dann muss ich keinen 230V Schütz nehemen,
> der seinerseits von einem Relais geschaltet wird.
> 24V Versionen gibts massig, 12V eher selten bis garnicht.

Ok. Warum nicht einzelene Relais? Die gehen auch bis 16A, ein Schütz 
muss doch net sein - oder?

> Falls Du dann auch das µC-Modul für Knoten nehmen möchtest:
> Auf einer externen Platine, wie für meine Schalter,
> kann man auch die Messung der Stromufnahme pro Knoten
> und einen gesteuerten Schaltregler für 12V etc. unterbringen.

Solltest Du einen Schaltregler oder den DC/DC layouten, die 
Pfostenstecker und die Bestückung für einen 1 Wire Bus (Dallas DS1820 
Temperatur Sensor), und natürlich den CAN Transceiver vorsehen würde ich 
mich höchstwahrscheinlich bei einer Platinenbestellung mit anschließsen. 
Natürlich wäre es dann gut vor der Bestellung mal den Schaltplan und das 
Layout zu haben.

Ausserdem wäre es mir wichtig, dass Du es erlaubst das Ganze als 
OpenSource auf der Projektseite
http://code.google.com/p/tech-home-automation/
zu veröffentlichen, natürlich unter Nennung Deines Namens, wenn Du das 
willst.

Schreib mal was Du davon hälst :-?

Grüße Timo

[Markus B. (mbp-bayern)]

Tien schrieb:
> Hi Markus,
> Schau Dir mal den Recom R-785.0-0.5 an.
> Der liegt im gleichen Preissegment:
> 
http://www.voelkner.de/products/82214/DC-DC-Wandler-Innoline-R-785.0-0.5-Sip3.html
> Eventl. bekommt man das Ding sogar günstiger:
> 
http://de.futureelectronics.com/de/technologies/electromechanical/power-supplies/dc-dc/Seiten/2793859-R-785.0-0.5.aspx
> Allerdings ist mir nicht klar was die mit "Americas Only" im Produkttext
> meinen.
>
> Vorteil dieser Lösung:
> Man könnte bei niedriger Busversorgungsspannung einfach einen 7805
> reinlöten. Oder man nimmt eine kleine Platine im 7805 Format mit einem
> Schaltregler drauf, davon gibt es schon Layouts im Netz. Man wäre also
> variabel.
> Einzig der Preis ist das negative.
>

Hallo Timo,
die Dinger kenne ich zumindest vom Datenblatt.
Gibt da verschidene Ströme 0,5A und 1A z.B.

Die 3 Löcher auf der Leiterplatte sollten immer am Rand draufpassen.
aber vergiss den echten 7805 - das sind echte Stromverschwender.

>> Villeicht ändere ich die Stiftleisten auf SMD,
>> der RM 2,54 soll aber bleiben.
>
> Das wäre mir auch wichtig!
Aha...
und schon wieder haben wir was übereinstimmendes bei den Interessen.

> Ich werde keine Schraumklemmen nutzen. Ich werde einfach 0,8mm² Adern
> auf die Platine löten und direkt an die Taster ran. Das kostet nix und
> spart Platz. Da das ganze ja nicht bewegt wird sollte es kein Problem
> sein.
>
> Genauso wird die Busankopplung stattfinden. Derzeit sind in jeder Dose
> vier MiniWago Klemmen drin auf die Adern der EIB Leitung aufgelegt sind.
> Daher auch hier 0,8mm² Adern auf Platine löten, Platine in
> Schrumpfschlauch, anschließen und fertig.
>

Hm Ok da wo RM 2,54 reingeht, da bekommt man die Drähte auch rein.


>> Die Zeit, die ich in die Layouts gesteckt hab,
>> war wenigstens lehrreich, was den Umgang mit Target angeht.
>
> Ich habe nun mit KiCAD angefangen. OpenSource und auch net schlecht.

In der Ausbildung hatten wir Eagle,
manchmal gar Corel Draw;
Später hatte ich eine frühe EVAL-Version von Target
(V8, V10 oder so - das war nix fü mich - zu kleine Pin/Pad Grenze.)
Zwischendurch hab ich am MAC G4 versucht GEDA zu verweenden,
aber das lief nicht richtig - mehr Abstürze als arbeiten.

Nach weiteren Versuchen mit Eagle hab ich dann die
PCB-Pool-Version von Target V12 entdeckt.
Vollversion, aber Herstellen nur beim Pool.

Und wie ich das verstehe:
Komplexere Sachen beim selben Hersteller als NON-Pool möglich,
und mittlerweile kommerzielle Nutzung zulässig,
solang man eben bei Beta-Layout fertigen lässt.

Wenn ich mehr zeit hät, so müsste ich mir mal das IBF-Wiki genau 
ansehen,
denn die EMV Simulation/Analyse wär schon noch interessant.


>
>> Ich werde Relais auf Hutschine setzen und keine SSS verwenden.
>> Als Halte-Spannung kann ich dann von 24V auf die VCC umschalten.
>
> Ok, eine mögliche Lösung, aber wie gesagt, ich will, wo möglich für 230V
> kommerzielle Ware mit CE usw. einsetzen. Und die SSS und Dimmer sind ja
> schon eingebaut.

Nun die Relais sind da ja ähnlich - haupsächlich mechanisch höher...
Erst ein Schaub/Steckklemm-Halter mit Relais auf die Schiene geschnappt,
dann an ein Ende die Kleinspannungsleitungen, und am Anderen die 230V AC
Keine 230V auf irgendeiner Platine von mir.


>
>> Für den Außenbereich habe ich mit enem Schütz
>> eine Komlett-Abschaltung aller Steckdosen vorgesehen.
>
> Ok. Warum nicht einzelene Relais? Die gehen auch bis 16A, ein Schütz
> muss doch net sein - oder?

Nun es wird außen auch eine Steckdose für Drehstrom geben,
und da ist es dann schon gut,
wenn alle Leitungen gleichzeitig geschalten werden.
Und wer weiß, was da außer dem Hochdruckreiniger alles angesteckt wird.

Die Waschmaschine hängt an einer Hebepumpe.
Dieses Gefäß muss beim Vorbesitzer schon abundzu übergegangen sein.
(Deutliche Schäden am Putz)

Ein weiterer Schütz schaltet den Strom der Waschküche im Keller,
samt Trockner.
Wasser gibts nur noch über Magnetventile.

Sollte ein Wasserfühler (noch zu bauen) dem Bus sagen,
dass er nasse Füße hat: Sofort alles aus,
auch wenn nur jemand beim Putzen übertrieben hat.

Das TFT-Terminal bekommt 6-8 ringbeleuchtete 19...25mm Edelstahl Taster
für WW + KW + Strom (Innen / und Außen) und kommt in die Waschküche.

Geplant war auch hier 12V für die Beleuchtung, das wird aber 24V,
denn Knöpfe mit 24V müsste es auch schon wieder mehr geben :-)
--> Wieder was für Deine 24V Idee.

Vermutlich wird eine Frontblene für das Terminal mit Target "gemalt",
und im Panel-Pool gefertigt.
Da gibts echt schöne eloxierte / Lackierte Bleche,
soweit das die Werbung von denen verspricht.

Das Display wird normal nur in großen Zahlen die Rest-Zeit anzeigen.
Time-Out ändern & Alarm-Reset kann dann über Touch gemacht werden.
(Villeicht auch die Bus-Konfiguration anpassen über dieses TFT)

Und wenn es öfer vorkommt,
dass das System Waschmaschine / Trockner unter "Voll-Last" Abschaltet,
weil der Timeout bei der 2. Ladung Wäsche vergessen wurde,
oder weil zu gut geputzt wird, da würden die Kontakte teils sehr leiden.

Irgendwann lernt man dann schon,
dass beim einlegen der 2. Wäsche eine Zeit-Zugabe
durch nochmaliges drückn am Terminal nötig ist,
und das der Wasser-Sensor nach dem Putzen zu trocknen ist.

2 Schützte 16A benötign 4TE und 6 Relais 5,33TE,
also wieder ein bischen Platz gespart und mehr Lebensdauer gewonnen.
Villeicht kann der 2TE Schütz sogar 4x 16A.


>
>> Falls Du dann auch das µC-Modul für Knoten nehmen möchtest:
>> Auf einer externen Platine, wie für meine Schalter,
>> kann man auch die Messung der Stromufnahme pro Knoten
>> und einen gesteuerten Schaltregler für 12V etc. unterbringen.
>
> Solltest Du einen Schaltregler oder den DC/DC layouten, die
> Pfostenstecker und die Bestückung für einen 1 Wire Bus (Dallas DS1820
> Temperatur Sensor), und natürlich den CAN Transceiver vorsehen würde ich
> mich höchstwahrscheinlich bei einer Platinenbestellung mit anschließsen.
> Natürlich wäre es dann gut vor der Bestellung mal den Schaltplan und das
> Layout zu haben.
>
> Ausserdem wäre es mir wichtig, dass Du es erlaubst das Ganze als
> OpenSource auf der Projektseite
> http://code.google.com/p/tech-home-automation/
> zu veröffentlichen, natürlich unter Nennung Deines Namens, wenn Du das
> willst.
>
> Schreib mal was Du davon hälst :-?

Was ich davon halte:
Nun das ist eine Super Sache;
Für OpenSource bin ich auch zu haben.

Ich werde die Sachen nochmals überarbeiten.
--> Jetzt sollten wir ein Kompaktes "Das muss drauf" erstellen.
bevor ich richtig anfange.

Dann werde ich ändern und wieder auf meinem Server lagern.
Von dort können die Files dann gerne auf deinen Server kopiert werden.

Anmerkung:
Vor langer Zeit hatte ich einmal ein Gästebuch...
und da war nach einem Link im einem Forum Täglich mehr Späääm drin,
als ich an einem Abend löschen konnte.
Abhilfe: Buchtabensalat "captcha"

Ich mag also nur nicht,
dass jeder (Daten-Sammmler) alles per Link direkt runterladen kann,
daher hab ich ja auch im anderen Thread geschrieben:

    Wer wirklich interesse hat, der kann sich die vollständige Doku
    herunterladen und ansehen.
    Zu finden ist sie auf meinem Server - der Pfad dort hin ist in
    CAN___C_Dez2010_Bestueckung.pdf und L1_Kupfer_und_Bauteile.PNG
    angegeben.

--> Ich hab die 2 Doku-Teile nochmal angehängt. (Alter Stand)

Die Target-Dateien sind je im selben Ordner.
Sie haben den selben Namen wie der Rest und wären downloadbar,
aber Dateien mit Endung .Txxx für Target lasse ich vom Listing 
ausblenden,
da es wohl die wenigsten öffnen könnten.
Mit ein bischen Experimentierfreude wäre das sogar zu erraten.

Wenn doch jemand ofiziell ohne experimentieren alles haben will:
--> bescheid geben.

MFG:MBP
Markus.

[Markus B. (mbp-bayern)]

Nun,
was bleibt bei mir drauf ?

- Der µC PIC18F458 (PIC18F4480 und PIC18F4580 passen da auch.)

- HS Quarz in kleiner flacher SMD-Bauform - 4 oder 8 Mhz geplant

- kleiner THT-Röllchenquarz mit 32 KHz

- CAN IC: Standard IC's: SO8 & SO14 High-Speed, SO14 Low-Speed.
  (3 Bestückungsvarianten.)

- Drossel-Spule für CAN.

- Optional Split-Terminmierung bei HS-CAN.

- Der DS1820 (DS18S20, DS18B20 sind Pinkompatibel.)



was muss geändert werden oder was kommt dazu ?

- Ein Linearer LDO-Regler für 5V VCC bis min. 30V, (40V Kurzzeitig)

- Ein Schaltregler für 5V VCC auch bis min. 30V, (40V Kurzzeitig)

- Eingangsfilter L/C für Versorgnug

- Platz am Rand einen billigen 78xx ähnlichen Regler einzubauen.



Brauchen wir auf der selben Leiterplatte ... ?

... Verpolschutz

... Transientenschutz mit TVS und Sicherung an Versorgung ?

... TVS für CAN ?

... ein Extermes EEProm ?
    (Wenn Ja - I2C, TWI oder 1W ?)



Was brauchen wir noch ?

MFG:MBP
Markus.

[Timo E. (tien)]

Hi Markus,

das macht ja richtige Spaß ;-)
Bin sehr gespannt was aus dem Projekt wird!

>> Recom R-785.0-0.5

> Gibt da verschidene Ströme 0,5A und 1A z.B.
> Die 3 Löcher auf der Leiterplatte sollten immer am Rand draufpassen.
> aber vergiss den echten 7805 - das sind echte Stromverschwender.

Ja, da hast Du natürlich recht :-)
Aber wenn wir den Platz irgendwo finden wäre ein Recom ja eine 
Alternative, je nachdem wieviel wir für die Schaltreglerbauteile 
bezahlen müssen.

> Nach weiteren Versuchen mit Eagle hab ich dann die
> PCB-Pool-Version von Target V12 entdeckt.
> Vollversion, aber Herstellen nur beim Pool.

Ja, war auch für mich eine Alternative. Aber da es ein OpenSource 
Projekt sein soll hab ich mich dann doch für KiCAD entschieden.

> Erst ein Schaub/Steckklemm-Halter mit Relais auf die Schiene geschnappt,
> dann an ein Ende die Kleinspannungsleitungen, und am Anderen die 230V AC
> Keine 230V auf irgendeiner Platine von mir.

Ah, ok, jetzt verstehe ich. Das sollte ja dann bzgl. CE, VDE usw. 
genauso ok sein.

> Wasser gibts nur noch über Magnetventile.

Wasser... hmmm... erinnere mich nicht daran... während der Umbauzeit ist 
an einem Freitag ein Wasserrohr geplatzt und am Montag hatte ich es erst 
gemerkt.... 75000 Liter Wasser... (es war ein neuer Wasserzähler 
eingebaut).

So bin ich genau Deiner Meinung, Wasser muss überwacht werden. Dazu habe 
ich mir mittlerweile auch ein paar Gedanken gemacht. Z.B. könnte man den 
Wasserdurchfluß überwachen (z.B. optisch an der Wasseruhr). Läuft Wasser 
ausserhalb bestimmter Kriterien wird abgeschaltet. Dabei könnte man die 
Menge überwachen, wenn eine maximal Menge durch ist wird abgeschaltet, 
wobei dabei natürlich die Veränderungen beachtet werden muss, nicht dass 
das Wasser abgeschaltet wird nur weil Zeitgleich die Klospülung, die 
Dusche und die Waschmaschine läuft. Auch der Gradient wäre eventl. 
interessant. Oder ein dauerhafte, aber ganz langsame Wasserentnahme über 
Nacht (undichte Stelle).

Auch wieder eine Anwendung für einen Node!

>> Schreib mal was Du davon hälst :-?
> Was ich davon halte:
> Nun das ist eine Super Sache;
> Für OpenSource bin ich auch zu haben.

Schön :-)

> --> Jetzt sollten wir ein Kompaktes "Das muss drauf" erstellen.
> bevor ich richtig anfange.

Absolut!

> Dann werde ich ändern und wieder auf meinem Server lagern.
> Von dort können die Files dann gerne auf deinen Server kopiert werden.

Super
Dann werde ich gleich mal zu Deinem weiteren Post was schreiben.


Grüße Timo

[Timo E. (tien)]

> Nun,
> was bleibt bei mir drauf ?
>
> - Der µC PIC18F458 (PIC18F4480 und PIC18F4580 passen da auch.)

Ich würde gerne den PIC18F2685 oder den PIC 18F4685 nehmen. Muss mal 
nachschauen ob die auch pinkompatibel sind...

> - HS Quarz in kleiner flacher SMD-Bauform - 4 oder 8 Mhz geplant

Wir wollen zunächst auf die maximale Frequenz gehen. Da wir ja ein OS 
nutzen geht da halt schon etwas dafür drauf. Aber das sollte ja bzgl. 
Platine kein Problem sein.

> - CAN IC: Standard IC's: SO8 & SO14 High-Speed, SO14 Low-Speed.
>   (3 Bestückungsvarianten.)
ok, bei uns wird es definitiv HS.

> - Drossel-Spule für CAN.
ok

> - Optional Split-Terminmierung bei HS-CAN.
ok

> - Der DS1820 (DS18S20, DS18B20 sind Pinkompatibel.)
ok

> - Ein Linearer LDO-Regler für 5V VCC bis min. 30V, (40V Kurzzeitig)
> - Ein Schaltregler für 5V VCC auch bis min. 30V, (40V Kurzzeitig)
> - Eingangsfilter L/C für Versorgnug
> - Platz am Rand einen billigen 78xx ähnlichen Regler einzubauen.

ok

> Brauchen wir auf der selben Leiterplatte ... ?
> ... Verpolschutz

nö, muss nicht unbedingt sein.

> ... Transientenschutz mit TVS und Sicherung an Versorgung ?

das wäre sinnvoll - oder?

> ... TVS für CAN ?

wäre auch gut.

> ... ein Extermes EEProm ?
>     (Wenn Ja - I2C, TWI oder 1W ?)

würde ich nur machen wenn wir noch Platz haben. Ich denke das interne 
sollte für die meisten Anwendungen reichen.

> Was brauchen wir noch ?

- Hm. Eine kleine LED fürs Debugen wäre gut.
- Und ein SMD Taster vielleicht noch, aber auch nur wenn Platz da ist.
- Und, wichtig, die ICP Pins sollten leicht zum auflöten sein, oder wenn 
möglich sogar auf Pfostenleiste verfügbar.
- Ein Beeper, es gibt so ganz kleine Piezo Teile, das wäre für eine 
Rückmeldung gut. Aber nur bei genügend Platz.
- Im 24V Zweig eine Möglichkeit für einen Shunt. Dieser sollte auf den 
Comparator Eingang gehen, natürlich mit entprechender Beschaltung. Damit 
wäre es eventl. möglich zu erkennen wenn die Versorgungsspannung 
wegbricht. Eventl. reicht uns die Kapazität um noch die Daten ins EEP zu 
speichern. Aber das sollte man mal ausrechnen. Ansonsten wäre auch der 
ADC dafür interessant, damit könnte jeder Node seinen Stromverbrauch 
selbst überwachen.

Mehr fällt mir jetzt gerade nicht ein - ist schon spät...

Bis dann!
Grüße Timo

[Markus B. (mbp-bayern)]

Hallo Timo,

das PDF hab ich überflogen, der Chip scheint auch zu passen.
Das kontrolliere ich aber noch ganz genau.

Was die Kosten angeht, viel billiger wär ja eh nur es beliben zu lassen.
Wir kucken nur auf ganze Euro, nicht auf "Zerquetschte" ;-)
Und dann wirds auch eine sinnvole, langzeitstabile Lösung.

Nen kleine Pieper kenn ich, der will ne PWM, dass es piept.
10mm hat der nicht im Durchmesser, irgenwdo 5 schätz ich,
hoch wär er auchned.

Für den Fall dass was kurz vor knapp im EEPROM gesichert werden soll:
Da benötigt man vermutlich (zu) viel "Vitamin C" um das durchzuhalten.
Es seidenn der PIC wär da so schnell, dass er im 3 mSec Bereich liegt,
Bzw. das ganze braucht wirklich keinen Strom...
Man kann notfalls noch irgendwo nen fetten Elko dranlöten,
wenn das später wirklich nötig sein sollte,
sofern der Platz in der Dose ist.

Die Abemssungen möchte ich nicht allzzu groß machen.
Ich hab bisher knapp 30 x 40mm - 40 x 50mm könnt ich schaffen.
Dafür muss ich aufpassen, das mir dann nicht wo der Platz ausgeht,
wo ich die CPU einbauen will. (Hutschienen-Module)

Bei den ganzen Ideen könnte man villeicht ein Sandwich machen,
das flach aus 2 Platinen besteht. (DC/DC Netzeil + Shunt eigens)
Zusammenlöten fände ich schlecht, falls man da doch dazwischen muss.
Es gibt aber zumindest Buchsen, die man in Lötaugen einlötet,
so dass sie nicht mal 1 mm hoch auftragen.
Mal sehen was da Sinn macht.

Dann noch ein schönes Wochenende.
Ich werd morgen noch nicht viel schafffen,
dann ist das WE eh schon wieder vorbei.


PS:
ein Wertvoller OP-AMP: LT1490 - kann Eingang über V+.

MFG:MBP
Markus.

[Thomas W. (tomiondrums)]

Hallo Max,
> schön zu hören, dass sich noch jemand mit der Thematik beschäftigt! Ich
> bin derzeit auch dabei es mit einer zentralen Steuerung, sprich einem
> PC, zu versuchen und zu schauen wie es funktioniert. Ich wollte anfangs
> auch die Knoten so einfach wie möglich halten und die eigentliche
> Intelligenz in die zentrale Steuerung packen, damit ich Sachen auch
> einfach änderen kann. Die Zuverlässigkeit macht mir hir noch am ehesten
> Sorgen, da alles von einem Superknoten abhängt. Ich wollte es aber so
> machen, dass die Grundfunktionen immer funktionieren und der PC
> lediglich Komfortfunktionen steuert.

Sorry, daß ich erst jetzt antworte, ich hab dein Posting irgendwie 
übersehen...
Meine Gründe für das Konzept mit der zentralen Steuerung hab ich ja 
schon angerissen -- eine vollständig Abhandlung würde vermutlich noch 
deutlich länger.

Apropos länger: Dieser Thread ist schon so ellenlang, daß ich eigentlich 
nur noch am scrollen bin. Ich denke es wäre, um das alles hier nicht zum 
Zusammenbruch zu bringen, besser, wir würden noch einen separaten Thread 
aufmachen (alternativ könnte ich auch ein ganzes Forum anbieten -> pm 
bei Interesse)

Wie weit bist du dann eigentlich schon? Hast du schonmal einen 
Node-Prototypen gebaut? Was hast du für Probleme hinsichtlich der 
"Zuverlässigkeit", welche man bei einem dezentralen System nicht hätte, 
bzw. welche sich nicht durch geschickte Redundanz lösen ließen?

MfG
 Tom

[Jürgen Harms (Gast)]

Ein paar Bemerkungen zu Euren Argumenten vor dem Hintergrund dessen was 
sich bei mir bewährt hat. Meine Lösung verwendet zwar Atmel AT90CANxxx 
(Programmierung mit avr-libc auf Unix Plattform) - aber diese Argumente 
sind im wesentlichen unabhängig von der gewählten Implementierung. Das 
gibt Euch vielleicht ein paar Anregungen für Eure Arbeit.


Knoten ID <-> CAN Identifier
----------------------------
CAN ist ein Broadcast Bus - es darf nichts ausmachen (kann sogar 
nützlich sein) wenn mehrere Knoten sendend gleiche IDs verwenden. Man 
braucht anfänglich eine ganze Menge Zeit, um sich in diese "Kultur" 
einzuarbeiten, dann aber stellt sich diese Art Adressierung als für 
einen Hausbus ideal heraus.

Ich verwende die CAN-ID im wesentlichen zur Darstellung des Typs der 
Nachricht (die erwähnten Begriffe - Öldruck, Temperatur XY - sind dabei 
schon ein Sonderfall): (a) die hohen Bits bestimmen den Typ, (b) die 
unteren den dazugehörigen Parameter. (a) enthält ein Prioritätsbit, der 
Rest in kodierter Form die Art der Nachricht: z.B. Broadcast (für alle 
von Interesse), Aufforderung Zustandsänderung an Aktorknoten mit 
gegebener Kennzeichnung, Zustandsrückmeldung von Aktorknoten, 
Konfigurationsdaten anfordern (bei mir ist alles dezentral, ausser die 
Konfigurationsbeschreibung und Ereignisliste - die liegen zur Zeit auf 
einem zentralen Knoten, können aber dezentral editiert werden), 
Tageszeit (darf nur der Zeitserver versenden), Nachricht an spezifischen 
Knoten (untere Bits = Knoten ID, "extended" Format - verwende ich z.B. 
zum Schicken von Konfigurierungsdaten and den Knoten der sie angefordert 
hat, eine numerierte Serie von Paketen - damit mogle ich und vermeide 
ein verbindungsorientiertes Protokoll bauen zu müssen).

Knoten ID ist bei mir eine reine Notion der Anwendungssoftware, im 
EEPROM gespeichert (neben der "logischen ID" speichere ich
- auch eine "physische ID" - das hilft bei der Verwaltung der 
Prozessoren, das wird schnell ein Flohzirkus den man zähmen muss,
- und eine Knotentyp Kennzeichnung - z.B. Aktorknoten, Displayknoten.

Ich bin davon abgekommen, EEprom zu "Laden": EEprom ist durch ein 
Fusebit (AT90CAN128) gegen Laden geschützt. Nachdem die 128 kBit Flash 
Speicher (aus verschiedenen Gründen verwende ich das als 
Standardsupport) weit mehr sind als ich brauche, wird EEprom 
programmgesteuert initialisiert - dadurch wird die dauerhafte 
Speicherung von IDs auf EEprom leicht gemacht. Ich bin gerade dabei eine 
neue Platine mit FRAM in Schwung zu bringen (mehr Speicher z.B. zum 
Aufzeichnen von Temperaturverläufen, keine komplexen Massnahmen zum 
Schutz des EEprom gegen zu häufiges Schreiben).

Der auslösende Punkt für diese EEprom Strategie war, dass im Knoten 
hardware-spezifische Daten permanent gespeichert werden müssen: z.B. bei 
Knoten, wo die Tageszeit eine Rolle spielt (Ereignisverwalter, 
Displayknoten) verwende ich einen Korrekturmechanismus für die 
Echtzeituhr, damit die Tageszeit möglichtst wenig driftet wenn sie 
längere Zeit nicht jede Sekunde synchronisiert wird - z.B. wenn das DCF 
Signal längere Zeit schlecht ist, oder der Knoten mit dem DCF Empfänger 
gerade neu programmiert wird. Dieser Korrekturmechanismus wird durch 
einen Parameter (Bit-Polynom) gesteuert, der für jede Prozessor-Quarz 
Kombination ein wenig anders ist. Ehe ich diese EEprom Strategie 
einführte, musste ich jedesmal im Quellenkode herumfummeln - was ich 
soundsooft vergass, jetzt ist das nicht mehr nötig.


Protokollkonzept
----------------
Bei mir ein ähnliches Konzept wie in Timos Mail vom 28.1. beschrieben: 
Aktorknoten werden zu Zustandsänderungen aufgefordert (vom 
Ereignisverwalter, von einem Tastenknoten), melden die Zustandsänderung 
mittels Broadcast zurück - das ist wichtig damit z.B. mehrere Anzeige 
LEDs gesteuert werden können, und auch die Anzeige am Displayknoten (ein 
eDIP Touchpanel).

Ich überlege gerade, ob ich nicht besser einen zweiten Ereignisverwalter 
einsetzen sollte - mein Hausbus macht auch "Son et lumiere" für 
Einbrecher, und das ergibt einen Haufen von programmierten Ereignissen, 
wodurch die Übersichtlichkeit der Anzeige am Displayknoten leidet; Ziel 
- dadurch könnte ein Display die händisch zu steuernden Funktionen 
zeigen und kontrolieren, und ein anderes nur für das Einbrechertheater 
(ich habe keine erkennbare Verzögerung zwischen Aufforderung und 
Ausführung - arbeite mit 100 kbps Taktrate).


Zentral - dezentral
-------------------
Total dezentral hätte den grossen Vorteil, das jeder Knoten völlig 
unabhängig neu programmiert werden kann - solange er nur Syntax und 
Semantik des Protokolls respektiert und der Adressraum stimmt. Ich 
wollte das so machen, gab es aber auf, weil zu komplex zu programmieren.

Unter dem Strich gibt es hierzu für mich zwei wichtige Kriterien: (1) 
bei Erweiterungen möglichst wenige Knoten neu programmiern müssen und 
(2) bei der Softwareverwaltung nicht den Boden unter den Füssen 
verlieren.

Ich verwende jetzt eine im wesentlichen dezentrale Zwischenlösung:
- Zustandsdaten am jeweiligen Knoten, mit Broadcast bei Zustandsänderung 
oder nach Abfrage bekanntgemacht),
- zentral verwaltete dynamische Daten (Ereignisbeschreibung) am 
Ereignisverwalter (EEprom gespeichert - in Zukunft FRAM -, überlebt 
Nachladen der Knotensoftware; falls die dafür bestimmte Speicherzone im 
EEprom leer ist, wird eine programmierte Anfangsversion vom Flash 
hereinkopiert),
- statische zentrale Konfigurationsdaten prinzipiell nicht auf 
Aktorknoten gespeichert, ich brauche diese Daten aber im Displayknoten 
und im Ereignisverwalter; Ereignisverwalter und Displayknoten müssen 
daher meistens zur gleichen Zeit neu geladen werden (ich verwende keinen 
Bootstrap über den Bus sondern einfaches Laden), die Aktorknoten müssen 
praktisch nie nachgeladen werden.

Durcheinander bei der Verwaltung der Software vermeide ich durch 
folgende Massnahmen:
- ich habe nur ganz wenige Typen von Aktorknoten, die aber im Makefile 
(ich habe eine Unix Plattform) mit Parametern individualisiert werden;
- jeder Typ von Knoten hat seine eigene Software - inklusive Makefile - 
in einer für den Knotentyp spezifischen Datei; diese Datei enthält nur 
Quellkode für dem Knotentyp eigene Funktionen - alles andere sind 
"Links" in eine Datei mit Systemweiten Modulen (Bibliotheksfunktionen - 
z.B. CANbibliothek und zentrale Definition von Konfigurationsdaten und 
Datenstrukturen/parametern). Das hat sich sehr bewährt.


Konfigurierung
--------------
Ich habe die Idee verworfen, das im Hintergrund ein PC zur 
Konfigurierung nötig ist. Wenn ich einen neuen Knoten einführe - das 
geschieht relativ selten - werden die Konfigurationsdaten im Flash des 
Ereignisverwalters und des Displayknotens neu programmiert.

Ereignisse (hinzufügen, löschen, ändern) erfolgt am Displayknoten mit 
einer graphischen Benutzerschnittstelle (eDIP Touchpanel - die 240 x 128 
Pixel reichen gerade alles nötige unterzubringen; ich möchte gerne auf 
320 x 240 ausbauen, aber das ist noch einmal teurer und Arbeit die ich 
bisher vermieden habe).

(Das Programmieren von Ereignissen ist natürlich nur eine Aufgabe des 
Displayknotens - seine normale Funktion sind die Anzeige von Zuständen 
der Aktorknoten, Temperaturen, Datum und Zeit, und GUI gesteuerte 
Schalterfunktion für alle Aktorknoten).

Fernwunsch ist, eine Brücke zu meinem Lan (Ethernet) zu implementieren, 
aber bisher waren immer andere Erweiterungen wichtiger (z.B. die 
Entwicklung einer neuen Platine mit FRAM, eine Log Einrichtung für z.B. 
Temperatur, und vor allem: schöne Kästchen bauen - ich habe viel zu viel 
¨unangezogene¨ Platinen: wenn etwas läuft, ist die Versuchung gross den 
Zeitaufwand für den Kästchenbau aufzuschieben).


Stromversorgung
---------------
Da bin ich radikal anderer Meinung: Stromversorgung hat auf der 
Knotenplatine nichts zu suchen. Meine Platinen wollen geregelte 5V. 
Entweder kommt die Versorgung über den Bus - bei mir 12V, mit 
Schaltregler IC im Verzweigerkästchen, wo der Knoten am Bus 
angeschlossen ist, oder aus der vom Knoten gesteuerten Anwendung - wenn 
die sowieso einen 235 V Anschluss mit Netzteil hat.

Ich verwende praktisch nur Schaltnetzteile (z.B Traco - aber da gibt es 
immer wieder neue billigere) für die Erzeugung der "Rohversorgung" mit 
12V (an einer Stelle, wo ich einen richtigen Schütz betreiben muss, sind 
es 24V - im allgemeinen reichen 12V Kammrelais) und Schaltregler (auch 
ich verwende die Recom R785 Teile) für das Herunteregeln der vom Bus 
kommenden Rohversorgung auf die "guten" 5V für die Knoten . Dazu kommen 
DC-DC Wandler für die galvanische Trennung eines Stichbusses durch den 
Garten, wo der Koppler gartenseitig natürlich auch 5V braucht. Nicht 
ganz billig, aber erschwinglich.

[Timo E. (tien)]

Hallo Jürgen,

vielen herzlichen Dank für Deine ausführliche Beschreibung. Sehr 
interessant! Gibt es eine Internetseite, auf der das Ganze dargestellt 
wird?
- Wieviel Knoten betreibst Du derzeit?
- Seit wann ist das System im Betrieb?
- Hast Du ein Fallback, wenn der Bus gestört ist?

> Knoten ID <-> CAN Identifier
> ----------------------------
> CAN ist ein Broadcast Bus - es darf nichts ausmachen (kann sogar
> nützlich sein) wenn mehrere Knoten sendend gleiche IDs verwenden.

Da muss ich Dir widersprechen! Der CAN ist zwar ein Broadcast Bus, aber 
eine CAN ID (11Bit oder 29Bit) darf nur von einem Teilnehmer genutzt 
werden! Dies ist wegen der Arbitierung zwingend notwendig. Wenn der Fall 
eintritt, dass zwei oder mehr Knoten mit der gleichen ID zur gleichen 
Zeit auf dem Bus senden kommt es spätestens beim Dateninhalt zu 
Konflikten da keiner der beiden feststellen kann, dass es noch einen 
anderen Sender gibt.
D.h. eine Message wird nicht gesendet (die Bits werden überschrieben), 
ein Ackn gibt es dennoch, aber für die Message des anderen Senders und 
der Sender der weggedrückten Message meint alles ist ok - das ist nicht 
gut!

> Man braucht anfänglich eine ganze Menge Zeit, um sich in diese "Kultur"
> einzuarbeiten, dann aber stellt sich diese Art Adressierung als für
> einen Hausbus ideal heraus.

Ich habe seit mehreren Jahren beruflich mit CAN und FlexRay zu tun, so 
ist mir die "Kultur" bekannt ;-)

Schau Dir mal diese Seite an:
http://code.google.com/p/tech-home-automation/wiki/CanCommunicationProtocol

Hier wird das von uns definierte Protokoll beschrieben.
Die Seite ist noch stark im Fluß und im Aufbau, so wird in den nächsten 
Monaten noch das ein oder andere dazu kommen. Noch ist die SW nicht 
produktiv einsetzbar, aber wenn die Basis SW (RTOS, Bootloader, COM, 
...) fertig ist könnte man die erst Applikation darauf zum Laufen 
bringen.

> Ich bin davon abgekommen, EEprom zu "Laden": EEprom ist durch ein
> Fusebit (AT90CAN128) gegen Laden geschützt. Nachdem die 128 kBit Flash
> Speicher (aus verschiedenen Gründen verwende ich das als
> Standardsupport) weit mehr sind als ich brauche, wird EEprom
> programmgesteuert initialisiert - dadurch wird die dauerhafte
> Speicherung von IDs auf EEprom leicht gemacht.

Hm, das hab ich nicht ganz verstanden. D.h. Du verwendest im laufenden 
Betrieb kein EEProm? Speichern Deine Knoten nicht den aktuellen Zustand?

> (ich verwende keinen
> Bootstrap über den Bus sondern einfaches Laden), die Aktorknoten müssen
> praktisch nie nachgeladen werden.

Wie machst Du eine Reprogrammierung der NodeSW? Sind Deine Nodes auch in 
Schalter- bzw. Steckdosen untergebracht?

> Stromversorgung
> ---------------
> Da bin ich radikal anderer Meinung: Stromversorgung hat auf der
> Knotenplatine nichts zu suchen. Meine Platinen wollen geregelte 5V.
> Entweder kommt die Versorgung über den Bus - bei mir 12V, mit
> Schaltregler IC im Verzweigerkästchen, wo der Knoten am Bus
> angeschlossen ist,

Das geht bei mir schon alleine wegen der Leitungslänge und der damit 
verbundenen Spannungsverluste nicht. Ich habe nur ein max. zwei Punkte 
an denen ich ein Schaltnetzteil an den Bus anschließen kann. D.h. die 
Spannung muss definitiv höher sein als die vor Ort benötigten 5V.

> oder aus der vom Knoten gesteuerten Anwendung - wenn
> die sowieso einen 235 V Anschluss mit Netzteil hat.

Ein Knoten, der z.B. in eine Steckdose eingebaut wird, um diese zu 
schalten hat bei uns keine direkte Verbindung zur Netzspannung. Als 
Schaltelement verwenden wir ein kompaktes Stromstoßrelais (z.B. von 
Eltako), welches mit in die Dose kommt. Vorteil ist außer dem 
Platzbedarf die strikte Trennung Bus - Netzspg (Sicherheit!). Es gibt 
nur einen Punkt, und das ist mein Schaltnetzteil in der Hauptverteilung. 
Ob das eine (viele Netzteile) oder andere System (ein Netzteil) 
Stromsparender wäre eine interessante Frage


Grüße Timo

[Juergen H. (harms)]

Hallo Timo - das wird eine interessante Diskussion

> Gibt es eine Internetseite, auf der das Ganze dargestellt wird?
Leider habe ich mir die Mühe bisher nicht gemacht - war kein Anlass 
dazu. Aber ich habe eine Menge interne Dokumentation, liesse sich 
machen. Ich habe nur meine CAN Bibliothek hier in der 
Anwendungsbibliothek dokumentiert und abgelegt.

> Wieviel Knoten betreibst Du derzeit?
10

> Seit wann ist das System im Betrieb?
Mehr als 2 1/2 Jahre (mein erster Eintrag ins CHANGELOG datiert vom 
1.6.2008)

> Hast Du ein Fallback, wenn der Bus gestört ist?
Nein, ich habe aber bewusst keine vitalen Funktionen angehängt (nicht 
Heizung, z.B.). Diese Defensivität is weniger weil ich vor Bus Ausfall 
Angst habe, als dass meine Frau kalt habe könnte wenn ich einmal einen 
Autounfall habe und sie einen der Knoten zu energisch abstaubt. Auch war 
wohl mein Vertrauen anfänglich weniger gross als heute (gesteuert werden 
verschiedene Aussenlampen, Rasensprengerkreise, Biotop Pumpen und 
Nachfüllung; auch Temperaturanzeige ist eine sehr geschätzte Funktion - 
aber ohne all dass könnte man überleben).

Ich hatte bisher nie einen Busausfall, dass schlimmste waren zwei oder 
drei Fehlverhalten zufolge Programmierfehler im Display. Die 
Kontaktknoten sind watscheneinfach und gut "durchschaubar", komplex und 
ist die Ereignissteuerung, die Übermittlung von Ereignisdaten zwischen 
Ereignisknoten und Displayknoten, und die Anzeige am Displayknoten - 
aber, touch wood. Natürlich habe ich ein getrenntes Bastelsystem, auf 
dem alles auf Herz und Nieren geprüft wird ehe es ins 
"Produktionssystem" geht.

>> CAN ist ein Broadcast Bus - es darf nichts ausmachen (kann sogar
>> nützlich sein) wenn mehrere Knoten sendend gleiche IDs verwenden.

> Da muss ich Dir widersprechen! Der CAN ist zwar ein Broadcast Bus, aber
> eine CAN ID (11Bit oder 29Bit) darf nur von einem Teilnehmer genutzt
> werden! Dies ist wegen der Arbitierung zwingend notwendig. Wenn der Fall
> eintritt, dass zwei oder mehr Knoten mit der gleichen ID zur gleichen
> Zeit auf dem Bus senden kommt es spätestens beim Dateninhalt zu
> Konflikten da keiner der beiden feststellen kann, dass es noch einen
> anderen Sender gibt.
> D.h. eine Message wird nicht gesendet (die Bits werden überschrieben),
> ein Ackn gibt es dennoch, aber für die Message des anderen Senders und
> der Sender der weggedrückten Message meint alles ist ok - das ist nicht
> gut!

Danke, das ist sehr hilfreich. Da klärst Du mich über eine Schlamperei 
beim Lesen und Denken auf - ich hatte zu sehr auf Netzwerkebene gedacht, 
und nicht dass ich da im Mac-level Sünden begehen könnte. Ich bin mir 
nicht sicher, ob so ein Fall bei mir wirklich vorkommen kann - ich habe 
bisher absolut keine Probleme beobachtet. Aber, wie gesagt, ich hatte 
beim Konzipieren ein inkorrektes Modell im Kopf und muss jetzt trotzdem 
über die Bücher gehn und prüfen.

> Schau Dir mal diese Seite an:
> http://code.google.com/p/tech-home-automation/wiki...
> Hier wird das von uns definierte Protokoll beschrieben.

Danke, werde ich tun Umgekehrt, falls das für Euch noch von Interesse 
ist, kann ich Euch einmal die Kopie der Datei mit Protokolldokumentation 
schicken.

> ... aber wenn die Basis SW (RTOS, Bootloader, COM, ...) fertig ist ...
Das interessiert mich sehr - vielleich kann ich da ein wenig "abschaun", 
z.B. falls ich einen Bootloader einsetzen will, aber vor allem das RTOS 
interessiert mich. Meine Lösung verwendet eine Idle-Loop mit Callback 
Funktionen. Da habe ich anfänglich gemogelt und es lief dann so gut, 
dass ich nie eine auf eine solide Lösung mit von einm RTOS verwalteten 
Prozessen umgestiegen bin - das steht ziemlich oben auf der Liste.


>> Ich bin davon abgekommen, EEprom zu "Laden": ...

> Hm, das hab ich nicht ganz verstanden. D.h. Du verwendest im laufenden
> Betrieb kein EEProm? Speichern Deine Knoten nicht den aktuellen Zustand?

Doch, ich speichere den aktuellen Zustand der Ereignisliste, und spiele 
sie nach eine Neustart nach. Händisch ausgelöste Zustandsänderung gingen 
bei einem Stromausfall verloren - das stört mich nicht. Aber, das steht 
auf der "todo" Liste wenn die neuen FRAM Knoten kommen. Bei der 
Speicherung der Ereignisliste in EEprom betreibe ich einigen Aufwand mit 
Zwischenspeicherung in RAM und Alterung ehe sie auf EEprom migrieren - 
vielleicht bin ich bezüglich Abnützung von EEprom ein wenig paranoid - 
ich bin sicher nicht paranoid beim Vermeiden vermeidbarer Komplexität 
(und diese Alterung ist ein wenig komplex) - ein Grund für die 
Einführung von FRAM

>> (ich verwende keinen Bootstrap über den Bus sondern einfaches Laden)

> Wie machst Du eine Reprogrammierung der NodeSW? Sind Deine Nodes auch
> in Schalter- bzw. Steckdosen untergebracht?

Wie gesagt, meine Aktorknoten werden praktisch nie re-programmiert. Ich 
habe einen in einer Unterputzdose, den habe ich in den 2 1/2 Jahren 
einmal zum Reprogrammieren ausbauen müssen. Ereignisknoten und 
Displayknoten sind leicht zugänglich, die wandern manchmal zum 
Reprogrammieren - das war bisher weniger Aufwand als die Investition in 
einen Bootloader - vielleicht ist das zu Überdenken.

>> ... kommt die Versorgung über den Bus ...

> Das geht bei mir schon alleine wegen der Leitungslänge und der damit
> verbundenen Spannungsverluste nicht. ...

Da habe ich mich zu wenig klar ausgedrückt: ich habe die 12V Versorgung 
nicht systematisch durchgeschleift, sondern nur jeweils auf einem 
Segment in Nachbarschaft eines versorgten Knotens - im allgemeinen nicht 
mehr als ca. 10 m, und nur geringe Leistung (die schlimmsten Verbraucher 
bei über den Bus versorgten Knoten sind ein paar LEDs, keine Relais) - 
ich habe einmal gemessen: ich verliere ein paar Zehntel Volt.

Trennung 235V - Niederspannung: ich teile voll Deine Meinung, habe 
strikte Trennung in der Verrohrung und nirgends CAN Knoten in der 
gleichen UP Dose mit 235 V. CAN Knoten in UP Dosen gibt es nur für 
Taster und LED Anzeigen. Mein Bus kam lange nach dem Hausbau, 
traditionelle Schalter hängen nicht am Bus. 235V wird vom Bus nur in 
eigens dafür gebauten Einheiten geschaltet. Für meinen Einbrecherzirkus 
muss ich z.B. momentan noch Stecker umstecken ehe ich länger weggehe - 
aber das ist natürlich nur eine Verlegenheitslösung bis ich Zeit habe 
das zu verbessern.

[Markus B. P. (MBP-Bayern) (Gast)]

Hallo zusammen.

Ich hatte die vergangenen Tage nur weing Zeit übrig,
aber was die Überarbeitung meiner µC-Platine angeht:

Das neue Höchst-Maß darf ca. 45 x 38 mm nicht überschreiten,
denn sonst wird es sogar in der UP-Dose zu eng.
Was aber im Vergleich zum bisherigern Platz von 38 x 28 mm
immer noch eine enorme Steigerung ist.

Rund finde ich eher unpraktisch,
aber die Ecken kann ich villeich noch abschrägen.
Was meint Ihr dazu ?

Den LDO-Regler werde ich nun doch ersatzlos streichen.
Der Schaltregler MAX5035 aus dem Vorschlag vom Max ist effizient genug.
Er benötigt lt. Datenblatt auch kaum Ruhestrom.

Er taktet (leider) nur mit 125 KHz
Das bringt aber eher mehr Vorteile:
   z.B. besseres EMV-VErhalten und höhere Effizienz.
als Nachteile:
   Platzbedarf
   z.B. größere Spule nötig.
(aber dafür wird ja kein LDO mehr eingesetzt)

Die Standard-CAN-Spule wird vermutlich durch:
   Epcos B82789C0104N00(2)/(1)
   0A15
   250V
   smd_4pin_5.2x3.2x3mm(LxBxH)
   EIA 1812
ersetzt. (Kleiner)

------------------------------------------------------------------------ 
---
------------------------------------------------------------------------ 
---
ACHTUNG:
Wegen sehr häufiger Abstürze ist mein Server selten bis nicht zu 
erreichen.
Die von mir genannten Hausbus-Links sind vorübergehend nicht zu 
erreichen.
Somit kann ich auch keine PN/Email aus diesem Forum erhalten.
Sicher ist nur, dass es keine aktiven Angriffe aus dem Netz sind,
die das verursachen, denn selbst ohne Netzwerk "friert" der Server ein.
Näheres werde ich am Wochenende ermitteln.
------------------------------------------------------------------------ 
---

Dies ist für mich Grund genug, bei meiner Meinung "PC & BUS" zu bleiben:
90-99 % aller Bus-Funktionen müssen ohne irgendeinen PC / Server 
funktionieren.


MFG:MBP
Markus.

[Timo E. (tien)]

Hallo Markus,

kannst Du für den Anschluß der Busadern (0.8qmm) und der Versorgung 
jeweils ein Loch in der Platine als Zugentlastung vorsehen. Also Ader 
durch das Loch und dann umbiegen und einlöten.
Eventl. auch noch für bis zu 6 Eingänge, für Taster, dann könnte man bei 
einfachen Tasterknoten auf
eine zweite Platine verzichten.

Bezgl. Abmessungen finde ich eckig mit abgeschrägten Kanten auch gut. 
Ich will die
Platine in Schrumpfschlauch einpacken,
daher ist rund eh nicht optimal.

Grüße Timo

[Markus B. P. (MBP-Bayern) (Gast)]

Timo E. schrieb:
> kannst Du für den Anschluß der Busadern (0.8qmm) und der Versorgung
> jeweils ein Loch in der Platine als Zugentlastung vorsehen. Also Ader
> durch das Loch und dann umbiegen und einlöten.

Hallo Timo,
das lässt sich sicher machen.

> Eventl. auch noch für bis zu 6 Eingänge, für Taster, dann könnte man bei
> einfachen Tasterknoten auf
> eine zweite Platine verzichten.

Für die 8 IO's RD0 - RD7 werde ich SMD PULL-UP
auf der Leiterplatte einplanen.
Daran kann man dann ggf. Taster anschließen,
wenn auch keinerlei Schutz an diesen Pins geplant ist.

Eine andere Möglichkeit aber eben als eigene Platine:
TWI-Erweiterung mit Schutzbeschaltung und Interrupt.
Eingänge für Taster / Schalter --> PCF8574.
Beleuchten mit LED --> PCA9531.

PCA9531:
einfacher 8-bit I2C LED dimmer (SO16)
Kann nur PWM dimmen bis 160Hz oder Blinken bis 1,6 Sek.
Die LED's benötigen den normalen Vorwiderstand.



Im Anhang der erste Entwurf für die neue Portbelegung.
(Text, TAB getrennt)

MFG:MBP
Markus.

[Tien (Gast)]

Hi Markus,

sehr schöne Deine Portbelegungsliste.

Ein Vorschlag dazu:

Wir würden gerne zur Überwachung der 24V auf Spannungseinbruch einen 
Comparator verwenden, da der dann ein Interrupt auslösen könnte. Den ADC 
müsste man ständig aktiv pollen, was im worst case 5ms bis 10ms bis zur 
Reaktion verschwendet. Ich gebe die Hoffnung noch nicht auf bei einem 
Spannungsausfall eventuell noch die RAM Daten ins EEP zu sichern. Durch 
den Schaltregler haben wir ja immerhin ca. 14V Differenz (bei einem 
Interrupt bei 20V), die erst mal abfallen müssen. Eine Diode und danach 
ein C am 24V Eingang wäre dann aber Voraussetzung. Ist aber weiterhin 
ein Bauchgefühl, müsste man mal ausprobieren.

Event. wäre der Anschluß eines ADC Eingangs parallel dazu auch nett, 
dann könnte der Knoten den Strom selbst überwachen und bei zuviel Strom 
eine Warnmeldung ausgeben.

Was meinst Du, ist das noch möglich bei Deinem Layout/Schaltplan?

Die I2C Chips sind ja nett, das wäre ein Grund über einen I2C Treiber in 
der Basis Software nachzudenken.


Grüße Tien

[Timo E. (tien)]

Hallo Markus,

warum hast Du einen OPAmp für die Stromaufnahme vorgesehen?
Sollte eigentlich auch über einen Spannungsteiler funktionieren. Die 
Differenzspannung könnte man ja per SW rechnen. Also vor dem Shunt per 
Spannungsteiler den einen ADC Kanal und den Comparator anschließen. Nach 
dem Shunt ebenfalls ein Spannungsteiler an einen anderen ADC Kanal.

Grüße Timo

[Timo E. (tien)]

Hi Markus,

noch ein paar Anmerkungen, welche beim Gespräch mit Christian kamen:

1. Tastereingänge, wenn möglich noch mit Serienwiderstand. Eventl. 
kannst Du die ja durchverbinden, so dass man zwischen den Pads eine 
dünne Leiterbahn bei Bedarf öffnen und einen Widerstand bestücken kann

2. Hast Du eine Verbindung zw. CAN Transceiver und PIC für den CAN 
WakeUp vorgesehen? Er sollte auf einem Interrupteingang liegen.
Den CAN Error könnte man auch auf einen IO legen.

3. Ich vermute, dass Du daran denkst, dass auf den Stiftleisten die 
Spannungsversorgung liegen muss ;-)


Grüße Timo

[Markus B. P. (MBP-Bayern) (Gast)]

Hallo Timo;

Op-Amp:

Mit einem Shunt und den 10 Bit ADC Auflösung,
da könnte das schon irgendwie
zum Schätzen der Stromaufnahme des kleinen Controllers genügen.

Aber ich bin der Meinung, dass sich nichts die 24V "greifen" darf,
ohne dass es über den Shunt und ggf. über die Sicherung geht.

Der Schaltregler für 5V darf 1A --> 5W.
Macht bei 24 V ca 200 mA.
Bei 1V am Shunt sind das 0,2W - nicht schön aber ok,
wenn man bedenkt, dass es wohl selten vorkommt.

Bei den 24V Schützen schätze ich mal je 0,5A kurzzeitig,
bis ich das auf 5V Haltesapnnung runterschalte.
Oder ein 12V Aufsatz für Deine Weihnachtsbeleuchtung:
(Beides Externe Technik, versorgt & bewacht vom Can-µC)

Dann sind wir wohl schnell bei (oder gar über) 1A @ 24V.

Wenn ich nun "nur" 1V Abfall am Shunt zulasse,
so ist das schon 1W in der Dose verheizt.
Diesmal an manchen Tagen sogar eher mehr als weniger lang.
Noch weniger schön.

Um die Spannung vor / Nach dem Shunt aufzubereiten:
24V bei 4,1V Ref. da ergibt sich ein Teiler von mindestens 6:1.
Nehmen wir also 10:1, dann darf es auch mal einiges mehr als 24V sein
und man kann schön rechnen.

Was bleibt von unserem Volt Differenz noch Über ?
1,0V : 10 --> 0,1V.

Sollen wir dafür den OpAmp Sparen und einen 2. AD-Eingang nehmen ?

Denn soweit ich das Datenblatt gelesen habe,
soweit ist mir nicht aufgefallen, dass der PIC18 aus 2 ADC-Eingängen
über "Differential gain" einen AD-Wert wandeln kann,
was ich von den Atmel Mega AVR kenne.



/* *******************************************************************
OffToppic:

Je mehr ich mich mit PIC18 beschäftige, desto öfters frage ich mich,
warum ich das eigentlich weiterhin tue.

Es gibt viel, das ich von meinen AVR basteleien gewohnt bin,
was ich beim PIC18 nicht so machen kann - Beispiele:

AD-Wandler bei TQFP44 AVR: 8 Kanäle am Stück + eigener REF-Anschluss.
Der Haupt-Oszillator belegt keine IO's
Die Schnittstellen SPI, TWI, RS232 (+XCK) sind bei AVR 3 eigene Module.

Aber es git auch was, was ich am PIC gut finde:
Die Programmierung mit VPP an Reset mit nur 2 IO Pins.
Der integrierte CAN - den benötigen wir sicher.
Interrupt-Prioritäten - villeicht ist das bei uns sogar nötig.
******************************************************************* */



Software-TWI:

Das habe ich beim PIC18 in meiner Portliste vorgesehen,
dass die Hardware SPI frei bleibt.
Jedoch kann man das erst konkret beim Bau von Aufsatzmodulen 
entscheiden.

Bleibt nur zu hoffen,
dass Programm und Strom die Namen der Leitungen nicht erkennen können...
;-)



Komparator:

(Nach Deinem Hinweis hab ich mir das Datenblatt genau angeschaut.)

Der PIC18 hat ein Komparator-Modul,
das benötigt das zu überwachende Signal und eine Referenz;
z.B. 2 Analog-Eingänge.

Diese Möglichkeit hätte ich gern genommen.
Dazu hätte ich einfach einen Spannungsteiler
von 24V auf einen freien Analog-Eingang als Bestückungsoption gemacht.


1. Alternative:

Man verwendet 4 analoge Eingänge,
wovon entweder die einen 2 auf den -IN der 2 Komparatoren sind,
oder aber die anderen 2.
Beide Komparatoren bekommen die Referenz vom Referenz-Modul.
Die Ausgänge können auf 2 Portpins geschaltet werden.


2. Alternative:

ein echter Komparator extern,
für den eigentlich nicht der Platz vorgesehen wäre.
Der aber dann auf einen INT-Eingang.


Auszug aus dem Datenblatt:

PIC18F4685 "39761c.PDF"
"The analog comparator module contains two comparators
that can be configured in a variety of ways. The
inputs can be selected from the analog inputs multiplexed
with pins RA0 through RA5, as well as the on-chip voltage
reference (see Section 21.0 “Comparator Voltage
Reference Module”). The digital outputs (normal or
inverted) are available at the pin level and can also be
read through the control register."


Im Datenblatt kann ich folgendes nicht nachvollziehen:

Die Zeichnung und die Register-Tabellen
beziehen sich nur auf RD0 bis RD3 als Eingänge.

Von den normalen Anlaog-Ports RA0-RA5 habe ich nichts gefunden,
wie man denn diese für die Komparatoren als Eingang verwendet.
Ich vermute, dass das bei diesem PIC garnicht geht.

Könnt Ihr mir da weiterhelfen ?


Der Eingang bekommt
- Sicherung und TVS-Diode zum Schutz.
- Kerkos, Spule und Diode als Eingangsfilter.
- Dann mindestens die Erforderliche Kapazität für den Regler.
- Nach dem Regler erneut Kondensatoren.



Serien-Widerstände:

Villeicht mach ich an alle Controller IO-Pins kleine RC-Filter.
Dazu könnte ich R-Netzwerke nehmen und C's an den Stifleisten,
oder auf dem Leitungsweg dort hin.

http://www.bourns.com/pdfs/bourns_chip_resistors_arrays_sf.pdf



Wake-Up:

SO8 TJA1040 haben sowas nicht und bei anderen weiß ichs nicht.

Der Wake-UP am SO14 TJA1041 / TJA1054 ist dazu da,
dass der CAN-Teilnehmer lokal aufgeweckt werden kann,
wenn keine VCC aktiv ist und ohne dass eine externe Botschaft dies tut.

Aufwecken z.B. über einen Taster / Schalter.
Was da angeschlossen wird,
das muss aber die UBat (bei uns 24V) vertragen.
Im geplanten Layout nur ein Pin an der Erweiterungs-Stiftleiste.



INH = INHIBIT:

Dieser Anschluss ist dazu gedacht,
einen externen Spannungsregler aktiv zu halten,
solange der TJA nicht selbst abgeschalten ist.

Mit dem wollte ich nur den ON/OFF des Schaltreglers ansteuern,
aber keinen IO, der das überwacht oder gar überschreibt.

Höchstens eine Option,
dass UBatt auf INHIBIT mit einem R gebrückt wird,
wenn der SO8 CAN bestückt wird.



Die TJA im SO14 sollten im Übrigen die 24V problemlos vertragen.
Operatng bis 27V, Überleben bei Transienten bis 40V.

Das hätte ich beinahe vergessen das zu kontrollieren,
da ja jetzt 24V statt 12V als Ziel gesteckt sind.



MFG:MBP
Markus

PS:
Spannung an den Stiftleisten:

Nö - das bleibt weg.
Das muss mit Induktion gehen,
denn wozu haben wir eine Spule am Schaltregler ?

Irgendwo müssen wir noch sparen, also sparen wir hier.
:-)

[Helmut (Gast)]

PIC18Fx58 Seite 245 ( AD-Wanldung mit Uref )

http://ww1.microchip.com/downloads/en/DeviceDoc/41159e.pdf

[Markus B. P. (MBP-Bayern) (Gast)]

Helmut schrieb:
> PIC18Fx58 Seite 245 ( AD-Wanldung mit Uref )
>
> http://ww1.microchip.com/downloads/en/DeviceDoc/41159e.pdf

Hallo Helmut,

in dem von Dir aufgeführten Datenblatt steht ein anderer Text über dem 
Komparator.

Der Passt auch zur Zeichnung im Datenblatt zum PIC18F4685.

MFG:MBP
Markus.

[Helmut (Gast)]

Ehrlich gesagt... ich weiß jetzt nicht was auf der Seite falsch steht, 
Uref für die AD-Wandlung wird da beschrieben.

War es nicht das was du gefragt hast?

Ich habe Hugo's CAN-Hausbus umgesetzt, nicht ganz....

Er hatte ein Wakeup über den PortB Interupt gemacht.

Den Prozessor also schlafen gelegt, solange bis jemand einen Taster 
drückt.

Das habe ich nicht gemacht, weil ich einen 18B20 drin habe, dafür einen 
Watchdog.

Da kann man sicher auch noch was mit dem Errorframe-Flags machen.

Aber das ganze gedöns, was du da machst habe ich nicht.

Schaltregler um Leistung zu sparen... habe ich nicht.

Einseitige Platine für die Schalterdose, Hutschienenmodul mit Relais 
auch einsetig.

Das Touchscreen-Bedienmodul ist 2-seitig.

Wenn ich sparen möchte/sollte würde ich bistabile Relais nehmen.

http://www.mikrocontroller.net/attachment/preview/25711/page_snapshots/001.png
Ein bischen kleiner als Raupe es hat:
http://www.mikrocontroller.net/attachment/16969/klein_actor.jpg

[Juergen H. (harms)]

Bei der Diskussion neulich fragte Timo nach Dokumentation über mein 
Projekt - ich habe jetzt einen ersten Teil fertig:
http://cui.unige.ch/~harms/Download/canbus/Projektbeschreibung.html

Ein zweiter Teil "Software" ist geplant - für Euch, weil PIC µC, wohl 
weniger relevant - und wird wohl eine Weile brauchen; vielleicht sollte 
ich schnell zumindest Daten zur Protokollbeschreibung hineingeben, das 
könnte Euch helfen. Meine wesentliche "Message" ist: Projektmanagement 
ist bei so etwas sehr wichtig, und fängt bei den Werkzeugen an.

Und danke, Timo, für den Hinweis auf den Protokollfehler. Beim 
Nachschaun habe ich festgestell, dass so eine Situation nur mit minimer 
Wahrscheinlichkeit auftritt - ist aber jetzt korrigiert, so etwas darf 
einfach nicht hedrumhängen.

[Markus B. P. (MBP-Bayern) (Gast)]

Hallo Helmut,

Eigentlich habe ich nicht nach der Referenz gefragt.

Interessiert hätte mich, wie man die RAxx Ports
als Eingang für den Komparator benutzen kann...

Ich habe noch mehr gekürzt, was ich nicht verstehe
und in den Vergleich zu dem Datenblatt von Dir gesetzt.
(Das hätte ich ohne Deinen Link nicht getan.)

Aus dem Datenblatt, welches ich heruntergeladen habe:
   "... The inputs can be selected from the analog inputs
    multiplexed with pins RA0 through RA5 ..." (neuerer PIC18)

Und das Datenblatt, welches Du verlinkt hast:
   "... The inputs to the comparators are
    multiplexed with the RD0 through RD3 pins. ..." (älterer PIC18)

Bis ich besserem belehrt werde,
solange nehme ich nun an, dass das Komparator-Modul
beim neueren PIC18 die selben Möglichkeiten bietet
und die selben IO's nutzt, wie das vom älteren PIC18.



Deine Fotos sind auch interessant.
Das sieht alles recht locker und luftig gebaut aus.

Ist das auf dem Foto Deine Labor-Anlage,
oder wird das die richtige Steuerung in dieser Anordnung ?

Links oben könnte Dein Eingangs-Modul sein.
Im rechten Gehäuse steckt wohl eine fertige Embedded-Platine ?
Mittig oben eine Anzeigeeinheit.
Mittig unten Dein Relais-Treiber.

Was kommt denn in die beiden Module mit den vielen LED's rein -
Schaltest Du damit Netzspannung ?

Wenn ja, wie ist das denn mit dem Abstand der Leitungen & Klemmen ?
Ich hab mich da nicht ganz genau informiert,
dachte aber dass Klemmen auf ebener Leiterplatte für 230V
5 mm oder mehr Abstand zueinander haben müssen.

Bei mir soll es keine 230V auf den Leiterbahnen geben.
Timo sieht das auch so.
Daher werden wir vorerst keine Gehäuse mit 230V Relais auf Platine 
entwickeln.

Der Ansatz mit bistabilen Relais ist mir nicht unbekannt.

Diese kosten aber mehr Aufpreis in der Anschaffung,
als die komplexere Lösung mit der Umschaltung auf Haltespannung.
Außerdem habe ich das Problem ausgeschlossen,
dass es einen unbekannten Schalt-Zustand geben kann.

Timo hat geschrieben, dass er "SSS" --> "Strom Stoß Schalter" nimmt.
Das ist ja auch bistabil.
Vielleicht benötigt er daher auch den Komparator um Zustände zu 
Speichern.

Ob ich SSS einbaue, das könnte ich erst dann sagen,
wenn ich so ein Ding zerlegt habe, welches 2 Kontakt-Sätze hat.
(1. Kontakt für Netz, 2. für Rückmeldung - Trennung NETZ / Haustechnik)


In vielen Schalterdosen im EG sind bei mir Netzkabel mit dabei.
Da ist es manchmal schon knapp mit den normalen Schaltern.
Daher wird es auch bei mir auf jeden Fall zentrale Eingänge geben 
müssen.

Am besten wäre dann noch, dass die betroffene IO-Zentrale überlebt,
wenn sich ein Kabel mit Kleinspannung vom Schlater löst und 230V 
erwischt.
(Was aber schon ziemlich unwahrscheinlich ist.)

Wenn einige IO dabei kaputt gehen, damit könnte ich leben.
Wenn das IO-Modul stirbt und den Bus blockiert, so wär es nicht schön.
Der Rest vom Bus aber muss einen solchen "Anschlag" überleben.

Diese Zentrale soll eine µC-Platine beinhalten,
genau wie eine UP-Dose, die genug Platz für einen eigenen Knoten hat.

Somit kann ich mit wenig Vielfalt etwas Reserven vorhalten.
Wenn wirklich was kaputt ist, so kann man auch mal was tauschen.

Das EMV kritischste benützt immer die selbe Leiterplatte.
Wenn davon Muster existieren, so wird das EMV-Verhalten grob geprüft.
(Das lasse ich nicht in einem teuren Labor machen, daher ohne 
Protokoll.)
Notfalls wird dann nochmals geändert.


MFG:MBP
Markus.

[Markus B. P. (MBP-Bayern) (Gast)]

Juergen Harms schrieb:
> Bei der Diskussion neulich fragte Timo nach Dokumentation über mein
> Projekt - ich habe jetzt einen ersten Teil fertig:
> http://cui.unige.ch/~harms/Download/canbus/Projekt...

Hallo Jürgen,

Deine Doku ist interessant und informativ.

Deine Verdrahtung erscheint aufgeräumt.
Wenn ich nur in alle 3 Dimensionen überall den selben Platz hätte...
Das FRAM mit SPI ist eine interessante Option.

MFG:MBP
Markus.

[Timo E. (tien)]

Hallo Zusammen,

nur kurz, da ich immer noch Arbeite und gerne bald Feierabend machen 
will :-)

Markus B. P. (MBP-Bayern) schrieb:
> Timo hat geschrieben, dass er "SSS" --> "Strom Stoß Schalter" nimmt.
> Das ist ja auch bistabil.
> Vielleicht benötigt er daher auch den Komparator um Zustände zu
> Speichern.

Richtig, ich habe derzeit SSS installiert. Allerdings hat Max ja 
mittlerweile die Eltako RS485 untersucht und es ist möglich die Dimmer 
als auch die Relais absolut zu schalten, d.h. man kann dem Dimmer den 
Wert in Prozent vorgeben und den Relais den Zustand. Somit werde ich bei 
allen Dingen, die ich automatisieren werde darauf umrüsten. Vorteil: man 
kann die Fallback Strategie einfach mit zwei ReedRelais sicherstellen 
(siehe Skizze).

Grüße Timo

[Helmut (Gast)]

Das ist mein Spielkoffer.
Rechts oben ist ein Webserver und links oben ist was mit Funk ;-)

Hat nichts mit CAN zu tun.

Die Flächenwippen haben unter den Wippen, an der richtigen Stelle 
eingeklebt, normale Microtaster drin.

Das CAN-Bus Projekt von Hugo, das Programm stammt ja von ihm, hat 64 
Relais Möglichkeiten, kann sogar 128 Relais adressieren.

Zum Spielen alle 64 Relais zu bestücken (Flachrelais von Finder), war 
mir zu teuer.
Daher habe ich nur die Anzeige-LED's eingelötet.

Bei mir zu Hause sind, real, 4 Schalterdosenplatinen mit 
Solidstate-Relais

http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=C38;GROUPID=3298;ARTICLE=15441;START=0;SORT=artnr;OFFSET=16;SID=11TU0@N38AAAIAAEGKD2I24494d7be0fc2974dc929336626a1fb5

in der Schalterdose im Probe-Betrieb.

Die "Schwachstrom-Beinchen" sind auf der CAN-Platine, die 230V~ Beine 
haben Lüsterklemmen von L1 zur Leuchte.

Wenn ich wieder mal renoviere kommt mehr an den Bus.

Da spiel' ich zwar auch ab und zu mit den Vieren rum, aber ist 
eigentlich ohne Probleme in Betrieb.

Durch die Solidstate-Relaisanordnung kommt auch keine Power auf's Board.

Versicherungsschutz hat man nur, wenn man den Relaistreiber (im Bild in 
der Mitte unten) mit gekauften Relaisträgern von Finder oä betreibt.

Dann hat man die 230V~ Bauteile in CE und VDE gerechten Bauteilen und 
Versicherungsschutz, weil die gebastelten Teile Kleinspannung haben, 
also kein VDE oä brauchen.

Übrigens ist das Modul mit dem LCD-Display und den Tastern die 
Not/Hand-Bedienung und die Anbindung an RS232 zur Visualisierung 
und/oder ähnlichem.

Nun schreibe ich doch auch so viel wie ihr, wollte ich nicht....
Gruß Helmut

[Max M. (maxmustermann)]

Hallo allerseits,

habe in meinem Beitrag "Re: Dimmer für den Verteilerschrank mit Steuerinterface" ein 
paar Informationen über die Eltako Funk Komponenten FTS12EM Taster 
Eingabemodul, FSA12 Schaltaktor und FUD12NPN Dimmaktor und deren RS485 
Protokoll gepostet.

Gruß Max

[Timo E. (tien)]

Hallo Zusammen,

anbei mal ein paar Bilder - einfach so...

1. Verteilung mit RCDs und LSS
2. Lichtsteuerung mit SSS und Dimmer
(die unsauber verlegten Steueradern werden noch gegen 0,8mm² ersetzt und 
ordentlich angeordnet)
Zwischen der Verteilung und der Lichsteuerung gibt es eine Verbindung 
über drei Leerrohre.
3. Eine Kaiser Elektronikdose kurz vor dem Steckdoseneinbau. Der 
zusätzliche Einbauraum wurde mit dem Meterstab kenntlich gemacht.

Grüße Timo

[Chris (Gast)]

Hallo Markus,

zu Deinem Posting:

24V-Power-Fail-Interrupt:
Der Vorschlag wäre einen einzelnen Komparator zu verwenden dessen einer 
Eingang (RD0) auf die stabilisierte Versorgung (5V) gelegt wird und der 
zweite Eingang (RD1) wird über einen Spannungsteiler (3:1) an die 24V 
angeschlossen. Schaltet der Komparator jetzt an der Schwelle (~20V) um 
so können wir einen Interrupt benutzen um das Herunterfahren einzuleiten 
und notfalls sogar den Controller aufzuwecken aus dem Sleep. Die 
Funktion entspricht also der 2. Alternative, aber allein mit dem 
internen Komparator abgebildet.

SPI und I²C (TWI):
Es sollte die Möglichkeit bestehen SPI und I²C Slaves an einem 
gemeinsamen Bus zu betreiben. Die SPI-Nodes haben kein Interesse an dem 
CLK (RC3) solange ihr CS nicht eingeschaltet ist. Ebenfalls werden sie 
auch keine Daten treiben auf SDI (RC4). Damit die I²C Slaves diesem 
Verhalten ebenfalls folgen kann man mit einer kleinen Logik den Clock 
schaltbar machen (funktioniert dann wie ein CS). Die Umschaltung im uC 
ist sicherlich kein Problem, ist der HW Aufwand vertretbar?

CAN-Wakeup:
Der TJA1040 kennt einen Stand-By Modus in dem er bei minimalem 
Stromverbrauch Kommunikation auf dem BUS an dem RxD-PIN signalisiert was 
an einen Interrupt gelegt vom uC ausgewertet werden kann. Das könnte 
auch die Vorzugsrichtung (Pull-up) bei abgeschaltetem uC sein. Das 
ECAN-Modul kann auf dem Puls auf der Rx-Leitung einen Wake-Interrupt 
erzeugen. Wenn ein Tranceiver diese Funktion so nicht unterstützt wie 
z.B. der TJA1041 so wäre der Anschluss einer WAKE-Leitung an den 
Interrupt-Eingang notwendig damit wir bei BUS-Traffic aufwachen können.

Den Schaltregler abzuschalten ist aus Sicht der Software nach jetzigem 
Konzept keine Option da ein Spannungsverlust einen kompletten Neustart 
erfordert. Bevorzugt ist ein SW-Kontrollierter SLEEP-Mode, der aber 
einer Spannungsversorgung am uC erfordert. Hier kann der Ruhestrom 
problemlos reduziert werden auf 0,1..2uA - fraglich nur welche 
Verlustleistung der Schaltregler in diesem Modus hat.

Viele Grüße,

Christian

[Timo E. (tien)]

Hi Markus,

zum Thema Strommessung:

Markus B. P. (MBP-Bayern) schrieb:
> Mit einem Shunt und den 10 Bit ADC Auflösung,
> da könnte das schon irgendwie
> zum Schätzen der Stromaufnahme des kleinen Controllers genügen.
> Aber ich bin der Meinung, dass sich nichts die 24V "greifen" darf,
> ohne dass es über den Shunt und ggf. über die Sicherung geht.

Das sehe ich genauso.

> Oder ein 12V Aufsatz für Deine Weihnachtsbeleuchtung:
> (Beides Externe Technik, versorgt & bewacht vom Can-µC)

Genau.

> Dann sind wir wohl schnell bei (oder gar über) 1A @ 24V.
> Wenn ich nun "nur" 1V Abfall am Shunt zulasse,
> so ist das schon 1W in der Dose verheizt.
> Diesmal an manchen Tagen sogar eher mehr als weniger lang.
> Noch weniger schön.

Es geht bei der Strommessung ja nicht darum den Strom des PICs oder 
anderer Logik zu messen, ich denke da sind wir uns einig - oder?

Deshalb würde ich mal bei 1A @24V das absolute Maximum für einen 
"normalen" Node ansetzen. In diesem Fall sollte die Verlustleistung am 
Shunt nicht höher als 250mW sein. Das wäre bei einem Shunt von 0,25 Ohm 
der Fall. Das wäre dann 0,025V pro 100mA am Shunt. Mit einem 
Spannungsteiler von 6,25:1 kommen wir am ADC auf eine Spannungsdiff von 
0,004V pro 100mA. Das bedeutet pro Bit 100mA. Das ist zwar schon recht 
ungenau, würde aber für eine Einschätzung der Last reichen.

Eventl. hast Du recht mit dem OPAmp...

Alternativ könnte man mit ein paar FETs einen Elko am Shunt laden und 
umschalten und so indirekt die Spannung über dem Shunt messen :-) 
Allerdings muss dann die Referenz recht klein werden, was für andere 
Anwendungen wieder blöd ist und Platz spart das dann auch nicht mehr....

Hm, bin mir unschlüßig...

Was meinst Du?


Grüße Timo

[Markus B. P. (MBP-Bayern) (Gast)]

Hallo Zusammen.

@Helmut:
Danke für die ausführliche Info.
Das mit dem Probebetrieb find ich übrigens zum schmunzeln ;-)
######################################################################## 
##

@Chris:
zum 24V-Power-Fail-Interrupt:
Ja, Ok auch ne Möglichkeit,
aber ob das gegen 5V noch enidutig klappt - was sagt das Dateblatt dazu 
?
Sonst nehmen wir die von mir vorgesehene 4,1V Referenz.
Der Spannungsteiler ist dann eben minimal abeichend und es geht sicher.


SPI und I²C (TWI):
Muss ich mir ansehen, aber das solte kein Problem sein.

Vermutung:
2 Antiserielle P-CH-FET's (Z.B. SOT23-6) in die TWI-CLK-Leitung und gut.
CS für I2C-Clock Enable ist dann LOW-Aktiv.
Die TWI-Slaves können dann noch den Master-Clock stretchen.
TWI hab ich einige AN's rumfliegen.


CAN-Wakeup:
>Der TJA1040 kennt einen Stand-By Modus in dem er bei minimalem
>Stromverbrauch Kommunikation auf dem BUS an dem RxD-PIN
So ähnlich kann der TJA1041 das auch - er kann noch mehr...

>Den Schaltregler abzuschalten ist aus Sicht der Software nach jetzigen
>Konzept keine Option.

vielleicht in Ausnahmen...
Der TJA1041 kann schlafen, genau wie der 1040er - Pin INH = +U
dann läuft der MAX5035 Regler weiter.

Er kann aber noch "tiefer" schlafen und die Versorgung abdrehen,
indem er INH auf High-Z stellt. Erst dann ist der µC wirklich weg.
Dazu muss der µC eben alles sichern, bevor er sich "den Stecker zieht".

Maxim schreibt:
350µA Quiescent Current at No Load, 10µA Shutdown Current.
######################################################################## 
##

@Timo:
Mann ihr habt alle so viel Platz in den Verteilern.
Ich sollte wohl doch noch einen echten Schaltschrank neben den 
Sicherungskasten an die Wand nageln, dann hab auch ich Platz.

Im Keller verteilt sind eigentlich einzelne einreihige VT geplant.
(Z.b. im Heizraum neben der Waschküche = unter Küche und Eszimmer.)

Die Dose kannte ich doch nicht.
Die bei mir nachgerüsteten sind normal rund, nur doppelt-tief.
Aber selten ist nur eine allein und verlassen in eine Wand eingeputzt.


Strommessung:
Den Strom des Controllers nicht, aber die 5V müssen berücksichtig sein.
(Von der 24V-Seite aus - insbesondere zwecks meiner Erweiterungen.)

Nun ich schlage vor, wir nehmen einen 10mR bis 100mR Shunt.
24V Common-Mode sind einiges.
Ob man den Op-Amp diskret zum Differenzverstärker beschalten sollte ?
Besser wäre ein integrierter, sonst werden evtl. 0,1% SMD-R's nötig.
######################################################################## 
##

MFG:MBP
Markus.

[Markus B. (mbp-bayern)]

Hallo Timo,

das mit dem Platz auf einer Platine erscheint mir noch immer etwas eng,
aber ich habe mal einige kleine Bauteile ausgesucht um Platz zu sparen.

***********************************************************
Spule für Schaltregler:

Nach Meinung eines Experten, so kann man auch eine Stabdrossel nehmen.
Dies könnte wertvollen Platz in der Bauhöhe sparen.


***********************************************************
Quarz für den PIC18:

Z.B. bei FreqTech gäbe es da Winzlinge als alternative.
Der FT13A gefällt mir in echt ganz gut.
Bildchen gibts dort: (PDF derzeit nur auf Anfrage - hab ich aber schon.)

http://www.freqtech.com/produkte_QuartzCrystals.php

Haken an der Sache: die gehen ab 12/13 MHz los.

Somit fällt "10 MHz HS PLL" aus, um an 40 MHz zu kommen.
Aber der Oszillator selbst müsste bis 40 MHz takten können.


***********************************************************
Shunt Verstärker:

INA193A - SOT23-5 - z.B. bei Farnell zu haben.


***********************************************************
Komparator für 24V Versorgung:

Aus dem Datenblatt zum PIC18F4685 habe ich entnommen:
Common Mode Comparator MAX = (VDD - 1,5V).
Dann müsste man die REF klein genug halten.

Vorschlag:
Erkennung extern ausgeführt, auf den INT0 Eingang.
Zusätzlich an Expansion - dann kann man das auch extern "abzapfen".
Bauteil: LPV7215 - SOT23-5 z.B. DigiKey.


***********************************************************
I2C Abkopplung:

P82B96 verwenden und dem die VCC abschalten,
bzw. über PIC18 IO zuführen.


***********************************************************
CAN - wie schon geschrieben:

Spule Epcos B82789C0104N00(2)/(1)


***********************************************************
Internes EE-Prom:

So wie ich das Datenblatt verstehe,
so sind für JEDES zu sichernde Byte 4 ms an Zeit erforderlich.
24xx EE-Proms mit 1024Kbit haben Pages von 128 / 256 Bytes.

Für die Bytes einer Page dauert die Übertragung auf TWI
nicht gerade lange - es gibt Baustene mit 400 KHz und 1 MHz (5V).
Die benötigen dann für den Page-Write nach dem Transfer ca 5 ms.


***********************************************************
Backup-Kondensator:

Denkbar wäre, einen GoldCap am Rand oder Rückseitig abstehend zu 
montieren.
Wenn man den nur bis 4V auflädt (Dioden),
so sollte der auch eine ewige Lebensdauer erreichen.

Über die LVD Erkennung könnte der PIC18 dann die Takt-Quelle umschalten,
und mit internem RC weiterlaufen, bis er wieder 5V bekommt.
Da kann er bei Stromausfall noch viel erledigen.


Was meinst Du ?
Besonders mit dem Quarz.

[Timo E. (tien)]

Hi Markus

> ***********************************************************
> Spule für Schaltregler:
> Nach Meinung eines Experten, so kann man auch eine Stabdrossel nehmen.
> Dies könnte wertvollen Platz in der Bauhöhe sparen.

Hast Du da einen Typ, den man auch halbwegs vernünftig bekommt?
Welchen Regler hast Du ausgesucht und welche Induktivität benötigen wir?


> ***********************************************************
> Quarz für den PIC18:
>
> Z.B. bei FreqTech gäbe es da Winzlinge als alternative.
> Der FT13A gefällt mir in echt ganz gut.
> Bildchen gibts dort: (PDF derzeit nur auf Anfrage - hab ich aber schon.)
> http://www.freqtech.com/produkte_QuartzCrystals.php
> Haken an der Sache: die gehen ab 12/13 MHz los.
> Somit fällt "10 MHz HS PLL" aus, um an 40 MHz zu kommen.
> Aber der Oszillator selbst müsste bis 40 MHz takten können.

Hm, wie sieht es mit dem Preis und der Verfügbarkeit aus?
Ich denke wir sollten nicht den Preis außer Augen lassen. Die Preise 
bewegen sich bei Rei**elt & Co zw. ca. 20 Cent und 3 Euro. Für 75 Cent 
bekommt man bei Rei**elt z.B. diesen 10MHz:
http://www.reichelt.de/?ACTION=3;ARTICLE=84990;PROVID=2402
Damit wäre der PLL Mode möglich.
Wenn man ohne PLL auskommen möchte (Strom sparen) gibt es in der 
gleichen Größe z.B. diesen 25Mhz Quarz zum gleichen Preis:
http://www.reichelt.de/?ACTION=3;ARTICLE=85001;PROVID=2402
Arg viel mehr sollte der FT13A Winzling meiner Meinung nach nicht 
kosten.


> ***********************************************************
> Shunt Verstärker:
> INA193A - SOT23-5 - z.B. bei Farnell zu haben.

Ok, damit ist die Verfügbarkeit geklärt, der Preis ist mit 2,86 € für 
Privatmenschen noch halbwegs erträglich. Ich denke man müsste das 
Bauteil auch nur im Bedarfsfall bestücken. Für einen Tastensensor würde 
ich eher darauf verzichten.


> ***********************************************************
> Komparator für 24V Versorgung:
> Aus dem Datenblatt zum PIC18F4685 habe ich entnommen:
> Common Mode Comparator MAX = (VDD - 1,5V).
> Dann müsste man die REF klein genug halten.
> Vorschlag:
> Erkennung extern ausgeführt, auf den INT0 Eingang.
> Zusätzlich an Expansion - dann kann man das auch extern "abzapfen".
> Bauteil: LPV7215 - SOT23-5 z.B. DigiKey.

Was hälst Du von diesem Teil:
http://www.reichelt.de/?ACTION=3;ARTICLE=39472;PROVID=2402
Hat ebenfalls SOT23-5 und ist mit 50 Cent relativ günstig.
Allerdings hab ich nicht genau auf die Werte geachtet.
Aber die Erkennung extern auszulegen halte ich auch für Sinnvoll.

> ***********************************************************
> I2C Abkopplung:
>
> P82B96 verwenden und dem die VCC abschalten,
> bzw. über PIC18 IO zuführen.

Da stell ich mir die Frage, ob wir das auf die Basisplatine packen, was 
meinst Du? Derzeit weiß ich noch nicht ob ich das wirklich benötige. 
Hast Du einen Anwendungsfall?

> ***********************************************************
> CAN - wie schon geschrieben:
> Spule Epcos B82789C0104N00(2)/(1)
ok, da gibt es wohl nicht wirklich etwas bei Rei**elt. Beim großen C 
gibt es diese hier:
http://www.conrad.de/ce/de/product/501837/SMD-DATENLEITUNGSDROSSEL-2X51UH-303/0218132&ref=list
Ist allerdings schon ganz schön groß im Gegensatz zu Deinem Vorschlag 
und auch nicht günstig. Wundert mich etwas, dass hier kaum was zu finden 
ist.
Gerade hab ich mit einem Kollegen aus der Hardware gesprochen. Er meint 
wir sollten auf die CAN Drossel nicht verzichten. Eventl. werden hier 
demnächst Restbestände verschrottet 
(http://www.tdk.co.jp/tefe02/e971_zjys81.pdf). Die könnte ich eventl. 
bekommen. Aber das ist noch sehr unsicher. Wenn ja wären das so um die 
400 St. D.h., wenn Du auf der Platine diesen Platz vorsehen könntest und 
ich die Dinger bekommen könnte, wäre das eine kostengünstige Lösung 
zumindest für uns. Eventl. könntest Du ja die Pads so dimensionieren, 
dass alle drei Varianten passen (Dein, die von C* und die ZJYS81.


> ***********************************************************
> Internes EE-Prom:
> So wie ich das Datenblatt verstehe,
> so sind für JEDES zu sichernde Byte 4 ms an Zeit erforderlich.
Chris hat sich mit dem EEPROM bereits intensiv beschäftigt, es wäre mal 
interessant wie schnell das in der Praxis ist.

> Für die Bytes einer Page dauert die Übertragung auf TWI
> nicht gerade lange - es gibt Baustene mit 400 KHz und 1 MHz (5V).
> Die benötigen dann für den Page-Write nach dem Transfer ca 5 ms.
Wenn Platz ist ok. Aber das Speichern bei Power Down war auch nur eine 
spontane Idee, wenn es aus Kosten, Platz bzw. Zeit Gründen nicht geht 
wäre das auch nicht schlimm.

> ***********************************************************
> Backup-Kondensator:
>
> Denkbar wäre, einen GoldCap am Rand oder Rückseitig abstehend zu
> montieren.
> Wenn man den nur bis 4V auflädt (Dioden),
> so sollte der auch eine ewige Lebensdauer erreichen.
> Über die LVD Erkennung könnte der PIC18 dann die Takt-Quelle umschalten,
> und mit internem RC weiterlaufen, bis er wieder 5V bekommt.
> Da kann er bei Stromausfall noch viel erledigen.

Auch hier ist natürlich wieder der Preis und der Platz entscheidend. Da 
wäre eher die Frage nach einer Notstromversorgung des kompletten Busses 
interessant. Allerdings müsste ein Netzausfall dann per Message an jeden 
Node gehen um unnötige Verbraucher abzuschalten. Das wäre vermtl. eine 
kostengünstigere Lösung. Damit würde dann auch der pro Node Komparator 
wegfallen. Was meinst Du?

> Was meinst Du ?
> Besonders mit dem Quarz.

Am liebsten wäre es mir ja, dass wir alle Bauteile von 1 bis max. 3 
gängigen Lieferanten beziehen könnten. Bei jeder Bestellung fallen ja 
noch Versandkosten an. Und da das ganze ja OpenSource sein soll wäre 
eine gute Versorgung an Private auch sinnvoll. Perfekt wäre es wenn alle 
Bauteile von einem Anbieter kommen würden.
Man könnte natürlich auch schauen alles über Far*ell zu beziehen, dann 
könnten Private über hbe-shop einkaufen.

Grüße Timo

[Markus B. (mbp-bayern)]

Hi Timo,

nur kurz zum Regler:
Hab mich für den von Max vorgeschlagenen MAX5035 entschieden.
Den Rest hab ich nur überflogen.

Bei 5V 1A aus 24V rund 100µH:

MAX VIN [ V ]  VOUT [ V ]  MAX IOUT [ A ]  FSW [ Hz ]
24             5           1,055555556     125000
L [ µH ]
100

Formel für Excel:
(x in der Formel von Zeile 14 durch Sternchen ersetzten)

       [ A ]             [ B ]             [ C ]             [ D ]
[ 11 ] MAX VIN [ V ]     VOUT [ V ]  MAX IOUT [ A ]       FSW [ Hz ]
[ 12 ] 24                5           1,05555555555555     125000
[ 13 ] L [ µH ]
[ 14 ] =(((A12-B12) x (B12/A12)) / (0,3 x C12 x D12) x 1000000)

MFG:MBP
Markus.

[Timo E. (tien)]

Hi Markus,

auch von mir nur kurz:
Zu 99% kann ich die CAN Drosseln (ZJYS81) bekommen, es muss nur noch der 
Chef ja sagen. Dann hätte ich ca. 800 Stück. ;-)
Außerdem hätte ich noch ein "paar"
- 47µF Elkos G68,
- 22µF Tantal Case D,
- 10µF Tantal Case B

Grüße Timo

[Timo E. (tien)]

Hi Markus,

nochmals zum Thema Power down Erkennung. Ich tendiere mittlerweile sehr 
stark zur zentralen Lösung. Das würde auch die von mir angedachte LED 
Notbeleuchtung abdecken. D.h. ich würde bei einem Netzausfall von einem 
Akku leben. Den will ich eh irgendwann installieren, damit meine 
Umwälzpumpe des Holzofens nicht ausfällt. Wenn dann auf Akkubetrieb 
umgeschaltet wird müssen die Nodes alles überflüßige abschalten und dann 
nach und nach runterfahren.

Externes EEPROM würde ich nicht auf die Platine machen, ich denke für 
90% der Fälle reicht das interne.

Bzgl. Quarz:
Ich denke ein Vorhalt ist wichtig, aber vermtl. können wir per 8MHz 
internen Takt und PLL, also mit 32 MHz arbeiten. D.h. wenn Du die Pads 
für den Quarz und die zwei Cs auf die Platine machen könntest wären wir 
für alle Fälle gerüstet.

Was uns wichtig wäre: der 32khz Quarz für Timer 1, der wäre sehr genial, 
da wir dann das Betriebssystem darüber takten könnten.


Grüße Timo

[Timo E. (tien)]

Hallo Markus,

hast Du für den MAX5035 einen Anbieter und einen Preis?
Ich hab ihn spontan nur bei Distre* für knapp 7 Euro gefunden.
Wenn man dann die Spule noch rechnet kommt man ja schon fast an die 9,17 
€ für den RECOM ran. Gibt es den MAX5035 irgendwo günstiger? Oder gibt 
es eventl. Alternativen?

Sorry, dass ich so auf den Preis schau, aber bei 20+ Platinchen geht 
halt jeder Euro ins Geld.

Mal ganz provokativ:
Was spricht gegen den MC 34063 AD
http://www.reichelt.de/?ACTION=3;ARTICLE=68603;PROVID=2402
Kostet nur 32 Cent...
Wo ist der Haken?


Grüße Timo

[Markus B. (mbp-bayern)]

Hallo Timo.

Timo E. schrieb:
> Hallo Markus,
>
> hast Du für den MAX5035 einen Anbieter und einen Preis?
> Ich hab ihn spontan nur bei Distre* für knapp 7 Euro gefunden.
> Wenn man dann die Spule noch rechnet kommt man ja schon fast an die 9,17
> € für den RECOM ran. Gibt es den MAX5035 irgendwo günstiger? Oder gibt
> es eventl. Alternativen?

Mit dem Maxim kann jemand sich sogar ein
48V versorgtes System oder noch mehr machen*.
Er kann bis 76V arbeiten und bis 80V leben.
Dynamische Versorgung wird der wohl auch ausregeln.
(*Vorsicht - dann aber kein SO14 CAN mit 6-27V BAT/INH anwenden!)

Er benötigt sehr sehr wenig Energie für sich selbst.

Eine vernünftige Alternative hab ich noch nicht entdeckt,
was aber nicht bedeutet, dass es sie nicht gibt.


>
> Sorry, dass ich so auf den Preis schau, aber bei 20+ Platinchen geht
> halt jeder Euro ins Geld.
>
Was die Kosten für Muster angeht das kann man nicht genau vorhersagen.
Die kann man vielleicht auch als kostenlose samples ab Werk bekommen.


Die "Kleinserie":

Für den MAX5035DASA nimmt Mouser
ab 25 St. 4,93 € à und ab 100 St. 3,58 €
(Steuern und Versand darf man dabei nicht vergessen.)


> Mal ganz provokativ:
> Was spricht gegen den MC 34063 AD
> http://www.reichelt.de/?ACTION=3;ARTICLE=68603;PROVID=2402
> Kostet nur 32 Cent...
> Wo ist der Haken?
>

Das Datenblatt von Reichelt ist ja "super"...
Naja also hier die Zusammenfassung:

40V wären gut genug,
sofern wir Transientenschutz am Eingang haben.

Für 5V 0,5A aus 25V benötigt der 220µH.
1.1A kann er in Muster-Beschaltung nur bei Kurzschluss.
Wenn man mit 0,5A bei 5V leben kann wohl Ok.
Da dürfte die Spulengröße kaum von unseren 100µH für 1A abweichen.

"Figure 6. Standby Supply Current versus Supply Voltage"
Weder Acrobat Reader V8, noch VX bilden eine Kennlinie ab.
Siehst Du mehr als ein leeres Gitter ?

Nimmt man 2,0 mA bei 25V Leerlauf, so bekommt man 50 mW
Der MAX5035 bekommt das mit 6,75mW hin.

Auffällig ist noch,
dass er einen Shunt von 0,33R am Eingang verwendet: Seite 5/9

Wirkungsgrad:
83,7% bei 0,5A sind OK.
Diagramm habe ich leider keines gefunden.



Fazit:
Technische Daten auf dem Papier OK.

Erweckt jetzt aber nicht das Vertrauen,
das ich in ein solch zentrales Bauteil brauche.

Etwas mehr als 2 Jahre "Garantiezeit" überleben,
dann planmäßig in den "Müll"...
Das würde ich dem locker zutrauen.

Aber für 10 Jahre und mehr kann ich mich mit dem nicht anfreunden.
Auch wenn er es villeicht doch überstehen könnte.

Und bevor jemand meckert:
In den (Haus-)Müll soll es ja nichtmal wenn es kaputt wäre.



MFG:MBP
Markus

[Markus B. (mbp-bayern)]

Hallo Timo;

> ...zum Thema Power down Erkennung. Ich tendiere mittlerweile sehr
> stark zur zentralen Lösung.
>
Gut dann setzten wir das hiermit fest.
Spart Platz und Kosten pro Platine.

Die 24V wird man schon irgendwie Puffern können.
Notfalls kommt eben irgendwo eine 230V USV hin,
die wichtige Dinge versorgen kann;
Z.B. auch einige Lampen, wo es kein Notlicht gibt.

Nur die USV-Akkus müssten nach 2-5 Jahren gewartet (getauscht) werden.


> Externes EEPROM würde ich nicht auf die Platine machen, ich denke für
> 90% der Fälle reicht das interne.
>

Wenn man den Platz irgendwie für SO8 Speicher hinbekommt,
so werde ich es mir nicht nehmen lassen das zu reservieren.
Serielles EEProm kostet wenig und gibts bis mindestens 1MBit.

Beitrag von Jürgen Harms:
Er hat für "FRAM" Platz gemacht.

Nun hab ich mal gekuckt, was ich da finde:

FM24V10 1Mbit, TWI - aber kaum zu bekommen
Future USA haben den für 9$ à.

FM25V10 fas das selbe, nur SPI; bei Mouser für ca 10 Ecken à.

Was die mit weniger Speicher kosten, und wie die verfügbar sind,
das hab ich nicht geschaut; Auch nicht nach anderen Herstellern.

Aber da könnte man ja den Jürgen um sachdienliche Hinweise bitten.

>
> Bzgl. Quarz:
> Ich denke ein Vorhalt ist wichtig, aber vermtl. können wir per 8MHz
> internen Takt und PLL, also mit 32 MHz arbeiten. D.h. wenn Du die Pads
> für den Quarz und die zwei Cs auf die Platine machen könntest wären wir
> für alle Fälle gerüstet.
>
Wie gut kann man den RC Kallibrieren - wie genau ist der ?
CAN ist empfindlich, was ich da so gelesen habe.

Nun SMD Haupt-Quraz im Layut auch sowieso.
Aber eben die Frage, müssen wir PLL,
oder können wir schon an den Pins mit 40 MHz vollgas geben.

(Je kleiner ein Quarz,
desto höher ist idR. die niedrigste Frequenz, die man bekommt.)

> Was uns wichtig wäre: der 32khz Quarz für Timer 1, der wäre sehr genial,
> da wir dann das Betriebssystem darüber takten könnten.
>
Keine Frage "OB".
Nur die Form - ich denk da auch schon wieder an kleine SMD Teile.
Da kann man THT notfalls auch anlöten und über den Controller falten.

MFG:MBP
Markus

[Markus B. (mbp-bayern)]

Hallo Timo;

>> ***********************************************************
>> Quarz für den PIC18:
>>
>
> Hm, wie sieht es mit dem Preis und der Verfügbarkeit aus?
> Ich denke wir sollten nicht den Preis außer Augen lassen. Die Preise
> bewegen sich bei Rei**elt & Co zw. ca. 20 Cent und 3 Euro. Für 75 Cent
>
Ich wüsste jetzt nicht, dass man bei FT für Quarze 3€ hinlegen müsste.
Aber der von Reichelt wäre von der Größe wie die FT7 Reihe.
FT sind sonst soweit ordentlich verfügbar.

>
>
>> ***********************************************************
>> Shunt Verstärker:
>> INA193A - SOT23-5 - z.B. bei Farnell zu haben.
>
> Ok, damit ist die Verfügbarkeit geklärt, der Preis ist mit 2,86 € für
> Privatmenschen noch halbwegs erträglich. Ich denke man müsste das
> Bauteil auch nur im Bedarfsfall bestücken. Für einen Tastensensor würde
> ich eher darauf verzichten.
>
Ja da gibts kaum was zu messen und selber abschalten macht keinen Sinn. 
Schutz bietet ja eine Sicherung.

>
>> ***********************************************************
>> Komparator für 24V Versorgung:
> Was hälst Du von diesem Teil:
> http://www.reichelt.de/?ACTION=3;ARTICLE=39472;PROVID=2402
> Hat ebenfalls SOT23-5 und ist mit 50 Cent relativ günstig.
> Allerdings hab ich nicht genau auf die Werte geachtet.
> Aber die Erkennung extern auszulegen halte ich auch für Sinnvoll.
>
Bis auf die neuseste Erkenntniss, das man darauf verzichten kann:
Genau hab ich den auch nicht angesehen, aber er kann ab 2,7V.
Somit wäre er wohl geeignet.
Evtl. ist der Pinkompatibel.

>> ***********************************************************
>> I2C Abkopplung:
>>
> Da stell ich mir die Frage, ob wir das auf die Basisplatine packen, was
> meinst Du? Derzeit weiß ich noch nicht ob ich das wirklich benötige.
> Hast Du einen Anwendungsfall?
>
Wenn der externe Speicher auf der CPU-Platine SPI ist,
dann benötigt er einige IO's von der CPU.
(DI,DO,CK,CS + "EXTENER TWI-Koppler OFF" oder "Adress-Pins")

Wenn er aber TWI ist,
dann benötigt er auch die Abkopplung auf der CPU.

Dafür kann dann das SPI aber als externe Expansion dienen.
Das mit dem SPI nCS für mehrere ICs würde ich dann als
"EIN PORT nCS = TWI_OFF" + "1..x Bit's = SPI-Adresse"
lösen und extern dekodieren.

Anwendungsfall:
Siehe anderer Beitrag von mir zum externen Speicher.

>> ***********************************************************
>> CAN - wie schon geschrieben:
>> Spule Epcos B82789C0104N00(2)/(1)
> ok, da gibt es wohl nicht wirklich etwas bei Rei**elt. Beim großen C
> gibt es diese hier:
> 
http://www.conrad.de/ce/de/product/501837/SMD-DATENLEITUNGSDROSSEL-2X51UH-303/0218132&ref=list
>
Das ist die "Standardbauform" von der ich eigentlich weg möchte,
um eben platz zu sparen.

> (http://www.tdk.co.jp/tefe02/e971_zjys81.pdf). Die könnte ich eventl.
> bekommen.
>
Die werde ich mir genau ansehen - das dürfte mit der von mir 
vorgeschlagenen Form im Layout vereinbar sein.

>> ***********************************************************
>> Backup-Kondensator:
>>
> Auch hier ist natürlich wieder der Preis und der Platz entscheidend. Da
> wäre eher die Frage nach einer Notstromversorgung des kompletten Busses
> interessant. Allerdings müsste ein Netzausfall dann per Message an jeden
> Node gehen um unnötige Verbraucher abzuschalten. Das wäre vermtl. eine
> kostengünstigere Lösung. Damit würde dann auch der pro Node Komparator
> wegfallen. Was meinst Du?
>
Wegfallen ist gut.
Das halte ich auch für sinnvoller.

Habe ich ja im andern Beitrag mittlerweile auch schon geschrieben.

Kaum ein Node wird einzeln was speichern müssen,
weil er alleine ausgesteckt wird.

> Am liebsten wäre es mir ja, dass wir alle Bauteile von 1 bis max. 3
> gängigen Lieferanten beziehen könnten. Bei jeder Bestellung fallen ja
> noch Versandkosten an. Und da das ganze ja OpenSource sein soll wäre
> eine gute Versorgung an Private auch sinnvoll. Perfekt wäre es wenn alle
> Bauteile von einem Anbieter kommen würden.
> Man könnte natürlich auch schauen alles über Far*ell zu beziehen, dann
> könnten Private über hbe-shop einkaufen.
>
Schön wäre "alles aus einer Hand" schon,
aber das wird sich nicht realisieren lassen.

Mit 3 wird es schon schwierig werden.

Lieferanten, mit denen man nach meiner Meinung mindestens Planen muss:
Re..., Co..., Bü..., Fa..., Di..., Mo...
Die Reihenfolge der Aufzählung ist nicht durchdacht oder Sortiert.

An der falschen Stelle zu sparen kann auch falsch sein.
Sparen an Anzahl nötiger Lieferanten ist sicher nicht falsch.

Und unter diesem Gesichtspunkt kann z.B. schon mal der Haupt-Quarz 
vermutlich nicht kleiner werden, ohne weitere Spezial-Liefernaten.
(Wieder ein Punkt erledigt.)

MFG:MBP
Markus.

[Timo E. (tien)]

Hi Max,
Hi Markus,

so, bin nun Besitzer von ca. 500 St. CAN Drosseln 51 mH (ZJYS81)
und ca. 500 St. mit 12 mH (ZJYS51).
http://www.tdk.co.jp/tefe02/e971_zjys81.pdf

Sollte also für die ersten Platinen unseres Projektes reichen ;-)

Außerdem hab ich noch eine Rolle (5000St.) 0 Ohm 0805 Brücken und ein 
paar Widerständchen und Cs.


Grüße Timo

[Max M. (maxmustermann)]

Hi Timo!

Timo E. schrieb:
> so, bin nun Besitzer von ca. 500 St. CAN Drosseln 51 mH (ZJYS81)
> und ca. 500 St. mit 12 mH (ZJYS51).
> http://www.tdk.co.jp/tefe02/e971_zjys81.pdf

das klingt mal super! Ich hör nur zum ersten mal von einer CAN Drossel, 
sind das wie die Übertrager bei Ethernet für eine galvanische Trennung 
oder bin ich mit dem Gedanken ganz falsch? Hast du rein zufällig ein 
Beispiel wie so eine CAN Drossel verschaltet ist?

Gruß Max

[Markus B. (mbp-bayern)]

Timo E. schrieb:
> so, bin nun Besitzer von ca. 500 St. CAN Drosseln 51 mH (ZJYS81)
> und ca. 500 St. mit 12 mH (ZJYS51).

Hallo Timo,

das ist doch super.

MFG:MBP
Markus

[Markus B. (mbp-bayern)]

Max Mustermann schrieb:
> Hi Timo!
>
> Timo E. schrieb:
>> so, bin nun Besitzer von ca. 500 St. CAN Drosseln 51 mH (ZJYS81)
>> und ca. 500 St. mit 12 mH (ZJYS51).
>> http://www.tdk.co.jp/tefe02/e971_zjys81.pdf
>
> das klingt mal super! Ich hör nur zum ersten mal von einer CAN Drossel,
> sind das wie die Übertrager bei Ethernet für eine galvanische Trennung
> oder bin ich mit dem Gedanken ganz falsch? Hast du rein zufällig ein
> Beispiel wie so eine CAN Drossel verschaltet ist?
>
> Gruß Max

Hallo Max,

bei CAN geht es nicht um eine galvanisceh Trennung, wie bei LAN.
Die Drossel dient zum herausfiltern von Gleichtaktstörungen.
Sie ist ähnlich wie ein Netzfilter angeschlossen.

Suche mal nach Applicationnotes mit dem Suchanbieter Deiner Wahl:
nxp common mode choke can

MFG:MBP
Markus.

[Max M. (maxmustermann)]

Hi Markus!

Danke für die Info!

Gruß

[Markus B. (mbp-bayern)]

Timo E. schrieb:
> so, bin nun Besitzer von ca. 500 St. CAN Drosseln 51 mH (ZJYS81)

Hallo Timo,

Bei den Kontrollen der Datenblätter ist mir aufgefallen,
dass die von mir vorgeschlagene Spule doch kleiner ist,
als die von Dir.

Deine passt von der Gehäuse-Form grob zur meiner bisherig gelayouteten 
Standard-Version.
Die Pads müssen hauptsächlich breiter sein als sie es bisher waren.

Ob ich die Kleine überhaupt noch im Layout vorsehe entscheide ich dann 
wenn es soweit ist - einen Vorteil bringt es nicht, da die anderen 2 den 
Platz brauchen.


Die Serien-Widerstände kommen nun als 4er R-Netze an zimlich alle IO's.
4x 0603 -> Entspricht 1206 Quer;

Der Abstand zwischen den jeweils äuseren Pins ist nur 0,1 mm.
Die PCB-Pool Spezifikation schreibt aber min. 0,15 mm Kupfer-Abstand 
vor.
Wenn man die Landepads etwas "umlayoutet", also schmäler macht so geht 
das.
Das dürfe für das Bauteil auch kein (Löt-)Problem sein.


Was EMV angeht,
so habe ich ein interressantes deutsches Buch gekauft:
(Englich kann ich zwar auch gut,
aber dann wäre das wohl noch komplexer als das Thema schon so ist.)

"EMV: Störungssicherer Aufbau elektronischer Schaltungen"
Joachim Franz; Gebundene Ausgabe; EUR 39,95
Fast noch druckfrisch - 4. Auflage 2011.

So manche Sache wird damit sehr klar.
Vor allem, was man unbewusst alles falsch machen kann.


MFG:MBP
Markus.

[Tien (Gast)]

Hi Markus,

na das hört sich ja gut an. Da bin ich sehr gespannt. Hast Du bereits 
ein Schaltplan?
Derzeit arbeite ich an der PC Anwendung, zur Reprogrammierung der Nodes. 
Irgendwann soll über diese Anwendung dann auch die Konfiguration 
ermöglicht werden.

Grüße Timo

[Markus B. (mbp-bayern)]

Hallo Timo,

der Schaltplan ist in Arbeit; genauer gesagt momentan auf "Pause".
Der Zwischenstand als PDF im Anhang.

Das EMV-Buch fertig zu lesen erscheint mir wichitger,
als schnell den Schlatplan zu haben.
Ende nächster Woche sollte ich das Buch grundsätzlich durch haben.

MFG:MBP
Markus.

[Tien (Gast)]

Hi Markus,

> Bei den Kontrollen der Datenblätter ist mir aufgefallen,
> dass die von mir vorgeschlagene Spule doch kleiner ist,
> als die von Dir.

Ja, das ist ja auch der Grund warum die Spulen zur Verschrottung 
freigegeben wurden. In den aktuellen Steuergeräten werden natürlich 
kleinere eingebaut, aber die bekomme ich natürlich nicht.

> Ob ich die Kleine überhaupt noch im Layout vorsehe entscheide ich dann
> wenn es soweit ist - einen Vorteil bringt es nicht, da die anderen 2 den
> Platz brauchen.

Einen Vorteil bringt es für uns, die wir die kostenlosen Spulen von mir 
nutzen können nicht. Aber für diejenigen, die Spulen kaufen würde es die 
Bauteilauswahl verbreitern.

> Das EMV-Buch fertig zu lesen erscheint mir wichitger,
> als schnell den Schlatplan zu haben.
> Ende nächster Woche sollte ich das Buch grundsätzlich durch haben.

Klar, wir haben ja auch Zeit (zumindest ich). Und lieber eine gut 
durchdachte Hardware als nachher stunden oder tagelang Probleme suchen.
Kannst ja mal Dein Urteil über das Buch mitteilen, wenn Du es durch 
hast. Eventl. würde ich mir sowas auch mal zulegen.


Grüße Timo

[Tien (Gast)]

Hi Markus,

hab mir heute den Schaltplan mal nähr angeschaut. Das mit den Eingangs 
Rs über die R Netzwerke finde ich eine gute Idee!

Ich habe allerdings noch ein paar Fragen:

1. die Rs in der VCC Leitung hast Du vermtl. als Tiefpass reingemacht, 
gute Idee. Allerdings könnte es eventl. sein, je nach interner 
Verdrahtung des PICs, dass es hier zu Spannungsdifferenzen zwischen den 
Vss Pins des PICs kommt. Wenn also über den einen Vss Pin mehr Strom 
gezogen wird wie über den anderen fällt mehr Spannung am Widerstand ab 
und es entsteht eine Spannungsdifferenz. Ich vermute, es ist besser 
beide Vss Pins aus einem R zu versorgen. Was meinst Du?

2. Die Schaltung zur Abkopplung der TWI/I2C ist gut. Aber ich kann mir 
vorstellen, dass es auch einfacher geht. Es sollte eigentlich reichen 
wenn man den Takt der I2C Teilnehmer z.B. per FET unterbricht. Ohne Takt 
sollte sich eine I2C Teilnehmer passiv verhalten, d.h. hochohmig sein. 
Das könnte / sollte man allerdings vorher nochmals prüfen. Aber wenn das 
geht ist das gewonnener Platinenplatz und weniger Geld für Bauteile.

3. Referenz
Gibt es einen Grund für L2 (Filterdrossel)?


Liebe Grüße Timo

[Markus B. (mbp-bayern)]

Tien schrieb:
> Hi Markus,
>
> hab mir heute den Schaltplan mal nähr angeschaut. Das mit den Eingangs
> Rs über die R Netzwerke finde ich eine gute Idee!
>
> Ich habe allerdings noch ein paar Fragen:
>
> 1. die Rs in der VCC Leitung hast Du vermtl. als Tiefpass reingemacht,
> gute Idee. Allerdings könnte es eventl. sein, je nach interner
> Verdrahtung des PICs, dass es hier zu Spannungsdifferenzen zwischen den
> Vss Pins des PICs kommt.

Nun eigentlich ist im PIC vermutlich wie im AVR eine metallene 
Verbindung. Zwischen den Pins im AVR ist das im mOhm-Bereich.
Sicher bin ich zwar nicht, meine das aber schon mal getestet zu haben.

Aus EMV Gründen werd ich das sicher noch optimieren.
Der Controller wird wohl eine kleine VCC-Fläche bekommen,
und die VCC-Pins werden dadurch verbunden.
Wie das dann versorgt wird ist was anderes.

Ob es die R's braucht oder ob die eher schaden,
da muss ich nochmal mit Experten diskutieren,
und mein Buch genauer studieren.

(Ich kann das Buch wirklich nur empfehlen.
Jeder der auch nur ein wenig Ahnung von Elektronik hat,
der sollte zumindest das Grundlegende Verstehen.
Z.B. die Stromumschaltanalyse.)


> 2. Die Schaltung zur Abkopplung der TWI/I2C ist gut. Aber ich kann mir
> vorstellen, dass es auch einfacher geht. Es sollte eigentlich reichen
> wenn man den Takt der I2C Teilnehmer z.B. per FET unterbricht. Ohne Takt
> sollte sich eine I2C Teilnehmer passiv verhalten, d.h. hochohmig sein.
> Das könnte / sollte man allerdings vorher nochmals prüfen. Aber wenn das
> geht ist das gewonnener Platinenplatz und weniger Geld für Bauteile.

Eine fallende Flanke auf der Datenleitung während Clock HIGH ist müsste 
das START auf dem TWI-BUS, und die Steigende das STOP sein.

Weiter gibt es bei manchen Bausteinen noch einzelne "Sonderfunktionen" 
am TWI-Bus, nur weiß ich gerade nicht, wo ich das zuletzt gelesen habe.

Das sollte man sicherheitshalber beides HIGH(Z) legen.

Die Schaltung habe ich in Ihrer Art aus der an255.pdf von NXP.
(Seite 4)

>
> 3. Referenz
> Gibt es einen Grund für L2 (Filterdrossel)?
>

Nun keinen Speziellen.
Vermutlich genügt das nachgeschaltete RC an der Ref. auch.

Wenn man die Ref aus Pins vom Controller zieht,
um sie so schalten zu können schadet das aber wohl nicht.
Nur ob man das Überhaupt so machen sollte ?

>
> Liebe Grüße Timo
Danke;


Nunja es ist eben Entwurfsstand.
Da sind einige Gedanken mal so festgehalten, dass sie nicht verloren 
gehen.

MFG:MBP
Markus.

PS:
Ich kann mich übrigens noch gut erinnern,
dass es mal einen Fehlerfall gab,
wo eine Schaltung jahrelang in Massenproduktion funktionierte,
bis einer von den VCC-Pins am AT90S8535 auf mehreren Platinen nicht 
gelötet war.

Der Fehler beim E-Test war Kurios:
Die Digital-Logik am anderen Ende des Controllers ging nicht...
Es war garkeine VCC an den Pads zu messen.

Nach einiger Suche ist aufgefallen,
dass ein par Controller-Pins nicht gelötet waren.
(Vermutlich SMD-Pastenauftrag Fehler.)

Aufgrund eines unbemerkten Layoutfehlers erhielt die Logik den Strom 
durch den Controller, und nicht aus VCC.

[Stefan (Gast)]

Wie siehts bei euch aus? Hat sich schon lange nix mehr getan?

[Tien (Gast)]

Hi Stefan,

also ich bin gerade an der Programmierung des PC Tools zur 
Reprogrammierung. Leider durch Hausumbau, Arbeitsplatzwechsel und 
Familie geht das ganze nur im Zeitlupentempo voran. Aber am 14.4. will 
ich mich mit Chris treffen und den Bootloader testen.

Soweit mal, ich melde mich wenn wir mal einen halbwegs brauchbaren 
Softwarestand haben.


Grüße Timo

[MBP-Bayern (Gast)]

Hallo Leute,

auch bei mir geht es sehr schleppend voran - kaum Zeit.

Den Stromlauf habe ich teilweise umgebaut;
Näheres wenn ich soweit einigermaßen fertig bin.

MFG:MBP
Markus

[Hermann (Gast)]

Hallo,

auf der Suche nach einem Bussystem für mein EFH, wird gerade gebaut, bin 
ich über diese Seite gestolpert.

Ihr seit ja schon sehr weit, aber ich würde mich doch noch gerne an der 
Entwicklung beteiligen wollen.

Ich kann Programmieren:
PIC’s in C18 und wenn es denn sein muss auch Assembler,
Windows-Anwendung in C++.

Wenn gewünscht, wie kann ich euch unterstützen?

Gruß

Hermann

[Markus B. (mbp-bayern)]

Hermann schrieb:
> Hallo,
>
> auf der Suche nach einem Bussystem für mein EFH, wird gerade gebaut, bin
> ich über diese Seite gestolpert.
>
> Ihr seit ja schon sehr weit, aber ich würde mich doch noch gerne an der
> Entwicklung beteiligen wollen.
>
> Ich kann Programmieren:
> PIC’s in C18 und wenn es denn sein muss auch Assembler,
> Windows-Anwendung in C++.
>
> Wenn gewünscht, wie kann ich euch unterstützen?
>
> Gruß
>
> Hermann

Hallo Hermann,

Sowas liest man gerne.

Die Kollegen hier haben teils Experimentierplatinen,
auf welchen sie Programmieren.

Mein Teil dürfte primär die Hardware sein.
Leider habe ich aber momentan immer noch das Problem,
dasss ich eingetlich überhaupt keine Zeit habe.
Daher habe ich auch noch nichts, was man Programmieren könnte.


MFG:MBP
Markus

[Hermann (Gast)]

Hallo Markus,

ich denke das meine Kenntnisse im Hardware-Bereich wohl nicht ausreichen 
um dich, dabei, zu unterstützen.

Werde mir mal, von Microchip, das PICDEM CAN-LINE 2 bestellen und 
einwenig Experimentieren und stelle mich dann mal auf ein Winterprojekt 
ein.


Habe geplant die Electroic-Dose(1068-02) von Kaiser zu verbauen, sind 
nicht ganz preiswert aber doch später problemlos zugängig oder gibt es 
eine Alternative oder bessere Lösung?

Gruß

Hermann

[Tien (Gast)]

Hallo Hermann,

nun möchte ich mich auch mal wieder melden.

Hermann schrieb:
> Ich kann Programmieren:
> PIC’s in C18 und wenn es denn sein muss auch Assembler,
> Windows-Anwendung in C++.

Schön, das Du Dich einbringen willst. Leider läuft es derzeit relativ 
langsam. Bei mir ist das teils beruflich (interner Stellenwechsel) 
bedingt, teils privat (unser Garten muss endlich gemacht werden). Daher 
ist es gerade recht still um das Projekt. Was nicht bedeutet, dass es 
auf Eis liegt. Es geht weiter, wenn auch nur sehr langsam. Wenn Du magst 
kannst Du Dir das Projekt mal anschauen:
http://code.google.com/p/tech-home-automation/
Ein guter Einstieg ist das Wiki, und hier die Protokolbeschreibung:
http://code.google.com/p/tech-home-automation/wiki/CanCommunicationProtocol

Da gibt es noch sehr viele offene Stellen, aber einen ersten Eindruck 
bekommt man schon. Gerne können wir hier über das Projekt diskutieren 
oder auch Fragen beantworten.

Der Softwarekern stammt derzeit fast 10%ig von Christian. Er hat das 
Protokoll umgesetzt, den Bootloader und CAN Treiber programmiert.
Derzeit hängt es an mir, ich schreibe gerade an einer C# Anwendung, mit 
der dann reprogrammiert werden soll. Sobald das halbwegs funktioniert 
könnte man erste Platinen in die UP-Dosen einbauen - ohne Bootloader 
macht das IMO keinen Sinn.

Hermann schrieb:
> Habe geplant die Electroic-Dose(1068-02) von Kaiser zu verbauen, sind
> nicht ganz preiswert aber doch später problemlos zugängig oder gibt es
> eine Alternative oder bessere Lösung?

Ich habe die Dosen bei mir überall eingebaut - nicht günstig, aber das 
einzige was ich diesbezgl. gefunden habe.

Hermann schrieb:
> Werde mir mal, von Microchip, das PICDEM CAN-LINE 2 bestellen und
> einwenig Experimentieren und stelle mich dann mal auf ein Winterprojekt
> ein.

Ja, das ist eine gute Grundlage. Ich denke es wird noch einige Zeit 
dauern bis wir eine funktionierend Lösung haben. Aber es geht mir pers. 
nicht darum "schnell" etwas zu haben, sondern etwas solides und dann 
lieber ein paar Monate länger daran entwickeln.

Wenn Du gerne aktiv mitarbeiten willst bist du herzlich willkommen und 
ich schalte Dir gerne den Zugang zum Repository frei. Allerdings sollten 
wir dann abstimmen, wie wir unsere Arbeit organisieren.


Liebe Grüße Timo

[Hermann (Gast)]

Hallo Timo,

dann werde ich mir mal das Wiki anschauen und mich bis mit dem PICDEM 
beschäftigen.
Ab August werde ich dann eh die meiste Zeit auf der Baustelle verbringen 
und mich unter anderem um die Verkabelung kümmern.
Machen wir es doch so, wenn ich was tun kann, vorzugsweise 
programmieren, sagt mir Bescheid.

Es sind ja schon einige SMD-Bauteile vorgesehen, wäre das eine Idee 
alles auf SMD umzustellen? Könnte mich ggf. nach einer Bestückungsfirma 
umsehen.

Gruß aus der Eifel

Hermann

[Timo E. (tien)]

Hallo Hermann,

schön, dann werden wir mal sehen was es zu tun gibt. Ich denke es wird 
genügend Applikationen zu programmieren geben, sobald wir die Basis 
(RTOS, CAN, Bootloader) mal am Laufen haben. Leider ist wie gesagt sehr 
wenig Zeit für das Projekt übrig. Aber es wird weitergehen, schließlich 
hab ich schon genug Kabel gezogen, die wollen auch was transportieren 
;-)

Das meiste sind SMD Bauteile. An der Hardware ist ja Markus dran, aber 
bei dem sieht's meines Wissens nach zeitlich auch nicht besser aus.

Viel Erfolg auf der Baustelle!
Das hab ich ja schon weitestgehend hinter mir - das Dachgeschoss fehlt 
noch.


Liebe Grüße Timo

[Markus B. (mbp-bayern)]

Timo E. schrieb:
> Das meiste sind SMD Bauteile. An der Hardware ist ja Markus dran, aber
> bei dem sieht's meines Wissens nach zeitlich auch nicht besser aus.

Hallo Zusammen;

nun wirklich viel besser sieht es noch nicht aus,
aber immerhin ein kleinwenig.

************************************************************************ 
******

Da hier im Forum jemand geschrieben hat,
dass Fault-Tolerant CAN TJA1054 für uns nicht nötig ist,
so habe ich diese Option nochmals überdacht.

Nun Kabelbrüche sollte es bei einer ordentlichen Installation im Haus 
nicht geben - die sind im KFZ wahrscheinlicher.

Störungen, die so hoch sind, dass der normale HS-CAN nicht mehr 
funktioniert, die sind wohl wirklich nicht zu erwarten.

Danach habe ich mir angesehen, welche Fehler denn der TJA1041 erkennen 
kann, und welche Fehler keinen Kommunikationsausfall verursachen.
Wirklich begeistert bin ich von den Möglichkeiten im Vergleich zum 
LS-CAN nicht.

Da geplant wird, dass nur bei vorhandener Versorgung geschlafen wird und 
dass der Bus-Knoten seine Versorgung nicht abstellen zu braucht,
so benötigen wir das INH-Feature eigentlich nicht.

Weiter sehe ich Versorgungen über 24V als realisierbar an,
aber die Bausteine können nur bis maximal 27V über VBATT/INH.

Die Vorteile gegenüber den Standard CAN-IC's sind wohl wirklich eher 
mager.

Dann noch die zusätzlichen IO's, die zu reservieren wären, so wie der 
Platzbedarf auf der Platine, der für andre Dinge sinnvoller ist.

************************************************************************ 
******

Die letzten größeren Änderungen am Stromlauf habe ich Ende März gemacht.
Dabei habe ich auf normale SO8 CAN reduziert und die IO's komplett neu 
verteilt.

Eine Spannungsregelung habe ich vorerst ebenfalls komplett entfernt,
wird aber wieder kommen, denn in dieser Form wäre die Schaltung nur mit 
5V zu versorgen.

Das Netzteil für den Controller könnte aber auch als eigene Platine 
realisiert werden, die Huckepack auf den Controller aufgesteckt wird - 
nur da habe ich mir noch nicht ausreichend Gedanken gemacht.

Den Zwischenstand füge ich euch mal unverbindlich zur Ansicht an.
Und zwar in Farbe, da sich dort die Anmerkungen besser zuordnen lassen 
als in SW.

Natürlich habe ich aber die alten Versionen auch noch.

************************************************************************ 
******

Da ich in einer kostenlosen Version von Target arbeite, so bin ich für 
die Herstellung der Leiterplatten an den PCB-Pool gebunden, was die 
Freiheiten etwas einschränkt.

Aber dort gibt es seit Februar was neues:
Wenn man seine Platinen dort fertigen lässt, so bekommt man seit Februar 
die Gerberdaten.

Somit können andere nun doch einen Abweichenden Hersteller aussuchen.

************************************************************************ 
******

Da ich selbst in einer kleinen Firma arbeite, in der sehr komplexe 
Baugruppen entwickelt und täglich in Stückzahlen von Muster bis 
Kleinserie im Einschicht-Betrieb gefertigt werden, so dürfte es nicht 
weiter kompliziert werden, eine kostengünstige Bestückung zu erhalten, 
sofern das wirklich nötig wäre.

Auch wenn das Thema SMD in den vom mir geplanten Größen für manche 
Hobby-Bastler schon äußerst komplex wirkt, so ist das für einen 
Elektroniker mit gutem Fingerspitzengefühl nur eine kleine 
Aufwärm-Übung.

Mit einem meiner Kollegen aus Prüffeld/Fertigung habe ich das schon 
genau besprochen;
Er würde sogar jedes Bauteil einzeln mit Pinzette und Lötkolben 
aufbringen, sofern ich nicht 100erte Platinen in kürzester Zeit 
benötige.


MFG:MBP
Markus.

[Timo E. (tien)]

Hi Markus,

vielen Dank für Deine Arbeit! Das bringt das Projekt schon wieder ein 
Stück weiter. Kannst Du bei Gelegenheit den Schaltplan noch etwas 
kommentieren.

Im speziellen würden mich folgende Punkte interessieren:

- Versorgung VDD, VCC getrennt durch L2, warum?
- Hab jetzt nicht in die Spec geschaut... Benötigen wir das Pico AND, 
oder kann eventl. ein Portpin den P82B96 direkt versorgen?
- Du denkst beim Layout an die vorhandenen ZJYS81 CAN Drosseln?

Mir gefällt der Entwurf sehr gut. Wie groß wird dann das Layout?

Eventl. wäre so eine extra Versorgungsplatine sehr nett, dann könnte man 
die µC Platine auch gut für andere Zwecke einsetzen. Nur vermute ich, 
dass die Anwender, welche die Elektronik in eine herkömmliche 
doppeltiefe UP Dose einbauen wollen eher Probleme mit der zusätzlichen 
Platine bekommen. Bei meinen Kaiser Elektronikdosen ist das kein 
Problem.

Momentan tendiere ich ja zu der simplen Lösung mit den Recom R-785.0-0.5
oder was macht Deine Idee mit dem Dual Spannungsregler?

Grüße Timo

[Gerald *. (pyromane)]

Sehr interessantes Projekt, werde ich auf jeden Fall im Auge behalten :)

Markus B. p. schrieb:
> Da ich in einer kostenlosen Version von Target arbeite, so bin ich für
> die Herstellung der Leiterplatten an den PCB-Pool gebunden, was die
> Freiheiten etwas einschränkt.

Du wirst vermutlich die TARGET3001! PCB-POOL® Edition nutzen, diese ist 
rein auf PCB-Pool gebunden, da sie für dich die Lizenzgebühren zahlen^^

Alle anderen Versionen findest du hier: 
http://server.ibfriedrich.com/wiki/ibfwikide/index.php?title=Versionen_und_Preise

[Markus B. (mbp-bayern)]

Gerald *. schrieb:
> Sehr interessantes Projekt, werde ich auf jeden Fall im Auge behalten :)
>
> Markus B. p. schrieb:
>> Da ich in einer kostenlosen Version von Target arbeite, so bin ich für
>> die Herstellung der Leiterplatten an den PCB-Pool gebunden, was die
>> Freiheiten etwas einschränkt.
>
> Du wirst vermutlich die TARGET3001! PCB-POOL® Edition nutzen, diese ist
> rein auf PCB-Pool gebunden, da sie für dich die Lizenzgebühren zahlen^^
>
> Alle anderen Versionen findest du hier:
> 
http://server.ibfriedrich.com/wiki/ibfwikide/index.php?title=Versionen_und_Preise

Hallo Gerald,

Dein Interersse freut mich.

Nun ich kenne die "Feinheiten" von den Versionen;
Insbesondere, dass die von mir eingesetzte Version mehr erlaubt,
als was die Mindestanforderng für diese Projekt ist.

Die Anforderung würde derzeit nur die Version erfüllen,
die man offiziell für etwas über 600€ kaufen kann:
Es sind 4 Lagen Multi-Layer geplant - 2 Lagen sind mir nicht genug.

Nur bin ich eben an den einen Pool gebunden;
Das stört mich aber nicht - Im Gegenteil - die Qual der Wahl entfällt.
Und für Muster ist der Pool sicherlich mehr als gut genug.

Wenn ich für Serie vom Pool abweichen möchte,
so könnte ich das seit Februar diesen Jahres,
sofern ich die Muster beim Pool machen lassen habe, ganz legal.

Bei einem kleinen Dienstleiter bekommt man sehr viel mit.
Viel gutes und noch mehr MIST.
Daher käme für mich nur ein einziger renomierter Hersteller in Frage,
wo ich mir sicher wäre, dass ich nicht viel Geld zum Fenster 
herauswerfe.

Wir hatten bei verschiedenen Herstellern schon größere und kleinere 
Probleme, aber der Liferant, der sich über 10 Jahre nach und nach zum 
Hauptlieferanten gemausert hat, der hat das nicht ohne Grund geschafft.
Der Grund ist aber nicht dass er nie Fehler macht.

Und Ja Chemisch NI-AU hätte schon was - das wäre mein Fafourit.
Aber Gold ist nicht billig, und erst recht nicht einfach zu löten.
Also nix für Hobbby-Bastler, die sowas noch nie gelötet haben.


MFG:MBP
Markus

[Markus B. (mbp-bayern)]

Timo E. schrieb:
> Hi Markus,
>
> vielen Dank für Deine Arbeit! Das bringt das Projekt schon wieder ein
> Stück weiter. Kannst Du bei Gelegenheit den Schaltplan noch etwas
> kommentieren.

Hallo Timo,

Fangen wir mal unten an:

Timo E. schrieb:
> Momentan tendiere ich ja zu der simplen Lösung mit den Recom R-785.0-0.5

Schaltregler - dem ich nach wie vor vertrauen würde:

Max Mustermann schrieb:
> Timo E. schrieb:
>> OnBoard:
>> --------
>> - Schaltregler für min. 24Volt
> Das hab ich mir auch schon überlegt. Bin beim MAX5035 gelandet
> (http://datasheets.maxim-ic.com/en/ds/MAX5035.pdf).

Besonders, da er nicht schlapp macht,
wenn mal deutlich mehr als 24V am Bus sind.

Den kann man auch noch gut gegen Transienten schützen,
da er so viel Spannung verträgt.

Wenn man 24V gar aus einem Akku beziehen möchte,
so ist der REC kaum noch zu schützen.
(TVSZ-Dioden Kennlinien beachten.)

Ein diskreter Schaltregler wäre zu hungrig nach Platz
Rein linear gefält mir noch weniger.

Eine duale Ausführung macht keinen Sinn,
wenn man einen solch guten Regler wie den MAX nimmt.

Und wenn man nach den Kosten kuckt:
2 billige Regler (LIN+SW-Mode) kosten ähnlich viel wie 1 teuerer.

Die C's für die Schaltung kann man nie umgehen;
An Schaltregler wird L+D auch deutlich auf die Kosten eingehen.
Um so schlimmer, je günstiger der Regler ist.

Was die ältern Schaltregler angeht - Tendenz:
Kleine Freuenz = geringer Eigenstrom aber große L+C.
Hohe Freuenz = kleine L+C aber höherer Eigenstrom.
Wobei hohe Frequenzen obendrein EMV-Kritischer sind als niedrige.

Nun die Löcher & den Platz für 7805-Pinkompatible Regler
werde ich auf alle Fälle mal vorsehen,
auch wenn ich das vermutlich nichtmal testweise bestücken werde.

Der von Dir vorgeschlagene Regler nimmt schon wieder 5-7 mA fürs 
nichts-Tun.
(lt. Datenblatt - nur für Spannug am Ausgang ohne Last.)
Den müsste man mal in der Praxis durchmessen.

Die Welt dieses Reglers ist der Ersatz eines 1A Linear-Reglers,
der immer gut ausgelastet ist, aber nicht unsere paar mA.


Beispiel-Rechnung:
24V * 5mA = 120 mW
24V, 5mA, 20 Platinen = 2,4W
2,4W bei 85% Netzteil Wirkung 230-->24V = 2,8W
2,8W * 24h = 68Wh/Tag
2,8W  24h  365 Tage = 24,7 KWh / Jahr.
24,7 * 0,20€ = 4,95€ Pro Jahr, für nichts.

Zur Erinnerung:
Markus B. p. schrieb:
> Der MAX5035 bekommt das mit 6,75mW hin.

6,75mW, 20 Platinen = 135mW
135mW bei 85% Netzteil Wirkung 230-->24V = 160mW
160mW * 24h = 3,8Wh/Tag
160mW  24h  365 Tage = 1,4 KWh / Jahr.
1,4 * 0,20€ = 0,28€ Pro Jahr, für nichts.

Daher gefällt mir der MAX so gut - der kostet 1x und nicht ständig.


*********************************************
Timo E. schrieb:
> Nur vermute ich, dass die Anwender, welche die Elektronik in eine
> herkömmliche doppeltiefe UP Dose einbauen wollen eher Probleme
> mit der zusätzlichen Platine bekommen.

Timo E. schrieb:
> Mir gefällt der Entwurf sehr gut. Wie groß wird dann das Layout?

Genau die Doppelt-tiefen Dosen habe ich selber;
Hinter jedem normalen Schalter ist zwischen den Karallen am meisten 
Platz.
Somit wäre meine Vorstellung, das das Ding kaum mehr 2D Platz benötigt,
als ein BJ-Schalter-Korpus.

Die Tiefe ist dann auch nicht so schlimm;
Aber diese Huckepack-Platine könnte sogar die größere von beiden werden,
da sie hinterhalb der Krallen wäre.

Für die Hohe CAN-Drossel könnte sie ein Loch haben,
dann wird das Sandwich auch schon wieder dünner.


Max 4x4x3 Cm über die jeweilig größten Abmessungen stelle ich mir also 
vor.


*********************************************
Schaltplan:

Deine Drossel benötigt nur minimal andere Pads,
als das bereits vorgesehene Standard-Bauteil.
Diese Kleinigeit wird im Layout berücksichtigt.

Pico-Gate:
Ein Port könnte das evtl. schon; Das hat aber mit der EMV zu tun.
Wenn das Pico-Gate vorhanden ist, so kann Strom nur von VCC zum P82B96;
Nicht aber von VDD für den PIC.

"- Versorgung VDD, VCC getrennt durch L2, warum?"
Heißes Eisen... schon wieder EMV.

Der PIC kann dann nur seine VDD/GND versauen
aber nicht die gesamte Schaltung.
Evtl. wird hier aber doch ein R oder R+L nötig;

Ich muss das Resonanzverhalten von sonem Ferit mal prüfen;
nicht dass ich hier einen LC-Resonanzkreis schaffe,
der durch den PIC erst richtig angeregt wird,
dann hätten wir einen schönen HF-Störsender.

MFG:MBP
Markus

[Hermann (Gast)]

Hallo Timo,

was hast du für Buskabel verlegt?
Liegt das Buskabel/Leerrohr Parallel zur Netzspannung?

Danke schon mal für die Info, Gruß aus der Eifel
Hermann

[Tien (Gast)]

Hallo Hermann,

bei mir liegt EIB Leitung in den Wänden. Das hat zum einen den Grund, 
das ich VDE konform sein will, zum anderen könnte bei einem eventuellen 
Verkauf der Nachfolger auf EIB umrüsten, da ich bestimmt meine Technik 
nicht drin lassen würde.
Anfangs hab ich Leerrohre gelegt, aber schnell erkannt, dass das zu 
lange dauert. Der Vorteil ist eher gering, da ich vermutlich nie die EIB 
Leitung ersetzen würde. Und da ich ja von Dose zu Dose fahre kann ich 
auch nicht schnell was einziehen ohne alle vorherigen Dosen zu öffnen. 
D.h. meine EIB Leitung liegt wie die Netzleitung unter Putz. Einzig 
Netzwerk und SatLeitungen liegen im Rohr. Ausserdem liegt in den 
Wohnräumen auf beiden Seiten je ein leeres Rohr um zukünftige Technik in 
die Zimmer zu bringen.

Die EIB Leitung liegt parallel zum Netzkabel. Ich geh mal davon aus, das 
ich 125kb/s hin bekomme. Wenn nicht, ist das auch nicht schlimm, da auch 
9,6kb/s für eine Steuerung reichen würde. Zum Reprogrammieren, ist das 
allerdings wirklich zu langsam.

Ich hab ja mittlerweile zwei Stockwerke fertig, d.h. wenn Markus die 
Platinen fertig hat kann ich mal einen Test machen und zwei oder mehr 
Platinen ans Netz hängen und ein Bustester darauf laufen lassen, bzw. 
mit CANoe mal messen.

Wenn du willst, kann ich mal ein paar Bilder hier einstellen, wie die 
EIB Leitung in Verbindung mit den Kaiser Dosen aussieht.

Grüße Timo

[Hermann (Gast)]

Hallo Timo,

Danke für die Ausführungen, das EIB-Kabel war auch meine Wahl.

Fotos wären toll, wieviel Meter Buskabel hast du verlegt?

Gruß

Hermann

[Timo E. (tien)]

Ok, Bilder folgen (hoffe ich komme heute Abend dazu).
Meter kann ich Dir nicht genau sagen, müßte schauen was ich gekauft 
habe.
Aber so grob geht es um jeden Raum einmal rum + hoch und runter, da ich 
ja zu jeder Steckdosenkombi, Tasterkombi, Rolladen, Heizung, Decke, Tür 
gefahren bin. Jeder Stock fängt im Keller in einer 
"MultimediaVerteilung" an und endet dort auch wieder. Falls die Länge 
eines Stockwerkstrangs zu lang wird gibt es noch die Möglichkeit den Bus 
ca. in der Mitte zu trennen und zwei Stichleitungen zu machen. Dann muss 
unten im Keller ein Gateway die Verteilung der Botschaften übernehmen.

Grüße Timo

[Markus B. (mbp-bayern)]

Hallo zusammen;

Dieses Wochenende habe ich mich wieder ettwas um die "CPU" gekümmert:
Zum Thema mit Spannungsregler/Netzteil:

Da habe ich beschlossen, dass ich es so realisieren werde,
wie schon kurz überlegt:

Die CPU bekommt nun KEINERLEI Stabilisierung - nur die 4,1V Referenz.

Werden soll es ein einseitig bestückter 4-Lagen Multilayer.
Abmessungen von: [38,100 mm x 27,940 mm] bis: [45,720 mm x 33,020 mm]

Theoretisch könnte man an die GPIO's Schalter oder Taster anklemmen;
Das habe ich aber nicht vor.

Für mich wird es ein "UP-Tasterinterface" für die "CPU" geben:
- ähnliche Abmessungen wie die CPU
- mit BUS-Anschluss (Klemme oder Lötaugen + Zugentlastung)
- Netzeil (vermutlich Schaltregler)
- aktive bzw. befilterte Eingänge für Schalter/Taster
- Ausgänge für LED-Beleuchtung der Wippen/Knöpfe.

Diese Platine möchte ich ebenfalls wieder einseitig bestückt ausführen.
Zumindest die kleineren Bauteile sollen zwischen den beiden Platinen 
sein.
Wenn man die Platinen zur "verschobenen" Montage auslegt,
so stehen dicke Spulen (CAN / Schaltnetzteil) und Klemmen am Rand frei.

Nach dem Zusammenbau soll das Sandwich 10-15mm an Dicke nicht 
überschreiten.

Bervor ich aber Details für das "UP-Tasterinterface" festlege,
so werde ich den Thread über den Taster-Nachbau nochmal genau ansehen.
Evtl. rüste ich dann teilweise auf solche Taster um.



@Timo:
Nachtrag zu "Schaltplan":

Das Pico-Gate hat übrigens noch einen Sinn:
Wenn man keinen IO für "nCS_SPI" anlegt,
so zieht der PULL-UP-R am Gatter den "nCS_SPI" auf HI;

Der TWI-BUS (der SO8 TWI-EEPROM) kann somit angesprochen werden,
ohne irgend einen externen IO opfern zu müssen.

nur wer SPI braucht,
der muss mit dem EXTERNEN EINGANG "nCS_SPI" den TWI-Puffer steuern.

Evtl. kann man die CPU auch als SPI-Slave nutzen.
Das aber nur, wenn vor dem eigentlichen nCS vom SPI-MASTER
ein "TWI-IDLE" auf den SPI-Leitungen erkannt wurde.


MFG:MBP
Markus.

[Timo E. (tien)]

Hi Markus

> Die CPU bekommt nun KEINERLEI Stabilisierung - nur die 4,1V Referenz.
ok. Das hat natürlich den Vorteil, dass man diese Platine auch für 
andere Dinge einsetzen kann.

> Für mich wird es ein "UP-Tasterinterface" für die "CPU" geben:
> - ähnliche Abmessungen wie die CPU
> - mit BUS-Anschluss (Klemme oder Lötaugen + Zugentlastung)
> - Netzeil (vermutlich Schaltregler)
> - aktive bzw. befilterte Eingänge für Schalter/Taster
> - Ausgänge für LED-Beleuchtung der Wippen/Knöpfe.
Ok. Ist auch nicht schlecht, so könnte man für verschiedene 
Applikationen verschiedene Platinen entwerfen. z.B. benötige ich 
irgendwann für meine Rolladen ein UP Modul, welches jeweils ein Rollo 
steuern kann.
Hast Du vor die Bus Beschaltung (Transceiver, Schutzschaltung) aus das 
CPU Board zu machen oder auf das Interface Board?

> @Timo:
> Nachtrag zu "Schaltplan":
>
> Das Pico-Gate hat übrigens noch einen Sinn:
> Wenn man keinen IO für "nCS_SPI" anlegt,
> so zieht der PULL-UP-R am Gatter den "nCS_SPI" auf HI;
>
> Der TWI-BUS (der SO8 TWI-EEPROM) kann somit angesprochen werden,
> ohne irgend einen externen IO opfern zu müssen.

Ja, ist ein Vorteil.

 Grüße Timo


P.S. Ich hab mir mittlerweile folgendes zugelegt:
http://www.mikroe.com/eng/products/view/595/mikrommb-for-pic32-board/
Das wird das Terminal für das Wohnzimmer.
Kostet ca. 72 Euro + Versand.

[Helmut (Gast)]

Ich sach doch, ihr kommt da auch noch hin:

http://www.youtube.com/watch?v=e703G_Qa19Q&feature=mfu_in_order&list=UL
und

www.helmutholm.de

und auch mit CAN-Bus.......mit dem MX7 soll auch noch Ethernet 
kommen...soll ..... wenn wieder Zeit ist....

[Timo E. (tien)]

Du bist schon ganz schön weit - Respekt!

Aber das Entwickeln macht ja auch Spaß (nicht ohne Grund hab ich dieses 
Hobby auch zum Beruf gemacht).
Ich habs nicht eilig, mal sehen was die Zukunft bringt.
Das wichtigste war, dass überall eine Datenleitung liegt, der Rest
kommt dann nach und nach.

Grüße Timo

[Markus B. (mbp-bayern)]

Timo E. schrieb:
> Hi Markus
>
>> Die CPU bekommt nun KEINERLEI Stabilisierung - nur die 4,1V Referenz.
> ok. Das hat natürlich den Vorteil, dass man diese Platine auch für
> andere Dinge einsetzen kann.
Ja das ist Sinn der Sache;

>
> ... z.B. benötige ich
> irgendwann für meine Rolladen ein UP Modul, welches jeweils ein Rollo
> steuern kann.

Also mit 230V auf Eigenbau ?

Mir gefällt Deine Idee mit den Strom-Stoß-Relais langsam immer besser.
Nach Datenblatt sind 2 Kontakt-Sätze in einem SSR auch über 1KV 
isoliert.
Wenn man dann noch ein "Rücklese-Interface" mit Optokopplern und 
isoliertem DC/DC (1-2W) baut, so ist man wohl schon verdammt sicher und 
man kann alles mit den SSR lösen.
Auch Rollos denn ein SSR kann die Richtung AUF/AB und ein 2. kann 
START/STOP.

> Hast Du vor die Bus Beschaltung (Transceiver, Schutzschaltung) aus das
> CPU Board zu machen oder auf das Interface Board?
Ja auf die CPU;
Der Schaltplan bleibt wohl so ziemlich so, wie er ist.

>
> P.S. Ich hab mir mittlerweile folgendes zugelegt:
> http://www.mikroe.com/eng/products/view/595/mikrommb-for-pic32-board/
> Das wird das Terminal für das Wohnzimmer.
> Kostet ca. 72 Euro + Versand.
Auch gut ja.
Schönes Teil - für Wohnzimmer muss man sich aber noch ein schikes 
Gehäuse machen.

Nun ich habs ja bekanntlich auf das hier abgesehen:
4,3" TFT mit serieller Schnittstelle
http://www.lcd-module.de/produkte/ediptft.html


MFG:MBP
Markus.

[Markus B. (mbp-bayern)]

Helmut schrieb:
> Ich sach doch, ihr kommt da auch noch hin:
>
> http://www.youtube.com/watch?v=e703G_Qa19Q&feature=mfu_in_order&list=UL
> und
>
Hehe ja irgendwann schon.............
Aber jetzt fangen wir mal überhaupt erst an.

> www.helmutholm.de
Hast ja schon einiges geschaffen.

>
> und auch mit CAN-Bus.......mit dem MX7 soll auch noch Ethernet
> kommen...soll ..... wenn wieder Zeit ist....

Ethernet:
Kennst Du Lantronix XPORT ?
Sehr kompakt - eine aktive ethernet-Buchse.

Ethernet zu RS232 (3,3V (5V tolerant))
300 bps to 921,600 bps

Werde ich evtl. mal testen.


MFG:MBP
Markus.

[Helmut (Gast)]

Hallo Markus,
der PIC32MX795 hat schon CAN und Ethernet drin.

Das macht es schon leichter, wobei die externen Bauelemente schon Stress 
genug sind.

Aber du bist gut drauf, hast erst im Januar angefangen. Das wird schon.

Wenn du die Hardware fertig hast, dann gibt es was zum testen, 
verbessern, testen und wieder verbessern.

Die Software ist ein extra Thema. Du wolltest welchen Compiler nehmen?

Gruß Helmut

[Markus B. (mbp-bayern)]

Hallo Helmut;

Helmut schrieb:
> Hallo Markus,
> der PIC32MX795 hat schon CAN und Ethernet drin.
Das macht ihn natürlich interressant für erste Versuche.

>
> Das macht es schon leichter, wobei die externen Bauelemente schon Stress
> genug sind.
Wie meinst Du das ?
Von der CPU-Load oder vom Leiterplatten entwickeln ?

>
> Aber du bist gut drauf, hast erst im Januar angefangen. Das wird schon.
>
Hehe das täuscht.

Die älteste Datei ist vom 26.12.2007.

Öfters war auch mal eine Länger Pause über Monate,
aber eigentlich habe ich immer wieder was überlegt.

Damals hätte es noch AVR Mega16 mit RS485 werden sollen.
Dann Mega16 + MCP2515
Später hab ich überlegt wegen Platzmagel Mega8 + MCP2515.

März 2009 kam die Überlegung PIC18 Tqfp44 mit CAN.
Auch wegen Stromverbrauch der 2 getrennten "Prozessoren".

Das hätte nie funktioniert, und wenn nicht lange,
oder es hätte gesendet wie ein Rundfunksender.
Schaltregler layouten ohne die geringste Ahnung...

In eine UP-Dose hätte die 1. Platine nur mit einem großen Hammer* 
gepasst.
[* vermutlich über 2 KG ;-) ]

Die Platinen wären rund gewesen und knapp der Durchmesser,
der an einer nackigen Dose am Tisch liegend innen ermittelt wurde.

An die Kabel hab ich zwar gedacht, aber nicht,
wie man die Platine nach den Kabeln hinein/heraus bekommt.

Aber das größere Problem:
Einige Dosen sind nach dem Einputzen nicht mehr 100% Rund.


> Wenn du die Hardware fertig hast, dann gibt es was zum testen,
> verbessern, testen und wieder verbessern.

Ja zum verbessern gäbe es immer was;
Insbesondere die Features.

Aber ich habe nicht vor,
dass ich 10 Versuche benötige, bis ich's einbaue.
Eigentlich soll die "Revision 0" grundsätzlich einsatzfähig sein.
Zumindest bis auf EMV - das kann ich nicht garantieren.

Lange genug habe ich ja nun schon dran "rumgedoktort".
Über die Jahre habe einge Erfahrung zusammen gebracht.
Insbesondere was man, und vorallem was ANDERE falsch machen können.

>
> Die Software ist ein extra Thema. Du wolltest welchen Compiler nehmen?

Ich habe mich da noch nicht festgelegt aber,
folgendes habe ich mehr oder weniger oft zwieschen den Fingern:

PIC18 &
dsPic33  --> SW vom Hersteller.

AVR      --> Studio 4 + ASM ODER WinAvr, noch kein "Inline ASM" gemacht.

8051     --> SDCC
(AT89S52 PLCC44 - Die lagen Stangenweise rum - macht aber wenig Spaß,
weil der aus Studio 4 bald 2 Minuten flasht.)

S12/HC12 --> Frescale CodeWarrior.

(Alles z.B. für Testaufbauten in der Firma.)

Off-Toppic:
Ansonsten ärgere ich mich Privat für einen Bekannten mit HOLTEK-C.
(auf HT46R23)

Habe ein Projekt, das auf AVR und diesem Chip parallel entwicklet wird.
Der AVR ist nur in (m)ein "Test-Gerät" eingebastelt, da Holtek OTP.

Das Gerät selbst wird in China gefertigt, der Prozessor soll bleiben,
da er dort in diversen anderen Projekten läuft.

AVR Compiliert die letze Erweiterung,
Holtek hat eine interne Grenze für die Anzahl der Funktionen,
vermutlich im Linker.

edit:
"Ethernut" (ARM) hab ich noch vergessen.
Damit habe ich auch schon etwas gespielt.
/edit.

Allen gemeinsam ist dass der Code-Editor für alle Notepad++ wurde.
Der Einheit wegen - jeder Hersteller hat sonst seine eigene Farb-Welt,
und dann blick ich zumindest garnix mehr.

>
> Gruß Helmut


MFG:MBP
Markus.

[Helmut (Gast)]

Nun denn, einfach mal machen.

Ich für meinen Teil, mache es mit 'nem Basic-Compiler von Mikroe und nur 
als Hobby.

Deshalb vielleicht auch die naiven, einfachen Layouts.......

Kein Schaltregler, bei so wenig Strom, finde ich, ist es unnötig. 
Bißchen BAT54S und ....Watchdog sei dank, es geht.

Gruß Helmut

[Timo E. (tien)]

Hi Markus,

>> ... z.B. benötige ich
>> irgendwann für meine Rolladen ein UP Modul, welches jeweils ein Rollo
>> steuern kann.
>
> Also mit 230V auf Eigenbau ?

Hm, da bin ich mir noch nicht ganz sicher... Es gibt hier bei 
mikrocontroller.net ein Thread, wo einer das mit einem Relais und einem 
SSR gelöst hatte - sah sehr elegant aus und ist wohl auch schon einige 
Jahre in Betrieb. Damit wäre eventl. auch die Idee umzusetzen die 
jeweils Stromlose Spule als "Drehzahlsensor" zu nutzen - keine Ahnung ob 
das geht, habs noch nicht getestet. Der Vorteil wäre, dass man einen 
blockierten Motor sofort erkennt. Weiterhin bleibt aber das Problem, 
dass der Motor weiterdreht obwohl der Rollo hängt und beim Abwärtsfahren 
gibts dann Chaos im Rollogehäuse. Ohne eine Absicherung tu ich mir 
schwer das autonom laufen zu lassen - ich denk da insb. an die 
Dachfensterrollos im Winter.

Das ganze halte ich bzgl. elektr. Sicherheit beherrschbar, da zum einen 
alles berührungssicher ist, zum anderen der Strom gut bekannt ist, d.h. 
man kann sehr scharf absichern. Und da ich ja auf der Platine nur die 
Phase habe kann eigentlich auch kein direkter Kurzschluss passieren.
Aber am liebsten wäre mir natürlich ein UP SSS, den hab ich aber bisher 
nicht mit zwei unabhängigen Relais gefunden - kennst Du was?
UP muss sein, da ich die Rolloleitungen nicht in die Verteilung ziehen 
konnte (zu wenig Platz, da Umbau, kein Neubau).

> Mir gefällt Deine Idee mit den Strom-Stoß-Relais langsam immer besser.
> Nach Datenblatt sind 2 Kontakt-Sätze in einem SSR auch über 1KV
> isoliert.
> Wenn man dann noch ein "Rücklese-Interface" mit Optokopplern und
> isoliertem DC/DC (1-2W) baut, so ist man wohl schon verdammt sicher und
> man kann alles mit den SSR lösen.

Hast Du Dir die RS485 Eltakos angeschaut? Johannes Fritsche hat da ja 
etwas Arbeit reingesteckt und es soweit zum lLaufen gebracht, dass er 
Dimmer und Relais direkt ansteuern kann (also den Zustand direkt 
vorgeben kann). Damit wäre für mich ein Zurücklesen nur für wirlich 
sicherheitsrelevante Dinge notwendig. Der Vorteil ist, dass man das 
System so aufbauen kann, dass die Basisfunktionen (Licht an/aus) auch 
ohne Selbstbau Hausautomation funktioniert (Eltako Tastenmodul ->RS485-> 
Eltako SSS). Sobald Spannung auf die Hausautomation gegeben wird 
schalten zwei Relais die RS485 auf einen µC um. Dieser fängt zum einen 
über das eine Ende der RS485 die Tastendrücke ab und steuert zum anderen 
über das andere RS485 Ende die Dimmer und SSS. Das ist meiner Meinung 
nach die derzeit beste Lösung beide Welten (Selbstbau & kommerzielle 
Aktoren) zu verbinden.

> Auch Rollos denn ein SSR kann die Richtung AUF/AB und ein 2. kann
> START/STOP.

Ja, wäre perfekt, aber wie gesagt ich brauch UP.
Und auch die Steuerung von Steckdosen muss ich UP machen. Aber da gibt 
es ja UP SSS und UP Dimmer.

>> Hast Du vor die Bus Beschaltung (Transceiver, Schutzschaltung) aus das
>> CPU Board zu machen oder auf das Interface Board?
> Ja auf die CPU;
> Der Schaltplan bleibt wohl so ziemlich so, wie er ist.

Kannst Du bitte trotzdem die drei Pins für einen "7805er" (bzw. Recom) 
drauf machen? Dann wäre das nämlich auch eine perfekte Platine für die 
ein oder andere Spielerei. Bzw. wenn man nur einen Sensor (z.B. DS1820) 
irgendwo braucht reicht dann die Platine mit Recom auch direkt. Das wäre 
SUPER :-)

>> P.S. Ich hab mir mittlerweile folgendes zugelegt:
>> http://www.mikroe.com/eng/products/view/595/mikrommb-for-pic32-board/
>> Das wird das Terminal für das Wohnzimmer.
>> Kostet ca. 72 Euro + Versand.

> Auch gut ja.
> Schönes Teil - für Wohnzimmer muss man sich aber noch ein schickes
> Gehäuse machen.

Da hab ich schon eine Idee: Aus dichtem schwarzem Kautschuk einen Rahmen 
ausschneiden, der den relativ geringen Abstand Wand->Display Oberfläche 
überbrückt. Dann einen netten Rahmen aus Edelstahl oder Alu um das 
Display rum, der den kleinen Platinenrand um das Display versteckt. Das 
ganze wird per Heißkleber unsichtbar zu einer Einheit verbunden 
(Edelstahlrahmen, Display, Kautschuk). Oder halt auf irgendeine andere 
Art am Display befestigt. Nun werden 4 Neodym Magnete bündig in den 
Kautschuk eingelassen und ebenfalls verklebt. In die Wand werden dann 
ebenfalls vier Neodym Magnete bündig eingelassen. Direkt hinter dem 
Display liegt eine UP Dose, die vom Display verdeckt wird. hier erfolgt 
die elektr. Anbindung an den Bus. Nun lässt sich das Display einfach an 
die Wand pinnen. Eventl. müssten man das Ganze gegen seitliche 
Verschiebung sichern z.B. durch eine Kante, aber ich denke das müsste 
mit den Magneten bereits ausreichend fest sein.
Ein ähnliches Prinzip hab ich ja mit dem 10" Display im Esszimmer für 
meinen "Keller" PC gemacht. Der per Laser ausgeschnittene 
Edelstahlrahmen ist an den Monitor geklebt (PowerStrips). Das Ganze wird 
dann per Magnete im (selbst gebauten) UP Gehäuse gehalten. Das ist 
erstaunlich stabil - ich hatte mir da selbst weniger erhofft.
Siehe hier:
Beitrag "Re: Anforderungssammlung CAN Hausbus mit PIC µC"
in den folge Beiträgen ist auch ein Lieferant für den Edelstahlrahmen 
genannt.

> Nun ich habs ja bekanntlich auf das hier abgesehen:
> 4,3" TFT mit serieller Schnittstelle
> http://www.lcd-module.de/produkte/ediptft.html

Das Tolle an dem MikroE MMB ist eben der PIC32, der auch bereits CAN 
dabei hat (ohne Transceiver, aber eine Platine mit Regler usw. wird eh 
benötigt). Außerdem ist ein Stereocodec drauf, damit sind Sprachausgaben 
auch möglich. Und das ganze ist auch noch günstiger.

Da ich in jedem Raum (ausser Speisekammer und WC) eine UP Dose als 
Terminal am Eingang habe werde ich aber noch eine "günstige" Lösung mit 
einem Touch Monochromdisplay umsetzen, welches in eine Jung 
Blindabdeckung passt.


Grüße,
Timo

[Timo E. (tien)]

Markus B. p. schrieb:

>> Aber du bist gut drauf, hast erst im Januar angefangen. Das wird schon.

> Hehe das täuscht.
> Die älteste Datei ist vom 26.12.2007.

Ja, ich sehe schon, wir haben beide einen ähnlich langen und intensiven 
Weg hinter uns bzgl. der Automation. Um so schöner ist es, wenn wir es 
schaffen das Projekt gemeinsam voranzubringen.

Grüße Timo

[Markus B. (mbp-bayern)]

Timo E. schrieb:
> Hi Markus,
Hallo Timo;

>
>>> ... z.B. benötige ich
>>> irgendwann für meine Rolladen ein UP Modul, welches jeweils ein Rollo
>>> steuern kann.
>>
>> Also mit 230V auf Eigenbau ?
> .... Damit wäre eventl. auch die Idee umzusetzen die
> jeweils Stromlose Spule als "Drehzahlsensor" zu nutzen - keine Ahnung ob
> das geht, habs noch nicht getestet. Der Vorteil wäre, dass man einen
> blockierten Motor sofort erkennt.

Nun ich vermute dass gute Motoren thermisch gesichert sind.
Bin da aber nicht ganz sicher.
Blockieren halte ich zudem für weniger problematisch als ein Überhitzen,
wenn jemand zu oft Auf/Zu spielt - das könnte die Software verhindern.

> Weiterhin bleibt aber das Problem,
> dass der Motor weiterdreht obwohl der Rollo hängt und beim Abwärtsfahren
> gibts dann Chaos im Rollogehäuse.

Und ob.
Das Chaos ist auch bei Hand-Bertrieb nicht zu unterschätzen;
Schalter an, kurz selbst umgedreht und wenige Motorumdrehungen
später ist das Chaos perfekt - schon gehabt.

> Ohne eine Absicherung tu ich mir
> schwer das autonom laufen zu lassen - ich denk da insb. an die
> Dachfensterrollos im Winter.

Eine Überwachung, ob der Rollo sich nach unten bewegt,
das wäre schon was - nur wie weiß ich auch nicht.
(Ausgenommen mehr oder weniger zverlässige Bastellösungen.)

Leider ist das keine starre Verbindung,
sonst könnte man die Stromaufnahme des Motors messen.

Ein Stromwandler und die Leitung da durchgefädelt,
ohne Kontakt zum Netz wäre ja möglich.

Nur wenn sich die Aufnahnme gravierend ändert,
so ist es wohl beim Rollo schon viel zu Spät.
Nagut villeicht auch nicht ganz, aber der Aufwand für fast Kaputt...

>
> Das ganze halte ich bzgl. elektr. Sicherheit beherrschbar, da zum einen
> alles berührungssicher ist, zum anderen der Strom gut bekannt ist, d.h.
> man kann sehr scharf absichern. Und da ich ja auf der Platine nur die
> Phase habe kann eigentlich auch kein direkter Kurzschluss passieren.

Ja schon;
Auch Lampen könnte man so machen.
z.B. gibt es bei mir Außenbeleuchtungen,
die von einer Dose innen abgehen.

> Aber am liebsten wäre mir natürlich ein UP SSS,
Auch ich will eigentlich in der Dose keine eigen 230V Platien.
Ob man drum rum kommt wird sich noch zeigen.

> den hab ich aber bisher
> nicht mit zwei unabhängigen Relais gefunden - kennst Du was?
Hm noch kenne ich da nichts.

> UP muss sein, da ich die Rolloleitungen nicht in die Verteilung ziehen
> konnte (zu wenig Platz, da Umbau, kein Neubau).
Bei mir kann man da noch ändern;
Das EG ist über Kabelkanäle und Leerrohre aus dem Keller verdrahtet.

Das OG ist duchch große Renovierung schon so ausgerüstet,
dass eine Zentralsteuerung realisierbar wäre.
Licht + Rollo + Außen (Scheinwerfer unterm Dach geplant.)

>
> Hast Du Dir die RS485 Eltakos angeschaut? Johannes Fritsche hat da ja
> etwas Arbeit reingesteckt und es soweit zum lLaufen gebracht, dass er
> Dimmer und Relais direkt ansteuern kann (also den Zustand direkt
> vorgeben kann).

Ja habe ich angeschaut.
Aber auch die Kosten... Ca. Faktor 3 pro SSR.

> Damit wäre für mich ein Zurücklesen nur für wirlich
> sicherheitsrelevante Dinge notwendig. Der Vorteil ist, dass man das
> System so aufbauen kann, dass die Basisfunktionen (Licht an/aus) auch
> ohne Selbstbau Hausautomation funktioniert (Eltako Tastenmodul ->RS485->
> Eltako SSS). Sobald Spannung auf die Hausautomation gegeben wird
> schalten zwei Relais die RS485 auf einen µC um. Dieser fängt zum einen
> über das eine Ende der RS485 die Tastendrücke ab und steuert zum anderen
> über das andere RS485 Ende die Dimmer und SSS. Das ist meiner Meinung
> nach die derzeit beste Lösung beide Welten (Selbstbau & kommerzielle
> Aktoren) zu verbinden.

Das interressannteste dürften in der Tat die Dimmer sein.
Aber ich plane ein System das nicht umgeschalten werden kann.
Wichtige Dinge kann ich mit Taster + SSR ausführen.

Die Elektronik kann dann an der Spule und/oder
am 2. Kontaktsatz "spionieren".

Wenn die Elektronik entscheidet, dass der Zustand zu ändern ist,
so muss sie selbst einen "virtuellen Taster"
parallel zur Verfügung stellen - z.B. ein Relais.

Wenn die Elektronik spinnt: Relais ziehen und gut.

>
>> Auch Rollos denn ein SSR kann die Richtung AUF/AB und ein 2. kann
>> START/STOP.
>
> Ja, wäre perfekt, aber wie gesagt ich brauch UP.
> Und auch die Steuerung von Steckdosen muss ich UP machen. Aber da gibt
> es ja UP SSS und UP Dimmer.

Steckdosen schalten wäre ein nettes Feature,
nur wird das bei mir eher nicht kommen.
Aber man soll ja niemals "NIE" sagen.

>> Der Schaltplan bleibt wohl so ziemlich so, wie er ist.
>
> Kannst Du bitte trotzdem die drei Pins für einen "7805er" (bzw. Recom)
> drauf machen? ... SUPER :-)

Nuja wenn ich hier schreiben würd "Nein",
so wär das ja kontraproduktiv.
Das soll ja nicht nur meine Platine werden;

Also JA.

Aber mach Dich gefasst dass ich das so anordne,
dass ich das abflexen kann wenn der Platz mal ned reicht ;-)

>
>>> P.S. Ich hab mir mittlerweile folgendes zugelegt:
>>> http://www.mikroe.com/eng/products/view/595/mikrommb-for-pic32-board/
>>> Das wird das Terminal für das Wohnzimmer.
>>> Kostet ca. 72 Euro + Versand.
>
>> Auch gut ja.
>> Schönes Teil - für Wohnzimmer muss man sich aber noch ein schickes
>> Gehäuse machen.
>
> Da hab ich schon eine Idee: Aus dichtem schwarzem Kautschuk einen Rahmen
> ausschneiden....

Wenn Du das fertig hast, dann bitte gut Dokumentieren;
Scheint als universal-Montage-Idee tauglich zu sein.

>> Nun ich habs ja bekanntlich auf das hier abgesehen:
>> 4,3" TFT mit serieller Schnittstelle
>> http://www.lcd-module.de/produkte/ediptft.html
>
> Das Tolle an dem MikroE MMB ist eben der PIC32, der auch bereits CAN
> dabei hat (ohne Transceiver, aber eine Platine mit Regler usw. wird eh
> benötigt). Außerdem ist ein Stereocodec drauf, damit sind Sprachausgaben
> auch möglich. Und das ganze ist auch noch günstiger.

Nun Sprachausgabe ist auf alle Fälle interressant.
Hab das Datenblatt überflogen.
Die Details kann ich mir ja noch in Ruhe durchlesen.

Nur das EA ist eben auch etwas größer oder hab ich mich da verlesen ?

>
> Da ich in jedem Raum (ausser Speisekammer und WC) eine UP Dose als
> Terminal am Eingang habe werde ich aber noch eine "günstige" Lösung mit
> einem Touch Monochromdisplay umsetzen, welches in eine Jung
> Blindabdeckung passt.

Nö das habe ich nich und das will ich nicht.
Display hier und da, aber nicht überall.

Für mich soll sich die meiste Technik verstecken.
Eine Fernbedienung mit Touch-Display wäre allerdings ne Sache.

>
>
> Grüße,
> Timo

MFG:MBP
Markus.

[Markus B. (mbp-bayern)]

Timo E. schrieb:
> Markus B. p. schrieb:
>
>>> Aber du bist gut drauf, hast erst im Januar angefangen. Das wird schon.
>
>> Hehe das täuscht.
>> Die älteste Datei ist vom 26.12.2007.
>
> Ja, ich sehe schon, wir haben beide einen ähnlich langen und intensiven
> Weg hinter uns bzgl. der Automation. Um so schöner ist es, wenn wir es
> schaffen das Projekt gemeinsam voranzubringen.
>
> Grüße Timo

Scheint so - Ja.

MFG:MBP
Markus.

[Tien (Gast)]

Markus B. p. schrieb:
> Und ob.
> Das Chaos ist auch bei Hand-Bertrieb nicht zu unterschätzen;
> Schalter an, kurz selbst umgedreht und wenige Motorumdrehungen
> später ist das Chaos perfekt - schon gehabt.

Ja, als ich das Haus (in einem für 13 Jahre jämerlichen Zustand) 
übernommen habe musste ich den Rollo der Gartentür entwirren... Die Kids 
der Vorgänger haben den Rollo runtergelassen, obwohl die 
Fliegengittertür offen war :-(
Nun, das erste war diese Tür zu entfernen, dann den kompletten Rollo 
freilegen und die Lammelen richten und wieder zu verbinden.
Deshalb darf das autonom nur laufen, wenn ich messen kann ob sich der 
Rollo auch in der Schiene wie erwartet bewegt...

>> Ohne eine Absicherung tu ich mir
>> schwer das autonom laufen zu lassen - ich denk da insb. an die
>> Dachfensterrollos im Winter.
>
> Eine Überwachung, ob der Rollo sich nach unten bewegt,
> das wäre schon was - nur wie weiß ich auch nicht.
> (Ausgenommen mehr oder weniger zverlässige Bastellösungen.)

Ja, Basteln muss da wohl schon sein. Es reicht, wenn man beim Eintritt 
des Rollos in die Schiene misst. Dies geht entweder optisch sehr einfach 
mit hell/dunkel Markierungen. Aber das ist keine Dauerhafte Lösung 
(Schmutz). Oder Magnetisch, das wäre dauerhaft, ist aber aufwendig, da 
man irgenwie Magnete an den Lamelen befestigen muss.
Eventl. könnte man einen Mikroschalter so anbringen, dass er die Lücken 
zwischen den Lamelen erkennt, aber das ist auch wieder anfällig.
Ultraschall? Zu aufwändig...
Man könnte auch die Lichtänderung im Raum messen? Zu viel 
Umgebungsparameter...
Körperschall? Zu aufwändig...
Schleifer und Kupferfolie in best. Abständen?
...
Naja, wenn ich mich mal um das Problem kümmere bin ich froh, dann hab 
ich nicht mehr viel Probleme mit dem Umbau ;-)

Markus B. p. schrieb:
>> Kannst Du bitte trotzdem die drei Pins für einen "7805er" (bzw. Recom)
>> drauf machen? ... SUPER :-)
>
> Nuja wenn ich hier schreiben würd "Nein",
> so wär das ja kontraproduktiv.
> Das soll ja nicht nur meine Platine werden;
>
> Also JA.
>
> Aber mach Dich gefasst dass ich das so anordne,
> dass ich das abflexen kann wenn der Platz mal ned reicht ;-)

Klar. wenns net geht gehts hal net, au net schlim...

Bis dann,
ich geh jetzt schlafen!
Timo

[Juergen H. (harms)]

Zum Thema "praktisches Pflichtenheft (apropos Steckdose schalten): ich 
dachte auch, dass geschaltete Steckdosen ein unnötiges Extra sind. Aber: 
eine meiner wichtigsten Anwendungen ist "Son et lumière" zum Abschrecken 
von Einbrechern (Licht geht in einem Raum aus, im Nebenraum an, etc.). 
Da hat sich herausgestellt, dass die Wahl der zu bespielenden 
Lichtquellen stark eingeschränkt ist durch Einblick von Fenstern: es hat 
keinen Sinn Lichter spielen zu lassen, wo man von außen sieht dass 
niemand im Raum ist. Letztenendes stelle ich jetzt, wenn ich länger weg 
bin, an ein paar strategischen Punkten zusätzliche ad-hoc Leuchten auf 
(ergo Steckdosen - bei mir geschaltet durch ein Relaiskasterl mit 
fliegendem Kabel zum Can Bus. Wenn ich beim Planen daran gedacht hätte 
...

Touch-Display: möchte ich nicht mehr missen, auch zum Bedienen von 
Schaltfunktionen, vor allem aber zum betrieblichen Anpassen von 
programmierten Schaltfunktionen - mein Bus ist unabhängig von einer 
Nabelschnur zum Komputer. Zurzeit verwende ich 240x128 eDIP240 Displays 
(trotz hohem Preis gewählt, weil schnell und ohne Aufwand zu 
programmieren). Ich habe mich beinahe durchgerungen, sie durch die 
eDIP320 zu ersetzen: die 240x128 sind beklemmend klein beim Gestalten, 
ich erwarte mir von den 25% (linear) mehr Punkten wesentlich mehr 
Flexibilität bei der Gestaltung des GUI - die letzte Entscheidung 
erfordert wohl das Spielen mit einem Prototyp Display.

[Helmut (Gast)]

Das Pflichtenheft wird aber lang, die Ausführung eher unbefriedigend, 
jedenfalls wenn man baut (Zeit, Geld, Geduld).

Aber was man immer so als Preisvergleich bei KNX/EIB gegenüber einer 
"normalen" Installation angibt, ist auch hier gültig.

Der Komfort bei diesen vermeintlichen teueren Installation, das 
Verbinden der Bewegungsmeldern zu Alarmgebern.

Das mögliche Anwählen von Sollwertvorgaben für Temperaturen mit solchen 
TFT's oder auch Tastern.

Die Szenenauswahl, die Scharfschaltung der Fenstergriffe, der 
Bewegungsmeldern zu Alarmanlage.

Das vernetzte Rauchmelder dazu führen, dass die Rolläden hochfahren und 
die Fenster zu Notausstiegen machen.

Der Emailversand bei Störungen und und.....

Das ist der Vorteil.

Und deswegen wird man auch nicht fertig......  ;-)

[Markus B. (mbp-bayern)]

Timo E. schrieb:
> Aber am liebsten wäre mir natürlich ein UP SSS, den hab ich aber bisher
> nicht mit zwei unabhängigen Relais gefunden - kennst Du was?

Hallo Timo,

Was ich bisher gefunden habe, das sind SSS mit 2 Kontakten.
Diese sind je nach Typ als 2 Schließer oder als 1 Ö + 1 S,
Reihenschaltung, Gruppenschalung und Jalousie-Steuerung verfügbar.
Also so wie auch die Hut-Schienen-Teile.

z.B. Finder 26.02.8.024.0000
Günstig zu haben - will aber offiziell 24V AC - DC gibts den nicht.
Aber vermutlich tut der auch mit DC.

Von Eltako gibts einen universell einstellbaren,
auf Basis von Elektronik mit bistabilen Relais.
ESR61M -- 8-230V UC (=AC/DC)
Verdammt teuer das ding. Empfohlen: 50,80 €/St. + MwSt.

Wenn der Platz für 2 bei Deinen Rollos wär,
so würde es also mit Zustandsüberwachung über den 2. Kontakt gehen.


MFG:MBP
Markus.

[Interessierter (Gast)]

Hallo,
habe mir jetzt innerhalb von 4 Tagen den Thread durchgelesen. Erstmal 
Hochachtung an alle, die hier Ihre Ideen einstellen.
Jetzt bin ich mir nicht mehr sicher, ob hier erwähnt wurde mit welcher 
Baudrate gearbeitet werden soll, bzw. wird.
Außerdem ist mir jetzt nicht ganz klar, in welcher Sprache ihr 
programmiert, Basic oder C?

Das mit der Programmierbarkeit über CAN ist eine sehr gute Idee, bitte 
weiter nachvollziehbar behandeln. Ich denke es lesen hier viele mit, die 
das interessiert.

Wie ich das verstanden habe, ist für jeden Node eine andere Software 
notwendig, oder?

Könnte man sich nicht vorstellen, einen, sagen wir Node-Selector über 
Binärswitches parametrierbar zu machen, der dann in der 
Standard-Software ausgewertet wird und entsprechende Codeteile ausführt 
oder nicht.
Hätte den Vorteil, dass man überall die gleiche SW hätte.

Danke und Gruß
etstudent

[Markus B. (mbp-bayern)]

Hallo Interessierter.

Interessierter schrieb:
> Hallo,
> habe mir jetzt innerhalb von 4 Tagen den Thread durchgelesen. Erstmal
> Hochachtung an alle, die hier Ihre Ideen einstellen.
Danke;
Nun ja der Thread ist mittlerweile lang geworden.

> Jetzt bin ich mir nicht mehr sicher, ob hier erwähnt wurde mit welcher
> Baudrate gearbeitet werden soll, bzw. wird.

Das haben wir noch nicht festgelegt;
Da es aber auf High-Speed CAN basiert,
so ist das theoretische Maximum bei 1 MBit.

Wie Timo aber im Beitrag #2253531 schreibt,
so muss sich das tatsächliche Maximum in der Praxis zeigen:
>> Die EIB Leitung liegt parallel zum Netzkabel. Ich geh mal davon aus, das
>> ich 125kb/s hin bekomme. Wenn nicht, ist das auch nicht schlimm, da auch
>> 9,6kb/s für eine Steuerung reichen würde. Zum Reprogrammieren, ist das
>> allerdings wirklich zu langsam.

> Außerdem ist mir jetzt nicht ganz klar, in welcher Sprache ihr
> programmiert, Basic oder C?

Eigentlich ist nur C geplant,
aber wer Unterstützung für eigene Firmware benötigt,
der wird nicht im Regen stehen gelassen.
Auch nicht wenn er/sie bisher in Basic programmiert.

>
> Das mit der Programmierbarkeit über CAN ist eine sehr gute Idee, bitte
> weiter nachvollziehbar behandeln. Ich denke es lesen hier viele mit, die
> das interessiert.

Das wird Timo sicherlich.

Wir haben uns geeinigt, dass dieses Projekt komplett veröffentlicht 
wird.
Mein Teil ist hauptsächlich die Hardware und die ist noch nicht fertig.

Die Sammelstelle wird aber dennoch die von Timo eröffnete Projektseite:
http://code.google.com/p/tech-home-automation/wiki/CanCommunicationProtocol

>
> Wie ich das verstanden habe, ist für jeden Node eine andere Software
> notwendig, oder?

Ja, bis auf den Bootloader.

>
> Könnte man sich nicht vorstellen, einen, sagen wir Node-Selector über
> Binärswitches parametrierbar zu machen, der dann in der
> Standard-Software ausgewertet wird und entsprechende Codeteile ausführt
> oder nicht.
> Hätte den Vorteil, dass man überall die gleiche SW hätte.

Da wir mit dem Temperatursensor DS18B20
und/oder über Konfigurationsbits im Prozessor
eine einmalige Hardware ID schaffen,
so ist jeder Knoten am Bus eindeutig identifizierbar,
egal welche Software dann darauf läuft.

Theoretisch könnte man also so etwas realisieren.
Ob Timo eine solche Funktionalität eingeplant hat ist mir nicht bekannt.

Allerdings habe ich nicht vor,
dass es irgendwelche Dip-Schalter etc. gibt,
denn auch jeder der keine Ahnung hat kann die verstellen.
Lötbrücken könnte ich mir aber vorstellen.

Nachteil:
Der Software Umfang könnte für einen einzigen Controller zu groß werden.
Ebenso halte ich es für schwer zu überblicken.

>
> Danke und Gruß
> etstudent

MFG:MBP
Markus.

[Tien (Gast)]

Hallo Interessierter

> Jetzt bin ich mir nicht mehr sicher, ob hier erwähnt wurde mit welcher
> Baudrate gearbeitet werden soll, bzw. wird.

Wie Markus geschrieben hat, theoretisch sind bis zu 1 MBit möglich. Ich 
denke das wird an der Buslänge scheitern, je nach verkabelung. Ich 
persönlich plane 125 KBit. Für die eigentliche Funktion ist es ja nicht 
notwendig mit hohen Datenraten zu arbeiten. Aber beim Reprogrammieren 
macht das natürlich schon was aus. Und am Anfang kommt das bestimmt des 
öfteren vor. So will ich mit ein paar Nodes mal tests machen was meine 
Verkabelung hergibt und ab wann die Fehler deutlich zunehmen.

> Außerdem ist mir jetzt nicht ganz klar, in welcher Sprache ihr
> programmiert, Basic oder C?

Wir programmieren in C und nutzen das MPLAB von Mikrochip. Ich hätte ja 
gerne den C Compiler von mikroe genutzt, für den hab ich eine gekaufte 
Lizenz, aber das FreeRTOS lief damit nicht (ok, hätte man bestimmt 
irgendwie hinbekommen...) mit dem C Compiler von Mikrochip und MPLAB 
steht aber eine kostenlose Entwicklungsumgebung zur Verfügung, die recht 
brauchbar ist. Die einzige Einschränkung ist, das in der freien Version 
einige Optimierungen abgeschaltet sind. Da wir aber zum einen die großen 
Derivate mit 96 kByte ROM nutzen wollen und zum anderen nicht wirklich 
extrem zeitkritische Anwendungen haben ist das eher nebensächlich.
Ich selbst habe früher einiges mit Basic gemacht, sowohl auf dem PC, als 
auch auf µCs. Da ich aber beruflich in C programmiere und auf dem PC 
mittlerweile mit C# eine sehr gute C ähnliche Sprache existiert nutze 
ich Basic nicht mehr. Wenn aber Umstiegsprobleme aufkommen haben wir 
bestimmt ein paar Tips.

> Das mit der Programmierbarkeit über CAN ist eine sehr gute Idee, bitte
> weiter nachvollziehbar behandeln. Ich denke es lesen hier viele mit, die
> das interessiert.

Das ist eines der wichtigesten Features. Ohne CAN Bootloader werde ich 
keine Platine in die Wand einbauen. Der Bootloader an sich existiert 
auch schon (dank Chris), was fehlt ist die PC seitige Anbindung - ich 
bin eigentlich gerade dabei, wenn da nicht soviele andere Dinge (Beruf, 
Garten, Familie, usw) meine Zeit verschlingen würden.
Gerade arbeite ich privat mit einem Kollegen zu sammen an einer 
sprechenden Uhr auf einem PIC32, soll ein Abschiedgeschenk für einen 
Kollegen werden. Wenn das geht hätten wir dann auch schon eine 
Sprachausgabe für das System ;-)
Wenn das fertig ist werde ich mal weiter mit dem Reprog Tool machen.

> Wie ich das verstanden habe, ist für jeden Node eine andere Software
> notwendig, oder?

Nicht unbedingt, wir haben ja recht viel Speicher. Ein großer Teil wird 
zwar durch das RTOS, den Protokollstack und den Bootloader verbraucht, 
aber es bleibt noch genügend.

> Könnte man sich nicht vorstellen, einen, sagen wir Node-Selector über
> Binärswitches parametrierbar zu machen, der dann in der
> Standard-Software ausgewertet wird und entsprechende Codeteile ausführt
> oder nicht.
> Hätte den Vorteil, dass man überall die gleiche SW hätte.

Ich kann mir durchaus vorstellen, dass es nur eine Implementierung gibt.
Die Konfiguration soll im EEPROM gespeichert werden. Jeder Node erhält 
eine eindeutige Nummer, welche im Netz nur einmal vorkommt (entweder die 
des DS1820 oder eine im EEPROM gespeicherte, mal sehen). Mit dieser 
Nummer lässt sich ein neu ans Netz angeschlossene Node parametrisieren, 
d.h. u.a. die CAN Id einstellen und natürlich auch die Reaktionen was 
gesendet wird, wenn ein Event auftritt.
Es ist in jedem Fall geplant mehr als einen Node gleichzeit zu 
programmieren.

Für die ersten Versuche vermute ich allerdings, dass wir speziallisierte 
Software haben werden. Vorteil: man kann dann recht schnell Erfahrung 
sammeln, Nachteil: nichts hält länger als ein Provisorium ;-)

Die bereits von Markus verlinkte Protokoll Beschreibung:
http://code.google.com/p/tech-home-automation/wiki/CanCommunicationProtocol
ist bereits im Protokollstack implementiert. Allerdings gibt es derzeit 
noch kein fertiges Gesamtprojekt.

Liebe Grüße Timo

[Markus B. (mbp-bayern)]

Hallo Zusammen,

heute habe ich 1-2 Recom Spannungsregler entdeckt,
welche die Wünsche von Timo und mir wohl vereinen lassen:

R-78C5.0-1.0
- 8 bis 42V,
- 1 mA für 0 mA,
- 85-93% Wirkung.

Für mehr als 24V Bus:
R-78HB5.0-0.5
- 9 bis 72V,
- 10 mA für 0 mA,
ca. 85% Wirkung.

Ersatztypen anderer Hersteller müssten noch gesucht werden.


Bevor jetzt jemand frägt,
weshalb ich nicht für den von Timo vorgeschlagenen,
ähnlichen R-785.0-0.5 zu begeistern bin:
Diese Bauteil kann nur bis 32V (34V)

Eine 24V Transientenschutz-Diode aus den Serien SMAJ oder SMCJ
begrenzt die Spitzenspannung leider auf MAX. knapp 40V. (38,9V)

Also muss der Regler fast 40V schadlos überstehen.
Mit dem MAX5035 wäre dies ebenso gegeben,
als nun mit den beiden Recom.

Man findet aber höchstens ABS MAX 34V o.ä. in den diversen 
Datenblättern.
Somit könnte also ein Ausfall vorprogrammiert sein.

Und als Wege zur Antwort auf die Frage
"Wo sollen bei 24V Versorgung 40V herkommen ?"
sollen Folgende Begriffe dienen:

Leitung + Kondensatoren...
   --> LC-Schwingkreis

Sprungantwort oder Ringing...
   --> Hier nach hartem Einschalten der 24V Versorgung.
   --> http://en.wikipedia.org/wiki/Ringing_(signal)
   --> http://de.wikipedia.org/wiki/%C3%9Cberschwingen

MFG:MBP

[Timo E. (tien)]

Hi Markus,

ok, Vorteil, wenn Du im Layout den RECOM vorsiehst wäre ja, dass jeder 
sich seinen gewünschten Regler reinsetzen kann. Bei Bedarf auch eine 
kleine Platine mit Schaltregler, ganz nach Belieben.

Damit wird die Platine in jedem Fall relativ universal - also
- wenn 5V zur Verfügung stehen direkt (z.B. in Geräten) (Vorteil: wenig 
Platzverlust),
- wenn 24V Bus, dann den R-78C5.0-1.0,
- wenn knapp über 5 Volt könnte man auch einen normalen 78C05 nehmen
- usw...

Ich würde die Platine vermtl. auch bei mir im T5 einsetzen, da ich die 
Innenbeleuchtung gerne dimmen will, da wäre dann der R-78HB5.0-0.5 
ideal.

Hast Du mal gerechnet wieviel Euro eine komplette Stromversorgung mit 
einem MAX5035 und Drossel usw. kosten würde?


Grüße Timo

[Markus B. (mbp-bayern)]

Timo E. schrieb:
> Hast Du mal gerechnet wieviel Euro eine komplette Stromversorgung mit
> einem MAX5035 und Drossel usw. kosten würde?

Hallo Timo,

der MAX kostet ca. 3€ - MwSt eingerechnet.
Ab 25St, 5V Typ, So8, 0-85°C,
100 Lagernd für den Preis, sonst 7 Wo. LFZ.
(-40°_+125° kostet ab ca. gut 6€)

Eine Speicherdrossel würde ich mal um 1 € ansetzen.

Kondensatoren - Keramik und/oder Elkos, kein Tantal
1,5€ schätze ich ohne nachzusehen.

Diode 0,5€

Summe: 3€ + 1€ + 1,5€ + 0,5€ = 6€

Also ab 6€ bei mind. 25 Platinen.
Bei 100 Platinen könnte es in Richtung 3-4€ gehen,
und bei 10 Platinen auch auch hoch auf 10€.

MFG:MBP
Markus.

[Christoph K. (christoph_k73)]

Hallo zusammen,

zuerst mal an alle die hier mitgewirkt haben und weiter mitwirken großen 
respekt echt tolle Leistung. Ich habe nicht mehr aufhören können zu 
lesen (sieht man an der Uhrzeit).

Ich würde mich gern in euer Projekt mit einklinken soweit möglich, ich 
werde die nächsten Jahre auch Hausbauen und würde da genau diese 
Steuerung verbauen (höhrt sich sehr vielversprechend an).

Ich bin zwar ein totaler Anfänger auf dem Gebiert der Programierung, 
aber meine ersten Erfahrungen in der PIC programierung habe ich schon 
gemacht.

Habt Ihr inzwischen schon weitere Erfolge verzeichnen können? Da der 
letzte eintrag schon 1,5 Monate zurück liegt.

Über Neuigkeiten und mehr Details würde ich mich sehr freuen.

MfG Christoph

[Markus B. (mbp-bayern)]

Hallo Christoph,

bei der Hardware gibt es leider nur wenige Fortschritte;

Die Bedingungen für Funktion und Haltbarkeit
dürften für den Stromlauf geklärt sein,
aber wenn Du gute Ideen hast bitte lasse es uns wissen,
es ist noch nicht zu spät!

*********

@All:
Aktueller Stand:

Obwohl sicher noch Stiftleisten, Schraubklemmen, Spannungsregler
in der aktuellen Stromlauf-Version* fehlen,
so habe ich versucht den Kern des ganzen Layoutmäßig vorzubereiten.
*( Beitrag "Re: Anforderungssammlung CAN Hausbus mit PIC µC" )

Nach dem die Pads von V13 unpassend (zu klein) erscheinen,
so hätte nun die aktuellste Version der Bibliothek zu grunde liegen 
sollen.
Allerdings sind deren größere Pads dem Anschein nach jetzt zu groß.

Es soll so klein wie möglich werden,
denn Platz hat man wohl nie genug.

Zu große, zu kleine oder falsche Pads ist alles nicht gut,
denn die Fertigung wird dadruch obendrein beeinträchtigt.
(Chip-R und C z.B. Reflow löten --> vermehrt Grabsteinbildnug möglich.)

Da ich mittlerweile also die Pads für jedes Bauteil in Frage stelle,
so habe ich festgestellt, dass fast jeder namhafte Hersteller
seine eigenen Vorschläge für die Pads für das gleichnamige Gehäuse hat,
egal, ob R, C oder Halbleiter.

So gering, wie noch in
Beitrag "Re: Landepads  Pads  Footprint / Land Pattern für SMD"
diskutiert, sind die Abweichungen wohl doch nicht.

Bei sot23 komme ich z.B. auf
2,7 bis 3,6 mm von Pad-Ende für Pin 1 zu 3.
|<- ?? mm ->|
[ 1 ]
  sot23 [ 3 ]
[ 2 ]

5 Hersteller,
6 Datenblätter (5x aktuell + 1x alt)
= 6 Abmessungen...

Deshalb bin ich derzeit nach wie vor daran,
meine Forschungen bezüglich des Layouts voranzutreiben,
um zu verstehen was das soll.

Das wird für mich sicher noch nützlich,
auch wenn es dieses Projekt leider mehr als ausbremst.

Mittlerweile bin ich bei der IPC 7351 gelandet;
"Generic Requirements for Surface Mount Design and Land Pattern 
Standard"
Leider habe ich nur die 2005er .EN und nicht die .DE Version aus 2010.

************************************************************************ 
*

Eine ältere Version meines Can-µC etc.
Beitrag "Re: Konzept zu einem Hausbus auf CAN-Bus Basis und die Enstehung des Konzeptes"
ist zwar als Layout fertig,
vermutlich passt aber allein schon der Prozessor nicht gut.
(Pads zu klein da alte Bibliothek "blind" angewendet.)

Diese Leiterplatte könnte ich für Versuchszwecke fertigen lassen
und aufbestücken, villeicht muss man irgendwelche Pins passend biegen.
Und sie erfüllt u.a. die Bedingung "24V BUS" NICHT ganz,
aber zum Basteln / Testen dürfte es einigermaßen genügen.

Info: Meine Webseite mit den alten Dokus geht nicht mehr:
DynDns will Kohle für Subdomains über Wildcards.

Wenns jemand eilig hat bitte eMail oder PN.

[Christoph K. (christoph_k73)]

Hallo Markus,
hallo an alle,

Tut mir leid wegen der späten Antwort, stress bei der Arbeit.

Also ist der Schaltplan den du im Juni gepostet hast der aktuelle Stand?
Da ich noch nicht so die Erfahrungen mit der ganzen Thematik habe ist 
das evtl. eine blöde Frage: ist es denn möglich einen Display an jeden 
Knoten anzuschließen, da ich plane für jeden Knoten eh eine eigene Dose 
zu setzen und um dieser nicht nur einen Deckel zu verpassen, würde ich 
gern einen Display einsetzten und einen Drehschalter zu Steuerung.

Da der Knoten ja 8 IOs hat, heißt das dann, dass ich 4 Schalter (Taster) 
anschließen kann, die anderen 4 sind doch dann zur Steuerung der LEDs in 
den Schaltern.

Gibt es schon einen Entwurf zur Steuerung der Relais (SSR, was auch 
immer)? Oder wie habt ihr das geplant, denn ich würde gerne alle Relais 
irgendwo im Keller an einer Stelle haben.

Ich bin z.Z. auf Dienstreise und deshalb hab ich jeden Tag nach der 
Arbeit Zeit (nichts mit Haushalt, Garten und so), kurz gesagt würde ich 
mich gerne irgendwie beteiligen. Leider bin ich wie gesagt noch nicht so 
im Thema drin, aber hoffe trotzdem das ich was helfen kann.

Weiß jmd. eventuell ein gutes Buch für mich um bei der Adressierung und 
Steuerung von CAN einmal durchzublicken?

MfG Christoph

[Helmut (Gast)]

http://www.ebookaktiv.de/eBook_CAN/eBook_CAN.htm

Kann ich empfehlen, ist gut gemacht: was ist attribierung, Tq's usw

[Markus B. (mbp-bayern)]

Christoph Kastl schrieb:
> Hallo Markus,
> hallo an alle,
>
> Tut mir leid wegen der späten Antwort, stress bei der Arbeit.
>
> Also ist der Schaltplan den du im Juni gepostet hast der aktuelle Stand?

Hallo Christoph,

Du hast Trotz der Späten Antwort nichts verpasst oder so.

Der Stand vom 24.06. ist vom Stromlauf unverändert;
Im Layout hat sich zwar der eine oder andere Strich getan,
aber viel zu wenig zum veröffentlichen.

Diesr Stromlauf benötigt immer noch Spannungsregelung,
BUS-Anschluss und Anschlüsse für die Erweiterungen.

Erweiterung soll über Stift-/Buchsen-leisten ausgeführt werden.

Allerdings ist die Anordnung der Mechanik noch nicht festgelegt;
Vielmehr werde ich das Layout und den Stromlauf parallel weiter machen.
Die Stiftleisten werden dann im Stromlauf erscheinen,
wenn der sonstige "Kern" gelayoutet ist.
Erst dann kann ich die Sinnvolle Belegung & Anordnung abschätzten.

Du hast richtig erkannt - es sind 8 FREIE, NUR Digitale I/O Anschlüsse.

Die weitern Signale mit Doppelnamen z.B. aus dem RBx_XXX Bereich:
Die sind ebenfalls - aber eingechränkt - verwendbar;
Z.B. können PGC und PGD nur benutzt werden,
wenn kein Debugger angeschlossen wird.

Für IO9+10 gilt:
Diese wären als TTL RS232 oder eben als GPIO nutzbar.

Die analogfähigen Anschlüsse müssten auch nicht alle analog sein.
AN4-AN7 kann man auch 100% rein digital nutzen.
Beispielsweise für Schaltereingänge,
welche man aber andererseits auch analog einlesen könnte.

Diese Platine soll so klein als möglich werden.
Dabei soll sie aber WEIKLICH NUR das bereitstellen,
was JEDER Knoten benötigt.
Dazu gehört weder ein Display noch echte Schalter-Anschlussklemmen.

Im Fazit bedeutet dies, dass jegliche Schalter, Anzeigen etc.
entweder frei fliegend, oder aber viel sinnvoller,
mit einer noch nicht festgelegten Adapterplatine zu verbinden sind.

Mir ist wichtig, dass die CPU für alle meine BUS-Knoten nutzbar wird.
Die Erweiterungsfähigkeit muss alle Richtungen im RM 2,54 werden.
Somit kann auch einmal ein Prototyp oder sonstiges auf Lochraster.



Timo und mir wäre es auch sehr recht,
wenn wir rein Zentrale Schaltstellen wie bei Dir im Keller hätten.
(Wird aber bei uns nicht gehen.)

Für die Zentralstellen möchten wir käufliche Hutschienenteile verwenden.
Hierzu zählen z.B. Relais, Strom-Stoß-Relais und RS485 Aktoren.

Aber auch für deren Ansteuerung muss noch Hutschienen-Hardware
entwickelt werden, welche auf obiger CPU basieren soll.

Was also die Mithilfe von Dir angeht,
so könntest Du z.B. schon Schaltungs-Vorschläge erstellen.
- Für (D)ein kleines Aufputz-Display-Modul
- Oder für einen Relais-Treiber auf Hutschine

Wenn Du Eagle beherrscht so darf es natürlich auch in Eagle sein;
Allerdings verwende ich die kostenlose Target V15 PCB-POOL-Edtion.



Bücher zum CAN-BUS kann ich keine empfehlen, da ich keine habe.
Mein Wissen habe auch ich aus dem Netz.
http://www.google.de/search?q=can-bus+osi liefert z.B. Fundstellen.



MFG:MBP
Markus

[Juergen H. (harms)]

Schaut interessant aus - aber deswegen auf Windows umbooten? Schade!

[Markus B. (mbp-bayern)]

Juergen Harms schrieb:
> Schaut interessant aus - aber deswegen auf Windows umbooten? Schade!

Hm und wie siehts mit Wine aus...
Da Target für Windows in Wine@Linux funktioniert,
warum nicht ein E-Book ?

Hab jetzt aber meinerseits keinen Bock, auf Linux zu booten zum Test.

MFG:MBP
Markus

[Juergen H. (harms)]

Bisher stand es nie dafür Wine zu installieren (wo ich es wirklich 
bräuchte - z.B. Aktualisieren meines TomToms - gibt es Dokumentation 
dass Wine nicht geht). Nach Deinem Beitrag habe ich es wiedereinmal 
probiert und tatsächlich mit Google einen Beitrag gefunden, demnach 
ebookaktiv über Wine tadellos läuft. Danke!

[Tien (Gast)]

Hi Christoph,

Christoph Kastl schrieb:
> Tut mir leid wegen der späten Antwort, stress bei der Arbeit.

Kein Problem ;-) Bei uns ist derzeit leider nicht viel los. Ich bin noch 
vor dem Winter mit den letzten Arbeiten im Garten tätig - da bleibt 
nicht viel Zeit. Aber ich betone es nochmal, auch wenn es lang dauen 
wird, es geht weiter.

> das evtl. eine blöde Frage: ist es denn möglich einen Display an jeden
> Knoten anzuschließen, da ich plane für jeden Knoten eh eine eigene Dose
> zu setzen und um dieser nicht nur einen Deckel zu verpassen, würde ich
> gern einen Display einsetzten und einen Drehschalter zu Steuerung.

So wie Markus ja bereits geschrieben hat steht zunächst "nur" der 
Buskoppler auf der Agenda. Für diesen Buskoppler kann man dann 
"beliebige" Peripherie entwickeln.

U.a. auch ein Display. Ich plane u.a. ein Terminal pro Raum. Darin soll 
ein Touchdisplay sein mit dem ich das ein oder andere anzeigen und 
steuern kann. Als Display will ich entweder ein günstiges kleines 
Monochromdisplay http://www.lcd-module.de/deu/pdf/grafik/dogm128.pdf 
verwenden. Dies wäre mit etwas Tricksen auch in einer UP Blindabdeckung 
einbaubar.
Oder ein farbiges Display gleich mit Controller drauf: 
http://www.mikroe.com/eng/products/view/595/mikrommb-for-pic32/
Hier müsste man einen Rahmen z.B. aus Edelstahl um das Display 
konstruieren.

Wichtig ist dabei, dass zunächst der Buskoppler inkl. der Basissoftware 
funktioniert. Die Basissoftware soll u.a. die Ankopplung an den CAN Bus 
machen inkl. Protokoll, Bootloader, Betriebssystem, EEPROM Treiber 
bereitstellen. Ziel ist es sich nur noch auf die eigentliche Applikation 
konzentrieren zu müssen. Wenn der Buskoppler mal funktionstüchtig ist 
wäre eine Ankopplung an das Display ein weiterer Schritt.

> Da der Knoten ja 8 IOs hat, heißt das dann, dass ich 4 Schalter (Taster)
> anschließen kann, die anderen 4 sind doch dann zur Steuerung der LEDs in
> den Schaltern.

Auch hier schließe ich mich Markus an. Was man dann mit den IOs steuert 
ist dann abhängig von der Applikation.

> Gibt es schon einen Entwurf zur Steuerung der Relais (SSR, was auch
> immer)? Oder wie habt ihr das geplant, denn ich würde gerne alle Relais
> irgendwo im Keller an einer Stelle haben.

Ich habe in einem UP Unterverteiler die Lichtsteuerung eingebaut. Dies 
ist bisher rein konventionell mit Stromstoßschalter (SSS) und Tastdimmer 
realisiert. Das war mir wichtig, da ich ja den Einzug und die erste 
Inbetriebnahme der Automation von einander unabhängig machen wollte.
Das bietet den Vorteil, dass die Grundfunktionen wie Licht an/aus usw. 
auch ohne etwas selbstgebastelte funktioniert.
Heute würde ich andere SSS und Dimmer verwenden. Es gibt von Eltako 
RS485 Dimmer, SSS und Taster Eingabemodule. Diese hätten den Vorteil, 
dass man relativ einfach eine Verbindung zum eigenen µC schafen kann 
bzw. recht einfach auch den ursprünglichen Zustand (also ohne 
Automation) herstellen kann.

> Ich bin z.Z. auf Dienstreise und deshalb hab ich jeden Tag nach der
> Arbeit Zeit (nichts mit Haushalt, Garten und so), kurz gesagt würde ich
> mich gerne irgendwie beteiligen. Leider bin ich wie gesagt noch nicht so
> im Thema drin, aber hoffe trotzdem das ich was helfen kann.

Was sind Deine Stärken? Was würdest Du gerne machen?

> Weiß jmd. eventuell ein gutes Buch für mich um bei der Adressierung und
> Steuerung von CAN einmal durchzublicken?

CAN ist eigentlich relativ simpel. Für unsere Belange reichen eigentlich 
die Artikel im Internet z.B. 
http://de.wikipedia.org/wiki/Controller_Area_Network
Das von uns geplante Protokoll findest Du hier:
https://code.google.com/p/tech-home-automation/wiki/CanCommunicationProtocol

Soweit mal,
Liebe Grüße Timo

[Juergen H. (harms)]

Das war ein Reinfall: ebookaktiv lässt sich zwar in wine starten und die 
Index Seite wird dann halbwegs angezeigt, aber was man nach dem 
Anklicken eines Themas kriegt ist unlesbarer Zeichensalat (ich verwende 
Mageia, vielleicht läuft es bei einer anderen Distro).

Jürgen

[Helmut (Gast)]

Hallo Juergen,
das würde ich dann unter Windows versuchen. Ich kann jedem nur raten Das 
anzusehen.

@all CAN-Bus bastler.
Ich hatte schon einmal das Projekt von Hugo angepriesen.
Warum wollt ihr nicht darauf aufbauen?

Und Bedienstationen mit dem mikroe TFT habe ich auch schon dazu.

Guckst du:
http://www.youtube.com/watch?v=WAS8-lThOow&feature=autoplay&list=ULqQIJpl2lpf8&lf=mfu_in_order&playnext=9

Gruß Helmut
Projektbeispiel auf helmutholm.de

[Christoph K. (christoph_k73)]

Guten morgen zusammen,

erstmal danke für die Tipps, das eBook ist echt klasse.

Jetzt ist mir einiges mehr klar, also besteht durchaus die Möglichkeit 
einen Display z.B. über die RS232 Schnittstelle anzuschließen.

Was meine Mitarbeit angeht, würde ich liebend gern mit entwickeln aber 
leider hab ich das Wissen dazu noch nicht. Ich weiß dafür eher in der 
Mechanik bescheid, habe soeben meinen Maschinenbautechniker 
abgeschlossen. Das heißt ich bin euer Mann, wenn es um irgendwelche 
mechanischen Teile, Teile wie Rahmen für n Display oder Sensoren geht.

Unter anderem habe ich eine sehr gute Idee was die Rollladen- Sache 
angeht, da die Kunststoffprofile ja meistens innen hohl sind könnte man 
doch in jeden 2. oder 3. ein kleines metallblech anbringen und oben 
einen induktiven Sensor, zum ersten wäre es kontaktfrei also 
wartungsfrei und zum zweiten könnte man diese Signale nicht nur zur 
Notabschaltung (Zeit zum nächsten Signal vorgeben) sonder auch zum 
Zählen (Endpositionen)  hernehmen.

Nochmal Danke für die Erläuterungen.

MfG Christoph Kastl

[Timo E. (tien)]

Hallo Christoph

> Jetzt ist mir einiges mehr klar, also besteht durchaus die Möglichkeit
> einen Display z.B. über die RS232 Schnittstelle anzuschließen.

Genau. Für ein einfaches Display wird man die übliche 4 Draht 
Schnittstelle verwenden. Für das von mir erwähnte Farbdisplay mit PIC32 
Controller würde ich eine reine Daten Kommunikation zw. Buskoppler und 
PIC32 realisieren. Oder direkt den PIC32 an den CAN Bus ankoppeln.

> Was meine Mitarbeit angeht, würde ich liebend gern mit entwickeln aber
> leider hab ich das Wissen dazu noch nicht. Ich weiß dafür eher in der
> Mechanik bescheid, habe soeben meinen Maschinenbautechniker
> abgeschlossen. Das heißt ich bin euer Mann, wenn es um irgendwelche
> mechanischen Teile, Teile wie Rahmen für n Display oder Sensoren geht.

Na das ist ja auch schon etwas wert, auch wenn wir die Mechanik erst in 
einer späteren Phase benötigen.

> Unter anderem habe ich eine sehr gute Idee was die Rollladen- Sache
> angeht, da die Kunststoffprofile ja meistens innen hohl sind könnte man
> doch in jeden 2. oder 3. ein kleines metallblech anbringen und oben
> einen induktiven Sensor, zum ersten wäre es kontaktfrei also
> wartungsfrei und zum zweiten könnte man diese Signale nicht nur zur
> Notabschaltung (Zeit zum nächsten Signal vorgeben) sonder auch zum
> Zählen (Endpositionen)  hernehmen.

Eine ähnliche Lösung hatte ich ach angedacht, allerdings mit Magnete. 
Das hat den Vorteil, das man die Auswertung mit einfachen Reedschaltern 
machen könnte. Ist die Frage was teurer bzw. Aufwändiger ist, Magnete & 
Reedkontakt oder Bleche & Hallsensor. Hättest Du eine Idee wie wir 
Bleche bzw. Magnete in den Lamellen befestigen können. Kleben?

> Nochmal Danke für die Erläuterungen.

Noch ein Hinweis: Ich denke es wird noch einige (viel) Zeit dauern, bis 
wir ein komplettes System haben, welches sich mit wenigen eigenen 
Anpassungen anwenden lässt. Ich will Dir diesbezüglich nicht zu viel 
versprechen - technisch ist viel möglich und das Konzept hat mit 
Sicherheit eine gute Basis. Aber bis Du die erste Funktion in Aktion im 
Haus eingebaut hast wird es noch viel Arbeit sein. Und ich denke es wird 
immer auch eigene Entwicklungsarbeit von Nöten sein, um das System an 
die Bedürfnisse anzupassen. Diesbezüglich sind andere Projekte, welche 
man im Internet findet bestimmt schon weiter.

Mein Ziel ist es eine stabile Basis zu schaffen - eben aus einer 
Basisplatine (derzeit durch Markus entwickelt) und aus einer 
Basissoftware (derzeit von Chris und teilw. durch mich entwickelt).
Auf diese Basis könnte dann jeder seine eigene Applikation darauf 
aufsetzen.

Natürlich dürfen gerne auch Applikation (z.B. 
Temperatur/Feuchtesensoren, Tastsensoren, Schaltaktoren usw.) auch auf 
der Projektseite veröffentlicht werden. Aber das erste Ziel ist es erst 
mal die Basisplatine inkl. Basis SW.

Wenn Du also einen festen Termin hast zu dem die Automation 
funktionieren muss rate ich Dir entweder etwas kommerzielle zu nehmen, 
oder ein beretis verfügbare Projekt zu suchen. Wenn Du Zeit und Spass am 
Entwickeln hast so bist Du herzlich eingeladen mit zu machen. Ich hoffe 
dass wir bis im Frühjahr 2012 (@Markus, ich hoffe das ist nicht 
utopisch) die erste Version der Basisplatine inkl. SW haben. Dann wird 
vermutlich auch mehr Dynamik rein kommen, da man dann ja etwas zum 
Spielen hat.

Liebe Grüße Timo

[Christoph K. (christoph_k73)]

Hallo Timo,

mit Mageneten würde ich das nicht machen, weil da andere metalische 
Teilchen hängen bleiben können, außerdem kosten so hallsensoren auch 
nicht viel glaub ich, muss man dann abwiegen wenn es wirklich so weit 
ist das man die braucht, die gibts ja sehr oft irgendwo im Angebot.

Das mit der Zeit ist bei mir auch nicht so kritisch, da ich auch noch 
garnicht mit der Hausplanung angefangen habe, meiner Meinung nach werde 
ich das in Richtung Ende nächsten Jahres mal beginnen.

Mal ne andere frage aus welcher Richtung Deutschlands kommt Ihr so? Ich 
bin aus Bayern!!!

Mich würde auch mal interesieren wie viele Leute hier mittlesen, da das 
ganze ein sehr interesantes Thema ist und Ihr wirklich gute Arbeit mach 
schätze ich auf sehr viele die das eventuel auch selber umsetzten 
wollen. Meldet euch doch mal und zollt Chris, Timo, Markus und allen 
anderen die hier aktiv mitwirken euren Respekt, die machen das hier echt 
gut oder?


MfG Christoph

[Tien (Gast)]

Christoph Kastl schrieb:
> Mal ne andere frage aus welcher Richtung Deutschlands kommt Ihr so? Ich
> bin aus Bayern!!!

Ich wohne im Raum Heilbronn, (nördlich von Stuttgart) genauer in Abstatt 
und arbeite hier bei einem Automobil Zulieferer.

> Mich würde auch mal interesieren wie viele Leute hier mittlesen, da das
> ganze ein sehr interesantes Thema ist und Ihr wirklich gute Arbeit mach
> schätze ich auf sehr viele die das eventuel auch selber umsetzten
> wollen. Meldet euch doch mal und zollt Chris, Timo, Markus und allen
> anderen die hier aktiv mitwirken euren Respekt, die machen das hier echt
> gut oder?

Naja, wollen wir mal nicht übertreiben - es gibt viele, die schon sehr 
viel weiter sind. Und wenn man sich das Datum anscheut, dann geht es 
wirklich nur schleppend voran. Aber wir haben halt alle noch vieles 
andere um die Ohren :-)
Aber eine Resonanz hier, wie von Dir ist für mich auch Ansporn weiter zu 
machen - statt abends vor der Klotze zu sitzen :-) So bin ich heute 
abend auch etwas aktiv.

Was noch toll wäre, wenn wir unsere Ideen im Wiki auf 
http://code.google.com/p/tech-home-automation/wiki/News?tm=6
sammeln würden. Zum Beispiel auch die Idee mit dem Rolladen. Eventl. 
könnte man ja im Artikel jeweils reicschreiben, ob es sich um eine Idee 
oder bereits umgesetztes handelt.

- implemented / implementiert
- planed / geplant
- proposed / vorgeschlagen

Hast Du dazu eventl. auch Lust? In das Wiki dürfen derzeit nur "Members" 
schreiben - aber eine kurze Mail reicht und ich trage Dich und andere 
gerne ein. Ich will damit nur verhindern, dass jemand irgendwelchen Mist 
schreibt. Herunterladen kann dafür jeder, das soll auch so bleiben.

Wenn also jemand Lust hat an der Doku mitzu schreiben gern auch in 
deutsch, einfach melden.

Wir könnten dann hier oder auch in einem extra Thread, oder auf der 
Projektseite
http://code.google.com/p/tech-home-automation/wiki/Discussion?ts=1318878120&updated=Discussion
über die Features der Basis SW / HW diskutieren. Auch stelle ich gerne 
die Ideen des Protokolls nochmal vor. Das Protokoll ist schon von Chris 
in Code gegossen, somit sollten hier nur dann Änderungen passieren, wenn 
wirklich notwendig.

Grüße Timo

[Markus B. (mbp-bayern)]

Juergen Harms schrieb:
> Das war ein Reinfall: ebookaktiv lässt sich zwar in wine starten

Mist - ich muss echt wieder mehr unter Linux arbeiten.
Naja muss ich halt mal mit meinem OpenSuse testen,
habe da aber wenig Hoffnung.



Christoph Kastl schrieb:
> Unter anderem habe ich eine sehr gute Idee was die Rollladen- Sache
> angeht, da die Kunststoffprofile ja meistens innen hohl sind könnte man
> doch in jeden 2. oder 3. ein kleines metallblech anbringen und oben
> einen induktiven Sensor

Darüber habe ich auch schon nachgedacht.
Evtl. kann man als Sensor einen aus dem Maschinenbau verwenden;
Viele Maschinen arbeiten mit 24V für Sensorik etc. - Wir auch...

Oder aber ein Zweckentfremdeter ABS-Sensor aus dem KFZ-Bereich.
Dann muss das Blech magnetisch und bis auf einige mm nah da sein.
Kleiner Spaß am Rande:
Villeicht muss man dann noch über Kobald satt Eisen diskutieren ;-)

Mechaniker für - nennen wir's mal "Gehäusetechnik" - können
wir sicher demnächst zur Unterstützung brauchen.



Timo E. schrieb:
> Für ein einfaches Display wird man die übliche 4 Draht
> Schnittstelle verwenden.

Ja - Zumindest die intelligennte bzw. moderne Displays.

@Christoph - Wieder was zu Deiner Elektronik-Bildung:
Bitte nicht verwechseln mit den altehrwürdigen
"HD44778 kompatiblen" und deren 4-Bit-Modus.

Was Timo meint wird als SPI-Schnittstelle bezeichnet.
http://www.mikrocontroller.net/articles/Serial_Peripheral_Interface

Wir sind gerne bereit,
Dich und andere in allen Fragen der Elektronik zu unterstützen,
wo wir nur können.



Timo E. schrieb:
> Auswertung mit einfachen Reedschaltern
> machen könnte.

Auch 'ne Möglichkeit.
Sollte man aber wohl vergossene aus der Alarmtechnik nehmen;
Die anderen aus reinem Glas halte ich für Mimosen,
was die Haltbarkeit angeht, egal ob der Magnet da Dreck anzieht;
Eher, wenn was außen gegen den Rollo fällt,
oder falls es Eis einzwickt.

>Mein Ziel ist es eine stabile Basis zu schaffen

Dito.

Kleine Software Bugs können wir uns ggf. erlauben.
Kann man ja Updaten bei eingebautem Modul über den CAN-Bootloader.

Aber die Hardware ist das allerwichtigste und Die darf nicht ausfallen.
Zumindest nicht ohne wichtigen Grund - hab ich schon wo erwähnt.
Wär 'ne Katasthrophe alle UP-Knoten wegen Serienfehler ersetzten.

> Ich hoffe
> dass wir bis im Frühjahr 2012 (@Markus, ich hoffe das ist nicht
> utopisch) die erste Version der Basisplatine inkl. SW haben.

Also Grundsätzlich verpreche ich mal nix was Zeiten angeht.
Weihnachten was zum basteln wär auch schön,
aber das wär dann fast schon ein Weihnachtswunder.

Mal sehen obs noch zum Wunder reicht,
oder ob ich's erst im nächsten Frühjahr aus dem Hut zaubern kann.

Notfalls muss ich es eben machen wie viele Bastler.
Schnell hinflicken und dann ggf. neu besser machen.

Und wie schon Beitrag #2355196 erwähnt:
der ältere Can µC V1 ginge zum Basteln sicher auch irgendwie.



Christoph Kastl schrieb:
> Mal ne andere frage aus welcher Richtung Deutschlands kommt Ihr so? Ich
> bin aus Bayern!!!

Nun ich sag immer:
Ich hab mein eigenes "3 Länder-Eck".
Ok Tschuldigung is nur ein 3 Landkreis-Eck:
Im Kreis AIC, 5 Km nach Kr. LL und weitere 5 nach FFB.
Also fast mittig zischen Augsburg und München.

> Mich würde auch mal interesieren wie viele Leute hier mittlesen

Auch Google liest fleißig mit - bei mir sind wir hier auf Platz 3,
kann bei anderen Suchenden evtl. abweichen.
http://www.google.de/search?q=can+bus+hausbus



Tien schrieb:
> Naja, wollen wir mal nicht übertreiben - es gibt viele, die schon sehr
> viel weiter sind.

Wie z.B. http://www.helmutholm.de/ mit seinem Display.
Und viele andere - nicht nur mit CAN.

Vor einigen Tagen habe ich http://www.freebus.org/ angesehen;
Dort wird in Zusammenarbeit EIB kompatible Entwicklung betrieben.
Die haben sich auch richtig viel Mühe gemacht.

Villeicht sollte man auch ein Gateway zu EIB im Hinterkopf halten,
um derartiges mit einzubinden egal, ob Orignal,
oder ob Nachbau Sensor/Aktor.

In deren FAQ findet sich viel interressantes.
Auch so mancher auffällige Rechtschreibfehler.
Heutzutage wird ja viel kopiert.
Die Fehler würden 1:1 Kopien aufdecken - auch eine Art Kopierschutz.

Aber offen zugegeben:
Wie viele Fehler ich je Post ohne Korrektur vor dem "Absenden" habe,
ist kaum zu zählen - viele viele viele jedenfalls.
Ansonsten muss ich mal wieder lernen wann & wo ein Komma kommt.

> Wenn also jemand Lust hat an der Doku mitzu schreiben gern auch in
> deutsch, einfach melden.

Hm ich such dann später gern unsere Fehler im deutschen Text.
Mit selber Schreiben sprenge ich wohl das Wiki.

Guten Morgen / gute N8. wünscht:
Markus

MFG:MBP

[Hermann (Gast)]

Hallo Markus,

nach den mir bekannten Schaltplänen werdenexterne Oszillatoren 
einsetzen.

Können wir nicht den/die internen Oszillatoren z.B. des PIC18F46K80 
verwenden?

Die K-Serie ist zu den günstiger, Preis für PIC18F46K80 liegt bei 2,50$.

Bis auf RA4 und T0CKI auf RB5 sollte er auch Pinkompatibel zum 
PIC18F4680 sein.

Schönes Wochenende in die Runde

Hermann

[Markus B. (mbp-bayern)]

Hermann schrieb:
> Können wir nicht den/die internen Oszillatoren z.B. des PIC18F46K80
> verwenden?

Villeicht...
Der hat aber bei 25 °C +/-2%
und bei -40 bis +85 sind +/- 5% Fehler möglcih.

Hab dort:
http://www.edaboard.de/baudratentoleranz-can-bus-t3268.html
gefunden:

>
>Erik Hermann schrieb:
>
>Um mal eine Zahl in den Raum zu werfen:
>Im Automobilbereich werden gefordert:
>
>500kbit/s +/- 0,4%
>250kBit/s +/- 0,7%
>125kbit/s +/- 1,2%
>
>Es gibt OEM mit schärferen Vorgaben, für bestimmte Anwendungen
>(Labormeßplätze etc.) kann man aber sicher auch mal mit 2%
>experimentieren, wenn man keine anderen µC zur Auswahl hat.
>

Hermann schrieb:
> Bis auf RA4
Nun dann must man auf den digitalen DS18B20 mit seiner ID verzichten.

Einen Temperatursensor hat der Pic intern aber auch nix genaues.
Datenblatt:
>The temperature diode is not calibrated or standardized;
>the user must calibrate the diode to their application.



Übrigens:

Pic18fxx80 /xx85:
Flash/Data EEPROM Retention: > 40 years

der Neue:
20 years minimum retention, typical



Nun wundere ich mich aber noch:
Wieso hat Atmel alle 44 pins auf TQFP belegt,
Microchip hatte bisher nur 40 belgt
und muss trotzdem noch RA4 für den neuen VDDCORE/VCAP streichen...

MFG:MBP
Markus

[Tien (Gast)]

Hermann schrieb:
> Können wir nicht den/die internen Oszillatoren z.B. des PIC18F46K80
> verwenden?

Es steht dem Anwender natürlich frei auf die Bestückung des Quarzes zu 
verzichten. Wenn das mit der Kommunikation denoch klappt ist das auch 
ok.

> Hermann schrieb:
>> Bis auf RA4
> Nun dann must man auf den digitalen DS18B20 mit seiner ID verzichten.

Die digitale eindeutige ID werden ist aus SW Sicht nicht unbedingt 
notwendig. Es ist geplant eine ID beim ersten Flashen zu vergeben. 
Somiut ist eine Bestückung nicht zwingend. Ich werde vermutlich trotzdem 
einige Platinen damit bestücken, zumindest wenn in der Nähe ein Aktor 
ist. Somit lässt sich über den Gradienten bzw. max. Temp. eine 
Fehlfunktion schneller erkennen. Die Vorbereitung sollte aber in jedem 
Fall auf der Platine sein.

> Können wir nicht den/die internen Oszillatoren z.B. des PIC18F46K80
> verwenden?
> Die K-Serie ist zu den günstiger, Preis für PIC18F46K80 liegt bei 2,50$.
> Bis auf RA4 und T0CKI auf RB5 sollte er auch Pinkompatibel zum
> PIC18F4680 sein.

Wenn er Pin kompatibel ist kann er ja bestückt werden. Ich plädiere 
allerdings für den größten verfügbaren Typ und das jede Platine gleich 
bestückt sein sollte. Somit können wir (eventl.) mit einer einzigen 
Software alles erschlagen (so zumindest ein fernes Ziel). Und bzgl. den 
Kosten... es gibt ja Samples...

Grüße Timo

[Christoph K. (christoph_k73)]

Hallo an alle,

hatte gerade ne kurze Heimreise "gewonnen" deshalb hab ich nichts 
geschrieben.


Markus B. p. schrieb:
> Nun ich sag immer:
>
> Ich hab mein eigenes "3 Länder-Eck".
>
> Ok Tschuldigung is nur ein 3 Landkreis-Eck:
>
> Im Kreis AIC, 5 Km nach Kr. LL und weitere 5 nach FFB.
>
> Also fast mittig zischen Augsburg und München.

Ich wohne in Pöttmes andere Seite AIC Kreis

Markus B. p. schrieb:
> Darüber habe ich auch schon nachgedacht.
>
> Evtl. kann man als Sensor einen aus dem Maschinenbau verwenden;
>
> Viele Maschinen arbeiten mit 24V für Sensorik etc. - Wir auch...

Ich hab auch sehr viel mit Sensoren aus dem Maschinenbau zu tun (Arbeite 
bei MAN Diesel in Augsburg) daher weiß ich auch wie man die 
Näherungssensoren gut einsetzen kann

Markus B. p. schrieb:
> Wir sind gerne bereit,
>
> Dich und andere in allen Fragen der Elektronik zu unterstützen,
>
> wo wir nur können.

Danke, schön das zu hören da werden sicher noch welche kommen!


Der Code ist hier in C geschrieben oder? Das versuche ich auch gerade 
(noch nebenbei) mir ansatzweise anzueignen. Kann jmd. evtl. mal einen 
Teil des Codes Posten oder Anhängen damit ich da etwas Praxis bezogenes 
zum Lernen habe?!

Vielen Dank für die Hilfsbereitschaft

MfG Christoph

[Hermann (Gast)]

Hallo Zusammen.

Ich habe jetzt etwas Zeit zum Experimentieren.

Bestellt ist und wird wohl noch in dieser Woche eintreffen.

Microchip PICDEM Can-Lin 2, einige Muster PIC18F46k80, MAX485
Eltako TFS12-EM-UC, FSR12-4x-12V DC und SNT12-230V/12VDC-2A

Meine Lichtsteuerung werde ich Zentral mit dem Eltako Ferntastsystem 
ausführen.

Einfach nur Experimentieren macht aus meiner Sicht nicht soviel Sinn und 
würde daher gerne die RS485 Steuerung für die Eltako Ferntastsystem 
erstellen.

Die Funktelegramme von Eltako,  Stand 8.8.2011, liegen vor.

Neben den obigen Teilen werde ich voraussichtlich noch die Teile 
FSR12-12V, FMS12-12V und den FUD12NPN-12V einsetzen wollen.

Welche Teile sollten noch unterstütz werden oder gibt es schon eine 
komplett Lösung?

Grüße Hermann


Frohe Weihnachten und ein gutes neues Jahr.

[Christoph K. (christoph_k73)]

Hallo zusammen,

hier in dem Thread hat sich ja lange nichts mehr getan, darum wollte ich 
mal fragen ob es irgendwelche Vortschritte gibt?

MfG Christoph

[Markus B. (mbp-bayern)]

Hallo Christoph,
Hallo Forum.

Von meiner Seite gibt es im Moment noch ein bischen wenig übrige Zeit.
Neben dem Job arbeite ich derzeit an einem anderen Projekt extrem 
intensiv, welches schon vor Jahren nebenbei begonnen wurde.

Es hat zwar meine Planungen wieder einmal aufgelhalten, aber die 
Erfahrungen sind auch für das Vorhaben "Haus-Bus" nützlich.


Mittlerweile habe ich 2 sehr kleine 2-lagige Layouts gemacht.
Das erste läuft in einer Kleinserie (25 Stück - Handgefertigt)
Und das 2. (Redesign zum Platzsparen) ist gerade beim LP-Hersteller,
um in ca. 14 Tagen maschinell SMD-gefertigt zu werden.

(Eine Adapterplatine mit Mega328 (QFN-32), RS232 (µMAX-10), SX1505 
(QFN20), so wie diverse 0603 R+C auf DIL28-Schmal (35,56 x 10,16 mm²)
Und es sei nebenbei angemerkt, dass das extrem winziges Zeug ist!)

Ein 3. Layout (Nur THT) ist in Vorbereitung und wird nebenbei gemacht.


Wenn auch dies problemlos klappt, so weiß ich zumindest, dass ich mich 
auf Target, PCB-Pool, Bauteile und deren Verarbeitung etc. verlassen 
kann, sofern man alles kontrolliert und genauestens spezifiziert.

Mit der C-Programmierung hatte ich in den letzten Monaten auch pausenlos 
zu tun, aber eben nicht mit mit dem Haus-Bus oder auch nicht mit CAN.

Planmäßig dauert mein Projekt noch bis mitte November,
wobei das gröbste mittlerweise tatsächlich erledigt ist.
Es ist sozusagen Licht am Ende des Tunnels erkennbar,
welches auch schon täglich mehr wird.
Da dieses Projekt nicht opensource ist, so kann ich nichts 
veröffentlichen.

Sollte aber jemand höchst eilig die CAN-µC-Platine von mir als Hardware 
wollen, um Software zu Entwickeln, so muss ich das nur mitgeteilt 
bekommen, um ein weing Zeit für diese Thema abzuzweigen.

Die Hardware-Version mit dem schlecht passenden Bauteilpads könnte ich 
in ca. 14 Tagen nach Bestellung von Platinen fertig haben, wobei alleine 
8 AT auf die günstigste Leerplatinenfertigung ohne Aufpreis entfallen.
Eine Lötpad-Optimierung wäre in 3 bis 4 Wochen zu haben,
aber zum Basteln/Testen auch nicht zwangsweise notwendig.


Von Timo & Co. habe aber auch ich keine informationen über den aktuellen 
Software-Stand.


MFG:MBP
Markus.

*******************************************************************
** Bei eiligen Fällen/Fragen MAIL an MBP-Bayern(ÄT)gmx(PUNKT)net **
*******************************************************************

[Tien (Gast)]

Was soll ich schreiben...
Mein Herz blutet, das ich nicht schon deutlich mehr Zeit investieren 
konnte. In den letzten Wochen war beruflich leider so viel los, dass ich 
direkt nach der Arbeit ins Bett gegangen bin und nach dem aufstehen 
weiter gearbeitet habe. Das wir sich auch erst Mitte September 
entspannen. Und weiterhin gibt es noch einige "Großbaustellen" im Garten 
und unter dem Dach. Somit ist es leider nicht wirklich absehbar wann es 
weitergeht.

Liebe grüße Timo

[Markus B. (mbp-bayern)]

Hallo zusammen,

nach dem Hermann vor einigen Tagen per Mail bei mir angefragt hat,
ob man denn nun Platinen schon zum Basteln haben kann,
so habe ich das Thema Hausbus nun wieder aufgenommen.

Das Angebot binnen kurzer Zeit Platinen von V1
zum Experimentieren zu fertigen, das lasse ich bestehen,
aber bei gründlicher Überlegung ist das nur eine Notlösung.


Nach langer Zeit habe ich heute die letzten Stände ausgebuddelt,
so wie nochmals alles überflogen,
was wir hier so zusammengetragen haben.

In den nächsten Tagen werde ich die Hardware dort fortsetzten,
wo ich am 27.08.2011 zuletzt am Werk war.

Als erstes wird nun die kleine Prozessor-Platine entworfen,
welche ohne Netzteil für 5V und ohne Kabel-Klemmen ausgeführt wird;
Diese wird CAN + Spule so wie CAN-ESD-Schutz beherbergen.

Ein Bus-Anschluss mit einem Netzteil für mindestens 7...36V
und Anschluss für die Kabel wird danach eigens konstruiert.

MFG:MBP


----------------------------------------------------------------
Was ich in früheren Posts als anderes Projekt bezeichnet habe:
Fast meine gesamte Freizeit ging in die Neuentwicklung(*)
der Firmware für das NiMh Ladegerät AV4ms,
weshalb ich so lange keine Zeit mehr für das Thema Haus-Bus hatte.

(*)
Dies wurde ohne Verdienst von mir als Hobby durchgeführt.
Am Verkauf der Geräte verdiene ich ebenfalls nicht.

Die dabei entwikelte kleine Prozessor-Platine und deren Software
ist zwar nur indirekt für das Thema Hausbus von Nutzen,
aber das war eben wirklich alles zusammen extrem lehrreich für mich.


Da das dies vorerst weitgehend erledigt ist, so hoffe ich,
dass ich mich nun wirklich wieder unserem Haus-Bus widmen kann,
um mein Versprechen der Hardware langam aber sicher einzulösen.

[Markus B. (mbp-bayern)]

Hallo zusammen!

Über die Feiertage habe ich nun einen Stand der CAN_uC Platine erreicht,
welcher nach meiner Ansicht bereit zur Veröffentlichung ist:

 - 2 Anhänge - 3D-Modell - so soll es bald aussehen.
 - 1 Anhang - Stromlauf in Farbe und Bunt*
   (* SW zum Ausdrucken auf meinem Server verfügbar!)

***

Es sind alle wichtigen Komponenten auf nur 38,10 x 27,94 mm,
über die wir uns schon geeinigt haben.

Eine Spannungsstabilisierung und Anschlussklemmen
sind NICHT auf dieser Platine!

Das kommt auf eine gesonderte Platine, da die uC-Platine
nur eine Kern-Platine für alle Module sein soll.

***

Bei ALLEN als Spulen gezeichneten "Filter 0603"
handelt es sich um SMD Ferrit-Filter.
Der/die genaue(n) Typ(en) ist/sind nicht festgelegt.

Beispielsweise:
http://katalog.we-online.de/de/pbs/WE-CBF?sid=992a290288#vs_ct:2


***

Als fertig möchte ich es aber noch nicht bezeichnen,
da ich mir im Moment noch nicht sicher bin,
ob es an der Struktur der Versorgungsspannung und GND
noch was zu verbessern gäbe oder eben auch nicht.

 - Dazu habe ich zum Stromlauf 4 Screensots angefügt,
   welche die wichtigsten Punkte im Layout darstellen.

Wenn hier jemand Ideen, Fragen oder Einwände hat:
Insbesondere die Versorgungs und Massefläche für den Controller,
so wie die Übergänge zwischen VCC/VDD und GND/GNDP
stehen noch zur Diskussion, ob dies so sinnvoll ist.

***

Auf meinem Server unter http://mbp-bayern.dyndns.org/HausBus/
ist neben den Anhängen zusätzlich der Stromlauf in SW zum Ausdruck,
so wie die .T3000 Datei des Projektes im T3000-Target-Format.
Auch die Vorlage für die Aufnahme dieser Platine ist dort.

Achtung: ".T3000"
kann nur mit dem kostenlosen PCB-Pool(r) Target geöffnet werden!

***

MFG:MBP
Markus

[Markus B. (mbp-bayern)]

Allen, die diesen Thread verfolgen einen schönen Abend
und eine gute Nacht!


Nun habe ich mir Gedanken über die Bus-Anbindung gemacht,
was wieder einmal den erreichten Stand in Frage stellt.

Die Anordnung der Stiftleisten macht mir Sorgen,
seit ich eine Lösung suche mit welcher man
neben der Spannungsregleung und den Klemmen für den Can-Bus
auch noch eine Kleinigkeit mit in die UP-Dose bekommt.


Nach reichlicher Suche war kaum eine Lösung zu finden,
welche es ermöglicht die Adern zum Bus und zu den Schaltern
anzuschließen, ohne die gesamte Platinenfläche zu belegen.

Einige der bisher überlegten Optionen sind ja Strommessung,
so wie die Eingänge für Schalter, sinnvollerweise mit
LED-Ausgängen für die Schalter (Beleuchtung / Zustandsanzeige).

Natürlich habe ich schnell diverse Steckverbinder gefunden,
welche mir gut gefallen würden, aber keine bezahlbare Lösung.
Denn: Wer möchte 300EUR für eine Crimpzange ausgeben ? ...

Selbst wenn man günstige Stecker mit kleinem Raster
auf der Bus-Platine unterbringt, so bleibt ein Problem:

Die meisten Miniatur-Dosenklemmen sind NICHT gegeignet,
um Flexible Adern mit starren Steuerleitungen zu verbinden.
Genau gesagt habe ich keine gefunden die klein genug ist.

Eine Lötverbindung zur Montage schließe ich aber aus;
Ebenso abstehend angelötete Starr-Drähte.



Die heutige Suche hat allerdings die Lösung zum Rätsel gebracht:
http://de.mouser.com/new/avxcorp/avx9276/

AVX bietet eine SMD-Klemme 9276 für bis zu 8 Adern an,
welche nicht nur klein genug sondern auch bezahlbar ist.

Netterweise nimmt diese Klemme Flexible oder Starre Adern auf.
Draht Durchmesser: von AWG18 (1 mm²) bis zu AWG24 (0,25 mm²)
Die größte Klemme misst dabei nur 20.00 x 5.00 x 9.00 mm

Eine 300€ Zange wird auch nicht benötigt,
nur ein Werkzeug zum Wechsel der Adern für 15€ empfohlen.



Bei Ausführung der uC-Signal Stiftleisten in SMD
und gleichzeitiger Vergrößerung der Platinenlänge
von 38,10 auf 40,64 mm finden auf einer Bus-Platine
in selber Größe bis 5 Stück 8er = 40 Kontakte! Platz.

Für SMD-Bauteile bliebe dann kaum noch Platz,
geschweige denn für deren Durchkontaktierungen,
aber man wird wohl nicht 40 Adern benötigen.

Die uC-Signal Stiftleisten / Buchsenleisten gibts bei Bürklin.



Anbei 3D-Screenshots von uC V3.
 - ohne die Klemmen, denn jene müssen auf die Bus-Platine.
 - nicht alle Bauteile sind da, wo sie endgültig sein werden.


MFG:MBP
Markus

[Markus B. (mbp-bayern)]

Hallo zusammen;

Heute kam die Frage per Mail,
weshalb ich denn so viele IO-Ports auf Stiftleisten lege,
ob man nicht vielleicht einige weglassen sollte.

Nun, die vielen Ports haben einen wohl überlegten Zweck
und die Platine nennt sich nur "Can-uC", ohne Unterputz etc.

Dies ist mit voller Absicht so, da diese Platine unser Ersatz
der beliebten oder auch gehassten "C-Control" wird.
Das wird für die meisten Knoten das Herz unserer Lösung.

(Wer unter Bastlern kennt die C-Control nicht wenigstens vom Namen ?)


Erst eine Busanbindung macht die Platine dann nutzbar.
Die UP-Busanbindung z.B. in einer Dose unter dem Putz.
Dort werden zwar sicher nicht immer alle Ports benötigt.

Da es aber beliebige andere Platinen geben kann,
wie Relais-Steuerungen und Anzeigeplatienen etc.,
so kann das mit den Ports schon mal nicht schaden,
auch wenn man mit SPI und TWI wieder Ports erweitern könnte.

Mit der SMD Lösung in V3 bekommt man jetzt auch auf der kleinen
UP-Busanbindung ausser Stiftleisten und Klemmen noch was unter.


Weiter verfolge ich die Beiträge von Herm um die Gira-Taster...
Herm sellt Vorlagen bereit für die Entwicklung eigener Platinen,
welche die Taster und LED's unter seinem Kunststoff tragen.

Ein 6-Fach Tastenfeld mit 6 LEDs belegt schon 12 IO's.
Bei 2 Farben für Led's sind es ohne Multiplex schon 18 IO's.

Für die Eingänge könnte man z.B. 6 von den ANx-Ports nehmen;
(Die kann man ja nicht nur Analog sondern auch Digital nutzen.)

Für die 12 Leds dann die 8 GPIO + TXD_IO9 + RXD_IO10 + RB0 + RB1.
Alternativ zu RXD / TXD kann mann auch andere Ports nehmen,
wenn man von der Tasterplatine aus direkt RS485 benötigt.
Viel Auswahl bleibt da aber nun schon nicht mehr.

Bei passender Bestückung (Wert) von R's / R-Netzen der uC-Platine
müsste auf die Tastatur nur noch die Stromversorgung mit
Schaltregler und Anschlussklemme + Schutz-Dioden,
so wie die SMD-Taster + LED's drauf.
Vorwiderstände für die LED's wären dort nicht nötig.

MFG:MBP
Markus

[Timo E. (tien)]

Markus B. p. schrieb:
>...
> Eine Lötverbindung zur Montage schließe ich aber aus;
> Ebenso abstehend angelötete Starr-Drähte.
>...
> AVX bietet eine SMD-Klemme 9276 für bis zu 8 Adern an,
> welche nicht nur klein genug sondern auch bezahlbar ist.

Hi Markus,

herzlichen Dank für Deine Posts und Deine Arbeit!

Die Lösung mit den Starrdrähten wird meine Lösung werden. Da ich davon 
ausgehe die Platine nur sehr sellten zu bewegen ist das aus meiner Sicht 
ok. Aber die von Dir gefundenen Klemmen sehen auch sehr interessant aus. 
Ich denke es kommt auf die Zielanwendung an - die Platine soll ja 
Multifunktional sein.

Ich will mich mal wieder etwas mehr um das Projekt bemühen - nachdem 
mein berufliches Projekt fertig ist und ein neues anfängt sollte es in 
den nächsten Wochen etwas ruhiger sein.

Liebe Grüße Timo

[Markus B. (mbp-bayern)]

Hallo Timo,

es freut mich RIESIG, dass Du auch mal wieder dabei bist.

Nun,
Hardware Layout V3 der uC-Platine ist fast fertig;
Das was mir am wenigsten Spass macht, das fehlt noch:
Namen der Bauteile lesbar anordnen!

Daher habe ich auch mit den Gedanken der Bus-Anbindung begonnen;
Also nicht nur mit den interressanten Klemmen.

Die Stromversorgung unserer uC müsste mit einigen 10 mA ausgehen;

Eine alternative zu Fertig(-IC)-Reglern wäre eine Lösung
mit dem TLC555, nach dem Schaltregler-Buch von Herrn Nothart Rohde (1).

Vorteile:
Benötigt auch nur Ca. 1-2 mA für 0 mA Last,
arbeitet mit variabler Frequenz bis Ca. 200 KHz,
benötigt keine teuren Spezial-Bauteile nur Z-D, R, C, T, FET, D
also Günstig!
Der kann im Zweifel sogar weit über 50V zu 5V umsetzen...

Nachteil:
Erheblich mehr externe Bauteile als ein 78xx-(Schalt-)Regler.


MFG:MBP
Markus

(1)
http://www.amazon.de/Schaltregler-Schaltnetzteile-entwickeln-Schaltungen-Bauanleitungen/dp/3645650024

[Stefan (Gast)]

Hallo!

Ich verfolge diesen Thread nun schon die 2 Jahre lang und frage mich, 
wie sieht es denn eigentlich so mit Software aus?

Bei mir geht mein Selbstbauhausbussystem in den nächsten Tagen von 
Testumgebung in einem Koffer in die erste Hausinstallation testweise 
rein.
Ich kann nur sagen, dass die Hardware das allerkleinste Problem bei mir 
war/ist und innerhalb von wenigen Wochen erledigt war.

Die Zeit für die Hardwareentwicklung ist vollkommen vernachlässigbar im 
Vergleich zur Softwareentwicklung, drum bin ich ein wenig nachdenklich 
drüber wie es so mit dem Projektfortschritt weitergehen wird, wenn die 
Hardwareentwicklung nach 2 Jahren noch nicht fertig ist?

Bei mir gibt es 4 große Softwareblöcke:
1. Mikrocontrollersoftware (konfigurierbar Eingänge und Ausänge für 
verschiedene Funktionen)
2. Konfigurationssoftware (damit man den Platinen sagen kann was sie wie 
wann wo tun sollen)
3. Comfortsoftware (Überwacht den Hausbus / die Platinen, schaut das 
alles mit rechten Dingen zugeht und macht z.B.: die Jalousien bei einer 
bestimmten Helligkeit und Tageszeit auf / zu)
4. Mobilsoftware (derzeit Android und Iphone unterstützt, damit man vom 
Sofa und auch im Urlaub das Haus steuern/regeln/überwachen kann)

Derzeit bin ich soweit, dass ich mal in eine echte Hausumgebung 
reingehen kann und hier auch einige Funktionen (Taster, Licht...) 
sinnvoll nutzen kann, aber ich bin noch einiges an Softwarearbeit 
entfernt um z.B.: Umgebungsdaten erfassen zu können.

Welches Konzept habt ihr euch bezüglich Software überlegt?
Kann jemand mit den vielen verschiedenen Architekturen umgehen? 
(Mikrocontroller, Windows/Linux, Android, Iphone, usw....)

Ich könnte noch ewig hier schreiben, aber grundsätzlich möchte ich mal 
das Thema Software hier aufgreifen und vielleicht ein wenig 
Ideen/Erfahrungsaustausch bezüglich Software hier machen.

[Markus B. (mbp-bayern)]

Hallo Stefan,

Timo hat bereits mit jemandem zusammen Grund-Software entwicklelt
und das auf Testboards grundsätzlich getestet;

http://code.google.com/p/tech-home-automation/wiki/CanCommunicationProtocol

Diese Lösung setzt auf ein RTOS und einen CAN-Bootloader,
um die Firmware jederzeit im fertigen System zu aktualisieren,
ohne alle Platinen dazu an die frische Luft holen zu müssen.

Leider ist es mit der Zeit bei Ihm mindestens so eng wie bei mir,
aber vielleicht kann ich wenigstens darauf aufbauen.

Dezentrale intelligenz finden wir beide Trumpf.
Für Komfort kann vielleicht http://fhem.de/fhem.html
angepasst werden. (Webserver --> Client = Plattform unabhägig!)

Dass Software auch Ihre Zeit benötigt, das ist mir klar;
Spätestens seit der Firmware-Aktualisierung für das AV4ms.
Jedoch kann man Software bei uns eher leicht ändern.

Hardware kann man später nicht mehr 'mal schnell' ändern.
Und Kaputt gehen - ja, nach 20 Jahren, aber nicht nach Zwei.
Geplante obsoleszenz berücksichtige ich bei Entwicklung nicht!
Also zuverlässige Hardware benötigt vorher Aufmerksamkeit.



Meine 1. Hardware-Lösung wäre zwar fertig gelayoutet,
aber die Bauteilpads für den PIC Prozessor - naja.

Da mir diverse Vorschläge und Anforderungen
aus diesem Thread auch gar nicht so fern sind,
so habe ich beschlossen dass V1 nicht überarbeitet wird,
was ja auch schon mehrfach im Thread steht.


V2 der zentralen µC-Platine wäre zwar seit Jan. so weit,
dass man sie fertigen und verwenden könnte,
aber der 3/4 Zaun aus Bedrahteten Steckern
der zersiebt mir die Aufsatz-Platinen viel zu sehr;
Das kostet wertvollen Platz auf dem Input-Aufsatz.

Wenn jemand dennoch mit V1 oder V2 basteln will:
Auf Lochraster könnte jederzeit Software gemacht werden;
Ein Par Kabel, Klemmen, 5V-Stabi, Taster, LEDs...
Und fertig ist ein 1. Haus-Bus-Software-Eval-System.

Aber die Fertigung der Leer-Platinen dauert 8 AT im Pool;
So vergehen mindestens 3 Wochen bei soforiger Bestellung,
bis jemand eine oder mehrere Platinen bei sich haben kann.
Näheres jederzeit per PN.


V3 mit SMD-Steckern wurde auch noch im Jan. begonnen.
Wie so oft kam wieder viel ungeplantes dazwischen,
was mir die Zeit streitig macht;

Derzeit ersetzte ich noch die R-Netzwerke durch 0603er R,
denn die Netzwerke möchte ich nicht von Hand auflöten,
falls ich mir mal schnell 3 oder 4 Platinen von Hand mache.
Die Serie wird mit hoher Wahrscheinlichkeit professionell
mit ner MyData bestückt, so wie im SMT Reflow-Ofen gelötet,
aber für die Muster kosten mir die SMD-Pastensiebe zu viel.


Danach steht die 1. UP-Aufsatzplatine an,
bei der ich nun auch endlich was/wie beschlossen habe:
- 24V + CAN-Busanbindung über SMD-Klemme AVX 9276
- ESD / Überspannungsschutz für 24V und CAN.
- 24V zu 5V über DC-DC-Regler bzw. Recom-78xx
  (Diskret mit TLC555 wär gut & günstig aber Platzhungrig)
- Anschluss für 4 "normale" 230V taugliche Schalter/Taster;
  (Je 24V/20mA "Kontakt wetting Current" via NSI45020T1G
   per µC/FET gesteuert, um nicht 0,5W je Schalter zu verheizen.)
- Anschluss für 2 Farb-LED je Taster/Schalter.


"Kontakt wetting" kenne ich vom KFZ Eingangsbaustein MC33972.
Damit sollte das Risiko späterer Kontaktprobleme klein sein.

Der IC hat 22 Ein-/Ausgänge je mit 2/16 mA KSQ + 4V Komparator.
Das wäre sogar super für die Steuerung von LEDs ohne Widerstand.

Aber bei 5V traue ich den 230V-Schaltern nicht auf Dauer und
LED's müssen aus DC-DC 5V statt aus 24V linear versorgt werden,
sonst verheizt man alleine pro 20 mA LED Ca. 0,5 Watt aus 24V.

Daher kann ich den SO32 IC mit 0,65mm Pitch nicht verwenden.
Und zwei IO-ICs nur wegen 4 Ein- und 8 Ausgängen wäre overkill.
Noch dazu: So was feines von Handlöten mag ich nicht.

MFG:MBP

EDIT:

Stefan schrieb:
> Kann jemand mit den vielen verschiedenen Architekturen umgehen?
> (Mikrocontroller, Windows/Linux, Android, Iphone, usw....)

- Mikrokontroller: AVR / 8051 in ASM + C, PIC nur in C
- PC: Alles was VisualBasic versteht liegt mir zu Füssen
- Android SDK habe ich getestet - naja, nur wenns sein muss!
  (Das Android-OS und dessen Philosophie bin ich nicht gewöhnt,
   was aber auf Mobil-Devices durchaus seinen Sinn macht.)
- (WEB/Linux)SERVER: PHP & Perl finde ich auch ganz brauchbar.

[Stefan (Gast)]

Hallo!

Was ich unter 
http://code.google.com/p/tech-home-automation/wiki/CanCommunicationProtocol 
so finde ist denke ich vermutlich nicht aktuell, bzw. nicht vollständig? 
Soweit ich das sehen konnte ist da noch nicht alles einbaubereit...

Mein System ist grundsätzlich auch völlig dezentral, sodass noch alles 
funktioniert wenn mal der Server ausfällt, aber trotzdem verwende ich 
den Server für Funktionen die man nicht einem Modul auftragen 
kann/möchte/soll.

Danke für den Link zu FHEM - mir war das noch nicht bekannt und es 
klingt auf der Website ziemlich brauchbar auf den ersten Blick.
Als Ideengrundlage werde ich das auf jeden Fall heranziehen.
Ich wollte das ganze selbst programmieren, damit ich mich 100%ig damit 
auskenne - deshalb war so ein System von Anfang an kein Thema.

[Timo E. (Gast)]

Hallo Stefan,

danke für Deine Beiträge hier.
Mir blutet ja echt das Herz, dass das Projekt Softwareseitig nun nicht 
wirklich in die Gänge kommt. Ich stimme Markus voll zu, dass eine gut 
entwickelte Hardware für solch ein Projekt absolut wichtig ist - wer 
möchte schon nach ein paar Monaten alle Clients ausbauen und 
austauschen. Allerdings bin ich ebenfalls Deiner Meinung, die Software 
ist natürlich auch ein richtig dickes Ding.
Die aktuelle Software ist nicht wirklich einsatzfähig. Es fehlen noch 
viele Dinge. Ziel war (und ist) ein Basissystem aufzusetzen, welches das 
Protokoll und den Bootloader beinhaltet. Dann könnte man bereits die ein 
oder andere Steueraufgabe hart codiert laufen lassen.

Leider wie so oft im Leben eines
Informatiker-Ingenieur-Ehemann-Papa-NochmalPapa-HausBesitzer-HausUmbauer 
-GartenGieser-HobbyKletterer-Biker-UndNochVielMehr  Leben kommt das 
geliebte Elektronik Hobby zu kurz und wird als erstes geopfert.
Der Wille das ganze fertig zu bekommen ist weiterhin da. Leider ist der 
WAF gering solange das Dachgeschoß noch nicht ausgebaut ist und wir noch 
im Gästezimmer nächtigen...
Somit darf jeder gerne auf der aktuellen Software aufbauen und die 
Hardware von Markus nutzen - einen Anspruch auf ein laufendes 
Plug-and-Play System werde ich eh nie erfüllen können.

Trotz all der anderen Themen ist es mein erklärtes Ziel weiter an dem 
Projekt zu arbeiten. Schon alleine weil ich in der nächsten Heizperiode 
meine Verbrauchsdaten (u.a. Durchflussmengenmesser) erfassen will.

Somit bleibt es dabei:
gestorben ist es nicht - wer allerdings keine Zeit hat darf gerne etwas 
selbst entwickeln oder sich auch hier einbringen.
Allen anderen bleibt eh nur eine komerzielle Lösungen.

Grüße Timo

[Stefan (Gast)]

Hallo!

Da bei mir ab dem Winter das Hausbauen anfangen wird, arbeite ich 
derzeit extrem intensiv daran, dass mein Hausbus einbaufertig wird.

Wirklich fertig wird so ein Projekt nie - darauf darf man es nie 
auslegen - es muss nur einbaufertig werden ;)

Die Platine von Markus ist für mich viel zu teuer / aufwändig um sie zig 
mal im ganzen Haus zu verbauen.
Die Platine, die ich im ganzen Haus verwende hat 24 Bauteile ohne 
Platine und einen Bauteilpreis von ca. 6€ bei reichelt.
Da sie mindestens 5-6 mal pro Raum vorkommen wird, ist der Preis nicht 
unerheblich.
Bei Interesse kann ich natürlich die von mir verwendete Platine 
funktionsmäßig vorstellen, aber ich denke, das passt hier jetzt nicht.
Ich wollte ja eigentlich nicht über Hardware hier schreiben, sondern 
Software, da das bei euch jetzt eigentlich kommt/kommen muss...

[Markus B. (mbp-bayern)]

Stefan schrieb:
> Die Platine von Markus ist für mich viel zu teuer

Hallo Stefan,

Das kann gut sein und das wird wohl vielen so gehen.

Bei mir geschätzte Kosten:
20-30€ für einen 4 fach Eingang
mit 2 farbiger LED je Taster / Schalter,
für normale 230V taugliche Schalter / Taster.

Jedoch nur 2-3 Knoten je Raum im Durchschnitt vom Haus,
was auf Ca. 30 Knoten für Wohnräume kommt.
Keller, Wintergarten, Garage etc. kommt später extra.


Die von mir entwickelte Hardware soll den Komfort
über viele Jahre zu 100% zuverlässig sichern,
ohne dass das System dabei hohe eigene Stromkosten erzeugt,
oder gar regelmäßig Hardware-Wartung/Tausch benötigt.

Im Gegenteil - es soll sogar Energie ersparen,
in dem es Licht ausschaltet, wo es bisher vergessen wird.
Teils kommen dazu wohl Bewegungsmelder zum Einsatz,
welche ansonsten zumindest für Alarm angedacht sind.



Bei mir wird die Leer-Platine so viel kosten wie Deine Teile.
Für 10 Stück Muster vermutlich sogar Ca. 20€ pro Stück.
Nach den Mustern wird sich zeigen, ob man auf 5€-6€ kommt.
Falls jemand mitbestellt ist es aber vermutlich zu machen.

Selbst Ätzen der 4 Lagen µC-Leerplatine ist nicht möglich,
das war aber auch nie mein Ziel.

Mittlerweile fertigt der PCB-Pool Gold-Oberfläche :-)
(Nicht mehr nur das chemisch Zinn wie früher.)
Das macht mir die Platinen-Kosten persönlich erträglicher.

Dazu kommt noch eine Aufsatzplatine zur µC-Platine dazu,
so wie natürlich alle Bauteile pro "Sandwich",
was die Ursache für die recht hohen Kosten ist.



> Bei Interesse kann ich natürlich die von mir verwendete Platine
> funktionsmäßig vorstellen, aber ich denke, das passt hier jetzt nicht.

Mein Interresse an allem was andere machen ist sehr groß;
Was ich bisher so gefunden habe das habe ich auch besichtigt;
Das was ich bisher so gesehen habe, das hat mir aber nicht zugesagt.

Da Du von Koffer geschrieben hast,
so frage ich mich, ob das Dein Projekt war,
welches ich schon gesehen und hinterfragt habe.
Aber ich meine dass es wohl ein anderes war,
da ich zu Deinem Namen hier keine Links fand.
Es kann natürlich auch ein anderer Thread gewesen sein.


Dieser Thread hier wird leider langsam unüberischtlich;
Den "Brauche Hilfe beim Bau einer Uhr" muss er nicht erreichen.

Wenn Du der Öffentlichkeit präsentieren möchstest,
was Du an Hard & Software bisher hast,
so bietet sich sicher ein eigener Thread an.

Ansonsten kannst mir ja auch z.B. PDF/PNG/ZIP mailen.
(HausBus[ÄT]MBP-Bayern[PUNKT]dyndns[PUNKT]org)



> Ich wollte ja eigentlich nicht über Hardware hier schreiben, sondern
> Software, da das bei euch jetzt eigentlich kommt/kommen muss...

Timo bastelt ab und an bei der Software bzw. hat.

Bis ich aber zur µC-Software komme,
da fließt noch einiges Wasser den Lech hinab,
auch wenn ich lieber heute als morgen anfangen würde.
(Der Lech ist der nächst gelegene Fluss in meiner Nähe.)


MFG:MBP
Markus.

[Stefan (Gast)]

Hallo!

Nein ich habe meinen Koffer nirgendso beschrieben - das muss ein anderes 
Projekt gewesen sein.

Vorstellen darf/kann/soll ich mein Hausbusprojekt leider nicht, da ich 
bei einer Firma als Entwickler arbeite und nicht der Eindruck entstehen 
darf, dass ich hier Firmenwissen im Internet verbreite - obwohl ich kein 
Firmenwissen verwendet habe.

Ich werde den Thread weiterverfolgen und mich wieder einklinken wenns 
dann um Software geht und ich noch flexibel bin bezüglich Ideen zur 
Realisierung von Detailfunktionen.

[Markus B. (mbp-bayern)]

Stefan schrieb:
> Vorstellen darf/kann/soll ich mein Hausbusprojekt leider nicht

Hallo Stefan,

ich würde mich freuen, wenn Du dennoch folgene Eckdaten nennen kannst:

- BUS-Typ - CAN / RS485 etc.
- Verwendete Prozessorarchitektur z.B.: PIC18
- BUS-Spannung, oder Versorgung aus 230V je Knoten
- Abmessungen + Lagenanzahl der LP, wenn Unterputz
- Anzahl Eingänge je Modul, wenn Unterputz
- Spannung und Strom bzw. Widerstand zum Einlesen der Eingänge.
- Art der 230V Steuerung:
  Kanäle 230V je eigener Platine für Unterputz,
  Kanäle 230V je eigener Platine für Verteilereinbau,
  Strombelastbarkeit von 230V bei Eigenbau-Platinen,
  oder werden nur gekaufte Produkte verwendet, um 230V zu schalten.
- Verwendete Programmiersprache(n)
- Größe/Zeilen eigener Knoten Sourcecode (z.B. ohne ein RTOS)


MFG:Markus

[Stefan (Gast)]

Hallo!

- BUS-Typ - CAN / RS485 etc.
CAN Leitungstreiber am UART des µC

- Verwendete Prozessorarchitektur z.B.: PIC18
ATMega von Atmel

- BUS-Spannung, oder Versorgung aus 230V je Knoten
12V

- Abmessungen + Lagenanzahl der LP, wenn Unterputz
1 Lage - 2. Lage verwendet für kapazitive Touchflächen

- Anzahl Eingänge je Modul, wenn Unterputz
3 Eingänge, 3 Ausgänge

- Spannung und Strom bzw. Widerstand zum Einlesen der Eingänge.
Variabel - kapazitive Touchauswertung oder Taster anschließbar

- Art der 230V Steuerung:
  Kanäle 230V je eigener Platine für Unterputz,
1 Kanal dimmbar 230V und 1 Kanal Relais/Digital/PWM ODER 3 Kanäle 
Relais/Digital/PWM

  Kanäle 230V je eigener Platine für Verteilereinbau,
Platinen für Unterputz = Platinen für Verteilereinbau

  Strombelastbarkeit von 230V bei Eigenbau-Platinen,
Dimmer ca. 300W, Relais 16A

  oder werden nur gekaufte Produkte verwendet, um 230V zu schalten.
Keine gekauften Produkte
(Es gibt nur 2 verschiedene Platinen: CPU und 230V Dimmer; Wenn ein 230V 
Dimmer benötigt wird, dann braucht man beide Platinen, sonst genügt 
eine)

- Verwendete Programmiersprache(n)
µC --> C
Server --> cpp
Android --> Java
IOS --> ObjC, C

- Größe/Zeilen eigener Knoten Sourcecode (z.B. ohne ein RTOS)
µC --> ca. 3K

[Markus B. (mbp-bayern)]

Hallo Stefan,

danke für die Infos;

Hier ist mir nun zumindest klar,
dass die Hardware preislisch nicht annähernd mithalten kann,
an welcher ich derzeit arbeite;

MFG:MBP
Markus

[Juergen H. (harms)]

Die Dokumentation zu meinem Projekt ist jetzt endlich zu einem Abschluss 
gekommen. Ist zwar andere Technologie als bei Euch (AT90CAN), und als 
Ergaenzung zu einer bestehenden konventionellen Verdrahtung gedacht, 
aber ich glaube dass eine Menge wertvolle Anregungen fuer andere drin 
stehen - ist aber englisch geschrieben.

Das Ding liegt auf http://cui.unige.ch/~harms/CanSite/CanSite.html

Juergen

[Fritz F. (asdfgh)]

Stefan schrieb: "Die Platine, die ich im ganzen Haus verwende hat 24 
Bauteile ohne Platine und einen Bauteilpreis von ca. 6"

Meine Platine soll nur Temperatur und Luftfeuchtigkeit auf den CAN legen 
und bekommt stabilisierte 5V.

Ich komme auf 10 Bauteile:

PIC18F248
MCP2551 + 2*R
Quarz + 2*C
SHT21 + 2*R

Ist mir immer noch zu teuer. Kann ich irgendwo was sparen? Gibt es ein 
preiswerteren µC mit CAN???

Stefan schrieb: "Bei Interesse kann ich natürlich die von mir verwendete 
Platine funktionsmäßig vorstellen"
Ja, gerne. Welchen µC verwendest du?

[Stefan (Gast)]

CAN hat seinen Preis...
Ich hab ein Multimasterprotokoll geschrieben das auf der CAN Hardware 
arbeitet, aber im Prinzip nix anderes als Multimaster RS458 ist.
Damit kann ich günstige ICs (in meinem Fall ATMega168) verwenden.

Irgendwie Bauteile sparen is der falsche Weg. Man kann nur Funktionen 
sparen, aber an der Anzahl der Bauteile sollte man sich nicht 
festhalten.
Schutzbeschaltungen usw. müssen drauf - sonst hat man nicht lange Freude 
an den Platinen.
Eine Platine die Aufgrund von EMV, ESD, Überspannung oder so kaputt wird 
ist im Haus ein no-go...
Bei deiner Bauteilliste fehlen noch ein paar C's und D's.