emc_traj_set_teleop_enable

[ross]

Buonasera a tutti,
durante l'esecuzione di un banale programma emc2 2.4.6 (axis) mi scrive "Impossibile eseguire il comando (EMC_TRAJ_SET_TELEOP_ENABLE) in modalità  automatica con l'interprete in stato libero".
Che significa?
Ho cercato info in rete ma non ho capito un granché di che si tratta e quindi ho fatto delle prove.
Ho testato il programma con il pc che ho in laboratorio e settando tutto come per il pc della macchina (tranne gli ingressi degli switch dei finecorsa perché non posso collegarli) e funziona correttamente, l'ho riprovato più volte e ogni volta funziona correttamente con quel pc, in azienda invece non c'è niente da fare, esegue fino ad certo punto e poi non va più avanti, se tolgo invece M7, M8 e M9, il listato viene eseguito fino alla fine ma così non posso utilizzarlo.
Che può essere?

Grazie.
Ross

[billielliot]

Ciao ross,

domanda ardua (per me!)

l'unico posto dove ho trovato qualche info e' nel manuale dello sviluppatore (in teoria concepito per chi scrive il codice che costituisce EMC2 o per i piu' curiosi).

Primo suggerimento/domanda: usi la stessa versione di EMC2 in entrambi i computer?

Altra domanda: quando esattamente genera l'errore? In fase di Homing? in fase di avvio del programma? Durante l'esecuzione del programma?

Eventualmente prova a eseguire il programma riga per riga in modo da capire a quale riga del Gcode genera l'errore (la riga precedente e' quasi sicuramente quella imputata.)

A te la palla (scotta!!).

Ciao

Mauro

[ross]

Ciao billielliot,
ti ringrazio per la consulenza e vengo subito al dunque.
1) entrambi i pc usano emc2 2.4.6, quello che ho in lab è un P3 550MHz con 384Mb di ram e non da nessun problema, l'unica particolarità  è che non ho configurato gli ingressi per i finecorsa, il resto è tutto uguale.
In azienda c'è un P3 800MHz con 512Mb di ram, raramente salta fuori all'avvio di axis il msg che dice di ricontrollare il tempo di latenza, poco fa ho visto anche i tempi di latenza della ram e li ho visto che erano settati male, poi ho riprovato ad avviare più volte axis e quei messaggi sembrano spariti. (boh, forse domani ci sarà  una nuova smentita!)
2)L'homing lo fa correttamente, durante l'esecuzione del programma viene fuori il messaggio "Impossibile eseguire il comando (EMC_TRAJ_SET_TELEOP_ENABLE) in modalità  automatica con l'interprete in stato libero" e dopo aver eseguito correttamente il primo M9, mentre esegue un G0 Z30.000 (leggo le coordinate Z che da 5.000 che di prima inizia a scorrere fino a 5.896 e si ferma, il motore Z si muove un attimo e poi niente). Togliendo gli M7, M8 e M9 il programma viene eseguito completamente. (cmq allego il listato e configurazione cnc)

Oggi, in tarda mattinata e durante le innumerevoli prove e test, sono andato su "visualizzare" dal menu di axis e poi ho settato una delle due ultime righe (alla loro destra c'è #) e il programma viene eseguito correttamente fino alla fine, l'ho eseguito 3 volte per scetticismo e per 3 volte ha fatto tutto per bene ma nel primo pomeriggio (il pc l'ho spento, pausa pranzo e poi riacceso dopo) quando volevo proseguire nei test con il resto che devo montare sulla macchina, il programma già  non andava più e il problema si è ripresentato nella solita e identica sequenza.

Sto pensando anche all'hd del pc, se ha qualche difetto di tempistica perché questa sera mentre ho lasciato il pc a misurare il tempo di latenza e dopo che il monitor è andato in stand-by (schermo nero e al tocco dei tasti chiede la password di accesso) il tempo max base è schizzato sopra i 2500000ns, normalmente quando avevo fatto il test il tempo base non ha mai superato i 16000ns, neanche quando aprivo un file pdf o gedit.
Devo dire anche che il pc quando lo spengo si spegne da solo, quello che ho in lab invece non lo fa da solo.
Di sicuro ci sono troppe variabili e non riesco a isolare il problema.

..dimenticavo, ho provato a sostituire M8 con M.. relativo all'avvio mandrino orario (ho cambiato anche la configurazione del pin relativo) e idem, poi sul tardi di stasera ho perfino aggiornato emc2 alla 2.4.7 (nella videata di avvio ci rimane sempre scritto 2.4.6 ma non so perché, il gestore delle installazioni dice che ora c'è la 2.4.7).

Ciao
Ross

[billielliot]

Ciao ross,

un problema alla volta.

Spegnimento automatico del computer: e' gestito da un processo che si achiama ACPI. Quando EMC2 si installa disabilita questa funzione (spegne l'ACPI) perche' crea problemi al corretto funzionamento del real-time. Il computer che hai a casa si comporta correttamente (per spegnerlo devi premere il pulsante). Se il computer del lavoro si spegne automaticamente , l'ACPI e' ancora attivo (e non e' una buona cosa). Molto probabilmenbte il valore spropositato durante il latency test viene generato dall'ACPI.

