Progetto on-line

[Luca Bettinelli]

Perchè dovrebbe essere illegale???

Per programmare i PLC siemens devi acquistare un software della Siemens che è soggetto a licenza, quindi questo presuppone la possibilità di non utilizzarlo, altrimenti il software sarebbe allegato al PLC.

Inoltre do per certo che esiste una software house tedesca che vende un software che si chiama PG2000 che permette di programmare i plc Siemens S5 ed S7 che ovviamente viene venduto a caro prezzo e non è Siemens.

Inoltre se non sbaglio esiste una cosa simile sul mercato Americano.

Voi cosa ne pensate ??

Ho trovato anche il link http://www.process-informatik.de/down.htm

[Federico Milan]

L'idea sembra buona, putroppo come reperire informazioni ?!?

Fare un compilatore non è poi così difficile, soprattutto se l'archittetura è abbastanza semplice come lo è (almeno credo) quella del PLC, forse bisogna stare attenti ad alcune gestioni ... del resto lo gcc è uyn esempio di come un unico compilatore possa essere usato per molte piattaforme, ovviamente non so da dove partire ... ma se qualcuno lo conosce si fa presto a implementare qualcosa ... sempre che si conosca il linguaggio macchina del PLC ...

ma per comunicare ?!? il protocollo come lo si trova ?!?

ciao

[ifachsoftware]

Si puo' fare , il problema e' cosa ...

Un saluto al forum

[elettrodino]

Mi ha sempre allettato l'idea di poter creare un un programma che potesse funzionare

su piu' marche e modelli di Plc .

Ovviamente mi rendo conto delle enormi differenze (anche solo tra modelli stessa marca ecc...) pero.... varrebbe la pena di valutare qualche idea.

Avevo scaricato (e mai usato) un software per la programmazione basato sugli

"stati finiti" che poteva essere portato su piu' piattaforme.

Penso che potrebbe interessare a parecchie persone implementare un sistema

multipiattaforma e magari "riusabile" su altre applicazioni.

Purtoppo non ho grandi capacita' tecniche , pero' se vi serve "manovalanza"

sono a Vs. disposizione.

[Livio Orsini]

Considerazioni sulle problematiche relative al progetto on line

Di seguito tento di riassumere ed evidenziare le problematiche emerse dalle discussioni relative a come e cosa realizzare con il nostro progetto on line.

I due problemi principali da risolvere sono: cosa deve essere progettato - realizzato e le modalità da impiegare per la reralizzazione. Le risposte ai due interrogativi sono strettamente interdipenti.

Cosa dobbiamo realizzare?

Io penso che prima di tutto dobbiamo decidere le finalità del nostro progetto. In altre parole è indispensabile che decidiamo se il nostro lavoro dovrà avere una possibile, e auspicabile, applicazione professionale-industriale, oppure dovrà avere esclusivamente finalità didattiche e propedeutiche.

Un altra questione non banale da definire è la complessità del progetto stesso.

Se decidiamo di realizzare un progetto con uno scopo didattico o dilettantistico, ed il termine dilettantistico va inteso nell'accezzione che si richiama al puro piacere, possiamo dedicarci a sviluppare, in modo anche velleitario, qualsiasi dispositivo che, di comune accordo, riteniamo più gratificante per le nostre personalità.

Al contrario, se decidiamo che l'obbiettivo finale del nostro progetto dovrà essere un'applicazione industriale, dovremo effettuare una scelta molto oculata dell'oggetto del nostro studio.

Personalmente sono convinto che sia necessario proporci come scopo del progetto un'applicazione industriale. Anche con questo obbiettivo potremmo comunque trarre piacere ed utili esperienze dal nostro lavoro.

