Easy Builder Pro Farbsensor über RS 232 auslesen

Sensounico

Level-1
Beiträge
3
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Liebe Gemeinde,

hat jemend einen Hinweis, wie man einen CSV string eines Farbsensors (Data type "Integer, also 0...255) in das Wachendorff HMI bekommt?

Ich habe gerade eine ganz lange Geschichte geschrieben und beim Versuch, diese zu senden wurde ich vom System rausgekickt und nach Eingabe meiner Anmeldedaten war alles weg!! Deshalb die nun kurze Frage...

Mir fehlt die korrekte Anweisung für die Ertsetllung des Makros und ggf. die richtigen Einstellungen der Variablentypen etc.. Letztlich möchte ich die R, B und G - Werte separat auswerten.

Danke für alle Hinweise bzw. Hinweise auf Infos, die man sich besorgen kann.

Senso
 
Hi Senso!
Besteht das Problem noch?
Verstehe ich dich richtig, dass Du quasi eine Zeichenkette über eine serielle Schnittstelle inlesen möchtest?
Gruß HMIman
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo HMIman,
danke für die Nachfrage. Zwischenzeitlich bin ich einen Schritt weiter, da mein Kollege das Ding zum sprechen gebracht hat. Was mich irritiert ist die rel. lange Zeit von ca. 1,2 sec, um eine Messung durchzuführen. Im Automatikmodus liefert der Sensor alle 400 ms einen Wert. Wir haben jetzt eine Einzelmessung angefordert über den Befehl: „R <CR>“, damit es keinen „Salat“ gibt. Das Makro wird dann wieder ausgeführt. Den Befehl muss man jeweils im Hexadezimalcode eingeben, dann auslesen als String z.B. der Form:
123,22,54
Diesen String muss man dann in einzelne Werte (string) zerlegen und in einen Integer umwandeln. Kommt mir also etwas kompliziert vor, vor allem scheint es langsam… Hast Du ne Idee wie es besser geht?

macro_command main()

unsigned char send[2]={0x52,0x0D} \\ Befehl: “R <CR>”, Variable “send[0]” =
unsigned char get[30]="" \\ Variablen zum Einlesen der Werte
short return_value
int length1
unsigned char message_clear[30]

int i,j, pos1, pos2, pos3
unsigned char red[30], green[30], blue[30]
unsigned char target1[30]=","
unsigned char target2[30]="*"
bool success, p1_success, p2_success, p3_success
unsigned char set1[30]
unsigned char set2[30]
int R,B, G

StringSet(message_clear[0],"Local HMI",LW, 50,30)
StringSet(message_clear[0],"Local HMI",LW, 160,30)
StringSet(message_clear[0],"Local HMI",LW, 260,30)
StringSet(message_clear[0],"Local HMI",LW, 360,30)
//StringGet(get[0],"Local HMI",LW,50,30)
FILL(get[0],0x20,30) //FILL with empty space
FILL(red[0],0x20,30) //FILL with empty space
FILL(green[0],0x20,30) //FILL with empty space
FILL(blue[0],0x20,30) //FILL with empty space

OUTPORT(send[0],"Free Protocol",2)
INPORT(get[0],"Free Protocol",30,return_value)
StringSet(get[0],"Local HMI",LW, 50,30)
length1=StringLength(get[0])// nutzlos



pos1=0 //initializieren
pos2=0 //initializieren
pos3=0//initializieren
p1_success=false//initializieren
p2_success=false//initializieren
p3_success=false//initializieren



pos1=StringFind(get[0],target1[0])
success=StringMid(get[0],pos1,red[0])
pos1=pos1+1
pos2=StringFind(get[pos1],target1[0])
success=StringMid(get[pos1],pos2,green[0])
pos2=pos2+1+pos1
pos3=StringFind(get[pos2],target2[0])
success=StringMid(get[pos2],pos3,blue[0])

ASCII2DEC(blue[0],B,3)
ASCII2DEC(green[0],G,3)
ASCII2DEC(red[0],R,3)

StringSet(red[0],"Local HMI",LW, 160,30)
StringSet(green[0],"Local HMI",LW, 260,30)
StringSet(blue[0],"Local HMI",LW, 360,30)
//DELAY(2000)
SetData(R,"Local HMI",LW,280,1)
SetData(B,"Local HMI",LW,300,1)
SetData(G,"Local HMI",LW,290,1)
end macro_command

Dank und Gruß

Senso
 
Hallo Sensounico!

Die lange Zeit ist klar. Schau mal wieviele Systemfunktionen Du in dem Makro aufrufst. StringSet(), Fill(), Outport(), InPort() und die ganze Zeichenkettenzerlegung StringFind(), StringMid(), usw. Auf das Zeitverhalten dieser Funktionen hast Du keinen Einfluss. Die gibst Du an das Betriebssystem des HMI ab und hoffst das sie schnell bearbeitet werden. Aber ganz so schnell sind die Makros des HMI nicht.
Kann der Sensor evtl. die Daten auch binär schicken? Dann könnte man sich evtl. die Zeichenkettenzerlegung sparen ...

Gruß HMIman
 
Schon klar, dass mehr Code auch längere Zeit bedeutet. Aber ...Soviele Zeilen sind das ja nicht, einige nicht mal aktiv. Also ein Prozessor kann ja etliche hundert Zeilen pro Sekunde abarbeiten schätze ich mal.

Nee, der Sensor kann nur Befehle in der beschriebenen Form verarbeiten, zumindest ist nichts anderes beschrieben. Im Manual steht:

Data type
Integer for RGB, ...
Format CSV string

Encoding

ASCII characters followed by a carriage return <CR>
Max string lengths 52 characters
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Sensounico,

sorry, aber die Anzahl der Zeilen in Deinem Programm sind nicht relevant für die Bearbeitungsgeschwindigkeit. Weßt Du denn wieviele Programmzeilen sich hinter einer einzigen Funktion verbergen die Du in Deinem Programm aufrufst? Das können theoretisch tausende sein! Ich bin überzeugt davon, dass die Bearbeitungszeit in den Systemfunktionen drauf geht. Um das Ganze schneller zu machen müsste man solche Systemfunktionsaufrufe einsparen.
Ein anderer Grund könnte die Prio für den gesamten Makro-Task sein. Ich prüfe mal, ob man ein einzelnes Makro höher priorisieren kann.

Gruß HMIman
 
Zurück
Oben