next topic »

[Reply #15 on:]

supposti giusto

ma se il collegamento lo effetto sulla seriale hardware, posso rimanere collegato con la usb ad arduino?

e soprattutto, una volta che mando la query, come leggo la risposta?

[Reply #16 on:]

ho scritto questo sketch giusto per vedere se lo strumento mi manda qualcosa:

Code:

#define baudRate 1200

boolean query = false;
String idn = "";
void setup(){
  pinMode(2,OUTPUT); 
  Serial.begin(baudRate);
  delay(10);
  Serial.println("*RST");
  delay(10);
  Serial.println("*CLS");
  delay(10);
  Serial.println("SYSTEM:REMOTE");
  delay(10);
  Serial.println("*IDN?");
  idn = Serial.readStringUntil('\n');
  idn.trim();
}

void loop(){
  if(idn != "" ){
    digitalWrite(2,HIGH);
  }
}

il led dovrebbe accendersi se idn è diverso dalla stringa vuota, dunque upload il codice, stacco la usb, attacco una pila da 9V alla vin, lo     strumento va in remoto, ma il led che si dovrebbe accendere, indovinate, rimane inesorabilmente spento

[Reply #17 on:]

In teoria potresi anche fare il collegamento in paralello ma credo che sia meglio di no, infatti ipotizzavo di usare un led per fare qualcosa del tipo

pseudocode:

result = query(x)
if (result == 200)
    accendi led
else
    spegni led

Ho anche fatto l'ipotesi di avere un display lcd collegato ad arduino così da stampare la risposta.

Si però se la supposizione è giusta ti dovresti accontentare di non vedere nessun messaggio di errore nel display dell'alimentatore, indi per cui si può pensare che effettivamente la RS232 dell'alimentatore è schizzionosa e vuole una connessione seriale hardware. In tal caso il problema rimane e dovrai trovare una alternativa, o una board con più seriali, o un altro atmega connesso tramite seriale all'alimentatore e alla board arduino tramite ISP o i2c.

Ma la seriale 9 pin sul pc non c'è l'hai vero?
Nel mio pc recente c'è, se l'avessi potresti collegare PC con alimentatore e scrivere un programmino in basic, c, python o altro per sincerarti che non ci sono problemi con la comunicazione seriale.

Mi hai anticipato.

Nota che println, aggiunge un ritorno carrello \n alla fine della stringa, prova ad usare print.

In pratica invii un reset, un clear, abiliti il remote e *IDN?, che è la query e cosa dovresti avere in risposta?

Ciao.

Ciao.

[Reply #18 on:]

collegando il pc con l'alimentatore problemi non ce ne sono, perchè usando matlab mi risponde alle query. così al comando *IDN? risponde inviando una stringa con l' "identità" dello strumento: produttore e versione firmware.

il println è "necessario" perchè essendo il linguaggio per comandare lo strumento scpi devo mandare stringhe tutte con NL alla fine

[Reply #19 on:]

NL sarebbe New line '\n' o cr + lf '\r\n'. Su sistema unix il fine riga è '\n' su windows è '\r\n', può essere che con la connessione seriale tu usi un linguaggio compatibile con windows e non con unix. Se fosse così devi usare print e in coda aggiungere una print '\r\n'.

Il compilatore gcc è stato sviluppato per unix poi è stato portato su windows, e avr-gcc è un build di gcc specifico per architettura AVR, ovviamente il build è diverso per unix/linux da quello per windows. Non ho idea di cosa faccia avr-gcc per windows riguardo al fine riga, penso che lasci decidere al programmatore altrimenti alcuni programmi arduino funzionerebbero solo su windows o su linux dipende quale compilatore è stato usato.

Per sicurezza prova ad usare print("\r\n") dopo ogni comando inviato sempre con print(). Scusa controlla che sia veramente print e non write la funzione da usare.

Ciao.

[Reply #20 on:]

ma il problema che riscontro io non è nell'inviare i comandi allo strumento, ma nel ricevere risposta:
se invio un qualsiasi comando, lo strumento risponde:
Esempio:

Code:

aliementatore.println("SYST:REM");(1)
alimentatore.println("OUTP:ON");(2)
alimentatore.println("APPL P6V,1.5,1.2");(3)

l'alimentatore risponde normalmente, (1)settandosi in controllo remoto, (2)abilitando l'output,(3)settando l'uscita a 1.5V 1.2A.

ma se invio una query

Code:

alimentatore.println("*IDN?");

lo strumento legge e processa la query, ma non scarica il buffer di output, infatti se invio un'altra query mi restituisce l'errore 410:query interrupted: il buffer di output è pieno e non può essere sovrascritto, perchè non ho letto la risposta, e non capisco perchè diamine non manda la risposta sulla seriale

spero di essere stato chiaro

[Reply #21 on:]

Ok vero, diversamente non prenderebbe nessun comando rimanendo in attesa.

Io non conosco la procedura corretta per la query, evidentemente qualcosa si comporta in modo differente tra seriale pc e seriale TTL, di mezzo c'è anche il max, che viene meno con la connessione seriale PC <-> agilent. Potrebbe essere lui?

Con la connessine PC <-> agilent disabiliti anche DTR/DSR o lo lasci abilitato?

Potrebbe essere la seriale software? no,  hai già provato con quella hardware.

Ciao.

[Reply #22 on:]

alla fine ce l'ho fatta:
come scritto sul manuale agilent, bisognava disabilitare l'handshake, rendendo flottante il dtr e mettendo a livello logico vero il dsr.

PS. per livello logico vero, nonostante si parli di rs232, si tratta di connettere il dsr al pin 2(v+) del max232, ovvero circa +8V