Con questo vincolo la scelta del dispositivo da realizzare ha limiti molto stretti. Da un lato abbiamo le limitazioni imposte dalle difficoltà oggettive per lo studio e la realizzazione di progetti troppo ambiziosi, da un altro lato dobbiamo considerare che alcuni dispositivi sono prodotti da una miriade di costruttori grandi, medi e piccoli, ed il nostro lavoro finirebbe per perdersi nel mare magno della produzione inflazionata. A titolo di esempio consideriamo la realizzazione di un termoregolatore. Potrebbe essere un prodotto interessante perchè può essere realizzato con una varietà di prestazioni, applicazioni e opzioni pressochè infinite; purtroppo sul mercato esistono miriadi di prodotti similari, con ottime prestazioni e prezzi veramente bassi, tali da rendere una nostra realizzazione solo un esercizio più o meno piacevole.

Una considerazione analoga potremmo farla per dispositivi tipo azionamenti in cc o in ca, con l'aggravante delle notevili difficoltà realizzative, teoriche e pratiche, che la realizzazione di simili dispositivi comporta.

La realizzazione di un PLC, magari basato su schede tipo PC, con sistemi operativi embedded tipo Linux embedded, QNX o altri, offre maggiori possibilità di successo sulla carta. L'ostacolo maggiore consiste nel trovare un'azienda disposta ad applicare il nostro dispositivo. Inoltre i costi di sviluppo che un simile dispositivo comporterebbe non sono trscurabili. Oltre al costo dell'hardware si pensi a cosa verrebbe a costare lo sviluppo del software, perchè non è proponibile, a livello industriale, un PLC che venga programmato in asembler o in "C".

Io seguo da tempo il progetto open source "math.plc", un plc basato su PC104 e Linux, ma non mi sembra che siano stati raggiunti risultati eclatanti, nonostante l'impegno diretto di alcune medie aziende e numerosi "professional".

A mio giudizio il dispositivo che, sulla carta, ha più possibilità di successo potrebbe essere un controllo assi multi asse (come proposto a suo tempo da Federico Milan). Le difficoltà realizzative ci sono ma possono essere superate abbastanza facilmente. Il campo di impiego ha numerose nicchie dove potremmo inserirci abbastanza agevolmente. Inoltre è un progetto che, a differenza di un PLC, può essere realizzato gradualmente a passi successivi. Inoltre credo che non comporti un eccessivo sforzo per dotarlo di un'interfaccia di programmazione; interfaccia che può essere realizzata benissimo con un PC ed un'abblicazione in VB o C#.

Come realizzarlo?

Le modalità di realizzazione riguardano principalmente la piattaforma Hw ed i tools Sw. Ovviamente i vincoli maggiori sono dovuti all'applicazione che andremo a scegliere. Di seguito effettuerò una breve disanima senza fare riferimento ad un'applicazione precisa.

Utilizzo di piattaforma tipo PC104. E' una soluzione che offre alcuni vantaggi non trascurabili. C'è una scelta quasi infinita di produttori e dispositivi, l'affidabiltà è sempre elevata ed i costi non sono eccessivi. Inoltre, essendo dispositive strettamente legati al mondo del PC, l'aggiornamento è costante ed i tools di sviluppo sono quelli che girano su PC. E' sufficiente disporre di un PC e di un compilatore "C" Borland o Microsoft e si può lkavorare. Gli svantaggi sono, principalmente, la necessità di sviluppare le interfaccie verso il campo. E' altrsì vero che è possibile usufruire di molti I/O già presenti sul mercato (VAGO, Beckoff, Phoenix, etc.) ma i costi salgono e la gamma non è completa.

Utilizzo di microprocessori e/o microcontrollori embedded.. Questa soluzione ha alcuni pro e contro generalizzati ed altri strettamente legati al tipo di processore scelto. Il vantaggio principale, praticamente unico, consiste che si possono ottimizzare tutte le scelte Hw; questa opzione costituisce anche uno dei limiti principali della scelta perchè tutto deve essere progettato, costruito e ottimizzato. Altro svantaggio non indifferente è il costo dei tools di sviluppo che può raggiungere anche alcune migliaia di Euro. Già l'acquisto di uno starter kit di un microcontrollore a 16 bits costa circa 200€ - 300€. E' possibile, scegliendo particolari tipi di pcontrollori come PIC o Rabbit, avere buone prestazioni con costi dei tools relativamente bassi.

