34401A through RS232 with Matlab?

[LaurentR]

I have a 34461A and a bunch or Rigols I have been successfully using with Matlab.
I just got a 34401A as a complement to the 34461A, but for the life of me, I can't seem to be able to use it with Matlab. I am trying to use it through an official FTDI USB>Serial cable.

Getting BenchVue / DMM Utility to work took a bit of work, but that is now 100% fine. I managed to do it both with the NI and the Agilent Visa drivers. For some reason, it only works using 9600bauds, 8b and no parity. No other config works, but this one does fine.

Using that same working config, in Matlab, things kinda work, but not enough. Basically, flow control doesn't work. If I pause enough between each request, it all works. If I chain commands as I normally would in a script, the first read/query hangs and timeout.

I found This post on the Matlab forum talking about what seems like this issue.

I can't believe the 34401A would not work in Matlab, but I am out of things to try (tried various combination of NI and Agilent drivers as primary/secondary/only, flow control options in the Visa driver, Visa object config in Matlab, windows serial port configs...) and I don't seem to be the only one having the issue, so I thought I'd ask if anyone had any success/experience with this configuration. Maybe it only works through GPIB?

[LaurentR]

I have a 34401A and use them at work.  I have ran them with RS232 but normally just use the GPIB.     

Basically, flow control doesn't work.

This does not tell me much.   The meter does support hardware flow control using DTR/DSR.    I assume this is what you are using, your FTDI adapter supports those signals and your cable is wired correctly.    So when you look at the handshake signals, do you see them switch correctly?

From what I can tell, it's really a Matlab issue. BenchVue/DMM Utility work fine. Matlab works fine if you pace the commands. However, back-to-back commands seem to just get dropped at the DMM. The NI I/O tracer sees the requests, but bytes don't get returned.

The Matlab documentation mentions they do not support DTR/DSR flow control. From the Matlab forum message linked above, it looks like Matlab just ignores the DSR/DTR flow control capability and thus sets the port for no flow control but still proceeds with sending stuff at full blast.

[LaurentR]

What flow control does MatLab offer?

