Lars Ro

Ich würde mal vermuten, die Spannungen sind von Anfang an im PMMA drin, sie werden nur erst sichtbar, wenn Ihr es erhitzt. Vielleicht kann man die Platten beim Abkühlen platt drücken? "Tempern" ist da wohl das Stichwort: "Der Begriff Tempern beschreibt allgemein das Erhitzen eines Materials über einen längeren Zeitraum. Mit einem solchen Verfahren ist es beispielsweise möglich, die Verteilung mechanischer Spannungen in einem Bauteil aus Glas oder Acryl zu kontrollieren." http://de.wikipedia.org/wiki/Tempern Als Vorschlag: Das PMMA noch vor dem Lasercut auf ein Backblech, da drauf eine plane, schwere Metallplatte und dann bei X °C für Y Minuten tempern. Anschließend langsam und gleichmäßig abkühlen lassen. Mehrere Lagen ggf. mit Backpapier trennen. PS: Siehe auch "Was ist Tempern und was ist dabei zu beachten?" http://www.plexiglas.de/product/plexiglas/de/ueber/faq/Pages/bearbeiten.aspx#faq_0_6 Acrylglas / Plexiglas tempern http://www.selbst.de/hobby-freizeit-artikel/modellbau/acrylglas-plexiglas-tempern-103482.html

Ich will hier auch noch mal das Encoder-Bricklet etwas pushen. Meine Anwendung wäre die Abfrage eines Endlos-Drehreglers, also hätte ich am liebsten ein Rotary-Encoder-Wheel-Bricklet inkl. Drehrad. Da sind die 1200 RPM auch ausreichend. Darüber hinaus finde ich eine DC-Motorsteuerung auch sehr interessant. AFAIK arbeiten die typischen 6-Achs-Roboter auch mit DC-Motoren plus Encoder (statt Schrittmotoren), weil das fehlerfrei läuft. Schrittmotoren können unter starker Belastung und/oder ungünstiger Programmierung wohl schon mal einen Schritt "auslassen". Und ein Selbstbau-Roboter wäre natürlich was... Aber erst nach der CNC-Fräse, dem 3D-Drucker und dem Bestückungsautomaten. Zur Realisierung: AFAIK ist auf dem (beim DC-Brick verwendeten) ATSAM3S2B ja ein Hardware Quadrature Decoder, der auch mit sehr hohen Frequenzen vmtl. überhaupt keine Probleme hat. Auf dem ATSAM3S4C des Master-Bricks sind sogar zwei. Leider scheinen die entsprechenden Pins (TIOA und TIOB? Find mich da nicht zurecht.) nicht auf den Bricklet Connectoren zu liegen. Da würde ich mal frech eine neue Hardware-Revision der Bricks vorschlagen, die die benötigten Signale mit Pins 2 und 3 eines Connectors verbindet. Da nicht genügend Hardware Decoder für alle Connectoren vorhanden sind, würde bei den "einfachen" Connectoren jeder Tick per Software abgefragt. Das erlaubt nur recht geringe Umdrehungsgeschwindigkeiten. "High Speed" bieten erst die mit einem Hardware Decoder verbundenen (und deshalb speziell gekennzeichneten) Connectoren. Bei den bisherigen Bricks gibt es eben nur die "einfachen".

Das Gehäuse und das auch das Kit sind eine gute Idee. Ich wäre für eine weiße Milchglas-Frontplatte, da fällt das Technik- und Kabel-Wirrwarr dahinter nicht gleich so auf (Stichworte wohnzimmertauglich und Woman-Acceptance-Factor). Die anderen Seiten transparent/klar, damit man dennoch leicht zeigen bzw. sehen kann, was drinsteckt.

Ich würde modernes C++ vorschlagen, also nicht C objektorientiert CamelCase coding-style (passt gut zu Qt) ähnlich wie die Java-Bindings (nur i.Allg. ohne new) std::string statt char* std::function und std::bind für Callbacks einfach uint8 statt uint8_t (ggf. selbst definieren) #include <iostream> using namespace std; #include "tinkerforge/IPConnection.hpp" using namespace tinkerforge; const string Host = "localhost"; const int Port = 4223; // Print incoming enumeration information void enumerationCallback( const string& uid, const string& connectedUID, char position, uint8 hardwareVersion[3], uint8 firmwareVersion[3], uint16 deviceID, uint8 enumerationType //nicht nötig, dank bind(), siehe unten//void* user_data ) { cout << "UID: " << uid << endl << "Enumeration Type: " << enumerationType << endl; if (enumerationType == IPConnection::EnumerationType::Disconnected) { cout << endl; return; } cout << "Connected UID: " << connectedUID << endl << "Position: " << position << endl << "Hardware Version: " << hardwareVersion[0] << "." << hardwareVersion[1] << "." << hardwareVersion[2] << endl << "Firmware Version: " << firmwareVersion[0] << "." << firmwareVersion[1] << "." << firmwareVersion[2] << endl << "Device ID: " << deviceID << endl << endl; } int main() { // Create IP Connection IPConnection ipcon; if (ipcon.connect(Host, Port)) { cerr << "Could not connect to brickd" << endl; exit(1); } // Register enumeration callback to "enumerationCallback" ipcon.registerEnumerationCallback(&enumerationCallback); //ipcon.registerEnumerationCallback(bind(&AClass::enumerationCallback, this)); // Trigger enumerate ipcon.enumerate(); cout << "Press key to exit" << endl; getchar(); //Nicht nötig, da vom Destruktor aufgerufen://ipcon.disconnect(); }

Hallo, eine Frage zur internen Interrupt-Behandlung: Ein Atmel SAM3S kann ja (beispielsweise) bei Änderungen an einem seiner (digitalen) Eingänge einen Interrupt auslösen. Das kann man ja auch in Eurem API nutzen. Aber wie funktioniert das über Brick-Grenzen hinweg? Geht das über die Signalleitungen "Interrupt 0-2" des Stack Data Connectors? Ich frage das, weil die laut Doku 1. scheinbar nur für Master-Extensions genutzt werden (oder nicht?), und 2. ja nur als "Interrupt Outputs" beschrieben sind (ich denke mal, Output aus Sicht des Masters, oder?) Wird da vielleicht auch nur gepollt? Viele Grüße, Lars