Personalmente la mia scelta sarebbe orientata per un dispositivo tipo controllo assi e microcontrollore tipo PIC o Rabbit. Tra l'altro la Microchip ha sviluppato anche nuove serie di microcontrollori che superano i vecchi limiti di memoria, con prestazioni velocistiche non indifferenti, e costi dei tools molto limitati.

Come procedere?

Dovremmo per prima cosa prendere una decisione sui due punti precedenti. Definiti questi due punti si dovrà procedere alla ripartizione del lavoro tra i vari partecipanti e stabilire un piano di sviluppo con le varie attività, tempistiche e costi preventivati.

E' assolutamente chiaro che, per la quasi totalità dei partecipanti, questo lavoro è un'aggiunta alla normale attività professionale e, pertanto, la sua priorità è a livello più basso.

Chi scrive è si un professionista, ma attualmente è anche un pensionato, e le sue priorità professionali sono meno stringenti. In pratica faccio solo i lavori che mi piacciono. Pertanto, nell'incontro del 26 u.s., mi sono offerto di sobbarcarni, oltre ad una parte di lavoro di sviluppo, anche le operazioni di coordinamento dei gruppi di studio e lavoro, sempre che i partecipanti acconsentano.

Attendo i commenti degli altri partecipanti al forum, ho postato giusto di venerdì cosi durante il fine settimana spero che arrivino numerosi contributi.

[Livio Orsini]

Scusate l'intromissione, ma invece di pensare a relizzare ad un PLC compreso Hardware, non sarebbe possibile sviluppare un progetto OpenSource sul software di programmazione di un plc esistente sul mercato?.

L'idea è bella ed è anche perfettamente legale.

Il problema risiede sul come fare. Io parlo per esperienza diretta perchè l'ho fatto ed ho anche sfruttato il lavoro già fatto da un altro costruttore.

Mi spego meglio. Anni fa ho fatto, per circa dieci anni, il responsabile dell'automazione del distributore italiano di un'azienda tedesca (oltre che produttore di azionamenti). Bene con la crescita vertiginosa del cambio lira-marco i piccoli PLC non erano più molto competitivi, quindi provai a progettarne uno economico sfruttando tutte le coneoscenze che avevo dell'hardware originale. Era basato su un micro 8051. Per realizzare il tutto si dovette usare l'editor originale, tanto per rispiarmare tempo, poi realizzare una specie di macrocompilatore che traducesse le istruzioni simil AWL in altrettante macro e poi sfruttare, ovviamente il macro assembler della Intel. Il set di istruzioni non era molto esteso e neanche lontanamente complicato come il microwin, p.e., nostante ciò e con tutte le facilitazioni di conoscenza del prodotto lo sviluppo del sw ci costò oltre due mesi uomo.

Immaginate ora un PLC con un set di istruzioni medio complicato come lo S7-2xx (ovviamente non consideriamo unità del 3xx o 4xx), di cui non si conosce NULLA della CPU usata, della mappatura di memoria per non parlare del BUS e degli I/O. E' un'impresa quasi disperata.

Queste cose le possono fare aziende specializzate nel reengineering o con conoscenze molto approfondite dell'Hw in questione, come, ad esempio, VIPA che da sempre è quasi un secon source di Siemens e, nonostante la guerra ufficiale, che fanno le varie filiali Siemens in Europa, ha accordi diretti con la R&S Siemens di Erlangen!

[Gabriele Riva]

mi sono offerto di sobbarcarni, oltre ad una parte di lavoro di sviluppo, anche le operazioni di coordinamento dei gruppi di studio e lavoro, sempre che i partecipanti acconsentano.

Certamente, scusami, mi sono dimenticato di dirlo.

