Ciclo di uncoupling

[leogrd]

ciao

ho una domanda relativamente a questa funzione.

su decoder esu, c’è possibilità di configurazione in modo tale da renderla indipendente dalla direzione di
marcia?

ovvero che la direzione di push e pull siano sempre le stesse indipendentemente dal posizionamento del throttle.

sulle istruzioni non mi sembra di aver letto nulla ma sicuramente posso sbagliare

spero di essere stato chiaro

grazie in anticipo a chi vivrà rispondermi

un saluto


Sent from my iPhone using Tapatalk

[Marco Fornaciari]

Stando alla tabella di configurazione e delle funzioni pare che forse si possa fare.
Al momento ho verificato solo in locale con i software Lokprogrammer e Decoderpro: se li hai, apri la cassella che abbina il tasto funzione al ciclo uncupling e aggiungi/modifichi le condizioni che ti interessano.
A livello di CV pure e scritte singolarmente, dovrei farla e memorizzarla poi vedere, manuale alla mano, quali CV ha cambiato della 256 in avanti. ** Ma direi che ci riesci anche tu.
Ma poi bisogna provare, perché piuttosto che una forzatura del senso di marcia della manovra; ho il dubbio che sia un vincolo, cioè la manovra si fa solo se attivo quel senso di marcia, e se tanto mi da tanto al 51% è così.
Se puoi prova, io quasi certamente non riesco prima di domenica pomeriggio.

Effettivamente nel manuale ESU non sono spiegate più di tanto tutte le possibilità di configurazione dei decoder, ma usando Lokprogrammer o Decoderpro, cliccando nelle caselle delle tabelle di configurazione si aprono le finestre con tutte le possibili condizioni associate a: tasti funzione, uscite, e altri stati interni del decoder.
C'è da prendere atto che a spiagare tutto per filo e per segno, poi il manuale diventa di centinaia di pagine.

**
Così per la cronaca.
A parte avere la DR5000 usata con telefonino/tablet e PC, piuttosto di mettermi a compilare a mano una tabelle di CV e poi trasferirla al decoder una per una nel 2022 ... ritorno all'analogico puro.
Per ora lo ho solo provato su tre locomotive senza gancio comandato, non né ho; ma in verita il ciclo si può usare anche con gli sganciavagoni tra le rotaie, basta azionarlo prima di lanciare il ciclo uncupling.

[leogrd]

grazie Marco

si sono con lokprogrammer..fare senza ormai è impensabile

ho provato modificando le condizioni sul mapping ma l’unico risultato ottenuto è che in una delle due direzioni il comando non viene eseguito.

ergo.. credo che l’unica via sia forzare la direzione di marcia attraverso il software

magari se ti va di provare e ci riesci fammi sapere

un saluto


Sent from my iPhone using Tapatalk

[Marco Fornaciari]

Ciao Leogrd,

di fatto sei arrivato alle stesse mie conclusioni, e hai confermato che prevale il senso di marcia impostato con il tasto dedicato.
Ho riguardato anche tutte le possibili combinazioni logiche e di comando del motore, e il risultato è:
- non è possibile inviare nessun comando al motore con i tasti funzione,
- con i tasti funzione al momento riscontro che si può solo comandare il ciclo di uncupling
- i parametri del motore sono solo quelli inerenti velocità e rampe
- il motore si comanda solo con i tasti dedicati e la manopola (o barra) del set di velocità.

Per scupolo ho riguardato anche i decoder Zimo, non si sa mai, ma le possibilità di configurazione di questi decoder sono inferiori e più vincolanti degli Esu; altri decoder non li ho.

Ciao
Marco

[Zampa di Lepre]

Permettete...
Ma perché non proviamo a fare il contrario...
Ovvero capire quale è l'esigenza e vedere se si può risolvere in qualche modo (anche al di là del ciclo di uncoupling)?

[Marco Fornaciari]