Latenza: non e' riferito alle memorie RAM. Per correggere il problema puoi provare a aumentare il valore "BASE_PERIOD" che trovi nel file ".ini". Prima di fare questa modifica ti suggerisco di eliminare il problema ACPI. L'ACPI potrebbe essere la vera causa della latenza (e fino a quando sara' attivo non potrai averne conferma).

L'unico modo che vedo per provare a eliminare l'ACPI e' reinstallare EMC2. Se conosci altri metodi ben venga (e non mi stupirei se con la reinstallazione si risolvesse anche l'altro problema).

Personalmente non farei altre modifiche fino a quando non si risolvera' questo problema (anche se mi rendo conto che le priorita' in produzione sono ben diverse da quelle dell'appassionato).

Ciao

Mauro

[ross]

Ciao billielliot,
per l'acpi ne avevo il sospetto, avevo letto in giro qualcosa al riguardo e quindi stamattina ho fatto così:
1)ho disabilitato dal bios l'ACPI,
2)test emc2 con il solito programma da eseguire, funziona fino alla fine e lo eseguo per un paio di volte ancora,
3)spengo e riaccendo il pc per vedere la "normalità " delle operazioni,
4)nuovo test emc2 con il solito prog ma già  non funziona più e si ferma dopo l'M9, va a Z5.872 e poi stop con quel messaggio,
5)rieseguo il test, e si ferma di nuovo a Z5.764.
6)avvio il latency test e poi copio la cartella della configurazione della cnc in un pc connesso in rete tramite lan e poi vado a leggere il valore, mi da 1008746ns.
7)chiudo Latency test e riavvio emc2, mi viene fuori il msg che mi dice di andare a vedere da terminale con dmesg e vedo che qualcosa non quadra (allego il file).
8 )Pensando che l'ACPI, all'atto dell'installazione del s.o., ha causato qualcosa che non va correttamente ho reinstallato tutto ubuntu 10.04 formattando il pc, riconfiguro tutto (anche questo pc monta una scheda video ATI, non integrata nella mb) perché dopo l'installazione RTAI non viene avviato/installato bene (nel pc in laboratorio ho fatto tutte le stesse operazioni ..scheda video ATI ..RTAI da attivare ecc. ma li funziona bene!) e poi rifaccio la configurazione copiando la cartella che avevo messo da parte nel pc connesso in rete.
9)rifaccio il test (emc2 2.4.3 del cd) con il solito programma da eseguire ma si ferma sullo stesso punto.
10)aggiorno emc2 alla versione 2.4.7 e rieseguo il test ma niente da fare.
11)aggiorno RTAI, sempre dallo stesso gestore di aggiornamenti come per il punto 10, riavvio e rieseguo il test ma niente da fare, si ferma in quel punto.

Ora mi viene in mente che dato che questo pc (P3 800MHz) è stato fermo alcuni anni, forse la batteria interna nella mb non mantiene correttamente i settaggi, ho avuto in passato un problema simile e devo verificare..
Nel frattempo ho rimediato un altro pc, un athlon xp da 2GHz con 640Mb di ram e voglio installarci tutto da capo così posso capire se è un problema di pc o di programma o di emc2.

Grazie ancora.
Ciao
Ross

[billielliot]

Ciao ross,

di solito il fine-vita della batteria del bIOS viene segnalato alla partenza del PC ("CMOS checksum error").

In ogni caso, considerato che hai la possibilita', fai la prova di sostituire il PC e verifica se il problema sparisce.

I primo test da fare e' il latency. Se hai la possibilita' eseguilo per tutta una notte. Se non passa non perdere tempo con quel PC.

Facci sapere.

Ciao

Mauro