Adesso e' ufficiale, tu Livio, sei il coordinatore del progetto on-line di PLCforum

Ora bisogna definire cosa dobbiamo realizzare.

Avanti con i voti:

io voto per il controllo assi multi asse proposto da Federico Milan, pero' eseguito con mezzi acessibili a tutti, quindi software free ed hardware poco costosi.

[cdc]

Per me va bene.

Io riconfermo la mia disponibilità per la parte software.

Ciao

[ifachsoftware]

Vedo che da alcuni giorni non ci sono idee ...

Non e' che non importa niente a nessuno del progetto o forse hanno tutti di meglio da fare ?

Un saluto al forum

[Gianmario Pedrani]

Ciao Ragazzi scusate il ritardo ma sono tornato sabato dalla cina e ci riparto il 15 di questo mese comuncue anche io sono d'accordo sul controllo assi e do la mia disponibilita

ciaooooooooo

Complimenti per Livio che e il capo organizzatore

[Igor]

Scusate l'assenza, sono stato in trasferta per alcuni giorni e in altri ho elaborato uno scritto che è simile in maniera inquietante con quello di Livio, per cui vi risparmio la mia prosa non proprio manzoniana e andiamo avanti, sottolineo solo alcuni punti secondo me cruciali:

1) L'oggetto deve avere potenzialità industriali, questo è un forum di professionisti o aspiranti tali.

2) Il controllo multiasse mi sembra un'ottimo valore aggiunto e, se implementato sin dall'inizio, anche una scelta non troppo costosa.

3) La realizzazione su HW custom mi sembra un'altra ottima scelta: il fine del progetto è anche quello di entrare noi tutti un po' più nel merito delle tecnologie che stanno alla base del nostro lavoro, un essenziale punto di crescita.

Vorrei aggiungere anche la possibilità di avere un'interfaccia utente (Video +tasti o touch screen) integrata o su coprocessore, e una apertura alle interfaccie di campo free (CANOpen, MACRO).

Interessante sarebbe avere sul PLC un completo server TCP-IP per poterlo programmare, controllare e per avere uno SCADA su rete ethernet.

Lo sviluppo di azionamenti sarebbe interessante per prodotti dedicati al controllo e che quindi si potrebbero connettere come vere e proprie espansioni realizzando il controllo asse in un'architettura multiprocessor in cui il processore interessato al controllo asse (Il PID) sarebbe residente nell'azionamento stesso. Se si vuole usare un'altro tipo di azionamento lo stesso processore sarebbe residente su una scheda che mi fornisce i canonici +-10V ecc assieme all'ingresso encoder ecc., il tutto chiaramente connesso a un bus digitale veloce (MACRO??).

Per quanto riguarda l'HW uno dei miei numerosi fratelli mi ha fatto conoscere un prodotto che mi sembra degno di attenzione per l'autorevolezza del costruttore e su cui sto rimuginando da un po', il tool di sviluppo è free dato che si programma in Java e il costo della scheda umano, Livio se vuoi ti dò il link o ti spedisco il manuale in PDF (è grosso!), fammi sapere.

Scusate il ritardo nella mia proposta ma non ho potuto fare meglio!

Ciao!!!

[Igor]

Mi sono dimenticato di dire che la scelta di Livio come coordinatore mi sembra la più giusta!!!

[Igor]

Ecco in breve su cosa sto rimuginando: è una scheda commerciale che si chiama TINI ed è prodotta dalla Dallas.

Ha già una java virtual machine interna e sviluppata dalla Dallas stessa oltre a 512k di RAM espandibile a 4 mega, un server TCP-IP(Ethernet e Web server), l'interfaccia per un bus di campo economico come 1-wire sempre della Dallas (comando di attuatori "lenti" come EV o sensori di cilindri idraulici o pneumatici, finecorsa non di assi controllati ecc, in rete c'è gia un progetto di una scheda, da industrializzare) 2 porte CANOpen, fino a 4 seriali, bus parallelo a disposizione, real time clock, batteria al litio per tamponare la RAM: costo 50$.

