LabVIEW VI for control TMCM 610 via USB?

[Olav Kahlbaum (TRINAMIC)]

Please try to reset the module to factory defaults first adn then try the update again. If it should not work via the USB interface then please try to use the RS232 interface of the module for updating.

Reading out the actual position of a motor can be done using the GAP 1, <axis> command. Please see the TMCL reference manual for details (chapter 3.6 and 4.1).

[gary-wagner]

Hello Olav (or other TRINAMIC or TMCM-610 board users),

I'm not clear on your recommended approach for USB control of the 610 module. Is it not possible to communicate with the 610 module directly from a LabVIEW program via USB? (Without a USB to RS-232 conversion?)

In my application, I have successfully written a LabVIEW program to control 4 TMCM-610 controller modules (with 6 axes each = 24 axes total). This LabVIEW program uses RS-232 communications. The first 610 board connects to the computer COM1 port, but the other 3 TMCM-610 boards connect via USB through individual USB/RS-232 converters.

My problem is that I am writing/reading these COM ports at a very high rate (maybe every 150 - 200 msec to each port), to continuously cycle motors. The communications via the COM1 port result in acceptable performance where there is about a 1 second delay (i.e. dwell) at the end of each motor cycle. For the 610 boards connected via the USB/RS-232 converters, this delay can be as great as 6 to 8 seconds (if I have all 6 axes driving motors), apparently due to the USB/RS-232 converters. The LabVIEW subroutines that control each of the 610 boards are in parallel in the main program, but since this is not truly multi-threaded, when I load one 610 board with motors it also slows down the other board communications.

I'm thinking I have 2 possible solutions. Revise the LabVIEW program to use USB communications to the 610 boards, or install a board in the computer with 3 COM ports and keep the RS-232 communications. Both of these solutions would eliminate the need for the USB/RS-232 converters. Please let me know your thoughts on this. Thanks!

Gary Wagner

[Olav Kahlbaum (TRINAMIC)]

I think that there are the following choices:

1) Do it as written in the second article of this thread, where I have described how the USB port of the TMCM-610 module can be used like a virtual COM port. You can then use RS232 communication via the USB ports, but without you USB-to-RS232 converters. And you don't have to change anything in your LabViwe program (except the COM port names).

2) Use an RS232 card in your computer (also easy, but communication will be a little bit slower).

3) Use the old USB protcol of the TMCM-610 devices. I would not recommend to do this, as you will have to change quite a lot in your LabView program then.

[gary-wagner]

Thanks so much for the fast reply Olav.

I was thinking your first choice would not offer an improvement over my present setup with the external USB/RS-232 converters. If I configure the TMCM-610 USB port to appear as a virtual COM port, I simply would be moving the USB/RS-232 conversion on to the 610 board and believe I'd see the same communications delays as I have now. Is that not true?

I'd like to consider your third choice. Could you point me to the documents / drivers available for using the USB protocol? Once I become familiar with what the LabVIEW program changes are that I would have to make, I could decide whether this approach would take too much time or not.

Thanks - Gary

[Olav Kahlbaum (TRINAMIC)]

That's not quite right. The TMCM-610 uses the FD245BM chip, which has a parallel bus interface to the CPU. So it is not USB-to-RS232, but USB to microcontroller data bus. It is always fast (you can select any baud rate, but it always works with maximum speed).
Using the third choice works on the module just the same way as the first one (an also uses the same driver in Windows), so it will not give you any improvement over the first one. It is just a different protocol, and also this will not give you any improvement. So I would really recommend using the first choice.

[gary-wagner]

OK - I understand now. Today I downloaded the TMCM-610 USB Driver, connected a USB cable to the 610 board, and installed the driver with the Found New Hardware Wizard. (I am running WindowsXP). I was able to find the board in the TMCL-IDE program (listed as a USB board), and checked the firmware version (it was v6.31). I downloaded firmware v6.35 and installed it successfully on the 610 board. I then sent the command to switch to the RS-232 protocol. I could no longer communicate to the board via USB after this command was sent, so I believe it worked properly. I actually successfully performed these steps on all 4 TMCM-610 boards I am using.

