Mal wieder: Arduino und Rapsberry als Treiber-Boards - Deutsches Howto

na immerhin ein Fortschritt

die 10.04 konnte man erfolgreich auf dem Rasperie kompilieren und am 7" touch screen laufen lassen
mit einem tb6560 board ging das auch an der maschine zwar nur bis maximal 1000mm/min
aber immmerhin eine Hobby Fräse im Kleinformat

pl7i92 wrote:

an der maschine zwar nur bis maximal 1000mm/min

auf welche uebersetzung/schrittweite beziehen sich solche werte?

wenn ich von jetzt mal 3 umdrehungen/10mm ausgehe, dann komme ich
im vollschritt auf ganz andere werte als im 1/16-schritt. und die billig-TAs aus
chinesien koennen ja auch 1/32 (was ich fuer ziemlich unsinnig halte).

Aktueller Stand: Rapsberry mit linuxCNC via Raw-Ethernet 12kHz am Stepper-Pin

na bitte geht doch
das Rauschen macht mir kopfweh ist das Das osziloskop
oder doch der Rasp

pl7i92 wrote:

na bitte geht doch
das Rauschen macht mir kopfweh ist das Das osziloskop
oder doch der Rasp

das ist eine zappelige masse - und ganz viele, ganz lange nicht abgeschirmte kabel.

das hier macht mich grad etwas nachdenklich:

step_type=2 - das war wohl die loesung, die ich suchte.

aber die the linux-tcpdump-timestamps sind etwas merkwuerdig, wenn
man mit with a stepgen.maxvel hart an die rt-ticks rangeht:
bei 30 sieht das gut aus:


setp stepgen.0.maxvel 30
(distance between two 60byte packets)

Time | last packet timediff

---

+

---

55.713276 - 0.00005000
55.713350 - 0.00007400
55.713426 - 0.00007600
55.713475 - 0.00004900
55.713550 - 0.00007500
55.713625 - 0.00007500
55.713676 - 0.00005100
55.713750 - 0.00007400
55.713825 - 0.00007500

aber bei 40 kommen solche zeitabstaenden zwischen 2 paketen raus:
0.00000200sec == 2usec -

kann ja nich sein.... bzw. darf nich sein

setp stepgen.0.maxvel 40
(distance between two 60byte packets)

Time | last packet timediff

---

+

---

54.504630 - 0.00000200
54.504631 - 0.00000100
54.504632 - 0.00000100
54.504633 - 0.00000100
54.504635 - 0.00000200
54.504636 - 0.00000100
54.504637 - 0.00000100
54.504639 - 0.00000200
54.504640 - 0.00000100
54.504641 - 0.00000100
54.504643 - 0.00000200
54.504644 - 0.00000100
54.504645 - 0.00000100
54.504646 - 0.00000100
54.504647 - 0.00000100


STEPGEN: Channel 0: The requested maximum velocity of 45000 steps/sec is too high.

eim zaehlen der pakete komme ich auf 170848 packets in 10 sekunden.
17000 pkt./sec ==> 0,000058824 sec./packet.

das kling halbwegs logisch - aber dennoch nach weniger, als
rechnerisch rauskommen sollte
40k packet/sekunde muessten ja moeglich sein bei einem
25usec-thread.

wenn ich gleich grosse pakete im loop direkt rauspruegel, dann
komme ich auf etwas mehr als 30k. (hatte ich mal getestet)


munter bleiben

wicki

Deswehgen vertaut auch keienr einem arduino oder rasp eine Echte maschine an

zudem ja ein Hauptrechner auf jeden Fall present sein muss oder Ist
also warumm der u,weg über eine zweiten rachner
bei einer STL an den Drucker schreibt der ja das programm selbst

CNc maschinen arbeiten in 2-2.5D da ist echter g-code gefragt keine punkteinterpolation
mit 0,254mm
die meisten wollen unter 0,01mm bei 5m/min

beim Plasma ist unter 8m/min in 1mm Blech kein sauberes Arbeiten möglich

pl7i92 wrote:

Deswehgen vertaut auch keienr einem arduino oder rasp eine Echte maschine an
zudem ja ein Hauptrechner auf jeden Fall present sein muss oder Ist
also warumm der u,weg über eine zweiten rachner
bei einer STL an den Drucker schreibt der ja das programm selbst

CNc maschinen arbeiten in 2-2.5D da ist echter g-code gefragt keine punkteinterpolation
mit 0,254mm die meisten wollen unter 0,01mm bei 5m/min

beim Plasma ist unter 8m/min in 1mm Blech kein sauberes Arbeiten möglich

hauptsache was zu nöhlen, ja ?

da antwort auf die letzte frage waere mir wichtiger: warum kommen so seltsame
messwerte bei paketversand raus?

8000mm/minute bei 1/100 aufloesung sind 13kHz.
geht. wenn man das will und braucht. auch mit raspberry, behaupte ich.
momentan sehe ich dort die grenze bei knapp ueber 5kHz.

womit man 3m/min bei 1/100 erreichen kann.
also mir reicht das.

sicher gibts auch leute, die das einfach nur mal zum spass versuchen wollen.

was stoert dich dran, wenn jemand einen treiber dafuer baut?
keiner zwingt dich, ihn zu benutzen.

schoenen tag noch

wicki

Du hast das sicher schon selbst erkannt die ergebnisse sind nicht stabil
und hängen oft sogar vom Hochlaufen des Rechnrs ab
de eine Portinitialisierung vom Bios schon vorgenommen wird

Das Gleiche git beim Start von Rapberry bei einer stabilen Spannungsversorgung NICHT USB kommt da was anderes Raus als bei besagtem USB

und diese Initialisierung ist leider nicht beeinflussbar

pl7i92 wrote:

Du hast das sicher schon selbst erkannt die ergebnisse sind nicht stabil
und hängen oft sogar vom Hochlaufen des Rechnrs ab
de eine Portinitialisierung vom Bios schon vorgenommen wird
Das Gleiche git beim Start von Rapberry bei einer stabilen Spannungsversorgung NICHT USB kommt da was anderes Raus als bei besagtem USB
und diese Initialisierung ist leider nicht beeinflussbar

das klingt - entschuldige - absurd.
ja, raspberries brauchen eine stabile stromversorgung - die braucht aber jeder PC oder
chip irgendwie....

welche portinitialisierung ein PC-bios vornimmt ist beim betrieb via eth irrelevant.

und ansonsten faegt man solche situationen mit einem gezielten power-on-event
auf der leistungsseite ab.

ich werde jetzt aber auch auf "das geht eh nicht", "das braucht keiner", "das will keiner"
nicht weiter eingehen. ich bau das weiter und benutze es und wenn ich feststelle, es geht
nicht, dann benutz ich es halt nicht mehr - und werde dann genau wissen, was nicht geht.

wenn man all diese dinge, die nicht gehen, die nicht gebraucht werden, die keiner will,
nicht gemacht hatte, dann haetten wir kein linux und kein GNU.

schoenen tag noch

wicki

Das Will Jeder Braucht jeder Hobbyist der auf das Geld schaut
MACH Weiter
Da hast du was Falsch verstanden
Die Zielgruppe ist nur nicht hier im Forum
die sind bei den Repraps