Un'azienda italiana ci ha già fatto un PLC!

la mia idea sarebbe quella di integrare in un oggetto unico basato su TINI interfaccia operatore e comunicazione con l'esterno attraverso bus, seriali ecc: oltre ad un certo numero di I\O locali.

I controlli asse e quant'altro sono remotate su schede dedicate e preprogrammate con microcontrollori che fanno solo quella funzione e che possono essere viste dal programma applicativo come delle funzioni da parametrizzare, con l'andare del tempo si potranno aggiungere anche altre schede dedicate per altre funzioni.

Si potrebbe pensare di interpolare con più assi, il generatore di traiettoria risiede sul master, le schedine accedono alla memoria in cui è riportata la traiettoria con un bus veloce, si sincronizzano con un clock di sistema, hanno una loro memoria buffer interna in modo da avere un certo margine di indipendenza dal bus e calcolano l'interpolazione internamente.

Sarebbe figo usare un bus in fibra ottica...

All'unità centrale si potrebbe magari aggiungere un microcontrollore solo per la grafica e sviluppare che accederebbe in seriale e con una priorità bassina alla memoria quando gli occorrano dei valori di processo per la sua visualizzazione (praticamente un terminale operatore alla fine...).

Con ethernet più PLC potrebbero parlare tra di loro e con uno SCADA esterno (linee automatiche...)

Ecco un paio di indirizzi internet:

www.macro.org (collegamento a 125 MBPS non propietario)

www.ibutton.com/TINI (sito della Dallas sulla scheda TINI, in rete c'è un sacco di roba....)

Ciao!!!

[ifachsoftware]

Voto per il tuo progetto.

[Federico Milan]

Parlando di java e dallas A me sta benone ... come fare per reperire il processore Kit ?!?

ciao

[ifachsoftware]

Federico Milan+Feb 7 2003, 05:03 PM-->

CITAZIONE(Federico Milan @ Feb 7 2003, 05:03 PM)

Si puo' ordinare il kit di sviluppo su www.maxim-ic.com , per il micro si possono chiedere sempre sullo stesso sito campioni gratuiti (io ho gia' fatto diversi esperimenti con i loro prodotti che sono validissimi e ti inviano gratuitamente fino a due campioni per tipo senza farti stressare dai venditori ; inoltre li reputo una ditta molto seria e di fatti li ho ripagati montando loro prodotti su tutta una serie di apparecchiature custom realizzate in ditta).

Un saluto al forum

[Livio Orsini]

Ciao a tutti.

In questo periodo ho avuto un po' da fare e mi sono limitato a brevi escursioni sul forum.

Ne ho approfittato per pensare un po' alla proposta di Igor.

La scheda TINI l'avevo già considerata per un'altra applicazione, quindi in linea di massima la conosco; ora cercherò di approfondirne l'analisi.

Vediamo se ho capito bene l'idea di Igor. Nelle considerazioni che seguono tento di spiegare quello che ho capito io, integrato magari da mie divagazioni.

Igor propone di usare la suddetta scheda come una spece di concentratore, unità centrale ed interfaccia operatore. La sua idea è usare i field bus tipo CAN ed Ethernet per dialofgare con le periferiche più o meno intelligienti. Inoltre si dovrebbe disporre di I/O locali, ma anche questi potrebbero essere connessi alla scheda tramite bus.

L'idea di base, a mio giudizio, è valida, anche se la mia opinione è inficiata dal fatto che questo tipo di architettura è un mio vecchio pallino.

Vediamo ora di analizzare, se ci riesco, in modo compiuto tutti gli eventuali punti deboli di questa strategia.

Il primo punto da analizzare bene è la valutazione delle prestazioni che si possono ottenere da questo processore. Le mie conoscenze attuali di questa Hw non mi consentono di esprimere una valutazione. Rivolgo un caldo invito a chiunque abbia informazioni al riguardo, possibilmente non per sentito dire, di trasmetterle.

