How can I communicate with a USB instrument which is not VISA?

I need to control a USB stepper motor controller which is not a VISA instrument. How can I use USB without VISA?

Answer 1

[Walter Roberson]

USB devices can often be opened as serial ports. If the device does not support VISA, then you will need to research the protocol.

If it is a line-oriented protocol then matters are often not so bad, but even with line oriented protocols, some devices have a fairly complicated command structure.

Some USB devices communicate with fixed length binary packets but still compatible with serial drivers. Sometimes the interfaces for these are fairly simple and sometimes the interface can get fairly complicated.

This approach requires that the device be willing to communicate with RS232 or TTL emulation. This approach does not work if the USB device registers itself as an audio or video device, or as a bulk data device (e.g. like a disk drive.) It is not possible to communicate directly from MATLAB to arbitrary USB devices: to work with such devices you need code that talks to the USB controller, giving USB controller commands and retrieving results, which requires a binary packet structure that cannot be created at the MATLAB level.

MATLAB also does not support any way of sending the USB controller a "push" packet, which effectively limits the number of back and forth serial interactions per second, as the USB drivers will wait for a while assuming that more serial data might arrive, only dispatching the packet when it fills up or a timeout occurs. The serial flush operation supported by MATLAB does not force the data to be sent: the serial flush operation is to remove any pending output from the output buffer.

[Patrick Johnston]

Sorry for my ignorance... it's been a couple decades since I had to do my own data acquisition programming... perhaps spoiled by Ubiquitous Serial Bus Plug&Play behavior, I was expecting that using USB with an instrument would be much more "standardized" than you describe... it seems to be the Unfriendly Serial Bus, rather than Universal Serial Bus...

the youngsters are after me to "do it in Python" but I have only a few years left, and am not interested in learning a new programming environment, when I already have some experience with Matlab, and it seemed to me to be fully capable... and, after all, USB means "Universal" Serial Bus... it should be pretty transparent, right?

WOW!... I just received an email awarding me a Thankful Level 1 Badge for accepting your answer... I haven't felt this good since getting a gold star sticker on my perfect spelling test in fifth grade... think I'll go top off my coffee mug and celebrate... Badges?... we don't need no stinking badges... what we need is answers...

Thank you, Sir, for your answer. Clearly, I do not yet know enough to make use of it, so back to the grindstone...

[Walter Roberson]

If you indicate exactly which device you are using then we could research the interface protocol it needs.

[Patrick Johnston]

It's an Arcus PMX-4EX-SA 4-axis stand-alone stepper motor controller, with USB and RS485 ports. We (meaning a grad student intern, who is now gone) tried using the 485 via a USB/485 dongle, with no success. It's possible that the student's lack of experience also came into play.

I have a 2013 document that claims that Arcus has a library for MATLAB, among many others listed, but have not found it on line. Earlier today, I sent an inquiry to Arcus regarding Matlab access... have not received a response yet.

BTW, we're trying to access from a Windows 7 machine using Matlab 2017b.

[Walter Roberson]

The manual available from https://www.arcus-technology.com/support/downloads/download-info/pmx-4ex-sa-manual/ lists a fair number of ASCII commands, and also describes a different command language for creating programs to be stored on the device. The list goes on a couple of pages in each case, so a non-trivial question becomes what you want to do with the device once you have it under control.

The document describes a Windows GUI that provides a command and status interface to the device. Are you able to talk to the device with their GUI?

[Patrick Johnston]

We can control the device nicely with the GUI they provide, but there is no obvious way to automate that with the frame-grabber data acquisition system. Of course, we expect to use that GUI for development of the particular sequence that needs to be automated.

I know the document you reference, and I understand the set of commands well enough. The last remaining trick is getting Matlab to send those commands to the device and read status from it.

BTW, I received a reply from Arcus... the third party Matlab sample source was removed from their site because it had some issues in a 64-bit environment. (which is us). He gave me a link to access it, but could not promise any Matlab-specific support

[Walter Roberson]

With regards to USB: You should probably think of USB as being closer to a half duplex computer network specification than it is to being just a "serial port".

The individual operations take place too quickly and with too tight of timing requirements for it to be practical for a user-level computer program to control the bit sequence over the serial bus, so there is a microprogrammed controller that takes care of all of the details. The user level program makes library calls that construct packets to be sent to the controller to instruct the controller what to do, and the controller takes care of all of the details of communicating with the multiple devices, including deciding which device has permission to communicate in which order and for how long.

USB supports a number of different kinds of devices, including:

• audio only (e.g., microphone)
• printers
• mice, joystick and other "Human Input Device (HID)"
• hard drives / mass storage
• combined audio and visual (e.g., webcam)
• billboards
• secure (encrypted) storage
• communications (e.g., serial port emulation)
• personal healthcare
• still image
• wireless controller

Each of those has protocols defined. For example, still image needs to be able to send back large blocks of data but the blocks are not real-time sensitive, so the controller tells it to send back part of the data at a time and wait for further instructions. This differs from microphone, for which there has to be a fixed bandwidth allocated for each controller cycle so that the data is transferred in a timely manner.

USB is not a free-for-all like ethernet is: devices do not just monitor the line and start trying to talk when they see the line is idle. Instead USB is a closely controlled master/slave relationship, like:

