Yaskawa Adjustment Commands Recently Started Failing

RapidCode API
1

[RMP 10.5.5]

Until recently, we have been able to send Yaskawa Adjustment Commands.

image
image872×770 99.3 KB

With some recent update, this code that hasn’t changed in a while has started failing, with the drive giving a status of 3.
You guys recently changed some SDO behavior. Is it possible that any of these changes could affect the process of sending adjustment commands and retrieving the status? I’m thinking of timing or other quirky issues with Yaskawa.

  • I send the command as a string.
  • I wait 5ms and check the status (repeating until the status is 0 or 3)
  • I get the response data, which might contain an error. In my case, the error is 0.

Any ideas?

2

I can, of course, do this “interactively” without problems, so I have to assume timing is related to the errors I’m receiving.

3

Hi Todd,

I don’t see any recent changes to the ServiceChannel thread other than the as yet released EoE feature. Are you reading 16 bytes of data on SubIndex 3? It looks like the Reply is only 16 bytes of data the first two of which don’t contain response data indicated by the Status of 3. It sounds like the SDO Read for Subindex 2 is working as intended. (3 being a valid response)

Do you ever see a failure case where you can read useful information in the reply? When you do the process manually, are you seeing a status of 0 or 1?

4

Don’t hear me suggesting that the SDO call itself is failing somehow. It’s not. The “action” I’m trying to perform is failing (reported back by the drive), but I haven’t changed this code (directly) in well over a year.

I’m hunting for ideas of what might have changed that could result in the Yaskawa drive (a very finicky customer) to complain about what (or probably, how) I’m doing.

5

What version did you switch from where the problem wasn’t an issue?

? → 10.5.5

Does reverting versions prevent the problem from reoccurring?

I can review code to see if there are any hints.

6

Conclusion

For the sake of closure, this problem happened when my byte-order detection code broke and I started sending big-endian values to the Yaskawa.

Thanks for the advice.

2 Likes
7

Thanks for the follow-up. I also wanted to note that if you’re reading string data from an SDO, be sure to copy the data before making more SDO calls as we are just returning you a pointer to the data that’s backed in the NetworkNode object and will be overwritten on the next ServiceChannelReadString(…).

1 Like