34401A through RS232 with Matlab? - Page 1
Forum section: electronics / testgear

author: LaurentR
author_rank: Frequent Contributor
timestamp: January 19, 2015, 02:46:23 am
content: 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 foundThis post on the Matlab forumtalking 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?

author: LaurentR
author_rank: Frequent Contributor
timestamp: January 20, 2015, 02:10:42 am
content: Quote from: joeqsmith on January 20, 2015, 01:41:33 amFrom 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.

author: LaurentR
author_rank: Frequent Contributor
timestamp: January 20, 2015, 02:22:19 am
content: Quote from: joeqsmith on January 20, 2015, 02:15:19 amThey 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)?

author: thmjpr
author_rank: Regular Contributor
timestamp: January 20, 2015, 04:37:19 am
content: 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: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:ndata = query(obj1, 'MEASure:VOLTage:DC? 10,0.003' );read(i) = str2double(data);c = clock;time(i) = c(6);endThis 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.

author: LaurentR
author_rank: Frequent Contributor
timestamp: January 20, 2015, 06:12:42 am
content: Quote from: thmjpr on January 20, 2015, 04:37:19 amThanks for the response. If I execute your code as is, all thequerytime out.However, if I add apause(0.1);before everyquery, it all works fine.What opening sequence do you use to createobj1? 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.

author: thmjpr
author_rank: Regular Contributor
timestamp: January 22, 2015, 06:43:02 am
content: Quote from: LaurentR on January 20, 2015, 06:12:42 amThat 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.

author: LaurentR
author_rank: Frequent Contributor
timestamp: January 22, 2015, 06:55:51 am
content: Quote from: thmjpr on January 22, 2015, 06:43:02 amYour 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:>> get(obj1)ByteOrder = littleEndianBytesAvailable = 0BytesAvailableFcn =BytesAvailableFcnCount = 48BytesAvailableFcnMode = terminatorBytesToOutput = 0ErrorFcn =InputBufferSize = 512Name = Serial-COM9ObjectVisibility = onOutputBufferSize = 512OutputEmptyFcn =RecordDetail = compactRecordMode = overwriteRecordName = record.txtRecordStatus = offStatus = openTag =Timeout = 10TimerFcn =TimerPeriod = 1TransferStatus = idleType = serialUserData = []ValuesReceived = 0ValuesSent = 67SERIAL specific properties:BaudRate = 9600BreakInterruptFcn =DataBits = 8DataTerminalReady = onFlowControl = noneParity = nonePinStatus = [1x1 struct]PinStatusFcn =Port = COM9ReadAsyncMode = continuousRequestToSend = onStopBits = 2Terminator = LFNote 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...

author: LaurentR
author_rank: Frequent Contributor
timestamp: January 22, 2015, 06:59:37 am
content: Quote from: joeqsmith on January 20, 2015, 02:28:48 amAfter 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!

author: thmjpr
author_rank: Regular Contributor
timestamp: January 22, 2015, 07:03:04 am
content: Its exactly the same as yours. Good that you've got the flow control mod working.Code:K>> get(obj1)ByteOrder = littleEndianBytesAvailable = 0BytesAvailableFcn =BytesAvailableFcnCount = 48BytesAvailableFcnMode = terminatorBytesToOutput = 0ErrorFcn =InputBufferSize = 512Name = Serial-COM7ObjectVisibility = onOutputBufferSize = 512OutputEmptyFcn =RecordDetail = compactRecordMode = overwriteRecordName = record.txtRecordStatus = offStatus = openTag =Timeout = 10TimerFcn =TimerPeriod = 1TransferStatus = idleType = serialUserData = []ValuesReceived = 0ValuesSent = 16SERIAL specific properties:BaudRate = 9600BreakInterruptFcn =DataBits = 8DataTerminalReady = onFlowControl = noneParity = nonePinStatus = [1x1 struct]PinStatusFcn =Port = COM7ReadAsyncMode = continuousRequestToSend = onStopBits = 2Terminator = LF

author: LaurentR
author_rank: Frequent Contributor
timestamp: January 22, 2015, 07:06:34 am
content: Quote from: thmjpr on January 22, 2015, 07:03:04 amTotally weird. Actually, without flow control, I am not even sure how yours works at allWhat RS232 cable do you have? A plain FTDI with a null modem cable/dongle?

author: thmjpr
author_rank: Regular Contributor
timestamp: January 22, 2015, 07:25:44 am
content: 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#.VMCjFC6BDbchttp://wch-ic.com/product/usb/ch340.asp

author: LaurentR
author_rank: Frequent Contributor
timestamp: January 22, 2015, 07:38:19 am
content: Quote from: thmjpr on January 22, 2015, 07:25:44 amNice. 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...

author: LaurentR
author_rank: Frequent Contributor
timestamp: January 26, 2015, 12:46:26 am
content: Quick note to close my investigations:I tried a bunch of other USB>RS232 cables. They all seem to be FTDI, CH340 (whatthmjprhas) 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.