Commande de GBF Agilent

fab_vb6 Messages postés 16 Date d'inscription samedi 20 mai 2006 Statut Membre Dernière intervention 19 novembre 2009 - 6 juin 2006 à 19:42
fab_vb6 Messages postés 16 Date d'inscription samedi 20 mai 2006 Statut Membre Dernière intervention 19 novembre 2009 - 9 juin 2006 à 17:48
Juste un p'tit problème...
Je pilote un GBF Agilent en envoyant des commandes SCPI (Standard Commands fo Programmable instruments).
L'envoi des commandes marche parfaitement, cependant j'essai de détecter l'instant ou GBF à terminé d'executer chaques groupes de commandes. La commande principale à utiliser pour faire cela est "*OPC?" mais cela ne fonctionne pas.
Cette commande doit retourner la valeur 1 sur la com quand l'envoi des commandes est fini.

Exemple :

'--------------Groupe de commande générant un sweep----------
MSComm_GBF.Output = "FREQ:STAR " & F_Start & vbLf   'Fréquence de start
MSComm_GBF.Output = "FREQ:STOP " & F_Stop & vbLf    'Fréquence de stop
MSComm_GBF.Output = "SWE:TIME " & Duree & vbLf      'Durée du sweep
MSComm_GBF.Output = "SWE:SPAC " & Ecart & vbLf      'Sweep Linéaire ou Log.
MSComm_GBF.Output = "TRIG:SOUR " & Trigger & vbLf   'Trigger GBF
MSComm_GBF.Output = "SWE:STAT " & Etat & vbLf       'On/Off SWEEP
'------------------------------------------------------------------

'Envoi de la commande "Opération complète ?"
MSComm_GBF.Output = "*OPC?" & vbLf

'Si la valeur retournée est égale à 1 (bit 1 à 1) l'operation est complète.
Do        
Loop Until Val(MSComm_GBF.Input) = 1

Si vous avez une idée.
Merci à tous par avance (et NON merci à Agilent... FRANCHEMENT.)

10 réponses

cs_casy Messages postés 7741 Date d'inscription mercredi 1 septembre 2004 Statut Membre Dernière intervention 24 septembre 2014 40
6 juin 2006 à 20:38
Salut,

Déjà, rajoute un doevents dans ta boucle, ça t'évitera de bloquer la reception des caractere par l'occupation du proco à boucler.

Ensuite je n'ai jamais utiliser la commande OPC, je ne la connais pas mais elle doit te retourner un mot d'état de l'appareil. Il y a de forte chance que ce mot ne soit pas uniquement égal à 1 lorsque la commande est finie. Il faut donc faire un masque sur le bit 1 et ne tester que celui là.

Puis tu ne synchronise rien, rien ne dit que la valeur que tu teste corresponde à la réponse de la commande OPC, il peut très bien s'agir d'un octet qui trainait dans le buffer de reception.

Au mieux, juste avant d'envoyer ta commande OPC, vide le buffer de reception, comme ça le premier octet reçu devrai, à priori, etre ta réponse.

PS : Agilent est une très bonne marque d'appareil de mesure surtout lorsque tu veux faire des banc de tests automatiques. Jamais eu de surprises avec contrairement à d'autres marques tout aussi connues.

PS2 : Agilent = Hewlett Packard pour les anciens

<hr /># Le partage est notre force #
0
fab_vb6 Messages postés 16 Date d'inscription samedi 20 mai 2006 Statut Membre Dernière intervention 19 novembre 2009
6 juin 2006 à 21:53
Merci de ta réponse !
J'envoie bien la commande "*CLS" (cf. ci-dessous) avant les lignes de codes que j'ai fourni.
.Par contre pour le DoEvent... Oui en effet, ça parait évident maintenant, car quand j'essais en pas pas je receptionne bien la mise à 1 =>La commande "*OPC?" retourne la valeur 1 quand la commande est executée
Copie de la doc...

-----------------------------------------------------------
"*CLS" :Clear the Status Byte summary register and all event registers.

-----------------------------------------------------------
"*OPC?" :The *OPC? command returns “1” to the output buffer when the burst or sweep is complete.

