Mach3-Kflop: problemi azzeramento assi

[Pedro]

beh, mi pare che con kmotioncnc vada un po' meglio, non perfetto ma meglio. Motori bolliti? guarda, se quando ti fa il problema del rallentamento devi guardare i dro, io la macchina la sento ormai ad orecchio se va fluida o rallenta, e se i dro si bloccano un attimo il problema sta nel software e non nei motori ne nei driver.

Un altro pc fa uguale? è da pensarci su

[walgri]

Arm, La settimana prox porto su anche l'altra kflop.

[arm]

Ok. Mi fermo qui. Nel frattempo vi ringrazio.
Magari vedo di riformattare più a fondo i pc.
Poi aggiornerò.
Ciao

[walgri]

Pedro, guarda quest'altro video di Arm: https://www.youtube.com/watch?v=YERB3iM84N0
Mostra chiaramente che i DRO di mach3 si fermano ogni tot.

[Pedro]

si, va a singhiozzo proprio come se ci fossero dei task di sottofondo ma non capisco cosa e quali.

Comunque se ci vai dai una pulita a quell'init facendolo snello e semplice, magari senza quei DoPC che forse, e dico forse, rallentano

[walgri]

Il sistema operativo di quel pc è XP appena installato, più "vaniglia" di così non si può, neanche io riesco a pensare cosa potrebbe esserci che lo blocca.

[Pedro]

bisogna vedere su "gestione" attività di wndows che risorse vengono "succhiate" dalle applicazioni. Comunque io una configurazione proprio base base la farei tanto per muovere i motori

[walgri]

Si si, nell'init.c lascio solo le definizioni degli assi.
Poi provo con gli altri pc - anche con l'EEEPC alimentato a batteria.
Poi provo con l'altra KFlop
Poi metto i drivers in enable permanente con i ponticelli, ma, dopo aver rivisto che i dro si piantano anche in Mach3, dubito che sia una prova che darà qualche indicazione. Cionondimento va eseguita.

[Pedro]

se arm ha voglia di fare un'altra prova:

usando sempre il file spirale3d, almeno sappiamo che file stiamo usando, prova a togliere dalla prima riga il comando G40.1 e, da mach3 sulla pagina port e pin, l'ultima opzione quella del mill option, prova anche a togliere la spunta su advanced compensation analysis, sempre riguardante la compensazione di g41 e g42 e vediamo se qualcosa cambia

[arm]

Si si Pedro, stasera faccio subito la prova; ho detto che mi fermavo qui per non abusare della vostra pazienza.
Inoltre provo a ripulire un mio notebook e provare anche con quello.
Vedo dall'orario in cui scrivi che ti facci perdere il sonno

[Pedro]

non perdo il sonno, solo che a volte la sera cado tipo "pera cotta" e poi la mattina mi sveglio più presto del solito, che già normalmente è presto.

Non preoccuparti della pazienza, io per quel che posso aiutare l'ho sempre fatto volentieri. La prova è per togliersi gli scrupoli più banali

[arm]

Macche', tutto uguale.
Questo è il task manager con i processi in corso

[walgri]

Aggiorno un pochino questo topic con una notizia, se non buona, neanche brutta brutta.

Ho caricato tutto su un miniportatile EEEPC, KMotion 4.32, Mach3 Version R3.043.066, ho tolto dall'init.c tutto quello che non riguardava direttamente la definizione degli assi, e impostato le LimitSwitchOptions a 0x100 perchè la KFlop è sulla scrivania, sola soletta e alimentata dalla USB del computer.

Ho caricato anche la configurazione K2.xml che Arm ha pubblicato qualche pagina fa. Al quale ho cambiato l'impostazione ActiveLow dell'Estop.

Il risultato è che mentre Kmotioncnc esegue la spirale 3d senza fare una piega (almeno questa è la mia impressione guardando le coordinate che cambiano nei DRO) in Mach3 inizialmente erano presenti le orribili pause che Arm ha documentato.

Inizialmente.

Ho notato che le interruzioni sembravano avvenire con una certa regolarità rispetto alla lunghezza del percorso: verso il centro dell'ellisse avvenivano dopo qualche giro, in periferia solo circa un giro.

Quindi mi è venuto un dubbio e sono tornato nella configurazione del plugin ed ho modificato il Windows Buffer ahead time e l'ho portato da 3 secondi a 0.5 secondi. Ora vedo cambiare le coordinate in modo fluido, senza interruzioni, nei limiti della mia percezione ovviamente.

Per prova ho provato a impostare l'ahead time a 10 secondi e le interruzioni erano anche più frequenti.

Quindi, per prima cosa consiglio Arm di provare a cambiare quel parametro (nel dialogo di configurazione del plugin è proprio sotto il logo Dynomotion) e riportare qui se qualcosa cambia.

Secondo me il nocciolo della questione è a livello di comunicazione usb, Pedro, se sei in ascolto, che ne pensi ?

[walgri]

Aggiungo che osservo il medesimo comportamento anche su un portatile HP core i5 più recente.

[arm]

Ieri avevo provato con un portatile ripulito a fondo, tutto uguale.
Domani, anzi oggi, provo come dici. Però anche con kmotioncnc la spirale 3d aveva qualche sussulto.

Dai riprovo e aggiorno. Thanks