Parliamo di decoder ESU V5, versioni precedenti non né ho.
Beh, Zampa, direi che non sbaglio se affermo: comando con un pulsante Fx il ciclo di uncupling e contemporaneamente scelgo il senso di marcia della manovra.
Quindi poi uso due pulsanti per comandare il ciclo di uncupling, uno per senso di marcia: all'atto pratico è solo un gradevole automatismo (anche solo per i pigri ).
Ora il senso di marcia della manovra lo si deve decidere a priori con i relativi tasti specifici, tale scelta è prioritaria rispetto a tutto il resto.
Di fatto può essere utile quando ci si diverte a fare manovre di composizione e scomposizione senza sella di lancio (a trovarla su un plastico), o quando sul carro c'è scritto "vietate manovre a spinta"
Ma direi che bisogna fare anche altre considerazioni, ralativamente al comando del treno, che cambia in base a:
1- uso di un palmare con manopola rotativa per la marcia e la velocità *
2- uso di palmare con touch screen, qui abbiano 3 comandi, i due sensi e la barra della velocità
3- c'è anche il palmare con il potenziomentro lineare, che di fatto è come un touch screen.

Per altri automatismi, almeno quelli che fino ad ora ho programmato io, si può fare, es.:
F2 = mezza velocità, annullamento rampe, luci bianche fronte retro accese
F3 = mezza velocità, annullamento rampe
F4 = annullamento rampe
F7 = comando terzo faro secondo senso di marcia con locomotiva in movimento e luci accese, ma comandi da F2 non attivi.

* Onestamente in questo caso, non avendone, non so come funziona la cosa all'atto pratico, anche sul plastico sociale avendo la Z21 uso il mio tablet ex telefono.

[Zampa di Lepre]

Marco se questa è la tua necessità ... come dici tu sarebbe solo un comodo (ma non ne sono per nulla convinto) automatismo...

... però, in realtà, le necessità che vorrei conoscere sono quelle di Leogrd, estensore del topic ... perchè ho la netta sensazione che le sue motivazioni siano altre rispetto a quanto da te "interpretato".

Detto ciò un poco di teoria: su nessun decoder mi risulta ci sia possibilità di decidere la direzione in base ad uno o più tasti funzione... questo per due motivi:
1) nel sistema DCC i comandi di direzione e velocità sono prioritari rispetto a tutti gli altri e legati direttamente al connubio controller/decoder (il primo comanda il secondo esegue);
2) se fosse possibile fare una cosa del genere di fatto sarebbe come cambiare il comportamento del decoder in corsa ovvero il controller dice di andare "avanti" (per esempio) ma all'improvviso al decoder, tramite un tasto, arriva il comando di reagire al contrario ... a parte i problemi di marcia qualora il comando tramite i tasti fosse prioritario rispetto al controller la direzione indicata da questo sarebbe inconsistente con quella reale.

Da cui una certezza: una doppia possibilità di comando porta solo ad un gran casino e a molto probabili errori di manovra durante l'esercizio.

In Esu, come in altri decoder, la direzione di marcia e lo stato (fermo o in moto) sono invece "condizioni", come i tasti premuti sul controller, per attivare o meno uscite o funzioni... quindi una logica cause--->effetti che non puo ammettere il potenziale loop in cui il "cambio di direzione" diventi anche una "causa" (e non penso di doverlo io spiegare a te che sei un esperto di automazione).

Aspetto con ansia il contributo di Leogrd ...

[Marco Fornaciari]

Oddio, che sia una comodità è effettivamente soggettivo.
Che il decoder funzioni in certo modo è chiaro, così com'è chiaro che solo pochi decoder sono così "performanti". (Al momento non considero quelli non presenti sul mercato italiano, e quelli dei quali ho trovato solo manuali in tedesco.)
Che la manovra di sgangiamento debba iniziare a treno fermo è palese, come cautele nelle condizioni di esecuzione si può sempre mettere anche lo stato di Stopped: cosa che devo provare, anche per essere certo che non appena la loco si muove il ciclo non venga annullato. Effettivamente non ho ancora verificato se già d'ufficio il comando non venga accettato se il treno è in movimento, il contrario forse l'ho provato.

