li ho collegati nell'hal vedo fps = 160 contro i 400/500 indicati nel manuale secondo te è normale ?

Non ho sperimentato molto con l'fps perché per i miei utilizzi di taglio poli la velocita' massima non e' critica. Hai provato a giocare coi parametri Comm Speed e fast data exchange?
Inoltre (magari dico una caxxata) se ricordo bene i 400/500 fps venivano dati per il 6 pin. Con 12 pin il frame dovrebbe essere lungo il doppio, se si tratta di quello che penso, e quindi la velocita' meta'.
Ed anche il tipo di pin configurato dovrebbe cambiare la lunghezza del frame.

Il mio in Comm speed = 12 segna circa 770 fps, sul mio pc che uso per sviluppare.
Su un vecchio portatile sempre con 12, segna 430 fps.
Comunque, per come e' sviluppata l'architettura software dell'Hal, direi che queste differenze non portano a nessuna conseguenza, non essendo messe in relazione alla massima frequenza di step da inviare ai driver(s).

Ok grazie in questi giorni ci smanetto un po' e vediamo come va, pensionare il caro vecchio mach3, mi fa una certa impressione :rolleyes:

Mi sono letto parecchia documentazione sul funzionamento 'intimo' di Mach3, per vedere anche come scrivere eventuali plug-in. Mach3 e' un vero gioco di prestigio, nel senso positivo del termine, che ha lo scopo di far eseguire ad una programma che gira su windows quello che in teoria non potrebbe fare. Parlo della generazione del timing dei motori, che necessita di un sistema operativo real-time, mentre Window non lo e'. Per fare questo il buon Art Fenerty ha fatto quello che un programmatore Windows non dovrebbe mai fare, arrivando persino a riscrivere parti di sistema operativo. Capiamoci, lo ha fatto per poter eseguire il suo gioco di prestigio, non per incompetenza, semmai il contrario.
A chi fosse interessato consiglio la lettura di questo documento: http://nv50.0fees.net/Doc/Mach3Myste...df?ckattempt=1.

Ora, con le moderne porte usb a farla da padrone e microprocessori programmabili a costi ridicoli, penso che non abbia piu' molto senso investire in questa tecnologia ormai antiquata basata su una break board 'stupida' collegata tramite porta parallela.

I pregi della soluzione Usb stanno in una gran semplicita' d'uso per l'utente (non serve piu' configurare settaggi esoterici nella porta parallela, che ormai fra l'altro non esiste piu' nei nuovi pc) e nel fatto che tutta la parte di temporizzazione e' poi lasciata al microprocessore della scheda, che cosi' fa un lavoro a lui consono e scarica il pc dal sovraccarico di lavoro a lui richiesto nel fare una cosa contro la sua volonta'-capacita' :P

Il brutto della soluzione Usb e' che porta ogni produttore di scheda o break board che sia a scrivere un proprio protocollo di comunicazione, generalmente piuttosto complesso. Quindi ogni scheda avra' in generale un proprio software di comunicazione/interfaccia. Quando si e' fortunati il progettista della scheda distribuisce anche un'applicazione (detta HAL: Hardware Abstraction Layer) che si occupa delle cose complesse che riguardano la comunicazione con la scheda, ed espone al programmatore dell'applicazione CNC una serie di funzioni e/o metodi per dare e ricevere informazioni alla scheda.
Scrivo ricevere perche' non e' sufficiente comunicare alla scheda i movimenti degli assi, ma e' anche importante ricevere informazioni quali la posizione attuale dei medesimi e ad esempio condizioni di allarme tipo fine corsa raggiunti.
L'occasione di aver fatto amicizia virtuale con Livio (padre del progetto Theremino) e la bonta' del suo lavoro (parere mio, ovvio) e' stata determinante nella mia scelta di investire da parte mia in questa architettura.
Vedremo come va a finire.