P.S. eventualmente (se hai tempo, voglia e modo) prova a sostituire ATI con Matrox.

[ross]

Ciao billielliot,
oggi ho fatto nuovi test ed ho isolato il problema.
Ho testato in totale 3 pc, compreso quello "di sempre".
- Pc Athlon XP 2000+ con 640Mb di ram + scheda video S3 (non so il modello di preciso)
Il latency test dava numeri allucinanti, esagerati al solo movimento di trascinamento della finestra "Latency test", ho voluto ugualmente installare ubuntu 10.04 e fare il test programma: esito negativo, al solito punto si ferma l'esecuzione.
- Pc Core 2 duo, 1Gb di ram e scheda video+lan integrata su MB: ero scettico sulla scheda video integrata per via dei tanti problemi che ho letto in giro ma.. il latency test già  da ubuntu avviato in live sembrava un sogno, non ha mai superato i 9800ns e in qualsiasi situazione dove negli altri hanno dato valori di gran lunga fuori quel pc li ha un ottimo funzionamento. Ho fatto tutto quanto da live ma il problema si è ripresentato allo solito punto di esecuzione. Ho modificato il listato scrivendo G00 al posto di G0 (lo so, è inutile perché il comando è uguale, l'ho fatto dal comando "modifica" di emc2 e senza chiuderlo) e il programma una volta ricaricato ha funzionato fino alla fine, senza intoppi. Ho rieseguito il programma (senza toccare nulla, solo la R da tastiera per farlo partire) e di nuovo si è ripresentato il problema.
Ho rimesso su il vecchio pc perché credo che non ha nulla di anormale e poi ho rifatto la configurazione come per il pc che ho in laboratorio, cioé agli ingressi della parallela non ci sono collegati i finecorsa e come per magia ha funzionato tutto alla perfezione (cioé 5 ingressi "inutilizzati"). Non ero soddisfatto, ho spento, riacceso e ritestato il solito programma con quella configurazione li per altre 2 volte ed ho avuto gli stessi risultati, esecuzione corretta fino alla fine.
Ho rimesso i "limite massimo + home switch" ad ogni ingresso della parallela (X, Y, Z), com'era prima e rifatto il test il programma da l'errore di sempre.
Anomalia dell'errore:
dopo quest'ultimo test, senza chiudere emc2 o spegnere il pc, dalla posizione corrente macchina ho eseguito il programma passo per passo premendo la lettera T da tastiera e arrivato al punto critico il messaggio d'errore non era più il solito ma ha scritto "era atteso il segno percentuale o fine programma" (non mi ricordo più bene com'era, in concetto è quello cmq).
Quindi credo che le cose sono due: configurazione switch non corretta oppure bug di emc2.
Ricordo anche che se tolgo un paio di M7..M9 il programma viene eseguito fino alla fine con la configurazione normale con finecorsa.

Domani altri test!

Ciao
Ross

[billielliot]

Ciao ross,

non escludo un bug di EMC2. Per ora mi limito a suggerirti di tenerti caro il "Pc Core 2 duo" che ti da brillanti risultati con il latency test.

Usa quello e eliminerai i problemi legati al real-time.

Per il problema dell'arresto anomalo puoi provare a riscrivere il file a mano con un editor di testo puro (Notepad su Windows o Gedit su Linux) per eliminare eventuali problemi di caratteri strani (non visibili). Se ho ben letto il file e' stato generato in automatico da dxf2gcode.

Prova anche a iniziare e terminare il file con una riga contenete solo un segno di "percento" (%) preceduto e seguito da uno spazio bianco.

E' un piu' ma......sia mai che vuole anche questo oltre al comando M2.

Ciao

Mauro

[ross]

Ciao billielliot,
il core 2 duo l'ho riportato da chi me l'ha prestato e per quanto riguarda l'esecuzione devo dirti che a volte funziona e a volte no, sempre con il vecchio pc. Il core 2 duo è un bel pc, molto veloce e un pò m'è dispiaciuto
L'esecuzione a volte va e a volte no.
Quando non va, è sufficiente che dal menu di axis clicco su visualizza->mostra posizione.. (quella seguita dal #, sono una delle ultime due voci in basso) e una volta fatta ripartire l'esecuzione, il programma viene eseguito completamente. Basta che avvio emc2, faccio l'azzeramento, carico il programma da eseguire e l'esecuzione si ferma al solito punto, cambio la visualizzazione.., faccio ripartire il programma e va tutto come dovrebbe ma non sempre funziona così, è capitato che facendo quelle operazioni di cambio visualizzazione e poi invece di quel messaggio viene fuori che manca il simbolo % ma l'esecuzione va fino alla fine. Una "sequenza" per farlo funzionare non c'è, ogni volta è un colpo di fortuna.
Boh, da come vedo sembra che emc2 non riesce a interpretare bene oppure si perde qualche valore o set in memoria, non so.
Domani riscrivo il programma con notepad e poi vedo che succede.
Vorrei provare anche con le altre interfacce diverse da axis per vedere che fa.

Grazie ancora!
Ciao
Ross

[ross]

Problema risolto!
Non lo voglio dire forte ma sembra che ho trovato l'inghippo, è il comando esterno "resume".
Questa mattina dopo le innumerevoli prove ho deciso di mettere un # davanti a "net resume.program ecc.." nel file custom.hal, giusto per vedere se crea problemi e poi ho testato con il solito programma da eseguire. Quel messaggio di errore non è venuto più fuori.
Ho rifatto il test più volte, spegnendo e riaccendendo il pc, nelle stesse condizioni ed ha eseguito il solito programma fino alla fine, senza intoppi e senza messaggi di delay da aggiustare che ogni tanto veniva fuori.
Lunedì riprovo di nuovo, non si sa mai ma se è così non ho problemi a rinunciare ad un pulsante resume esterno.

Buon weekend a tutti.
Ross

P.S. Da una breve ricerca in internet ho trovato gli esempi di configurazione per il resume ed ho visto che non è proprio come viene indicato in un altro post di questo forum.
http://www.linuxcnc.org/docs/2.5/html/h ... mples.html

[billielliot]

Ciao ross,

e' bello sapere che hai risolto.

Con tutte le prove che hai fatto mi rimane un dubbio: come hai realizzato la connessione elettrica del pusante esterno "resume"?

Riesci a postare uno schema elettrico? Anche un semplice disegno a mano (purche' comprensibile).

Ciao

Mauro

[Dino]

Problema risolto!
Non lo voglio dire forte ma sembra che ho trovato l'inghippo, è il comando esterno "resume".

Probabilmente il problema deriva da interferenze elettriche sul cavo, potresti provare a collegare il segnale ad un debounce (soluzione software) o ad un filtro passa basso (soluzione hardware) così da eliminare eventuali disturbi.

[billielliot]

Ciao Dino,

Ben riletto!!

Ciao

Mauro

[ross]

Ciao billielliot, ciao Dino,
il problema non è tanto il collegamento fisico del tasto resume perché dalla centralina non l'ho portato fuori (non c'è un cavo e pulsante esterno, sta tutto nella centralina) e poi come ho scritto nei precedenti post, bastava cliccare sul metodo di visualizzazione delle coordinate e inspiegabilmente funzionava, 3-4 volte di seguito sempre ok, ho fatto i test più volte nella stessa maniera e se era dovuto ad un disturbo sul segnale l'esecuzione del programma si doveva fermare in qualsiasi punto o momento ma non è stato così, l'esecuzione si ferma sempre dopo l'M9, l'asse Z, che in quel caso è la riga successiva in esecuzione, iniziava a muoversi.
Per il collegamento c'è una resistenza di pull-up e un fotoaccoppiatore, lavora a bassa impedenza ma è praticamente impossibile che si crea un loop con un segnale di qualche volt e oltretutto il resume viene gestito dalla centralina.

A rendere ancora più anomalo il problema è il fatto che togliendo uno dei due M9 dal programma tutto funziona regolarmente, l'M1 per la pausa non l'ho inserito.
I circuiti driver di potenza dei motori e la centralina sono schermati, come pure i cavi che portano corrente ai motori.
Forse il problema vero e proprio è dipeso da come viene settato il pin per il resume, se andate a leggere qui http://www.linuxcnc.org/docs/2.5/html/h ... mples.html troverete che per configurare i pin per avere i comandi esterni "start" "pause" e "resume" è stato indicato diversamente da quanto è stato scritto in un altro post di questo forum.
Per ora altre cause non ne vedo, dai test fatti tutto si riconduce ad un'anomalia software/configurazione.

Buona serata!
Ross

[Dino]

Ho pensato ad un problema di interferenze proprio perché dicevi che il problema si verifica dopo l'M9 (se non ricordo male) ho pensato potesse essere un disturbo indotto dall'apertura di un relay o qualcos'altro.