VISA Read Error - Timeout expired before operation completed

[Zuol]

I have a AutomationDirect STP-MTRD-17038RE motor/drive that I am trying to communicate with in LabVIEW using VISA serial commands with the drive connected to my PC via a serial to USB adapter. I am able to use the software provided with the drive (SureMotion Pro V1.0.4) to send and receive packets from the drive. It operates as expected using their software. I have gotten to the point of being able to configure the COM port correctly and send commands to the drive in LabVIEW. The documented commands work as expected and the drive responds to all my commands sent via the VISA Write VI. Although anytime I call the VISA Read VI, I get the Timeout error. 

I have also successfully used puTTY terminal to send and receive packets so I know that my hardware is all working properly and that its likely some sort of configuration of the port that is causing the issue.

I've piggy backed off the following forum posts in order to get to this point. I had to do things such as send the "HR" command to open an session and close it with the "QT" command. This was the magic that enabled me to even be able to send commands but I'm still stuck on reading any feedback from the drive. 

https://forums.ni.com/t5/LabVIEW/how-to-control-STP-DRV-4850-Stepper-Drive-in-labview/td-p/2324578

https://forums.ni.com/t5/LabVIEW/how-to-control-automation-direct-stepper-motor-stp-drv-4850-and/td-...

I've been using the VISA Interactive Control to test out different configuration but to no avail. 

I'll include my LabVIEW VI as well as screenshots of my VISA Interactive Control .

Any feedback or suggestions is much appreciated. I can probably manage with just being able to send commands for my project but I would really prefer having some motor feedback. Thanks!

[Zuol · Accepted solution]

Well... as it turns out I solved my issue on my own. I am posting this follow up so that if anyone comes across this problem again with AutomationDirect servos, this should serve as a good reference. 

Apparently the servo drive was expecting a specific designator at the beginning of every command in order for the drive to know which motor is providing the response in the case of having multiple motors on the same network. For some reason, it would accept the commands as I write them without the designator but it would not send back the drive response packet if it was not included. The drive default was set to "1", so I just appended a "1" to the beginning of every command and the read function worked like a charm. 

I'll include my final VI for reference.

[JÞB]

Outstanding! Another poster converted to the RTFM enthusiasts group:D

[billko]

---

@Zuol wrote:

Well... as it turns out I solved my issue on my own. I am posting this follow up so that if anyone comes across this problem again with AutomationDirect servos, this should serve as a good reference. 

Apparently the servo drive was expecting a specific designator at the beginning of every command in order for the drive to know which motor is providing the response in the case of having multiple motors on the same network. For some reason, it would accept the commands as I write them without the designator but it would not send back the drive response packet if it was not included. The drive default was set to "1", so I just appended a "1" to the beginning of every command and the read function worked like a charm. 

I'll include my final VI for reference.

---

Thank you for being thoughtful enough to post your solution so that others can benefit.  That's awesome.  🙂