Cncontrol by Melino65
-
- Senior
- Messaggi: 1341
- Iscritto il: martedì 22 aprile 2008, 16:37
- Località: BZ
Re: Cncontrol by Melino65
-
- Member
- Messaggi: 295
- Iscritto il: martedì 14 novembre 2006, 20:59
- Località: Cologno Monzese
Re: Cncontrol by Melino65
mh alex non funziona "a timer" ne "a impulsi" è solo una porta.
Non sò se hai visto mach3, nella schermata dei motor tuning se non erro ti chiede quanto deve durare il segnale, da 1us a 5us.
Questa cosa la puoi realizzare tramite il timer attivi il timer , metti a 1 il pin, aspetti da 1 a 5us, metti il pin a 0.
spero di essere stato chiaro.
Non sò se hai visto mach3, nella schermata dei motor tuning se non erro ti chiede quanto deve durare il segnale, da 1us a 5us.
Questa cosa la puoi realizzare tramite il timer attivi il timer , metti a 1 il pin, aspetti da 1 a 5us, metti il pin a 0.
spero di essere stato chiaro.
U.
- niki77
- Member
- Messaggi: 527
- Iscritto il: martedì 27 marzo 2007, 13:42
- Località: Tolentino(MC)
Re: Cncontrol by Melino65
Se si tratta di scrivere un software con relativo driver per windows che piloti direttamente la parallela non sono interessato.franceso ha scritto:Quanti sono che vogliono scrivere un SW ?
Se qualcuno avesse voglia di iniziare il progetto di un cnccontroller usb (scheda a microprocessore) e sviluppare un relativo driver per mach3 sono interessato ,visto che ho cominciato un progetto di questo tipo molti mesi fà e per mancanza di tempo da solo non riesco a finirlo.
Saluti.
Meglio non dire una cosa che dirne una sbagliata!
-
- Senior
- Messaggi: 1341
- Iscritto il: martedì 22 aprile 2008, 16:37
- Località: BZ
Re: Cncontrol by Melino65
Ho driver (dll) belli finiti per pilotaggio motori stepper tramite porta parallela, non solo interfaccia porta parallela.
Ho microcontroller per pilotaggio motori stepper con interfaccia seriale.
Mi manca software di interfaccia grafica, driver per mach3 in verità¡ ci sarebbe gia, ma mi interessa poco.
Ho microcontroller per pilotaggio motori stepper con interfaccia seriale.
Mi manca software di interfaccia grafica, driver per mach3 in verità¡ ci sarebbe gia, ma mi interessa poco.
-
- Newbie
- Messaggi: 39
- Iscritto il: sabato 1 novembre 2008, 9:29
- Località: LECCE
Re: Cncontrol by Melino65
E' possibile mettere a disposizione quei driver?
Ciao
Ciao
-
- Junior
- Messaggi: 61
- Iscritto il: mercoledì 3 gennaio 2007, 1:52
- Località: Ascoli Piceno
- Contatta:
Re: Cncontrol by Melino65
Ragazzi mi complimento con tutti voi per i vostri buoni propositi.
Scrivere un codice per governare una CNC non è poi cosi' difficile, basta solo un po di buona volonta' .
Il problema non e' quale driver usare (io.dll o inpout32.dll) bensi il kernel di windows, che non riesce a gestire tempi
dell'ordine di 5 us(come sostiene UMBEZ) .
Il TIMER di sistema scende al massimo a 2/3 milliSecondi (quando va bene) e questo vuol dire che i vostri motori raggiungeranno al massimo la velocita' di 300/500 step/sec (1 o 2 rotazioni al sec).
Percio' studiate un driver che possa gestire con precisione tempi brevissimi oppure sfruttate la velocita' di elaborazione del processore (calcolando quandi cicli compie al secondo) e sfruttatelo come cronometro (ma con minor precisione)
Esempio:
Se il vostro processore impiega 1 sec. per compiere il seguente ciclo:
For Z =1 to 1000000:next Z
in teoria con un ciclo For/Next da 1 a 5
otterrete un ritardo di 5 uS
Fate dei test e vedrete che non e' proprio cosi' !
Scrivere un codice per governare una CNC non è poi cosi' difficile, basta solo un po di buona volonta' .
Il problema non e' quale driver usare (io.dll o inpout32.dll) bensi il kernel di windows, che non riesce a gestire tempi
dell'ordine di 5 us(come sostiene UMBEZ) .
Il TIMER di sistema scende al massimo a 2/3 milliSecondi (quando va bene) e questo vuol dire che i vostri motori raggiungeranno al massimo la velocita' di 300/500 step/sec (1 o 2 rotazioni al sec).
Percio' studiate un driver che possa gestire con precisione tempi brevissimi oppure sfruttate la velocita' di elaborazione del processore (calcolando quandi cicli compie al secondo) e sfruttatelo come cronometro (ma con minor precisione)
Esempio:
Se il vostro processore impiega 1 sec. per compiere il seguente ciclo:
For Z =1 to 1000000:next Z
in teoria con un ciclo For/Next da 1 a 5
otterrete un ritardo di 5 uS
Fate dei test e vedrete che non e' proprio cosi' !
-
- Member
- Messaggi: 295
- Iscritto il: martedì 14 novembre 2006, 20:59
- Località: Cologno Monzese
Re: Cncontrol by Melino65
non lo sostiene UMBEZ, c'è scritto nella videata di mach3 il mio era solo un esempio.
Comunque se proprio bisogna essere precisi dipende anche dalla schedulazione del processore dalle priorità del processo e tanti altri fattori e questo lo posso affermare io dopo un esame di sistemi operativi.
Comunque giusto per completezza :
http://www.codeguru.com/forum/showthrea ... post933257
Comunque se proprio bisogna essere precisi dipende anche dalla schedulazione del processore dalle priorità del processo e tanti altri fattori e questo lo posso affermare io dopo un esame di sistemi operativi.
Comunque giusto per completezza :
http://www.codeguru.com/forum/showthrea ... post933257
U.
- niki77
- Member
- Messaggi: 527
- Iscritto il: martedì 27 marzo 2007, 13:42
- Località: Tolentino(MC)
Re: Cncontrol by Melino65
Già , questo perchè windows fa altri 100000 c---i in background ed è impossibile evitarlo.melino65 ha scritto: Esempio:
Se il vostro processore impiega 1 sec. per compiere il seguente ciclo:
For Z =1 to 1000000:next Z
in teoria con un ciclo For/Next da 1 a 5
otterrete un ritardo di 5 uS
Fate dei test e vedrete che non e' proprio cosi' !
Anche utilizzando un ipotetico driver RTOS per windows non si otterranno comunque grandi miglioramenti.
In questo caso si guadagna molto nella costanza dei tempi di risposta,ma non si ha comunque una soddisfacente velocità per la generazione di impulsi .
E' inutile continuare ad insistere su questa strada, già mach3 ha bisogno di un sistema operativo configurato ad hoc e spesso non basta, e non è che in ArtSoft siano proprio dei dilettanti che non sanno fare di meglio.
Se proprio si vuole fare qualcosa di interessante a questo punto conviene lavorare direttamente in assemblere e far girare il software su dos (vedi turbocnc, è una scheggia e va benissimo), solo che li diventa problematica la gestione dell'interfaccia grafica e di un eventuale anteprima del tracciato.
La soluzione ideale stà in un hardware dedicato(scheda a microprocessore , via usb o ethernet) con un software dedicato(firmare per scheda a microprocessore) e un software per comandarla o un driver per mach3.
Con una scheda dedicata con a bordo una mcu moderna che può lavorare ad un clock di 80mhz ci si possono togliere davvero delle belle soddisfazioni
Saluti.
Meglio non dire una cosa che dirne una sbagliata!
-
- Senior
- Messaggi: 612
- Iscritto il: domenica 10 giugno 2007, 10:32
- Località: Rg
Re: Cncontrol by Melino65
Vorrei provarlo anche io , ci sono complicazioni se installo Cncontrol assieme a mach3?
-
- Junior
- Messaggi: 61
- Iscritto il: mercoledì 3 gennaio 2007, 1:52
- Località: Ascoli Piceno
- Contatta:
Re: Cncontrol by Melino65
No, nessuna complicazione !buby ha scritto:Vorrei provarlo anche io , ci sono complicazioni se installo Cncontrol assieme a mach3?
-
- Senior
- Messaggi: 612
- Iscritto il: domenica 10 giugno 2007, 10:32
- Località: Rg
Re: Cncontrol by Melino65
Grazie.
-
- Junior
- Messaggi: 98
- Iscritto il: mercoledì 15 novembre 2006, 19:17
- Località: Genova
Re: Cncontrol by Melino65
Sono d'accordo con Nik77.
Bisognerebbe fare una cosa del genere.
http://www.cncdudez.co.uk/
Il pic in questione PIC18F4550 ha la usb integrata.
Questo pic ha un clock di 40MHz ma le serie superiori vanno più sù.
La flessibilità dei pic e la usb possono portare ad un ottimo risultato.
L'deale sarebbe quello di rendere la scheda completamente indipendente dal pc dandogli in pasto il g-code attraverso una chiavetta usb e il sw decodificatore g-code/comandi per stepper all'interno del pic e se non basta la sua memoria utilizzare una eeprom esterna.
Che ne pensate?
Ciao
Antonio
Bisognerebbe fare una cosa del genere.
http://www.cncdudez.co.uk/
Il pic in questione PIC18F4550 ha la usb integrata.
Questo pic ha un clock di 40MHz ma le serie superiori vanno più sù.
La flessibilità dei pic e la usb possono portare ad un ottimo risultato.
L'deale sarebbe quello di rendere la scheda completamente indipendente dal pc dandogli in pasto il g-code attraverso una chiavetta usb e il sw decodificatore g-code/comandi per stepper all'interno del pic e se non basta la sua memoria utilizzare una eeprom esterna.
Che ne pensate?
Ciao
Antonio
-
- Senior
- Messaggi: 732
- Iscritto il: venerdì 29 maggio 2009, 8:43
- Località: Ferrara
- Contatta:
Re: Cncontrol by Melino65
E' sicuramente una ottima strategia spostare l'attenzione dall'approccio seguito da mach 3 ai nuovi controlli via Usb. Inutile nasconderlo : sono personalmente convinto che i problemi derivanti dal timing di Windows sono grossi ostacoli che, se non impediscono, certamente rendono difficili futuri salti di qualita'.
L'attuale svantaggio pero' sta nella mancanza di uno standard di comunicazione fra il software e la schedadi controllo. Mi spiego meglio. Con l'approccio utilizzato finora non si pone il problema dello standard. L'applicazione pilota direttamente l'hardware della parallela alzando a abbassando i relativi pin per il tempo necessario. C'e' da stupirsi degli eccellenti risultati ottenuti da Mach3 e applicazioni similari considerando che di mezzo c'e' Windows.
Con i controlli USB L'applicazione non deve generare direttamente la sequenza di impulsi ma ordina al controllo di eseguire certe azioni. E' il controllo che poi, ricevute e bufferizzate le istruzioni si preoccupa di creare la sequenza di impulsi giusta che pilota gli azionamenti a valle di esso. Spostando la logica dalla applicazione utente al controllo USB, nasce un nuovo problema. Ogni costruttore di schede USB implementa (giustamente direi...) un suo protocollo di dialogo fra l'applicazione e la scheda. Ora, questi protocolli non sono documentati e questo rende difficile (anzi impossibile) scrivere applicazioni che possano sostituire o integrare il software in dotazione alle varie schede.
Ci vorrebbe un protocollo aperto o quantomeno documentato che consentirebbe a chi lo vuole fare di scrivere del soffware che poi puo' funzionare schede diverse.
Non sono un esperto di hardware e quindi non so quanta "intelligenza" sia nei controlli usb che sono disponibili oggi ma certamente ogni soluzione e' "proprietaria" e questo, come dicevo prima e' comprensibile (per le aziende che hanno investito in sviluppo) ma allo stesso tempo e' anche un freno perche' rende difficile l'ingresso di nuovi attori nel panorama CNC hobbistico e/o semiprofessionale per non parlare di quello professionale.
La vitalita' di una piattaforma sta nel software che ci gira intorno. Se scrivere nuovo software e' appannaggio solo di chi produce l'hardware il progresso sara' piu' lento e subordinato alle esigenze del produttore.
Faccio un breve esempio. Personalmente ho una certa esperienza di programmazione di interpreti e linguaggi ma nessuna di hardware. Ora, potrei in modo relativamente semplice definire un nuovo linguaggio e scrivere un programma interprete che legga la sintassi di quel linguaggio e produca come risultato una serie di istruzioni. E' quello che ho tra l'altro gia' fatto ma il risultato finale attualmente e' un file APT-CL che poi viene tradotto dal postprocessor nelle istruzioni del controllo che si intende utilizzare. Sarebbe molto interessante saltare queste ultime fasi intermedie e pilotare direttamente il controllo ma per i motivi di cui sopra ancora non e' possibile farlo e credo che nel breve-medio termine non lo sara' ancora.
Saluti e buon lavoro
Sandro
L'attuale svantaggio pero' sta nella mancanza di uno standard di comunicazione fra il software e la schedadi controllo. Mi spiego meglio. Con l'approccio utilizzato finora non si pone il problema dello standard. L'applicazione pilota direttamente l'hardware della parallela alzando a abbassando i relativi pin per il tempo necessario. C'e' da stupirsi degli eccellenti risultati ottenuti da Mach3 e applicazioni similari considerando che di mezzo c'e' Windows.
Con i controlli USB L'applicazione non deve generare direttamente la sequenza di impulsi ma ordina al controllo di eseguire certe azioni. E' il controllo che poi, ricevute e bufferizzate le istruzioni si preoccupa di creare la sequenza di impulsi giusta che pilota gli azionamenti a valle di esso. Spostando la logica dalla applicazione utente al controllo USB, nasce un nuovo problema. Ogni costruttore di schede USB implementa (giustamente direi...) un suo protocollo di dialogo fra l'applicazione e la scheda. Ora, questi protocolli non sono documentati e questo rende difficile (anzi impossibile) scrivere applicazioni che possano sostituire o integrare il software in dotazione alle varie schede.
Ci vorrebbe un protocollo aperto o quantomeno documentato che consentirebbe a chi lo vuole fare di scrivere del soffware che poi puo' funzionare schede diverse.
Non sono un esperto di hardware e quindi non so quanta "intelligenza" sia nei controlli usb che sono disponibili oggi ma certamente ogni soluzione e' "proprietaria" e questo, come dicevo prima e' comprensibile (per le aziende che hanno investito in sviluppo) ma allo stesso tempo e' anche un freno perche' rende difficile l'ingresso di nuovi attori nel panorama CNC hobbistico e/o semiprofessionale per non parlare di quello professionale.
La vitalita' di una piattaforma sta nel software che ci gira intorno. Se scrivere nuovo software e' appannaggio solo di chi produce l'hardware il progresso sara' piu' lento e subordinato alle esigenze del produttore.
Faccio un breve esempio. Personalmente ho una certa esperienza di programmazione di interpreti e linguaggi ma nessuna di hardware. Ora, potrei in modo relativamente semplice definire un nuovo linguaggio e scrivere un programma interprete che legga la sintassi di quel linguaggio e produca come risultato una serie di istruzioni. E' quello che ho tra l'altro gia' fatto ma il risultato finale attualmente e' un file APT-CL che poi viene tradotto dal postprocessor nelle istruzioni del controllo che si intende utilizzare. Sarebbe molto interessante saltare queste ultime fasi intermedie e pilotare direttamente il controllo ma per i motivi di cui sopra ancora non e' possibile farlo e credo che nel breve-medio termine non lo sara' ancora.
Saluti e buon lavoro
Sandro
More Maiorum
- g_federico_g
- Senior
- Messaggi: 723
- Iscritto il: mercoledì 31 ottobre 2007, 13:53
- Località: Termoli
Re: Cncontrol by Melino65
Ciao Melino
Il software lo sviluppi/aggiorni ancora ?
Lo vorrei provare !
Grazie.
Il software lo sviluppi/aggiorni ancora ?
Lo vorrei provare !
Grazie.
Motoclub - www.roadeaters.it - Motoclub
- g_federico_g
- Senior
- Messaggi: 723
- Iscritto il: mercoledì 31 ottobre 2007, 13:53
- Località: Termoli
Re: Cncontrol by Melino65
L'installazione Ok.
La mia CPU è un PIII 664 Mhz con 384 Mb di RAM. Con il test CPu mi da 1500 Step/min.Un Piccolo Pc dedicato solo al cnc (con Mach va alla grande).
ho impostato gli stessi valori si mach per STEP - Dir- velocità - Accel. - rampa - ma:
(E' un problema riscontrato anche da altri utenti) muovo gli assi in direzione -X, premo il tasto per andare in direzione +X, ma si muove in -X, Premo -Y, mi va ancora in -X, ripremo -Y va in -Y, premo +Y, va in -Y e cosi via ...
cosa posso fare ?
Motoclub - www.roadeaters.it - Motoclub