Tra l'alto non ricordo se ho testato completamente gli automatismi che ho presentato nel post precedente: il caso di F2 è palese che debba iniziare dallo stato di Stopped, devo metterlo come condizione.
Così come ho già abilitato il terzo faro solo con le altre luci anteriori accese e locomotiva in movimento ma non in manovra (a questo link chiarimenti o/e coriosità http://www.forum-duegieditrice.com/view ... 0&start=15 )

Che alcuni comandi che attivano dei cicli automatici in qualsisi automazione, alla fine generino dei lopp o debbano annularsi a vicenda è a volte necessario, ovviamente sta a chi editta gli schemi di cablggio e i software porre la massima attenzione, in alcuni casi si usa attivare i movimnti solo se due operartori danno start da due postazioni differenti in piena vista, ovvero è prevista una password.

Va anche riconosciuto che nei trenini, e in altre apparecchiature, l'edizione del SW è quasi sempe demandata a informatici puri (quindi privi di altre conoscenze necessarie) che spesso si dimenticano degli interblocchi, ovvero con la manovre incopatibili si spegne tutto, se nel TV è solo una seccatura, in altri ambiti è pericoloso.

[Senialas]

La manovra di sgancio viene effettuata anche a loco in movimento (ESU).
Quindi prima bisogna fermare la loco con il verso di marcia opposto a dove sono i rotabili da sganciare. Poi si lancia il ciclo di sgancio.
Scusa poi: se metti come condizione il treno in stop, come fa la loco a togliere tensione sui ganci (muovendosi in spinta) e ad allontanarsi poi con il gancio sollevato?

[Marco Fornaciari]

Sempre decoder Esu V5
Rapida prova prima di cena.
Il comportamento è anomalo.
1- Gli stati Moving e Stopped non paiono fratelli: il terzo faro è condizionato dallo stato Moving accenedendosi solo con motore in marcia: lo ritengo corretto, a parte essere quello che desidero.
2- Lo stato Stopping condiziona il comando uncupling impedendone lo start: potrebbe starci.
3- Con motore in marcia il comando uncupling è accettato ma non eseguito, appena il motore è a zero giri il ciclo uncupling avviene: non va bene.

Le prove le sto eseguendo con il pannello di comando PC di Decoderpro, ma temo che nell'ultima versione ci sia qualche finzionamento anomalo nei tasti, poi provo anche con il palmare e la APP Z21 e il pannello su PC proprietario della DR5000. Tra i due pannelli su PC ho già notato in precedenza delle differenze di comportamento, migliore il DR5000.

Lo stato Moving pare proprio che dica se il motore gira o no: nelle condizioni ha senso, vincola la fatto che il motore giri e quindi la loco sia in movimento.
Lo stato Stopped pare dica stai fermo: nelle condizioni non ha senso, blocca qualsiasi comando in qualsiasi momento.

[Marco Fornaciari]

Risultato prove notturne.

Comandi da PC con pannello Decoderpro e DR5000, e tablet con APP Z21.
Precisazione: i tasti del pannello DR5000 funzionano tutti come interruttore e non sono configurabili (almeno non ho trovato nulla) i pulsanti di Decoderpro e APP Z21 sono configurabili come interruttore (defaut) o pulsante; altri terminali non li ho quindi non so.

Il decoder è statto configurato con Decoderpro, e corrispondono tra di loro la tabella "mappa funzioni" e la tabella delle singole CV 16.3.257-511, che sono aggiornate in simultanea e automaticamente.
Esportando le CV in file .csv la CV 16.3.449 risulta la valore: 1, 2, 4 in base alla scelta fatta.

Provando a fare in locale la stessa configurazione con Lokprogrammer ultima versione (non ho l'hardware artt. 53451 o 53452), per le CV di cui sopra non c'è aggiornamento simultaneo delle due tabelle.
In entrambi i casi è si crea la stessa configurazione con le stesse modalità (anche se per es. Stopped diventa Stop).
Esportando le CV in un file .txt la CV 16.3.449 risulta al valore zero, e non a: 1, 2, 4 in base all'impostazione.

La condizione Stopped funziona per gestire le luci (posso testare solo le luci per avere un riscontro visibile): a motore fermo le luci si accendono, come il motore gira le luci si spengono.
Allo stesso modo sulle luci funziona la condizione di Moving.

Il ciclo uncupling come condizione, oltre al tasto Fx, accetta l'unicità del senso di marcia, la condizione di Stopped impedisce l'esecuzione del ciclo, la cosa non ha molto senso, anzi si perde una condizione di sicurezza.

Ma bisogna stare attenti alla configurazione del tasto funzione:
- se programmato come interruttore resta memorizzato, pertanto a fine manovra va ripremuto per annullare il comando, diversamente alla prossima fermata da marcia normale la manovra di sgancio è ripetuta
- se programmato come pulsante bisogna tenerlo premuto fino a fine manova, diversamente il ciclo si annulla.
Da ciò deduco che il ciclo di uncupling ha già un suo modo di funzionare, non completamente noto, e non accetta condizioni a parte il tasto funzione e il senso di marcia predefinito dai normali comandi di marcia: direi che questo è un bug da segnalare a ESU (eventualmente provo a scrivere qualcosa di comprensibile una volta tradotto).