Jump to content

gianmarco

Members
  • Posts

    5
  • Joined

  • Last visited

    Never

Posts posted by gianmarco

  1. I understood was Brian was saying . What is missing are the characters "T1" before ALL the commands.

    I modified it and I've got the answer from the instrument. However, now I'm getting a new error related to the waiting time. If I increase it in the box the error is still present. I suppose something is wrong in the reading time, maybe Labview waits for a closing character that doesn' t arrive? Enclosed screen error.

    I'm a beginner...be patient.

    Gianmarco

    post-7095-1166179207.jpg?width=400

  2. Thanks for taking a look at this. I found out the problem. I was missing a portion of the "Header message" when I sent the commands to the controller. The documentation doesn't really explain this header until you get into the examples. I missed it in my rush to get things done. Sorry for the false alarm about events and flow control.

    Brian

    Hi, I'm doing the same as Brian did, i.e. interfacing a Digi-Sense 89000-0015 with Labview 8.2 (so I suppose Visa driver is the last available).

    The Brian's vi (as posted) doesn't work with my instrument too. I haven't understood what is missing in the code, what is the missing portion of the "Header message" ?

    If Brian or someone else can add this detail this will be helpful for me.

    Thanks

    Gianmarco

  3. Hi Gianmarco,

    some multimeters abuse handshake lines DTR and RTS to supply builtin opto couplers with power.

    To investigate this please Unplug Multimeter. Close LabVIEW and run the Mas-VIEW program.

    One way to verify states of lines is to measure voltage at pin4=DTR and pin7=RTS versus pin5=ground.

    Or investigate states of lines with MAX by opening VISA Test Panel of the Com-Port.

    Please report your results to the forum and we can give further help how to control handshake lines

    out of LabVIEW by a property node.

    Your Start.vi executes write and read in parallel.

    Modify like tcplomp did. ...pass the VISA-resource from one subvi into the next.

    Manfred

    Hi Manfred,

    you are very right! That's what I did following also the suggestions of Ni-support team (italy). I measured the voltage of all the pins during a working transmission by the multimeter itself. I understood that the working programs (Mas-view and Matlab) setted the RTS to null instead Labview put it to high. So I modified it and ...now it 's working

    I suppose this is not a very common serial transmission procedure but that is.Thanks to people that helped me.

    For the people intered in I enclosed a couple of vis for a working communications.

    Gianmarco

    Download File:post-7095-1165435177.vi

    Download File:post-7095-1165435195.vi

  4. Hi gianmarco,

    I see some issues in your code, you tell VISA to wait for a termination character (the T-boolean), and specify this byte as 0x00 (a null-byte) but your specs say it should be a CR (0x0D).

    You try to read 1024 bytes thought you'll only get 14 bytes per reading.

    You specify XonXoff as flow control this doesn't show up in your specs

    Why did you modify the VISA configurator?

    Hopefully this code can help you:

    post-2399-1165086997.png?width=400

    Ton

    Hi Ton you are right : these parameters were modified later. Anyway if you put terminator character "False" and you read only 14 bytes you get the same framing error (1073807339). The same is true for flow control that should be 0.

    I 've enclosed again the start.vi with the parameters in line with what you said. Sorry for my mistake.

    The reason why I modified the Visa configurator is to modify XonXoff characters. It was the only way I found.

    Gianmarco

    Download File:post-7095-1165146406.vi

  5. Hi, I'm a beginner of Labview (8.2) and I'm trying to controll a Digital Multimeter DVM345DI ex Velleman (alias MAS34-xx ex Mastech I found both the vendors supply the same nstrument produced somewhere in China).

    The instrument uses a RS232C serial interface that works with a software called Mas-View. The communication specs are the following:

    RS232C Interface protocol

    3-1. MAS34X series

    Mode : 600,n,7,2

    Format : Ascii Code

    Total : 14 bytes

    Whenever any one byte received from P/C, output 14 bytes.

    BYTE 1-2 : MEASURING MODE (ex;DC,AC,OH,CA,TE...)

    BYTE 4 : SIGN(-)

    BYTE 5-9 : Decimal point and value

    Current measurement value(ex;10.00, OL.,3.999)

    BYTE 10-13 : Unit (ex; mV,A,KOHM,nF...)

    BYTE 14 : Carriage Return

    Note : Interval time over 1 second is required for stable

    measuring data from the meter.

    I also made a Matlab code that is working fine :

    s = serial('COM4');

    s.BaudRate=600;

    s.StopBits=2;

    s.Timeout=10;

    s.Terminator='';

    s.DataBits=7;

    s.ReadAsyncMode = 'continuous';

    get(s,{'BaudRate','DataBits','Parity','StopBits','Terminator'});

    fopen(s);

    fprintf(s,'D');

    s.BytesAvailable;

    out = fscanf(s) % es DC -0.000 V

    fclose(s);

    Now, I would like get the same thing with Labview. I did the code start.vi with a modified driver for the serial communication (both enclosed).

    Nothing to do, I cannot succed. I suppose I have some parameters wrong in the .vi code. I always get:

    Error -1073807253 occurred at VISA Read in start.vi

    Possible reason(s):VISA: (Hex 0xBFFF006B) A framing error occurred during transfer.

    I monitored all the three communications with Portmon. I have reported all the results in the spreadsheet file.

    In my opinion something is wrong in the read part. It is also interesting that Mas-view and Matlab get the data in two different ways,but Labview cannot get the answer from the instrument. This makes me crazy !

    Anyone can help me ? Whatever suggestion is wellcome, thanks.

    Gianmarco

    Download File:post-7095-1165066712.vi

    Download File:post-7095-1165066765.vi

    Download File:post-7095-1165067071.xml

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.