Controller: Are there any new devices since I last asked?
(devices: no response in time window because none of them are new)
Controller: device #3, do you have anything to send?
Device #3: No
Controller: device #7, do you have anything to send?
Device #7: Yes, I have 13718 bytes of disk data
Controller: device #8, do you have anything to send?
Device #8: Yes, I have 2183 bytes of serial data, and I have included the first 1016 bytes of it
Controller: device #9, do you have anything to send?
Device #9: Yes, I have 13718 bytes of audio data
Controller: device #10: do you have anything to send?
Device #10: No
Controller: Okay, device #9, send 4040 bytes of that audio data
Device #9: here is 4040 bytes of audio data
Controller: Okay, device #8, send 1016 bytes of that serial data
Device #8: here is 1016 bytes of serial data
Controller: That's all we had time for in this cycle, everyone else hold your horses

Controller: Are there any new devices since I last asked?
(devices: no response in time window because none of them are new)
Controller: device #3, do you have anything to send?
Device #3: Yes, I have 87 bytes of printer status reports, which I have included
Controller: device #7, do you have anything to send?
Device #7: I still have that 13718 bytes of disk data I told you about
Controller: device #8, do you have anything to send?
Device #8: Yes, I have 151 bytes of serial data, I have included the first 151 bytes of it
Controller: device #9, do you have anything to send?
Device #9: Yes, I have 10190 bytes of audio data
Controller: device #10, do you have anything to send?
Device #10: no
Controller: Okay, device #9, send 4040 bytes of that audio data
Device #9: here is 4040 bytes of audio data
Controller: Okay, device #7, send 2038 bytes of that disk data
Device #7: here is 2038 bytes of disk data
Controller: That's all we had time for in this cycle, everyone else hold your horses

Notice that only the controller is permitted to talk without being told to talk

Notice that some of the device types are permitted to include a portion of the data in the status packet but other device types are not permitted.

Notice that the controller has prioritized audio data and serial data over disk data, and has decided how much data should be sent in order to meet the prioritization goals negotiated (by a process not illustrated here.)

[Walter Roberson]

port = 'COM3';
cp = '@00';
s = fopen(port, 'BaudRate', 9600, 'Terminator', 'CR');
if ~strcmp(s.status, 'open')
  error('Failed to open USB port "%s"', port);
end

fprintf(s, [cp 'DN']);   %harmless command to provoke a response
junk = fgetl(s);   %read to terminator, possibly including junk
junk = fread(s, s.BytesAvailable);  %flush waiting stuff

Now go ahead and send all commands by printf(s), each time using cp as the command prefix. Or if you feel comfortable that the device name will never change, hard-code the @00 into each command.

Get responses by using fgetl(s) to get back an entire line (which you can then post-process), or by using fscanf(s, 'Format goes here') .

Using fscanf() is often more convenient, but it depends crucially upon the communications flow being exactly what you expect, which is probably not a good idea in this situation considering that there are limiters and that you might trigger ABORT or STOP.

My recommendation in dealing with serial devices in line-oriented protocols is to fgetl() each time, and then to analyze the text line you get back. If it has exactly the format you expect at that point in the code, then Great!, but if it does not, then you have a chance to handle the situation smoothly.

Remember to fclose(s) when you are done with it.

[Patrick Johnston]

WOW! Thanks! I take it that COM3 is somehow attached to the USB hardware... I won't get a chance to test this until, probably, tomorrow, but thank you, Mr. Roberson!

[Walter Roberson]

The GUI interface you were using should, I think, tell you which COM port is in use. Devices of this variety report their type as Communications devices, and implement "serial over USB". Serial over USB is close to being a raw stream of bytes presented as packets, but each packet also starts with a few bytes of emulated pin statuses like DTR.

Answer 2

[Nanda Gupta]

I understand that you are trying to use USB Stepper Motor Controller with MATLAB. Unfortunately, Instrument Control Toolbox does not support USB devices without VISA interface as mentioned in the following documentation link for USB devices and Support for Instrument Control Toolbox:

https://www.mathworks.com/products/instrument/supported/usb.html

One other way to communicate with this instrument could be to have an intermediate device that is supported by MATLAB and configure this device to talk to the stepper motor and MATLAB. Please note that this might just be one of the possibilities.

[Patrick Johnston]

Nanda, thank you for answering. I do not have any such intermediate devices as you suggest. Are you talking about an arduino or some such device? I am puzzled about why Matlab does not support general communication over USB... maybe there is some contractual deal with VISA companies... Well, what if there is a .dll of C/C++ routines... would Matlab allow calling of those routines?

What I am attempting to do is write a Matlab script which moves one or more stages via the stepper controller, and then grabs images from a frame grabber. The frame grabber in question is supported under the Matlab Vision Toolbox, but the motion controller is a bottleneck. Their software works just fine over USB, but it can't integrate with Matlab.

[Nanda Gupta]

Yes, Arduino could be one such intermediate device. The technical support can not quote as to why USB without VISA is not supported. However, if you have DLLs in C routine, you can use this with the help of 'loablibrary' function in MATLAB. The following link talks more about the same:

https://www.mathworks.com/help/matlab/ref/loadlibrary.html

[Walter Roberson]

In turns out that Arduino is not required for this particular device.