Symbol PDT 3100

[DigitalKiller]

Ciao a tutti!
Ho per le mani un terminale della Symbol PDT 3100 da cui dovrei scaricare dei dati tramite la porta seriale. Dato che dovrei utilizzare spesso questo terminale, avevo pensato di scrivere un programma in java per scaricare i dati.
Non so se sia corretto o meno, ma ho provato a utilizzare hyper terminal di windows per scaricare i dati. L'unica cosa che sono riuscito ad ottenere, però, è stato un carattere ASCII (sul pdt3100 il trasferimento risultava andato a buon fine):fagiano:
Qualcuno di voi si è già trovato in una situazione simile? Avete delle dritte da darmi?:D
Grazie

[DigitalKiller]

L'approccio con hyper terminal immagino fosse sbagliato:D Ho provato tantissime combinazioni, ma non sono mai riuscito a vedere nulla a video:muro:
Ho provato a scaricare l'api javacomm ed a eseguire il programma d'esempio SimpleRead fornito con l'api.
Il programma, tramite questo codice:
case SerialPortEvent.DATA_AVAILABLE:
byte[] readBuffer = new byte[20];

try {
while (inputStream.available() > 0) {
int numBytes = inputStream.read(readBuffer);
}

System.out.print(new String(readBuffer));
} catch (IOException e) {}

break;
}

stampa a video una serie di byte. Immagino che questi siano i dati che mi servono e non mi resta che "tradurli", vero?:D

[dannythegreat]

Non hai avuto più novità su come scaricare questi dati? Sarei molto interessato ne ho uno per le mani anche io

[cionci]

Google rulez: http://support.symbol.com/support/browse.do?WidgetName=BROWSE_PRODUCT&IsRootNode=true&TaxoName=SG_SupportGoals&BROWSE_PRODUCT.isProductTaxonomy=true&BROWSE_PRODUCT.NodeId=SG_PDT3100_1_2&BROWSE_PRODUCT.thisPageUrl=%2Fproduct%2Fproducts.do&id=m4&BROWSE_PRODUCT.TaxoName=SG_SupportGoals&NodeType=leaf&NodeName=PDT3100&BROWSE_PRODUCT.NodeType=leaf&NodeId=SG_PDT3100_1_2&AppContext=AC_ProductPage&param_document=sp

[DigitalKiller]

Non hai avuto più novità su come scaricare questi dati? Sarei molto interessato ne ho uno per le mani anche io

Dopo numerosi tentativi, grazie anche all'aiuto di un programmatore di questi terminali, sono riuscito a capire che il software sviluppato per la mia azienda aveva un po' di bug:muro:
Alla fine, ho risolto facendo riscrivere da zero il software:D

[Augusto Vinciguerra]

Salve a tutti !
abbiamo messo in disponibilità per la cessione, n° 30 pz terminalini PDT 3100 usati ma in ottime condizioni;
abbiamo anche i caricabatteria completi.
Nel caso vi fossero utili, non indugiate a contattarci.

We have now about 30 pieces of PDT3100 scanners available for sale, they are used but in pristine conditions.

grazie dell'attenzione.

[RedDuke]