Secondo punto, ma forse è il primo in pordine di importanza, è come programmiamo la nostra scheda, prima, e l'apparecchaitura poi. Cerco di spiegarmi meglio. Igor ha già accennato alla presenza di una Java virtual machine ed alla possibilità di programmare in Java. Non metto assolutamente in discussione le prestazioni che possono essere raggiunte con questo tool: mi necessitano ancora le informazioni a cui facevo riferimento prima. La cosa che mi preoccupa fin da ora è come potrà essere programmato dagli utilizzatori.

Senza voler far torto a nessuno penso che persone con il tipo di cultura di chi scrive, di Igor o di Federico, tanto fare qualche esempio, non dovrebbero avere difficoltà ad usare Java. Però l'utenza a cui ci rivolgiamo è composta, per buona parte, da tecnici che conoscono solo linguaggi PLC. Igor, ti ricordo cosa disse in proposito durante l'incontro del 26 di gennaio.

Dobbiamo quindi pensare che, scegliendo questa strada, o progettiamo un sistema che potrà essere usato solo da una certa tipologia di utenti, oppure dovremo mettere in preventivo un grosso lavoro per creare uno strumento che ne allarghi la fruibilità anche a chi conosce solo i PLC. Non è detto che si possa procedere per approssimazioni successive: la cosa importante è avere ben chiaro quali sono i problemi e cosi si può fare per risolverli.

Ritengo che sul problema del linguaggio di programmazione sia indispensabile raccogliere il numero maggiore possibile di opinioni: invito pertanto TUTTI ad esprimersi in proposito.

La cosa più bella di un'architettura come quella ipotizzata è la possibilità di far crescere il progetto per tappe successive. Inoltre permette di poter fare del telelavoro con il massimo della sinergia con un gruppo di persone molto eterogenee.

Conclusioni.

 La piattaforma proposta da Igor, sembra valida e permette di lavorare con costi contenuti. Potremmo cominciare quindi a lavorare per approfondirne le conoscienza (cosa che personalmente faccio da subito). In parallelo se qualc'uno ha altre proposte, relative allo Hw, le esterni.

 Analizziamo bene il problema linguaggio di programmazione.

Io sono molto favorevelo ad un'architettura di questo tipo perchè permette di avere il amssimo della flessibilità.

Propongo di concentrarci su un bus di campo di tipo Eternet, visto che ormai anche un colosso come Siemens sembra averlo accettato (subito?).

Sono molto favorevole ad avere unità periferiche specializzate ed intelligenti. Lascerei che l'unità base svolga solo compiti di gestione e di automazione logica.

Limiterei l'interfaccia uomo al solo testo: tastiera più visualizzazione testi; per interfaccie HMI più complesse dovrebbe essere previsto un dispositivo tipo PC dedicato alla bisogna.

Se le risorse umane che prenderanno parte al progetto (volontari) saranno sufficienti per quantità e competenza potremmo sviluppare in contemporanea anche le periferiche intelligienti tipo controllo asse.

Come prossimo impegno mi assegno l'incarico di approfondire la conoscenza dello Hw proposto da Igor ed ipotizzare un'eventuale architettura del controllo.

[Federico Milan]

Livio sono pienamente daccorco con te ...

se ho un po di tempo prova anchio a capirci qualcosa ... almeno da non trovarmi spiazato ... ciao

[cdc]

Io non ho molte conoscenze a livello H/W. Posso solo esprimere una mia opinione per quanto riguarda il software: sono molto favorevole a utilizzare JAVA come linguaggio di programmazione per diversi motivi:

- imparerei un linguaggio nuovo (Voglio ricordare che "imparare" è lo scopo principale di questo progetto)

- l'ambiente IDE, l'SDK, il Run-time sono completamente FREE e senza costi di installazione (io ho già iniziato a scaricare un pò di roba)