Return “1” to the output buffer after the previous commands have

been executed.

Used only in the triggered burst mode and triggeredsweep mode.
------------------------------------------------------------

Sinon pour Agilent/HP, je pense que je ne suis pas tombé sur le bon technicien... c'est tout, enfin j'espere, je ne m'étendrais pas plus sur le sujet... Je ne mets pas en doute la qualité de leurs équipements certainement pas, (même s'ils ne souhaitent plus assurer la maintenant de certains après une certaines periode que je trouve bien courte et ce n'est sans doute pas par hazard...).
Un grand merci à toi en tout cas.
0
fab_vb6 Messages postés 16 Date d'inscription samedi 20 mai 2006 Statut Membre Dernière intervention 19 novembre 2009
6 juin 2006 à 22:05
Je rajoute un petit prog fourni en exemple dans la doc...
Les deux lignes

concernées sont en rouge.



Je suis plutot surpris par la maniere dont ces commandes sont utilisées.

Mais bon ca doit être moi...








’ This program shows how to download an arbitrary waveform
’ using ASCII data over the RS-232 interface. The program
’ generates a damped sine wave using 1,000 points.




npnts = 1000 ’ Define number of ASCII points in waveform
NCYCLES = 10 ’ Define number of cycles
DAMPFACTOR = -5 ’ Define damping factor
DIM waveform(npnts) ’ Dimension waveform array



’ Configure COM2 for 9600 baud, even parity, 7 data bits, 2 stop bits,
’ suppress detection of Request to Send (rs), set timeout of Data Carrier
’ Detect line (cd), and terminate output with line feed (lf).



OPEN "com2:9600,e,7,2,rs,cd,lf,pe" FOR RANDOM AS #1 LEN = 1000

PRINT #1, ":SYST:REM" ’ Enable the remote RS-232 mode
PRINT #1, "*RST" ’ Reset the function generator
PRINT #1, "FORM:BORD SWAP" ’ Swap data bytes (send LSB first)
PRINT #1, "FREQ 5000" ’ Output frequency is 5 kHz
PRINT #1, "OUTP:LOAD 50" ’ Output termination is 50 ohms
PRINT #1, "VOLT 5" ’ Output amplitude is 5 Vpp





'Calculate data points
PRINT "Calculating Data Points..."
pi = 3.1415

FOR I = 1 TO npnts
waveform(I) = EXP(DAMPFACTOR * I / npnts) * SIN(2 * pi * NCYCLES * I / npnts)
NEXT I





'Download data points to volatile memory
PRINT "Downloading Arb..."
PRINT #1, "DATA VOLATILE,";

FOR I = 1 TO npnts - 1
PRINT #1, STR$(waveform(I)) + ",";
NEXT I



PRINT #1, STR$(waveform(npnts))

PRINT #1, "*OPC?"                ’ Wait for download to complete

LINE INPUT #1, resp$



PRINT "Download Complete"
PRINT #1, "DATA:COPY DAMP_SIN, VOLATILE" ’ Copy to non-volatile memory
PRINT #1, "FUNC:USER DAMP_SIN" ’ Select the active arb
PRINT #1, "FUNC:SHAP USER" ’ Output the selected arb



PRINT #1, "*OPC?"
LINE INPUT #1, resp$


PRINT "Program Complete"



END
0
cs_casy Messages postés 7741 Date d'inscription mercredi 1 septembre 2004 Statut Membre Dernière intervention 24 septembre 2014 40
6 juin 2006 à 22:19
Ok pour les commandes OPC et CLS

LE mode pas à pas crée une pause dans ton logiciel, donc libère le proco, dans ce cas la réception peut se faire. D'où la necessité du DoEvents en run.

Pour le buffer à vider, je ne paralis pas du buffer de ton HP, pardon, de ton Agi..., mais de celui coté logiciel (MsComm).

Quant au SAV d'agilent, je m'étendrait pas sur le sujet, ils font tous (ou feront tous petit à petit) la même chose.