Ciao a tutti,
ho lavorato diversi anni su questi terminali e , nella speranza possa essere acora utile fornire qualche informazione, qui di seguito un "decalogo" sulle possiblità di programmazione di questa serie di terminali.
I terminali Symbol PDT/LDT fanno parte della famiglia "3000/6000" prodotti su scala mondiale all'inizio degli anni 90 dalla (allora) società americana Symbol Technologies (acquisita nel 2006 da Motorola) .
Il sistema operativo di queste apparecchiature è il DR-DOS.
Si parla quindi di "compatibilità" ad un ambiente SW che "ruota" intorno ai sistemi che al tempo erano il DOS (nel senso di ambienti di programmazione e tools utilizzabili sui PC di allora).
Riguardo quindi gli ambienti di sviluppo SW per il terminale, sono il 'C' (Microsoft o Borland) in versione 16 bit (ci si può "spingere" fino al C++ contenuto nel kit VC++ 1.5 , ma sempre considerandone l'ambiente a 16 bit) a cui era utile abbinare delle librerie specifiche 'C' fornite dalla Symbol (chiamate ADL/ADK). Queste librerire permettevano di agire in modo "specifico" sull HW di questi terminali che avevano un firmware "mappato" a basso livello diverso da quello di un PC-DOS (es per il video, lo scanner , le comunicazioni ed i files su cui venivano memorizzati i dati)
C'era un altro ambiente chiamato FORCE (che era similare al CLIPPER), sviluppato da una SW tedesca e 'certificato' (a quei tempi) dalla Symbol.
Tuttavia era molto più consigliabile sviluppare con Microsoft 'C' (anche perchè ci si poteva avvalere delle ADL-ADK che agivano in modo specifico ed erano supportate direttamente da Symbol).
Sempre in quegli anni , venne prodotto l'ambiente RAD MCL che permetteva di sviluppare applicazioni senza dovers essere necessariamente un programmatore esperto ma , come tutti i tools di "generatore di programma" avenano qualche limitazione (non era possibile sviluppare proprio tutto quanto poteva essere chiesto da un cliente) ed aveva un costo "impegnativo" in termini di pacchetto e licenze (in pratica, il fornitore SW doveva valutare bene se avrebbe avuto un business continuativo per giustificare l'acquisto di questo pacchetto).
Detto ciò , si riassume che il Kit più adatto è Microsoft 'C' 6.00 + Symbol ADL - ADK ed un programmatore che conosce anche gli accorgimenti da usare per ottenere attese performance sull'apparecchiatura finale (seppur macchina DOS , non ha proprio le prestazione di un PC..anzi :-) )

In merito alla possibilità di trasmettere dati (altro punto...dolente) ai tempi nulla era "dato per scontato" (anche a causa delle ristrette limitazioni HW che avevano necessariamente queste macchine).
Riguardo una applicazione "batch", si poteva trasmettere solo dati localmente via Cradle e cavo RS232 , o tramite linea telefonica (modem a V22/V22 Bis).
Per una tramissione locale , è possibile utilizzare su PC un "programmino" DOS di nome TFT3000 oppure avvalersi del protocollo XMODEM (non il più "recente" ZMODEM!) e utilizzare programmi come Hyper Terminal o similari.
I terminali suportavano (più che altro) in modo "nativo" un protocollo di comunicazione studiato da Symbol che si chiamava Msi2Way. Richiedeva però che sul PC ricevente ci fosse un SW chiamato PDTPAL (che "lavorava" appunto utilizzando questo protocollo custom).
PDTPAL nacque comunque per PC DOS (puri) errivò ad essere compatibile (un pò "forzatamente") fino a sistemi come Windows 2000.
Con XP/2K3/7 credo che la speranza di potresi avvalere di PDTPAL vada lentamente a spegnersi (a meno che di usare macchine virtuali con vecchi OS).
Concludendo anche l'argomentazione "comunicazione dati" per questi terminali, credo quindi che ai giorni nostri non rimane che potersi avvalere di comunicazioni in locale via RS232 con il SW TFT3000 (attenzione, dovreste riuscire a recuperare la versione di TFT3000 compatibile con sistemi windows) o utilizzare XMODEM ed un Hyper terminal.
Naturalmente, è necessario che il SW che gira sul terminale , abbia la modalità di comunicazine sviluppata e disponibile nel Vostro programma.
Come sopraccitato , se il Vs terminale ha un modem interno, potete anche avvalervi di una comunicazione via "doppino" telefonico , ma avete bisogno di un vecchio modem V22/V22bis (solo più recenti versioni di PDT supportano il V42 e dicendo "recenti", intendo prodotti dal 2001 in avanti)

Mi scuso per la lungaggine , nella speranza che le informazioni siano state utili per chi ha ancora queste "fantastiche" apparecchiature (e non lo dico come battuta) e non ha la più pallida idea di come poterci "approcciare"