However, I could not see any of the boards as COM ports in the TMCL-IDE program under the RS-232 type. I reviewed the steps you suggested for the other customer in this thread that had the same problem, but was not able to achieve success. In the Windows device manager > driver details, I do not see an Advanced Tab to allow me to select "Load VCP". I also deleted previous FTDI drivers from my computer to be sure to use the latest driver I installed. I also looked in the INF file, but did not see a line already with "Product ID" (to modify to 0xEF10 as you have suggested in this thread). I downloaded the TMCM-610 USB Driver zip file from the TMCM-610 product page. Is this the driver I need? When I look at the driver details it shows FTDI 1.6.6.0 with a date of 10-30-03, which seems fairly old.

For the weekend, I was able to return to control via the regular 610 board RS-232 port and all 4 boards work properly. Do you have any other ideas for me to try on Monday to get the USB virtual COM port working?

Thanks - Gary

[Olav Kahlbaum (TRINAMIC)]

I will have to take a look at the FTDI driver. I will put the latest one from FTDI configured for the TMCM-610 also onto our website (but I will also leave the old one there).

[gary-wagner]

I did finally get the TMCM-610 boards to appear as COM ports. Here is what I did...

I downloaded an uninstaller from the FTDI website as I believe the uninstalls I did previously were not complete. The uninstaller file name is CDMUninstaller_v1.4.zip. With this uninstaller, you are able to enter the product ID you want to uninstall. I entered PID EF10 as well as PID 6001 (as I had earlier installed a USB converter that used a similar driver). I did get a confirmation that both drivers were uninstalled.

I then downloaded the latest driver from the FTDI site, CDM20808.zip and changed the product ID to EF10 (from 6001) in both the ftdiport.inf and ftdibus.inf files that are included in the zip file. When I plugged in each TMCM-610 board (I am using 4), I installed this modified driver for each board via the Found New Hardware Wizard.

The boards then appeared in the Device Manager list of COM ports. The good news is that I am now controlling the 4 TMCM-610 boards via USB as COM ports. The bad news for me is that the motor cycle program is still running slower than desired as I continuously access the boards to check motor status and command moves for all 6 axes. Moving to USB direct from USB/RS-232 converters did improve my system response time, but I need to speed up the cycle rate more. I'll have to review my LabVIEW program to see if I can design in a bit more efficiency.

[gary-wagner]

I am using 4 TMCM-610 boards to continuously cycle 6 stepper motors on each board. I seem to have hit a limit on how fast my LabVIEW program can cycle these motors. I am sending commands to the TMCM-610 board (now via USB/Virtual COM port, originally via RS-232) regularly at intervals of 100 to 300 msec (estimated). The program execution / cycle rate is slower than anticipated and I'm not sure where the delays are coming from.

Question - how fast does the TMCM-610 board respond when queried (via RS-232 and via USB/VCP). That is, how many milliseconds after I send a status request to the board should the response be available at the PC COM port?

Thanks - Gary

[Olav Kahlbaum (TRINAMIC)]

Command proecessing on our modules is quite fast. On the AVR based modules (like the TMCM-610) somewhere between 2ms and 4ms (depending on the command), on the newer ARM based modules around 10 times faster.
But you will have to take into account how long it will take to send the command to the module and to send back the answer. For RS232 this is easy to calculate: 1/Baudrate * 10 Bits * 9 Bytes for the command, and the same for the answer (we have to take into account the start bit and the stop bit, so this makes 10 Bits per Byte). So for 9600bps this would be 1/9600*10*9=9.375ms for sending the TMCL command to the module and the same time for sending back the data.
For a USB VCP it is not that easy to say. The FTDI chip is a USB1.1 full speed device, and it is connected to the AVR processor using the 8 bit parallel data bus, so there is no limiting caused by USB-to-RS232 conversion. The FTDI VCP driver can do up to 300kB/s, but a problem with USB is that there is some overhead when changing the data direction, which drastically limits the speed (waiting for the next time slot).