Cmd 138 not working on TMCM-1060

[marnixh]

Hello,

I'm trying out a TMCM-1060 using the CAN bus for communication. Everything is working well. However, command 138 doesn't seem to return the second reply (target position reached).
First I give an MVP ABS command, next I give command 138. I do get an acknowledge (status 100) from the controller but never the second message (status 128).
I have tried several combinations of bit masks in the value attribute and also in the type and motor attributes but that doesn't help. I also tried setting the target position directly (SAP 0, ...)

Below you can see several attempts recorded with a CAN sniffer. The TMCM-1060 has ID 102, the PLC has ID 2:

ID: 0002 TIMESTAMP: 00041839 LEN: 7 DATA: 66 64 8A 00 00 00 01
ID: 0102 TIMESTAMP: 00041839 LEN: 7 DATA: 8A 01 01 00 00 00 01
ID: 0002 TIMESTAMP: 00031358 LEN: 7 DATA: 66 64 04 00 00 00 00
ID: 0102 TIMESTAMP: 00031358 LEN: 7 DATA: 04 00 00 00 00 00 00
ID: 0002 TIMESTAMP: 00017725 LEN: 7 DATA: 66 64 8A FF FF FF FF
ID: 0102 TIMESTAMP: 00017724 LEN: 7 DATA: 8A 00 00 FF FF FF FF
ID: 0002 TIMESTAMP: 00011489 LEN: 7 DATA: 66 64 8A FF FF FF FF
ID: 0102 TIMESTAMP: 00011489 LEN: 7 DATA: 8A 00 00 FF FF FF FF
ID: 0002 TIMESTAMP: 00002509 LEN: 7 DATA: 66 64 04 00 01 90 00
ID: 0102 TIMESTAMP: 00002509 LEN: 7 DATA: 04 00 00 00 01 90 00

Can you tell me if I'm missing anything? The "target position reached event message" is very important for us as we want to control 32 motors in a single machine and I don't want to poll the status continuously.

[Olav Kahlbaum (TRINAMIC)]

It seems that you are using command 138 the wrong way. Set the type parameter to 1, the motor parameter to 0 and the value parameter to 1 (this is a bit mask that shows for which motors you would like to have this event - and as it is a one-motor module, bit 0 has to be set for motor 0). Then you will get a position reached event message for every MVP command that comes after the command 138.
So, please send 8A 01 00 00 00 00 01 and then try some MVP commands. I have just tried it out, and it works fine.

You can switch off this function by setting type and value parameter of command 138 to zero.

[marnixh]

Thank you for the speedy reply.

I did some more testing with your comments and I found the following:
If I send 138 as the first command after power-on and after that I send either an MVP or start my stand-alone program, I do get the "target position reached" messages.
However, if I first start my program and THEN send 138, I never get the "target position reached" message. Not even after I stop/reset the program and send 138 again.
In this situation there seems to be no way to get it to work other than cycling the power.
Also, this would mean that I cannot use the "auto start mode" (global parameter 77).



P.S. you state that the type parameter in cmd 138 should be 1 to enable, but the firmware manual states that the value of the type parameter doesn't matter. Also, the manual says that the request message requires the motor number, and not a bit mask.

[Olav Kahlbaum (TRINAMIC)]

Of course it should also work when it is not the first command sent to the module. I will check this also, maybe you can help me by telling me what the first commands in your program are. The error in the documentation regarding command 138 will be corrected. We apologize for that.

[marnixh]

The startup part of my program (currently) looks like this:

Code: Select all

Startup:
        SCO 0,   0, 0
        SCO 1,   0, 25400
        SAP 140, 0, 8
        SAP 4,   0, NormalSpeed   
        SAP 5,   0, NormalAccel
       
        SGP 0,   2, 0
        SGP 1,   2, NormalSpeed
        SGP 2,   2, NormalAccel
        SGP 4,   2, VibSpeed
        SGP 5,   2, VibAccel
        SGP 3,   2, VibAmplitude
        SGP 6,   2, VibCount


[marnixh]

If you're going to change anything about how command 138 works then I would like to ask you to consider the following:
Enable command 138 automatically at start-up, depending on the value of a global parameter. In our application we will always need it enabled so we this way we wouldn't need to send the command at all.
Another option would be to make it possible to enable it from a stand-alone program.

[Olav Kahlbaum (TRINAMIC)]

Introducing a global parameter for this seems to be a good idea to me. This would also make it possible to enable it from a stand-alone program (although this would only make sense when the module is also connected to a host).
Thank you for mentioning this.

[marnixh]

Hello Olav,

Did you decide to implement this as a global parameter? If so, when do you expect this feature to be available?
I'm asking because my requirements have changed somewhat and it would really help if I could also prevent the "target position reached" from being sent from the TMCL program.

[Olav Kahlbaum (TRINAMIC)]

I didn't make the decision right now, but I am just working on a new firmware revision (4.38) where I will try it out and then decide about that.

[Olav Kahlbaum (TRINAMIC)]

The good news: the problem with command 138 on the TMCM-1060 has been found and fixed. Rev. 4.38 will come out soon where this is fixed and with another goodie: positioning speed and acceleration can also be changed while positioning is in progress (something which many users needed).

But concerning a parameter that can be used instead of command 138 there is one problem: selecting the interface where the reply shall go. With command 138 this is easy: the delayed reply just goes to the same interface where the command came from. But when doing it as a parameter, another parameter is needed to select the interface where the reply shall go.
What do you think about that?

[marnixh]

That is good news indeed. We recently got a custom modification for the firmware to be able to use a minimum positioning speed (axis parameter 130). Will you also include that in the new normal firmware?

As for the command 138, maybe the easiest way would be to assign it a mnemonic and use the TYPE attribute to indicate which interface to use? That would certainly meet our needs.
But if you really want a single global parameter, I suppose you could also "split" it up so that the last bits indicate the interface to use. That would work for us as well.

[Olav Kahlbaum (TRINAMIC)]

Yes, the parameter 130 will also be included in the normal firmware. I will think about the rest.