Modelli personalizzati
Modelli di ordini standard
I modelli di ordini forniti da STOLL insieme allo STOLL PPS (vedi Gestione di modelli di ordini, Modelli di ordini standard e rispettivi parametri) consentono un approccio rapido nell'utilizzo di modelli.
Un modello utilizzato per la creazione di un ticket XML
I modelli possono essere adattati al rispettivo caso di applicazione mediante:
- eliminazione di parametri
- aggiunta di parametri
- assegnazione di parametri
- blocco delle assegnazioni preliminari per modifiche durante l'applicazione di modelli, al fine di evitare errori.
- Tutto ciò che è elencato nei file modello XML in TEMPLATE_TAGS ha la funzione di generare caselle di modifica nel ticket.
- Tutto ciò che è contenuto nei blocchi CDATA, viene scritto in un file di ticket *.XML tramite il meccanismo Velocity, con l'ausilio dei dati immessi e della macro AddTag.
- Il meccanismo Velocity esegue ciascuna riga di input nel modello indipendentemente dalle righe precedentemente elaborate e cerca il riferimento specificato negli XML del modello per sostituirlo con l'immissione e scrivere le righe nel ticket. Se il riferimento è incorporato in una macro, la macro viene richiamata per creare l'output nel file XML.
Parametri nei modelli di ordini standard
Per i parametri nei modelli di ordini standard risultano formati di acquisizione differenti, aventi in comune quanto segue:
- La casella di modifica per un parametro comprende normalmente un commento tra parentesi quadre [ ]. Il suddetto commento viene rimosso quando il ticket viene generato dalla macro Velocity AddTag.
- La casella di modifica per un parametro può essere utilizzata per l'acquisizione di più elementi del parametro.
- In questo caso verranno separati da punto e virgola (;). A supporto dell'utente è possibile descrivere in un campo di commento di quali singoli elementi si tratta.
- Per parametri facoltativi che non devono essere utilizzati, occorre lasciare invariato il punto e virgola per preservare la sequenza di parametri. Nell'esempio è stato tralasciato il terzo parametro. La maggior parte dei parametri non è facoltativa e deve essere specificata non appena è compilato anche un solo parametro.
- Se non vengono fatte immissioni, il tag non verrà trasferito nell'ordine XML. Eccezioni:
- Con la macro Velocity AddTAG è possibile specificare valori di default.
I suddetti valori di default vengono incorporati nel ticket XML risultante qualora, pur essendo prevista per il parametro una casella di modifica, non abbiano avuto luogo qui immissioni. (Ad esempio IMAGE, LOGO o OP_AUTHENTICATION_NEEDED)
Esempio:#AddTAG("<LOGO>$ParamList[0]</LOGO>" $LOGO "Templates/Logo.png") - Se resta vuota la casella di modifica LOGO, al tag LOGO viene comunque assegnato Templates/Logo.png nel ticket.
- Se una riga nei blocchi ORDER_VELOCITY e CUSTOM_VELOCITY non presenta indicazioni di riferimento a una casella di modifica, la riga va a finire automaticamente nell'XML del ticket.
Esempio:<STOLL:MACHINE_INFO>
<STOLL:TC_LOAD_DATE/>
<STOLL:TC_DONE_DATE/>
<STOLL:DONE_EXECUTIONS/>
<STOLL:TC_STATE/>
<STOLL:PATTERN_NAME/>
<STOLL:CURRENT_SHIFT/>
<STOLL:USER_NAME/>
</STOLL:MACHINE_INFO> - La macro Velocity AddTAG- eseguita nel modello consente l'immissione di più parametri e del commento in una riga.
- Ogni blocco ORDER_VELOCITY e CUSTOM_VELOCITY presenta qui una macro AddTAG- separata, ognuna delle quali è attualmente identica all'altra.
- Tener presente che l'immissione non deve in linea di massima contenere caratteri di controllo XML quali <>,. Se si richiedono tuttavia questi caratteri, esistono alternative quali {}, oppure occorrerà convertire i caratteri (Caratteri speciali in XML).
- Se si applica la macro, i dati di immissione non devono contenere nemmeno ; o [, in quanto questi caratteri vengono interpretati dalla macro AddTAG come caratteri separatori.
All'occorrenza è possibile modificare la macro nel modello oppure aggiungerne un'altra che utilizzi altri caratteri separatori. - Nella tabella seguente sono riportati tre esempi di parametri TITLE, LOGO e DIMENSION del modello standard Auto Production.
- Tutti e tre presentano un commento.
- Nel caso del parametro LOGO si tratta di un percorso file per un file immagine. Esso può essere specificato in modo assoluto o relativo rispetto alla directory template.
- Il parametro DIMENSION presenta gli elementi Grandezza, Lunghezza, Larghezza, Peso.
|
Nome modello | Parametri avanzati |
Auto Production | TITLE; [Title for ticket] LOGO; [String; FilePath to Logo] : DIMENSION;;;; [Size;Length;Width;Weight]: |
Per creare modelli personalizzati:
- 322
- Ricorrere come base a un file modello Stoll.
(Vedi file XML in D:\PPS\SampleTickets\PpsTicketTemplate) - 323
- Attribuire un nome al modello, da riportare nell'attributo name del tag ORDER_TEMPLATE.
- 324
- Con il tag TEMPLATE_DESCRIPTION assegnare ai propri modelli un testo descrittivo.
- 325
- I tag che, pur dovendo essere contenuti nel ticket risultante, non richiedono immissioni, possono essere riportati stabilmente nell'intestazione, fuori dai blocchi ORDER_VELOCITY e CUSTOM_VELOCITY. Essi non rientrano pertanto nella categoria di campo standard e non vengono visualizzati.
Confrontare al riguardo come il blocco PRODUCTION_INFO sia incorporato nel modelli forniti a corredo, direttamente sotto TEMPLATE_DESCRIPTION. - 326
- Affinché sia visibile all'utente nel modello di processo, una casella di modifica deve essere elencata nel blocco TEMPLATE_TAGS.
Si differenzia in questo caso tra:
CUSTOM_TAG
Vengono qui definiti tutti i tag non rientranti negli USER_TAG.
Esempio:<CUSTOM_TAG label="LOAD_PAT_CONTAINER_COMP" editable="true">;;; [SIN;JAC;SET; Each [1||0], 0 prevents loading pattern component. Consider need of ERASE_ALL=false.]</CUSTOM_TAG>
- L'attributo label indica il nome come viene visualizzato nel modello del ticket.
- Al contempo, il nome funge anche da riferimento ($LOAD_PAT_CONTAINER_COMP) per l'utilizzo nel blocco ORDER_VELOCITY \ CDATA quando si tratta di tag dallo StollTicket.xsd.
- Per i tag dallo spazio dei nomi specificato in CustomTicket.xsd, i riferimenti devono essere elencati nel blocco CUSTOM_VELOCITY \ CDATA.
- Con il riferimento viene stabilito il rapporto con la casella di modifica. Il meccanismo Velocity cerca il riferimento e assegna l'immissione alla riga localizzata.
- L'attributo editable indica se è consentito modificare la casella di modifica.
È opportuno un blocco quando si intende specificare un valore che non deve essere modificato. - Il valore CUSTOM_TAG è costituito dal valore che si intende assegnare al tag.
- Se si ricorre in CDATA alla macro AddTag, sarà possibile utilizzare tag con più parametri che vengono specificati separati da punto e virgola.
- La macro AddTag separa il commento dai parametri (;) a partire dalla prima parentesi ([) e frammenta i parametri in prossimità del (;) in un array ParamList[].
- I $ParamList[n] possono essere ripartiti nel tag previsto in AddTag tra attributi e valore principale.
Tenere qui presente che n indica la posizione dei parametri nell'immissione a partire da 0. - Esempio:
#AddTAG("<STOLL:LOAD_PAT_CONTAINER_COMP SIN='$ParamList[0]' JAC='$ParamList[1]' SET='$ParamList[2]' />" $LOAD_PAT_CONTAINER_COMP) - Attributi facoltativi
- Per il controllo di attributi facoltativi occorre comunicare alla macro di quali attributi si tratta. Ciò viene configurato facendo precedere l'attributo da Opt[n]:. Come per ParamList, anche n deve qui corrispondere alla posizione del parametro nell'immissione.
- Esempio:
#AddTAG("<STOLL:LOAD_PAT_CONTAINER_COMP Opt[0]:SIN='$ParamList[0]' Opt[1]:JAC='$ParamList[1]' Opt[2]:SET='$ParamList[2]' />" $LOAD_PAT_CONTAINER_COMP)
USER_TAG
Qui si definiscono i tag che vengono proposti sulla macchina per feedback utente e sono elencati come dati del cliente (4).
Finestra Esempio:<USER_TAG label="Faulty pieces" editable="true">30%</USER_TAG>
- L'attributo label specifica il nome come viene visualizzato nell'elenco .
Il valore di input può essere immesso come predefinito (qui 30%).
Opportuno per il valore presumibilmente corretto, a titolo di orientamento o a scopo informativo. - A differenza del CUSTOM_TAG, lo USER_TAG non è soggetto al meccanismo Velocity e genera implicitamente con il software PPS una voce nel ticket XML.
- 327
- Convalidare i modelli nei confronti dello StollOrderTemplates.xsd prima di caricare il file modello nel PPS.
Strumento adatto:
Notepad++ e XML Tools Addin
(vedi cartella PpsInstallation\Tools\Notepad++ nei rispettivi file di installazione) - 328
- Salvare il file modello con un nome proprio che termini con ,,,OrderTemplate.xml.
- 329
- Caricare quindi il nuovo modello nel PPS.
Assegnare ai modelli un nome file e un nome modello separati.
- Se viene aggiornato il software PPS ed è stato modificato un modello standard o un file Template di modelli standard Stoll (D:\PPS\SampleTickets\PpsTicketTemplate), le modifiche andranno perse in seguito all'aggiornamento.
- I file di modelli Stoll esistenti vengono salvati tramite un aggiornamento in D:\PPS\PpsJBossServer\PpsServerInstallScripts\PpsLast\ PpsSwUsedTillSetup_....
- Le modifiche apportate a un modello standard Stoll direttamente nel PPS, si perdono quando si caricano modelli aggiornati.
- Queste modifiche potranno essere recuperate solo mediante un ripristino del database allo stato che precede la sostituzione del modello.
- Prima di un aggiornamento, leggere la documentazione allegata (Cosa c'è di nuovo?) e trasferire le modifiche importanti nei modelli.
- Le modifiche tecniche nei modelli Stoll non vengono trasferite automaticamente nei modelli personalizzati.