Gdybym nie był chętny na posiedzenie nad takim projektem, nie marnowałbym czasu na włączanie się do dyskusji "w tym temacie".
Kwestia pieniędzy: już jedną rzecz robię charytatywnie, więc jeszcze jedna nie zawadzi
Czyli jeden projektant/programista/elektronik/informatyk jest

rchobby, czyli zgadzasz się z moim podejściem: zróbmy "inteligencję" narazie na PC, a potem ewentualnie przenieśmy ją na uP ?

Moim zdaniem - to minimum a nie kosmos
A tak serio: TMC453 kosztuyje 220 zł (około). Wolę wydać 31 zł na 3977 a za różnicę kupić jakiegoś mocnego AVR z FPGA lub FPGA + ARM.
Architektura rzeczywiście powinna być modułowa.
Ogólnie jestem za bo wolę się pogrzebać a nie kupować gotowca

pit202, trzeba sobie powiedzieć jasno czy chcemy się grzebać czy kupować gotowce.

Na oczy nie widziałem profesjonalnej maszyny CNC ,
ale coś mi się właśnie wydawało, że jeden procesor dowolnie duży tam jednak nie siedzi tylko ich chmara tam jest

pit202 pisze:bedzie trzeba mądrzejszy program napisać na PC`ta

Na uP takie same algorytmy będą, więc będzie tylko troch więcej pracy związanej z architekturą uP i jego przypadłościami.
Napewno musi być uP do buforowania poleceń sterujących bezpośrednio silnikami.
W tym momencie należy już zdecydować czy gro czynności będzie wykonywał uP (lub zespół uP) czy PC.

Widzę w tej sytuacji dwa rozwiązania:
1. PC przesyła do uP czysty G-kod, określający standardowe parametry pracy narzędzia - tj. nastepną pozyję szybkość ruchu. uP - mając informacje na temat masy bramy, siły silników, rodzaju materiału obrabianego oraz co będzie maszyna musiała wykonać w następnym kroku - określa parametry bieżącego ruchu narzędzia.
2. PC wykonuje czarną robotę i wysyła G-kod w rozszerzonym formacie do uP, który tylko wykonuje kolejne polecenia z kontrolę granic ruchu narzędzia.

Co o tym sądzicie ?
PS.
a) Ja bym wolał numerek jeden ale dyskutujmy
b) Sądzę, że kwesja formatu danych/ramek/"co chodzi po kablu" jest rzeczą narazie drugoplanową.

Tu muszę się zapytać: czy podczas samego frezowania ruch narzędzia jest jednostajny dla określonej głębokości, a tylko podczas przemieszczania narzędzia nad materiałem następuje ruch o zmiennej prędkości ?

pit202,
Rysowanie - czyli symulacja działania urządzenia - to jedno a sterowanie nim to drugie. Jeżeli program na PC będzie liczył jak ma się ruszać frez to wydaje mi się że zbliżamy się do rozwiązania typu Mach, którego niedogodności były opisywane. Jak sobie wyobrażasz porcjowanie danych - pytam całkowicie serio - będzie do wyfrezowania krzywa np. paraboliczna i co podamy 1/4 paraboli później resztę ?
piechur,
Implementacja protokołu transmisji danych jest tutaj stosunkowo najprostrzą rzeczą do zrobienia (z mojego punktu widzenia )

Ja bym widział implementację całego "ruchu" maszyny na mikroprocesorze. Np.:
PC --G-Code--> uP --sygn.ster.--> silniki.

Czyli składowymi naszego systemu będą:
- program na PC
- kontroler
- sterownik maszynki CNC

Program na PC będzie przesyłał informacje o trajektorii ruch elementu roboczego ( np. G-Code ). Kontroler będzie dane weryfikował, nastepnie obrabiał i przesyłał konkretne informacje o sterowaniu do sterownika uwzględniając parametry fizyczne silników itp. Sterownik będzie się martwił o poprawność fizyczną wykonywanych operacji (kontorla końca/początku itp.).

Czy tak to mogłoby wyglądać ?

pit202 pisze:lubi sobie poprzerywać dosc czesto

Czyli sugerujesz, że Mach przesłał by wszystkie dane o sterowaniu hurtem wszystko do procka ? patrzyłeś ile to danych ? (ja tego nigdy nie sprawdzałem, ale na szybko mogę skleić jakiś monitor portu równoległego i wszystko będzie wiadomo - widzę tu problem ilości pamięci RAM w takim systemie mikroprocesorowym.

pit202 pisze:ale wyobraz sobie opisac cos wiekszego
za pomocą linii

A nie jest to tylko kwesja siły algorytmów i procyzji obliczeń ?