Pour ton programme, rien de bien spécial. C'est le Print #1 qui te gène ???, C'est tout simplement parce qu'ils ne passe pas par le controle MsComm mais qu'ils ouvrent le port série comme un flux de donnée. Du coup, ils l'utilisent ensuite comme un fichier.
C'est du Basic évolué, mais je en suis pas sûr que ce soit du VB, je n'ai jamais utilisé le port série comme ça en VB (mais en C , oui). Je ne sais pas si ça marche, mais pourquoi pas.

Remarque que dans leur soft ils ne testent pas la valeur de retour de OPC, ils attente juste que la réponse soit arrivée.

<hr /># Le partage est notre force #
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
fab_vb6 Messages postés 16 Date d'inscription samedi 20 mai 2006 Statut Membre Dernière intervention 19 novembre 2009
6 juin 2006 à 22:42
....Oui c'est du QBASIC. Pour le print, non c'est OK, c'etait bien le fait qu'ils ne testaient pas la valeur de retour, mais bon...
Car dans mon cas si j'envoie des commandes de sweep repetées le GBF se met en erreur, raison pour laquel je teste la valeur de retour pour constater que les commandes de sweep sont bien effectives.

(La propriété InputLen est à 0, donc je lis la totalité du buffer sur un MSComm.input)
-----------------------------------------------------------------------------------------------------------
Private Sub Command_Click()
       
Dim Recept As String
       
MSComm_GBF.Output = "*CLS" & vbLf        'Efface les reg. du GBF       
Recept = MSComm_GBF.Input                        'Vide le buffer de recept.
       
'--------------Groupe de commande générant un sweep----------
MSComm_GBF.Output = "FREQ:STAR " & F_Start & vbLf   'Fréquence de start
MSComm_GBF.Output = "FREQ:STOP " & F_Stop & vbLf    'Fréquence de stop
MSComm_GBF.Output = "SWE:TIME " & Duree & vbLf      'Durée du sweep
MSComm_GBF.Output = "SWE:SPAC " & Ecart & vbLf      'Sweep Linéaire ou Log.
MSComm_GBF.Output = "TRIG:SOUR " & Trigger & vbLf   'Trigger GBF
MSComm_GBF.Output = "SWE:STAT " & Etat & vbLf       'On/Off SWEEP
'------------------------------------------------------------------

MSComm_GBF.Output = "*OPC?" & vbLf      'Demande si commande executée

'Si la valeur retournée est égale à 1 (bit 1 à 1) l'operation est complète.
Do
    DoEvents
Loop Until Val(MSComm_GBF.Input) = 1
End Sub

Aller pour ce soir c'est OK, on verra demain ce que l'Agi veut bien me raconter..
Et encore MERCI !!!! A+
0
fab_vb6 Messages postés 16 Date d'inscription samedi 20 mai 2006 Statut Membre Dernière intervention 19 novembre 2009
7 juin 2006 à 20:18
Salut !
En fait j'ai un petit doute au niveau du câble apparement...
Agilent emploi un cable série DB9 qu'ils nomment Null Modem cependant il ne respect pas le câblage d'un "vrai " Null Modem (ma remarque peut parait evidente pour les initiés, mais je n'ai plus la tête dans les com... faut que je ressorte les cours et il me semble bien qu'il y a un truc par là...).
Sur un Null Modem la ligne DTR (Data terminal prêt) est renvoyé sur l'autre connecteur sur DSR (data prête) + DCD (detection de porteurse) mais sur le câble "null Modem" Agilent, DTR est relié à DSR et la ligne de detection de porteuse DCD est directement reliés de chaque côté, ce qui veut dire que la ligne DCD n'est pas activée par DTR dans ce cas. Je me fais une idée de ce que cela peut changer mais en ce qui concerne mon problème mentionné plus haute je ne vois pas ce peut influencer sur le fonctionnement. En effet j'arrive à detecter l'envoi de commandes par la commande *OPC ? qu'en effectuant une tempo avant l'envoi de cette commande... (ce qui est ennuyeux car je perts tout le benefice de la commande).
(Bon aller je vais essayer de retrouver mes cours... quand même !)
Merci !!!