They claim to support RTS/CTS (and xon/xoff, which I guess is not relevant here). Could RTS/CTS on the FTDI get rewired to DTR/DSR on the 34401A (and change the driver's flow control so that it reports RTS/CTS)?

[thmjpr]

Can you post the few lines that would cause the problem?

Originally I had a bluetooth connection and ran into the problems mentioned in that forum and the manual for DTR. So I switched to hardwired connection for now, until I get a better BT module.

I tried this and don't see any errors:

Code: [Select]

fprintf(obj1, 'DISP:TEXT ''TEST 1234''');
data = query(obj1, 'MEASure:VOLTage:AC? 10,0.003' )
fprintf(obj1, 'DISP:TEXT ''TEST 12345''');
data = query(obj1, 'MEASure:VOLTage:DC? 10,0.003' )
fprintf(obj1, 'DISP:TEXT ''TEST 123456''');
data = query(obj1, 'MEASure:VOLTage:AC? 10,0.003' )

for i=1:n
    data = query(obj1, 'MEASure:VOLTage:DC? 10,0.003' );
    read(i) = str2double(data);
    c = clock;
    time(i) = c(6);
end

This is just using straight serial commands so it may be slightly different than going through VISA/matlab drivers. In that loop I am getting a read every ~73ms (13Hz). Maybe my setup is too slow to see the problem? Matlab 2011b, w/ CH340 serial adapter, 9600 baud, 8 bit, 2 stop bit.

[LaurentR]

Can you post the few lines that would cause the problem?
...
This is just using straight serial commands so it may be slightly different than going through VISA/matlab drivers. In that loop I am getting a read every ~73ms (13Hz). Maybe my setup is too slow to see the problem? Matlab 2011b, w/ CH340 serial adapter, 9600 baud, 8 bit, 2 stop bit.

Thanks for the response. If I execute your code as is, all the query time out.
However, if I add a pause(0.1); before every query, it all works fine.

What opening sequence do you use to create obj1? I am going through a serial object to avoid the Visa layer (but it's the same if I call a Visa object). Do you set any parameter? I tried pretty much every config of parameters, but nothing works better.

BTW, which FW do you have? Mine is a somewhat old 10-05-02.

[thmjpr]

Thanks for the response. If I execute your code as is, all the query time out.
However, if I add a pause(0.1); before every query, it all works fine.

What opening sequence do you use to create obj1? I am going through a serial object to avoid the Visa layer (but it's the same if I call a Visa object). Do you set any parameter? I tried pretty much every config of parameters, but nothing works better.

BTW, which FW do you have? Mine is a somewhat old 10-05-02.

That is odd. With the default visa setup, the timeout seems to be 2s (at least in the config it shows that). In matlab the default value is obj1.timeout = 10 seconds (http://www.mathworks.com/help/matlab/matlab_external/timeout.html).
I only set baud rate and stop bits. Attached the file.

Same firmware version.

[LaurentR]

That is odd. With the default visa setup, the timeout seems to be 2s (at least in the config it shows that). In matlab the default value is obj1.timeout = 10 seconds (http://www.mathworks.com/help/matlab/matlab_external/timeout.html).
I only set baud rate and stop bits. Attached the file.

Same firmware version.

Your exact code just hangs on the first access...
Can you print what get(obj1) says on yours? I'd be interested to see if there is any default parameter difference.
Mine looks like this:

Code: [Select]

>> get(obj1)
    ByteOrder = littleEndian
    BytesAvailable = 0
    BytesAvailableFcn =
    BytesAvailableFcnCount = 48
    BytesAvailableFcnMode = terminator
    BytesToOutput = 0
    ErrorFcn =
    InputBufferSize = 512
    Name = Serial-COM9
    ObjectVisibility = on
    OutputBufferSize = 512
    OutputEmptyFcn =
    RecordDetail = compact
    RecordMode = overwrite
    RecordName = record.txt
    RecordStatus = off
    Status = open
    Tag =
    Timeout = 10
    TimerFcn =
    TimerPeriod = 1
    TransferStatus = idle
    Type = serial
    UserData = []
    ValuesReceived = 0
    ValuesSent = 67

    SERIAL specific properties:
    BaudRate = 9600
    BreakInterruptFcn =
    DataBits = 8
    DataTerminalReady = on
    FlowControl = none
    Parity = none
    PinStatus = [1x1 struct]
    PinStatusFcn =
    Port = COM9
    ReadAsyncMode = continuous
    RequestToSend = on
    StopBits = 2
    Terminator = LF

Note that I just managed to get my setup to work properly, but it takes rewiring of my null modem cable (see next post). Would still be happier to see a sw fix...

[LaurentR]

That's where I was heading with it.

After a few attempts and dealing with more Matlab oddities, this actually seems to work. I rewired the null modem cable so that the 34401A's DTR/DSR is instead fed to the CTS/RTS pin of the PC, forced the flow control to be hardware (i.e. CTS/RTS in Matlab) and it all seems to work now. I have had a few odd behavior I have to investigate, but otherwise, it's generally not timing out anymore and a quick probing of the DTR/DSR from the 34401A shows flow control indeed asserted regularly. I'll do a full race with serial stream and flow control if I find the time.

Thanks!

[thmjpr]

Its exactly the same as yours. Good that you've got the flow control mod working.

Code: [Select]

K>> get(obj1)
    ByteOrder = littleEndian
    BytesAvailable = 0
    BytesAvailableFcn =
    BytesAvailableFcnCount = 48
    BytesAvailableFcnMode = terminator
    BytesToOutput = 0
    ErrorFcn =
    InputBufferSize = 512
    Name = Serial-COM7
    ObjectVisibility = on
    OutputBufferSize = 512
    OutputEmptyFcn =
    RecordDetail = compact
    RecordMode = overwrite
    RecordName = record.txt
    RecordStatus = off
    Status = open
    Tag =
    Timeout = 10
    TimerFcn =
    TimerPeriod = 1
    TransferStatus = idle
    Type = serial
    UserData = []
    ValuesReceived = 0
    ValuesSent = 16

    SERIAL specific properties:
    BaudRate = 9600
    BreakInterruptFcn =
    DataBits = 8
    DataTerminalReady = on
    FlowControl = none
    Parity = none
    PinStatus = [1x1 struct]
    PinStatusFcn =
    Port = COM7
    ReadAsyncMode = continuous
    RequestToSend = on
    StopBits = 2
    Terminator = LF

[LaurentR]

Its exactly the same as yours. Good that you've got the flow control mod working.

Totally weird. Actually, without flow control, I am not even sure how yours works at all
What RS232 cable do you have? A plain FTDI with a null modem cable/dongle?

[thmjpr]

CH340 with a null modem adapter. Its a chinese designed ultra cheap 232 IC (<50c in quantity).

Maybe I am incredibly lucky and they wired the cable incorrectly at the factory.
It would make up for last time where a serial stream would die after about 10s due to a missing filter cap (the QC testing was probably someone typing a couple characters on a keyboard).

http://www.dx.com/p/usb-rs232-cable-622#.VMCjFC6BDbc
http://wch-ic.com/product/usb/ch340.asp

[LaurentR]

CH340 with a null modem adapter. Its a chinese designed ultra cheap 232 IC (<50c in quantity).

Maybe I am incredibly lucky and they wired the cable incorrectly at the factory.
It would make up for last time where a serial stream would die after about 10s due to a missing filter cap (the QC testing was probably someone typing a couple characters on a keyboard).

http://www.dx.com/p/usb-rs232-cable-622#.VMCjFC6BDbc
http://wch-ic.com/product/usb/ch340.asp

Nice. I wonder if your Chinese USB<>RS232 is not just dealing with flow control by itself while the FTDI chip leaves it to software and Matlab doesn't support it. Time to go to my local Fry's, grab a bunch of different brand adapters (not FTDI-based) and give them a try...

[LaurentR]

Quick note to close my investigations:

I tried a bunch of other USB>RS232 cables. They all seem to be FTDI, CH340 (what thmjpr has) or Atten. All in all, there is no major difference, they all fail at one point or another. It seems that the 34401A asserts flow control on write commands and if a read command is sent in that window, the response is lost. Most write commands work ok as they are immediate or close. But something like *RST that takes a while systematically trips all serial adapters, e.g. a *RST followed by a MEAS:CURR:DC?. The response to the measurement read times out.

On the other hand, the RS232 trick of rerouting the DTR/DSR pins of the 34401A to the RTS/CTS pins of the serial adapter (and setting 'FlowControl' to "Hardware') seems to work flawlessly.

DTR/DSR flow control seems to be clearly obsolete now, and even though the 34401A uses it and the Visa drivers support it, neither Windows nor Matlab support it and I don't think it'll change, so the hardware work-around seems to be the only real option.