Different types of replies from module TMCM 351

[simistech]

Hi,

I am using TMCM 351 for a 3 axis application. I am using labview 7.1 for its front end and sending commands in binary form.

1. Usually I get replies in the form as said in the firmware manual. But when I send GGP command the last 5 bytes of reply comes as the first 5 bytes and 1st 4 bytes comes in the end. Why this is happening?

2. In some other case, I am sending 10 SGP commands at once puting it in a loop of 10 iterations. After every write I am reading the reply after a small delay. When I send 0109 0A02 0000 0A00 20, ie when my operand is 00000A00 i am not able to read the full reply. I have given bytes at port to be read. When i display bytes at port and return count after read i have 2 different values. Bytes at port will be 9 but return count will be 7. Only 7 bytes are read and diaplayed. The rest 2 bytes will be read in the next SGP command's reply and it will display all 11 bytes. This problem is found for values 00000A00 to 00000AFF. 00000B00 onwards it returns properply. Generally all other values are giving a 9 byte reply and all 9 bytes can be read. So I am really wondering what is wrong?

3. In one other place after GGP command I am giving a read for bytes at port. then it reads 1st 4 bytes. Then I have to read the next 5 bytes again to get the operand. This time the order of bytes are correct. The bytes at port will be 9 but return count of read operation will be 4. In one other place GGP returns all 9 bytes with last 5 bytes coming 1st as I said earlier.

4. Also I am sending a STOP command from labview while stand alone program is running. If the motor is rotating to a position when I send the stop command, it will not STOP immedietly. Only after reaching the position it will stop. Whether there is any posibility to stop immedietly and continue from the same command.

Hope you will reply soon.

Thanks
Simi

[Olav Kahlbaum (TRINAMIC)]

There are no different types of replies. The structure of the reply is always is the same. There are only two exceptions to this: reading the TMCL memory (for the "disassemble" function of the TMCL-IDE) and reading the firmware revision as a string. But you are not using these two commands.
For all other commands there is always the same reply.

1.-3. I think the problem you are observing must be in your COM port reading routine. Maybe you are trying to read the COM port too soon after you have sent the command so that the answer has not fully arrieved yet. This can result in mixing up answers of different commands. Please try to wait a short time between sending the command and trying to read the answer. Or, do not start reading from the COM port before all nine bytes of the answer have arrived.
The response times of the commands are not all the same, so this might explain why you are observing this problem only with some and not all commands.

4. The STOP command only stops the TMCL program, not the motor. You will also have to send an MST command then. Program execution can be continued from the next address on by sending a RUN command (command 129) with the type parameter set to 0.

[simistech]

Hi,

I have tried small delays to big delays. But its the same. I dont think delay is the problem. Even if delay was problem, how can the response time for SAP for different operands(the last 4 bytes before checksum) is different? That is why I am puzzled. Also bytes at port is shown as 9 which is the input of serial read. So serial read is suppose to read 9 bytes but only reads 7. So what can be the problem?

Thanks
Simi

[Olav Kahlbaum (TRINAMIC)]

The response time of some commands may be different, but the response is always sent in one go. So there should be no delays between single bytes of the response (regardless of the command). Please try it out using the direct mode dialogue of the TMCL-IDE.
I can't say why you are loosing some bytes in the communciation. The TMCM-351 (and all other TMCL modules, too) always send back nine bytes. But if bytes are getting lost, evaluation of the returned data will go wrong. Maybe there is a problem with the link between module and PC?

[G_geek]

Hello simistech,
sounds like there is something left in the receive buffer when you`ll send the new command...
You could try to use the "flush I/O Buffer" VI each time before sending a new command and then wait until all 9
bytes of the answer has been received.
This is how I do this for the GGP command:


You may try to "reprogram" this structure for LABVIEW 7.1 and check if it will work since I`m not able to provide the VI`s in Labview 7.1...

have fun
G_Geek

[Olav Kahlbaum (TRINAMIC)]

Thank you again, G_Geek!

[simistech]

Thanks G_Geek...

I still have to try it out. Will come back if problem continues...

Thanks
Simi

[simistech]

Hi

My questions 1-3 problem still exists. And specially for GGP command. As I said when we send GGP the reply's 1st 4 bytes will be coming as last 4 bytes. I dont think its a delay problem beacause i have tried using different delays. Finally I finished my front end with out using GGP command. Instead I used co-ordinate 20 to use as my variable.

I think this is a bug in the module. Also encoder connection given in the hardware manuel of TMCM 351 is wrong. It will be good if you can fix these problems.

Thanks
Simi

[Olav Kahlbaum (TRINAMIC)]

The problem must be somewhere in the RS232 receive routine of your LabView code. The module definitely always sends the same type of reply for all commands. The only exception is when getting the module type and firmware revision as a string and when reading the TMCL memory (commands 134 and 136 but you are not doing this). And these two command were sending back an extra byte until firmware revision 4.14. But there has not been any problem with all the other commands. The GGP command for example is being used in direct mode by many other users also, without any problems.

Please tell us what you have found to be wrong with the encoder connections so that it can be fixed.

[simistech]

Hi,

The encoder connector shown in TMCM 351's Hardware manuel(page 12) and firmware manuel (page 9) are different. The pin connections shown in hardware manuel is wrong. Firmware manuel is correct. So the correct connections are there in the firmware manuel.

About Labview, I did write a program in Labview to just send a command and read its reply. I tried a few commands on it and only GGP gave a different replay. Thats why I am puzzeled.

Thanks
Simi

[Olav Kahlbaum (TRINAMIC)]

Thank you for the hint with the encoder connector.

To be able to analyze your other problem further, please tell us which bytes you are sending to the module and which are coming back (if it is possible to monitor them somehow in LabView - I don't know if this is possible and how).

[simistech]

Hi,

It is possible to monitor all the replies in Labview. I wrote a program to send just one command and read it reply. The reslts are given as attachment. Also I am adding the image of laview for the program. I hope we can find a solution for this problem. Or if I am wrong please tell me where i am wrong.

Commands Test_Results.xls

Results of Command Test

(24.5 KiB) Downloaded 122 times

Labview Front End

frontend.JPG (29.18 KiB) Viewed 2175 times

Labview Backend

backend.JPG (65.77 KiB) Viewed 2174 times

Thanks & Regards
Simi

[Olav Kahlbaum (TRINAMIC)]

From this one can see that the TMCM-351 always sends the full and correct reply. But it seems that the serial port reading routine of LabView sometimes does not catch up all bytes at once (maybe when the reply comes very fast, as a GGP or SGP with a user variable works a little bit faster than e.g a MVP or SAP command). So one solution I can think of is to wait until nine bytes have reached the serial port and then start to read them or to make a reading routine that reads from the serial port until it has read nine bytes (with a reasonable timeout in case the connection gets broken e.g. by disconnecting the cable).

Internally the TMCL-IDE does something like that, because when reading the serial port directly with the appropriate functions of Windows you will also not always get the full reply at once.

[simistech]

Hi,

Even if I wait 5 seconds this is same. When I read, it shows that there are 9 bytes at port but only 4 can be read that time. Rest is read in the next read. Why that happens? I think the reply is there at the port but cannot be read fully. May be there is a problem with Labview. But why it is only for some commands or sometimes depanding on operands? I am using Labview 7.1. May be it is rectified in the new version.

Thanks
Simi

[Olav Kahlbaum (TRINAMIC)]

The problem can be in LabView, but can also be in the serial port driver of Windows.