'Avec la tempo çà marche....................
Private Sub Command_Click()
       
Dim Recept As String
       
MSComm_GBF.Output = "*CLS" & vbLf        'Efface les reg. du GBF       
Recept = MSComm_GBF.Input                        'Vide le buffer de recept.
       
'--------------Groupe de commande générant un sweep----------
MSComm_GBF.Output = "FREQ:STAR " & F_Start & vbLf   'Fréquence de start
MSComm_GBF.Output = "FREQ:STOP " & F_Stop & vbLf    'Fréquence de stop
MSComm_GBF.Output = "SWE:TIME " & Duree & vbLf      'Durée du sweep
MSComm_GBF.Output = "SWE:SPAC " & Ecart & vbLf      'Sweep Linéaire ou Log.
MSComm_GBF.Output = "TRIG:SOUR " & Trigger & vbLf   'Trigger GBF
MSComm_GBF.Output = "SWE:STAT " & Etat & vbLf       'On/Off SWEEP
'------------------------------------------------------------------

>>> Ici avec une tempo d'1 sec çà marche....

MSComm_GBF.Output = "*OPC?" & vbLf      'Demande si commande executée

'Si la valeur retournée est égale à 1 (bit 1 à 1) l'operation est complète.
Do
    DoEvents
Loop Until Val(MSComm_GBF.Input) = 1
End Sub
0
cs_casy Messages postés 7741 Date d'inscription mercredi 1 septembre 2004 Statut Membre Dernière intervention 24 septembre 2014 40
7 juin 2006 à 20:53
Je suis surpris que ce ne soit pas un cable 3 fils pour la liaison série. Il est de plus en plus rare de nos jours de trouver de la com à plus de 3 fils.

Bref, la ligne DCD n'est généralement pas utilisée hormis dans les modems. Je ne pense pas qu'il soit génant qu'elle ne soit pas reliée aux autres. Tu trouve même des cordons ou elle n'est pas cablé du tout. Pour le reste du branchement, je peux pas te dire je n'ai pas mes bibles sous la main.

Si ça marche en pas à pas il est effectivement peu probable que ça vienne du cable, à moins d'avoir un cable vraiment très pourri.

Quel protocole d'handshake as-tu programmé? avec DTR, CTS, ... c'est normalement le protocole matériel qu'il faut (comRTS sous VB). Ca viens peut-etre de là, ton appareil n'a pas le temps de tout recevoir.

<hr /># Le partage est notre force #
0
fab_vb6 Messages postés 16 Date d'inscription samedi 20 mai 2006 Statut Membre Dernière intervention 19 novembre 2009
7 juin 2006 à 21:13
DTR enable = True pour la propriété Mscomm
Pour le proto, que ce soit RTS/CTS ou Xon/Xoff, ca ne parche pas (oueh je sais... y 'a un truc)
Il faut que je creuse... Je ne dispose pas encore du "bon" câble et n'ai pas eu le temps de le faire donc...
Je ne m'etais pas soucié du câble car l'envoi des commandes était parfait jusque là, mais la lecture du buffer de l'agi ne se fait pas comme il faut => Il s'agit d'un pb d'handshake à mon avis et j' espere pouvoir trouver, c'est un pb interessant.

Merci pour ton aide encore une fois.
et surtout :Le partage est notre force !
0
fab_vb6 Messages postés 16 Date d'inscription samedi 20 mai 2006 Statut Membre Dernière intervention 19 novembre 2009
9 juin 2006 à 17:45
...juste un pb de buffer... pfffff.
L'agi ne gère pas le CTS/RTS...
Donc tout est Ok maintenant et ca marche super ! Comme sur des roulettes.
Et non merci au tech de chez Agi (bah ce devait être un mauvais jour pour lui je suppose... des fois ca m'arrive aussi !)
 Le partage est notre force parait-il !
0
fab_vb6 Messages postés 16 Date d'inscription samedi 20 mai 2006 Statut Membre Dernière intervention 19 novembre 2009
9 juin 2006 à 17:48
A oui j'allais oubler aussi... merci pour cet excellent site et à casy !
0
Rejoignez-nous