Communicate with motion controller through a USB port

[SegFault1119]

Hello,

I asked this question already but I missed the guidelines for posting and got no response, so I'm gonna follow it closely this time. Also, this is my second week using LabView so please excuse me if I don't make sense.

I'm trying to communicate with a stepper controller unit through a USB port. Originally, I used an Arduino and outputting HIGH/LOW to the controller's input pins, and it worked. The project recently got changed and now, I must communicate with the controller directly by sending ASCII (please see the attachment below for the manual pages). I went through the tutorial of configuring the port using NI Device Wizard and had the .INF file installed. However, the device shows up in MAX as a serial port instead of USB port. So, my first question is How do I know if LabView is correctly communicating with the controller/If I successfully configured the COM port? I tried writing *IDN?\n to the controller using VISA Test Panel and return data showed no error with return count: 6 bytes. However, nothing happen when I wrote a command to the controller. Also, the tutorials I saw were for Windows 8 and previous versions of LabView so I'm not sure if I even needed to go through all that in the first place.

I'm using Windows 10, Labview 2017, and the controller is DPY50611 from Anaheim Automation.

Thanks in advance!

[Bob_Schor · Accepted solution]

If you have a Device that you want to use with LabVIEW, you need to meet MAX, NI's Measurment & Automation Explorer.  If you don't have a MAX icon on your desktop, you should find it (it's called NI MAX) under the list of Programs in Windows 10 (under the N's, of course).

Before getting started with MAX, did you install the VISA Drivers when you installed LabVIEW?  [I'm assuming the answer is "Yes", as you seem to have some VISA functions available to you.

So open MAX.  Find your device in Devices and Interfaces.  Double-click your DPY50611 Port, and you should see the right-hand pane appear with the Port settings.  

Start playing around.  If it is a VISA device, you'll have things like Baud Rate, Parity, Stop Bits, etc., and should also have a section that is more "communication" related, such as does the device use a Termination Character (typically a Line Feed, 0A) when sending data out.  You should then be able to go to a section that lets you send characters ("commands") to the Device and read what it sends back to you.  This is an excellent way to "get acquainted with your Device".

The Manual page you sent talks about sending commands, but says little about receiving responses.  You aren't using Hyperterminal, you are using MAX.  So once you have things set up, send "@0\r" (the characters "\r" will be interpreted by MAX as <Carriage Return>).  You should then send "@0$\r" to try to get a response from your unit.  [Note I'm assuming you are talking to Unit 0].

Play around and verify that MAX can talk to your unit, and can receive messages as well.  Once you've established this, you only have to do the same thing using VISA functions.  Configure using VISA Configure Port, then use VISA Write and VISA Read with appropriate String Inputs and Outputs.  If your device uses a Termination Character on outputs (which most do), be sure to configure VISA to use this (you need to look at the Help for Configure Port to see which unlabeled Terminal does this), then configure your VISA Read to read, say, 100 bytes -- it will read until the Termination character, then stop, a much safer way to read than using "Bytes at Port".

Give it a try.  If you need to come back with more questions, do not post pictures of LabVIEW code, post the actual VIs.  If you need to post an image of MAX, or a VISA Port Configuration, be sure to show everything.

Bob Schor  

[natasftw]

As the VISA Test Panels are in MAX, it's safe to assume you have both installed VISA and found MAX (you also mention MAX in your post).

The *IDN?\n command you reference is a common loopback command.  You're sending that out and asking for a reply.  You get that back successfully.

That tells us a few things:

1) The software configuration you have works

2) You know the interface to send commands to the controller

3) The controller can receive and read your commands

Here's where we need to figure things out.  You said it doesn't work if you send a command.  We've already shown it does.  That means the actual problem comes down to it's not responding to a different command you're trying to send.  For this, we need to try to figure out why.  To do that, we need to know what command you're sending exactly.  I suspect you're missing something trivial like a termination character.  By not including that character, the controller thinks it still needs to listen for the command so it doesn't start acting.  In the IDN command we saw prior, we used the end of line character.  Have you tried adding the \n to the end of your command to see if that changes the behavior?

