PC WorX und erster Versuch eines FB in ST

[Mobi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Portisch,

bin nun endlich mal dazu gekommen dein PC Worx Projekt mir anzuschauen. Sieht schonmal klasse aus.
Was mich nur irrtiert, ein PND_IO-Array. Im Busaufbau ist eine ILC 150 ETH. Was machst du denn mit Profinet?

Und kannst du mal den Schaltplan geben von der Haupt-µC-Platine? Möchte mir das gerne mal aufbauen, aber wie gesagt nur
mit dem IR Part.
Wenn du so nett wärst.

Und ich würde an deiner Stelle selbst erstellte Datentypen nicht mit in die sys_flag_types packen sondern in ein eigenes Datentypenblatt.
Vorallem wenn man aus dem Projekt eine Lib macht.

Wieso gibst du den Ausgang IR_Changed auf einen Flankenbaustein?

R_TRIG(CLK := IR_Changed);
IR_Changed := R_TRIG.Q;

 

[Portisch]

Anbei einmal ein Schaltplan wie ich mir schon einmal etwas aufgebaut habe.
Meine Platine passt dann in eine Unterputzdose.

Es ist mit einem Atmega168 (SMD)
+ IR Steckplatz (TSOP4838 )
+ OneWire Steckplatz
+ RS232
+ USB (V-USB)
+ CAN (MCP2515)

Nach einigen Tests hat sich gezeigt, dass doch CAN das bessere ist um die µC miteinander zu verbinden.
Die Firmware für den µC ist stark im Aufbau und dauert sicher noch ein wenig.

Derzeit habe ich erfolgreich getestet:
OneWire Temperatursensoren, OneWire Humitidy (DS2438 + HIH-4021), IR Empfang (IRMP)

Und ich würde an deiner Stelle selbst erstellte Datentypen nicht mit in die sys_flag_types packen sondern in ein eigenes Datentypenblatt.
Vorallem wenn man aus dem Projekt eine Lib macht.

Wusste ich nicht - danke für den Tipp!

Wieso gibst du den Ausgang IR_Changed auf einen Flankenbaustein?

Da ich es nicht besser weis...
Es sollte eigentlich reichen eine VAR_OUT auf True zu setzen und beim nächsten Durchlauf wieder auf False, oder?

Ich habe auch einmal das "aktuell" Projekt von PC WorX angehängt.
Bei der Auswertung von Temperatur und IR Signalen hat scih schon einiges getan.

Aber ist alles noch Alpha Stadium!
Nix is fix!

Derzeit bin ich noch daran den µC Protokolltechnisch aufzubauen. Es soll dann auch über den "Master" im Schaltschrank über USB ein Firmwareupdate der Slaves (über CAN) möglich sein usw...
Steckt noch eine Menge Arbeit drinnen!

AVR & CAN: http://www.kreatives-chaos.com/artikel/universelle-can-bibliothek
Die haben auch einen CAN-Bootloader.

Anhang anzeigen RS232_Test.zip
Anhang anzeigen AVR_CAN.pdf

 

[Mobi]

Zuviel Werbung?
-> Hier kostenlos registrieren

So hab jetzt die Woche frei und wollte mich mal mit dem IR-Teil beschäftigen. Hab nen Atmega16 und einen TSOP1736, damit müsste es ja auch funktionieren. Ich werds dann mal aufbauen mit meinem "schönen" Pollin-Board. Kannst du mal den Code für den Mega posten?

 

[Portisch]

Den ganzen µC Code nicht - das ist eine zu große Baustelle!

Aber es ist ganz einfach:
http://www.mikrocontroller.net/articles/IRMP

Man besorgt sich das IRMP Paket.
Da ist auch ein Beispiel drinnen, wie man Signale empfängt und auswertet.
Diese Daten dann einfach bei der RS232 rausschieben.
Achtung: 9600, 8E1 nicht wie üblich 8N1

Hier ein paar Schnipsel:
Überprüfung ob neuer IR-Code empfangen wurde und gleichzeitig eine Entprellung der Fernbedienung:

IRMP_DATA irmp_data;
uint8_t RepeatCounter = 0;
uint8_t MinRepeats = 5;
void check_for_new_irmp_data(void)
{
 if (irmp_get_data (&irmp_data))  
 {
  if (!(irmp_data.flags & IRMP_FLAG_REPETITION))    // first check if the IR command is repeated
  {
   RepeatCounter = 0;          // new command received, reset RepeatCounter
  }                 
  else
  { 
   RepeatCounter++;          // still the same command, inc RepeatCounter
  }  
   
  if ((RepeatCounter == 0) | ( RepeatCounter >= MinRepeats)) // only send interrupt if first command, or Repeatcounter >= MinRepeats
  {
   if (RepeatCounter >= MinRepeats) 
    RepeatCounter = MinRepeats;       // fix overflow for long key push
   // Send the new message
   uart_put(IRMP_DECODED, CAN_NODE_NR, (uint8_t *)&irmp_data, sizeof(IRMP_DATA));
  }   
 }
}

Und noch die Uart_Put:

void uart_put(uint8_t command, uint8_t NodeID, uint8_t data[], uint8_t len)
{
 uint8_t i;
 uart_putc(BUS_SYNC_BYTE_1);
 uart_putc(BUS_SYNC_BYTE_2);
 uart_putc((uint8_t)(sizeof(command) + sizeof(NodeID) + len)); 
 uart_putc(NodeID);
 uart_putc(command);
 
 for (i=0; i < len; i++)
  uart_putc(data[i]);
}

Die UART Lib habe ich von http://jump.to/fleury
Die einzige Änderung ist auf 8E1:

    /* Set frame format: asynchronous, 8data, even parity, 1stop bit */
#ifdef URSEL0
    UCSR0C = (1<<URSEL0)|(3<<UCSZ00)|(1<<UPM01);
#else
    UCSR0C = (3<<UCSZ00) | (1<<UPM01);
#endif

(musst du dir aus den code der uart.c raussuchen)

Derzeit werde ich gerade mit dem CAN Bus wahnsinnig.
Es ist einfach blöde wenn man pro CAN-Message nur 8 Bytes hat und man will z.B. 12 verschicken...

 

[Portisch]

Ich bin nun schon ein schönes Stück weiter!

Aber die Lösung mit Konstanten gefällt mir so nicht so ganz:

(* define temperature sensors here *)
Devices.DeviceCount := 5;

Devices.OneWireDevice[0].Name := 'Raum 1';
Devices.OneWireDevice[0].Serial := '000003BB3921';
Devices.OneWireDevice[0].Index := 0;
Devices.OneWireDevice[0].HumitidySensor := False;
Devices.OneWireDevice[0].IntensitySensor := False;
Devices.OneWireDevice[0].PressureSensor := False;

Devices.OneWireDevice[1].Name := 'Raum 2';
Devices.OneWireDevice[1].Serial := '000003BB38A8';
Devices.OneWireDevice[1].Index := 1;
Devices.OneWireDevice[1].HumitidySensor := False;
Devices.OneWireDevice[1].IntensitySensor := False;
Devices.OneWireDevice[1].PressureSensor := False;

Devices.OneWireDevice[2].Name := 'Raum 3';
Devices.OneWireDevice[2].Serial := '0000015510F6';
Devices.OneWireDevice[2].Index := 2;
Devices.OneWireDevice[2].HumitidySensor := True;
Devices.OneWireDevice[2].IntensitySensor := False;
Devices.OneWireDevice[2].PressureSensor := False;

Devices.OneWireDevice[3].Name := 'Raum 4';
Devices.OneWireDevice[3].Serial := '0000015510EC';
Devices.OneWireDevice[3].Index := 3;
Devices.OneWireDevice[3].HumitidySensor := False;
Devices.OneWireDevice[3].IntensitySensor := True;
Devices.OneWireDevice[3].PressureSensor := False;

Devices.OneWireDevice[4].Name := 'Raum 5';
Devices.OneWireDevice[4].Serial := '0000015606EE';
Devices.OneWireDevice[4].Index := 4;
Devices.OneWireDevice[4].HumitidySensor := False;
Devices.OneWireDevice[4].IntensitySensor := False;
Devices.OneWireDevice[4].PressureSensor := True;

Ich habe jetzt einmal in einem Programm hier meine OneWire Sensoren augelistet.
Wird ein Sensor mit der passenden Serial gefunden wird der Name angezeigt.
Auch definiere ich hier ob es sich um einen Humitidy, Pressure oder Itensity Sensor handelt.

Wenn ich aber nun einen Sensor austuasche muss ich das SPS Projekt anpassen.
Kann man das irgendwie schön lösen, dass sich die SPS die Daten von wo anders holt.
Dann nur einen Trigger an die SPS -> lade Daten neu oder so.

Danke!

 

[Mobi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du könntest über eine selbstgeschriebene Client Anwendung Sensoren hinzufügen über TCP/IP. Wenn die DeviceCount begrenzt ist kannst du ja dann die Sensoren einfach einfügen in das remanente Array. Wenn nicht würde ich die in einer CSV schreiben auf dem FTP.

Kann den der Sensor alle drei Typen gleichzeitig haben?

 Devices.OneWireDevice[2].HumitidySensor := True; Devices.OneWireDevice[2].IntensitySensor := False; Devices.OneWireDevice[2].PressureSensor := False;

Wenn nicht reicht doch ein Eintrag wo du den Typ angibst.

 

[Portisch]

Ging ja schnell!

Du könntest über eine selbstgeschriebene Client Anwendung Sensoren hinzufügen über TCP/IP. Wenn die DeviceCount begrenzt ist kannst du ja dann die Sensoren einfach einfügen in das remanente Array. Wenn nicht würde ich die in einer CSV schreiben auf dem FTP.

Das mit TCP gefällt mir nicht so, da die SPS wirklich ohne externes Zutun starten soll. Ansonsten müsste ich ja die Daten bei einem Neustart/Stromausfall die Daten wieder runterschieben. Da gefällt mir die Lösung mit einer CSV auf dem FTP schon besser.

Gibt es zu CSV ein fertigen FB? Oder muss man sich das String zerlegen selber zusammenbauen?

Wenn nicht reicht doch ein Eintrag wo du den Typ angibst.

Wenn zu 100% sicher ist, dass die Startwerte auf FALSE sind? Oder muss ich das auch selber in einer FOR-Schleife erledigen?

 

[Mobi]

Über TCP sollen doch nur die Daten reinkommen. Speichern kannst du die in einem Array, so wie jetzt, oder in der CSV. Die Daten würde ich als XML Schema übertragen.

Könnte sein, dass es schon einen fertigen FB gibt, spätestens wenn ich ihn schreibe.

Warum sollen die Startwerte denn auf False stehen? Ich würde das eher so machen. Ein Hex-Wert gibt den Typ an.


Humitidy = 0x01
Intensity = 0x02
Pressure = 0x04

Wenn du mal einen Sensor hast der z.B. Humitidy und Pressure kann lautet der Wert 0x05.

 

[Portisch]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das mit dem Sensor Typ über Bits zu definieren gefällt mir! Danke!

Ich habe einmal die Oscat Lib überflogen - da scheint was für XML drinnen zu sein.
XML gefällt mir persönlich auch besser als CSV.

Hört sich so gut an:
Daten per TCP an die SPS, die legt es in einem XML auf dem FTP ab.
Oder XML direkt auf den FTP und dann die SPS die Datei neu einlesen lassen. Wär weniger Arbeit.
Mal sehen wie sich das am einfachsten Umsetzen lässt.

 

[Mobi]

Ich meinte eigentlich die Daten im XML-Scheme zu übertragen und dann in die CSV zu schreiben. Aber wenn du es auch als XML speichern willst...ok.

 

[Mobi]

Hab mal schnell nen Client geschrieben um es dir mal zu zeigen was ich meine. Als IP kannste ja die von deinem Router nehmen und Port 80, nur damit die Felder alle freigeschaltet sind. Das Anhaken des Sensortyps funktioniert schonmal nur der Button "Device hinzufügen" ist noch ohne Funktion.

 

[Portisch]

Zuviel Werbung?
-> Hier kostenlos registrieren

Werde ich mir noch ansehen! Danke!

Ich habe jetzt aber dazu noch eine Frage wegen dem RS232_RECEIVE.

ich habe das in dem Default_Task drinnen und es wird somit bei jedem Zyklus ausgeführt.
Dadurch steigt aber die CPU auf ~30%. Ohne dem Receive habe ich ~3%.
Es ist egal ob REQUEST auf TRUE oder FALSE steht.

Ist das egal oder sollte man hier etwas verbessern?

 

[Mobi]

Hallo Hugo,

ich hab aktuell ein Projekt, da möchte ich auch gerne 1-Wire verwenden. Aber ich möchte das gerne direkt an die RS232 vom ILC hängen. Natürlich mit einem Interface dazwischen z.B. DS2480B oder so. Wie läuft inzwischen deine Sache so?

 

[Portisch]

Eigentlich zu 100% Stabil

Anbei mal mein RS232 Part und mein Command Handling von der SPS.
Die AVR senden ca. alle 3min neue Sensor Daten an die SPS um den Bus nicht zu überfordern.

Das AVR Projekt könnte ich auch mal zur Verfügung stellen. Ist halt ein Projekt auf meine Anforderungen abgestimmt.
Da ist dann ja auch noch ein CAN mit drinnen, um mehrere AVRs miteinander zu verbinden.