Obtain XY position feedback

[GGalbato]

Hi, this is my first time interacting with you and I hope I am not violating any rules. I tried to look for other discussions dealing with this particular problem but I found nothing.
I am using LaserGRBL in my university lab to control a laser engraving setup. For a project I am working on I need to obtain XY coordinates VS absolute time, I am currently using the comlog to obtain positions and I am synchronizing them using absolute time from session log.

From comlog I am using strings like this:
02604 18728860 rx <Run|MPos:12.300,14.012,0.000|Bf:34,12|FS:1000,1|Pn:P|CL:0,100|PS:2,1|ER:0,0>\r
where (I think) I can read XY coordinates after "MPos". However, I would like to obtain two things:

1. Obtain acquisitions at fixed frequency (now frequency is not constant), and possibly increasing it;
2. Obtain absolute time with each aquisition, so I can avoid to use the matlab code I wrote to synchronize the measurements.

Is there a way to do this?

Thank you a lot,
Gabriele

[arkypita]

Ciao Gabriele, sei italiano?

Se hai piacere scrivimi a info@lasergrbl.com il tuo numero che scambiamo due parole e mi spieghi meglio di che tipo di interazione hai bisogno che provo a indicarti la soluzione migliore.

Due dritte per iniziare:

1. LaserGRBL non conosce la posizione del laser in tempo reale.
2. LaserGRBL invia al controller il G-Code con i comandi di posizionamento e il controller lo esegue con una sua autonomia, solo il controller sa la posizione del laser in tempo reale.
3. Il controller invia periodicamente e di sua spontanea volontà un messaggio di stato che contiene, oltre allo stato della macchina, anche i dati di posizione, velocità, potenza. Ovviamente tra quando viene generato questo messaggio, e quando LaserGRBL lo riceve esistono degli intertempi che dipendono dalla comunicazione seriale e dal multi threading (windows potrebbe non star eseguendo il codice di LaserGRBL in quel preciso istante, ma lo farà solo un po' più tardi). ATTENZIONE: l'invio spontaneo del messaggio di stato è poco frequente, nell'ordine di una volta ogni 10 secondi, perché il microcontrollore preferisce spendere il suo tempo nel generare comandi motore accurati piuttosto che usarlo per dire al PC dove si trova il laser.
4. LaserGRBL può stuzzicare (e lo fa) l'invio del messaggio di stato con una frequenza più alta. Questa frequenza comunque non può essere troppo elevata, altrimenti il microcontrollore del laser non riesce a starci dietro. Per stimolare l'invio del messaggio LaserGRBL invia il comando "?" a cui il microcontrollore risponde secondo queste regole: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface#real-time-status-reports
5. La frequenza con cui LaserGRBL inserisce questi "?" può essere configurata sotto "Settings - Threading Mode". La modalità "Insane" è quella che garantisce la più alta frequenza (5Hz, 1 ogni 200ms) e la maggior intensività e responsività della comunicazione, inoltre con questa opzione i thread di LaserGRBL vengono fatti girare alla massima velocità garantendo una maggior accuratezza anche dei tempi misurati.
6. Quando LaserGRBL processa il messaggio di stato aggiorna la sua UI, ma prima ancora scrive nel log comlog (log della comunicazione, se abilitato) il pacchetto ricevuto con il suo timestamp relativo in millisecondi.

Ora due considerazioni:

1. Prendere i dati dal file comlog non è il massimo. Sicuramente puoi modificare il codice di LaserGRBL per ottenere qualcosa di più facile da integrare con ciò che stai cercando di fare.
2. A meno di non dialogare in tempo reale con il microcontrollore che controlla la scheda ci sarà sempre un certo margine di errore dovuto alla comunicazione e a tutto il multithreading. Bisogna capire/stimare quanto è questo errore e se è tollerabile nella tua applicazione.

Se ti serve altro appunto, fammi avere il tuo numero.