Also, a fun fact for you.  The S in USB stands for "Serial."  The reason you're seeing this as a serial device is because it is in fact a serial device.  Whether it's using the DB9 connector you likely associate with serial, UART, USB, or one of the connections that look similar to Ethernet, they're all just serial.  If you want to talk to the device, you need to treat it like a serial device.  The type of connector is no longer important once you know that you've got a working connection.  The protocol becomes the piece that's missing.

[SegFault1119]

Thanks for responding guys!! 

It was the carriage return, "\r". I assumed that VISA would automatically include it for every command. Now, everything works except for a read out error. Originally, I followed a tutorial and had the byte count for VISA read out at 1024, and I got the error -1073807339  with possible reason: VISA:  (Hex 0xBFFF0015) Timeout expired before operation completed. When I changed the byte count to 10, the indicator showed no error but only the first part of the message returned and the second part returned in the next run. So, I increased the byte count and still had the same problem, but this time the error -1073807339  showed up after a few executions. I've attached my .vi file and a snapshot of my port setting below. I've verified the setting with the unit manual and it's correct.

 Thanks!

[Bob_Schor]

I'd appreciate your testing the code I attached, which I call "Testing DPY (BS), on your system.  I took it largely from your code, but used the techniques that I tried to describe to you in my earlier post, including the use of the Read Terminating Character.  If it errors out, try changing the Termination Character from Hex A (<LF>, \n) to Hex D (<CR>, \r).

Bob Schor

[SegFault1119]

Bob,

I'm not sure if I changed the termination char correctly(probably not) by changing "A" to "D" at the VISA serial block. From Google search, it seems like A is the default and to modify/add new termination chars, I need to add a Serial Property Node. Anyway, Labview gave the same error when I executed the program with A/D. 

Also, when I used VISA Test Panel with the Termination Character set at Line Feed -\n, Value xA, the read returned SMC60\rV3.04\r which was to be expected. It produced the same error as when executing in Labview. When I changed the Termination Character setting to Carriage Return -\r, Value xD, the read returned SMC60\r for the first execution and V3.04\r for the second execution with no error. For the third read without write, I got the same error.

Thanks for your help so far!

[Bob_Schor]

OK, I'm at work now, and I've got a Balance that I can "talk to" using VISA.  I open MAX and configure it as follows:

• I/O Settings:  Send End on Writes = False, Suppress End on Reads = False, Enable Termination Character = True, Termination Character = Line Feed.  Be sure to push "Apply Changes".
• I go to Input/Output tab.  My device's "ID" Command is "@", and it terminates with \r. 
• I Clear Buffer, Clear (device), enter @\r\n, and push Write.  The system says Byte Count = 3.
• I push Read.  VISA returns a status of 0x3FFF0005, Termination Character Read.  I have a 19-byte string that looks like an ID string, ending in \r\n (which is expected).

I'm not sure you did all these steps, which work for me in MAX, and work for me when I program the device in LabVIEW (using Write followed by Read of 1024 characters, with, in one case of setups, a 50 msec delay before the read, but otherwise no delays).

So what works in MAX works in code.  I never check Bytes at Port, and never hardly ever get errors (these are old balances, located 4 floors away, sending over a Serial-to-TCP/IP concentrator over the campus network, ...).  If you follow a similar procedure, it should work for you ...

Bob Schor

[SegFault1119]

Hi Bob,

I followed your configuration and still got the same error. I read the manual again and I found this line "Note: In direct talk mode each command is followed by a carriage return." This means that the termination character should be \r. The command that I used for testing was returning "something"\r +"something else" \r. So when the termination char set to \n, LabView couldn't find the term. char; and hence, the error. When the term. char set to \r, LabView read "something"\r and stopped there. Besides that command, all other commands will only return an int with max value being 9,999,999.

I wonder if there is a way to check if the read buffer is empty. I remember C/C++ allows us to check for NULL. Also, I will be using the outputs from the commands, so could you provide a hint on how I'd go about that. If the read returns a string then maybe I have to store them in an array of some sort?

Anyway, I'm greatly appreciate all your helps. I will mark your initial reply as the solution for this post. If you come up with something else, please share it on here :). I will post my finding if any.

Cheers!

[SegFault1119]

Hi Bob,

I found the problem (it was me 😉 ). The return string from the device has no line feed (\n). When I first wrote my program in Labview, I enabled the term char (\r) at the beginning of the program, i.e. before write, read, and such; I thought this would apply to both write and read but it didn't. Anyway, my program is working now :D.