linux user group brescia

Enrico Colombini said:
> On Sunday 10 August 2003 10:58, Luca Coianiz wrote:
>>  Non sono addentro come te nel ramo industriale, e peraltro so che a
>> voi
>> ingegneri piace giocherellare con i fili ed i criteri per fare le cose
>> più strane... quando invece ci sono comodissimi standard da seguire
>> ;))), però IMHO ha poco senso OGGI una cosa del genere.
> Avresti ragione se stessimo parlando di PC e modem, i dispositivi
> industriali  sono un'altra cosa. Standard RS-232 significa che i fili
> sono collegati in un  certo modo e i dati viaggiano con un certo
> protocollo a basso livello. Tutto  quanto sta sopra e' da definire.

 Uhmmm... certo... diciamo che io so che, usando l'RS-232, collego un
connettore DTE qui (al PC), uno DCE là (alla macchina) e posso
trasmettere dei bit usando dei fili (TX/RX prima di tutto, poi RTS, CTS,
DTR, DSR, ecc. per eseguire il controllo di flusso, e via così) con
determinate tensioni, correnti e dimensioni dei cavi (ah... anche la
"pinnatura" dei connettori ;)).

 Chiaramente (chiaramente?) se voglio trasmettere UN BYTE il discorso si
sposta a livello "applicativo" (o, meglio, in questo caso: sul driver di
sistema)... se poi voglio interpretare il byte (e/o interagire con gli
apparati) ci si sposta ancora più "in alto" e si definiscono le "sequenze
di byte" come "comandi"... questo almeno secondo una teoria... poi ce ne
sono mille altre. :)
(almeno tante quanti i protocolli)

>> tipo quelli di Alberto: seriale su tre fili, di cui uno era la
>> massa)...
> Tuttora usatissimo.

 ULP!!!.. ed io che pensavo di avere già fatto una "zozzata" a
proporglielo per il suo robottino... :/
(diciamocelo: voi ingegneri siete proprio perversi ;)))

>>  Ma, a parte programmi di controllo automatico, per eseguire
>> l'interfaccia
>> utente (brutale tty oppure ncurses) non sei comunque costretto ad
>> aprire almeno una minima shell? (che poi sarebbe lo standard di Linux)
> Non so cosa intenda farne Francesco, io parlo di programamzione:
> l'interfaccia  utente la fa il programma, la comunicazione con la
> seriale e' un'altra cosa  che non c'entra nulla.

 Sigh... scusa: tendo a confondere il programma, che "fa le cose", con
l'interfaccia-utente, che "gli dice cosa fare" (ma nemmeno sempre: nei
sistemi automatizzati, per esempio, non c'è uno straccio di GUI: tutti
bei bottoni, grossi così).

>>  Probabilmente perchè (butto là) dovevi fare l'interfaccia di
>> controllo in
>> "modo Windows" mentre il tuo programma doveva lavorare in modo custom
>> con la seriale: due cose che si sposano probabilmente poco.
> No, anche qui penso che  tu stia confondendo l'uso 'utente' dall'uso da
> parte  di un programma. Se vuoi usare la seriale come utente, minicom
> basta e  avanza.

 Certo... io, come dicevo, tendevo a fare una "combo" di programma + UI
pensando, a priori (quindi, magari, non è nemmeno questo il caso), che ci
fosse un qualche "PC di controllo" di una o più macchine utensili, che
tale PC facesse girare Linux (btw, picchiamoci subito: Debian, RH o SuSE?
;)))), che l'operatore umano avesse bisogno, tramite appunto
l'interfaccia (UI) di (A) verificare lo stato corrente delle macchine
controllate, (B) avviare/arrestare manualmente dei cicli di lavorazione,
(C) verificare eventuali condizioni d'errore e forse (D) controllare
altre funzionalità "off-line" (tipo lo storico dei pezzi, disponibilità a
magazzino o statistiche di produzione... anche se questo, di solito, non
lo si fa sull'UI delle macchine ma in altri luoghi).

 Il tuo discorso invece, giustamente, riguarda più i "moduli" applicativi
che eseguono queste funzioni, danno i comandi alle macchine,
caricano/scaricano i programmi dalle stesse, ecc.
 Il tutto basandosi sul fatidico modulo d'interfaccia (standard o custom)
con la linea seriale (o le multiseriali).

>>  E' una baggianata se dico che non avresti avuto questi problemi con
>> una macchina DOS (con l'interfaccia "tipo Norton Commander")?
> Si', e' una baggianata :-)

 Com'è buono lei ((C)Fantozzi/P.Villaggio) ;))))

> Anche col DOS mi ero dovuto scrivere un
> driver (in  questo caso un driver vero, non un wrapper).

 ...mentre con Linux bisogna ancora vedere se il driver esistente soddisfa
i requirement. :)
(magari basta RTLinux per poter usare il driver standard)

      Ciao,
            Luca