- esistono estensioni del linguaggio (librerie) per il Real-Time (da quello che ho visto solo per Linux, ma forse ci potrebbe andar bene ....)

- JAVA in automazione, da quello che so io, rappresenta una novità e questo potrebbe essere un punto vincente nel nostro progetto. Nulla vieta di scrivere il Firmware della scheda in un modo e fornire degli strumenti "facili" (es: configuratori) agli utilizzatori finali. Vedi ad esempio Linux: non tutti hanno le capacità e le conoscenze per scrivere il Kernel del SO, ma chiunque può utilizzarlo e configurarlo a suo piacere.

Ciao

[Gianmario Pedrani]

Sono pienamente d'accordo anche io con questo nuovo progetto perche non si limita a una sola scheda ma da la sensazione che si espandera anche in futuro

e poi se utilizziamo Linus per programmare e per creare delle sw sarebbe veramente fantastico voi che ne pensate ?

io ci sono

[Igor]

Penso che lo spirito di quanto ho esposto sia stato compreso: il progetto è un qualcosa fatto per imparare, per dare un valore aggiunto al nostro lavoro e per spezzare il monopolio di fatto delle aziende produttrici di PLC. Esse infatti garantiscono solo a parole la portabilità dei loro SW su macchine diverse obbligando il cliente a seguirle se non vuole affrontare il guado percoloso del cambiamento di HW.

Io non so programmare in Java, ma penso che scrivere i nostri SW in un linguaggio neutro come questo sia un qualcosa non da poco.

Lo sviluppare una macchina praticamente da zero porta a conoscere a fondo l'oggetto su cui si lavora, lontano dai proclami e dalle fanfaronate dei commerciali, il fatto che questo sia su base condivisa porta ad una libera circolazione delle informazioni.

Io ho solo esperienza di elettronica analogica, ma mi attrezzo.

Ciao!

[Federico Milan]

Java è molto semplice come linguaggio, e per giunta utilizza tutti i paradigmi della programmazione OO.

C'è da dire però che si dovrà valutare sull'estensione di java, in quanto ottimo come linguaggio per e-comerce, solo negli ultimi due anni si evoluto in ambiente scentifico con classi otimmizzate per calcolo numerico.

Java è una tecnologia più che un linguaggio in quanto presuppone diversi apsetti :

JVM + byteCode + Host ...

gira da pertutto, non ci sono vincoli, solo 2 ... le idee e la pertinenza della piattaforma software ...

Java è stato creato da sun, il sistema di sviluppo è free e lo si preleva nel sito della sun, ovviamente non è open!

Bisogna a questo punto controllare quanto è standarizzato questo Tini sul byteCode java, poi tutto il resto viene da solo.

Il punto a favore è quello di non essere legati a nessuna piattforma in particolare, quindi Ms/*nix/qnx/... tutte vanno bene ... basta avere il JDKxx.xx e si è a posto, quasi ...

Java è in continua evoluzione, ci sono package grafici che si evolvono e altre finezze in continuo mglioramento, poi c'è la piattaforma JMe cioè java microedition usato per dispositivi con pochissima memoria (credo che tini faccia parte proprio di questa categoria) ... in pratica è un sotto set di java, non è molto compatibile con il jdk1.1.x per ovvie ragioni, è quello che oggi si trova sui cellulari ... utilizza api dedicate per l'interfacciamento con l'hw.

provo ad andar leggere qualcosa di Tini vediamo ?!?

ciao

[Gianmario Pedrani]

io non riesco ad aprire i link che ha postato igor a voi funzionano?

[Federico Milan]

www.dalsemi.com

altrimenti cerca con google "TINI Dallas" ... meglio questo perchè altrimenti sei catupultato su alcuni siti un po' osè ...

ciao

[Gianmario Pedrani]

Grazie Federico o risolto era un problema della mia connessione che uso al lavor

con tiscali funziona benissimo ciao e alla prossima