SDO access to the register during PO->SO (PO2SOconfigx hook)

[MartinHolcik]

Hello, I was recently trying to make functional test (PDO communication) to Yaskawa GA500 (using their JOHB-SMP3-MA communication option card). I am facing the issues with ec_SDOwrite when accessing registers:

1. 0x6048 (velocity acceleration) and
2. 0x6049 (velocity deceleration) When trying to write out registers 0x1C12/0x1C13, even 0x6060 (operation mode) has no issues but velocity acc & dec off some reason I can't write to (see lines 84 to 89 in simple_test_custom.c) This is the result

I'd love to know where can be the issue (since retval od SDOwrite/read is -5, I assume that It can be timeout, but even after increasing tout to .5s nothing has changed). Am I doing something wrong?

Many thanks for any tips you possibly have or can share. Thanks a lot and have a nice day :)

Martin

[ArthurKetels]

The control parameters of a servo drive are not supposed to be written with mailbox protocols like SDOwrite. You should use the PDO cycle for that. First map all required PDO variables in the Tx and RxPDO's, then go to Operational and manipulate the data directly in the IOmap space.

Please read the many older post here on how to do that.

[MartinHolcik]

Hi once again, I have changed communicated registers to PDO (pdo#42) as described by the manufacturer @ page 59/60. Now I have some strange behavior - some of the registers are transferred perfectly but some are not (e.g. crucial one targetVel and some others - see screenshot) Any other ideas or tips you could have?

Many thanks @ArthurKetels

[ArthurKetels]

As aways, a wireshark trace will tell what went wrong.

[MartinHolcik]

Hi once again @ArthurKetels - would you mind to check these traces? It would help me a lot, since I am not so "deep" into ECAT frames etc.

Many thanks & have a nice day Martin

[Choochoo1111]

I encountered the same problem，and slave it by analysis ethercat frame between PC and slave device.

All send SDO_write cmd are followed by a cmd（FPWR ado:0x107f data:0x00, len:1 ）.

so , I add the same cmd after SDO write cmd send(ethercatmain.c line 973):

int ecx_mbxsend(ecx_contextt context, uint16 slave,ec_mbxbuft mbx, int timeout) { uint16 mbxwo,mbxl,configadr; uint8_t temp = 0; int wkc; wkc = 0; configadr = context->slavelist[slave].configadr; mbxl = context->slavelist[slave].mbx_l; if ((mbxl > 0) && (mbxl <= EC_MAXMBX)) { if (ecx_mbxempty(context, slave, timeout)) { mbxwo = context->slavelist[slave].mbx_wo; / write slave in mailbox / wkc = ecx_FPWR(context->port, configadr, mbxwo, mbxl, mbx, EC_TIMEOUTRET3); // add FPWR cmd wkc = ecx_FPWR(context->port, configadr, 0x107f, 1, &temp, EC_TIMEOUTTXM); } else { wkc = 0; } } return wkc; }

And, SDO_write work normal.

Hope the information above can help you.

[ArthurKetels]

@Choochoo1111 , please do not hijack a thread with unrelated issues. Your solution is also not correct. Your real problem is that your mailbox size definition in SOEM is too small. Writing the last byte of the SM will solve this, but your solution is not generic and will break almost all other slaves.

[ArthurKetels]

@MartinHolcik, from the SOEM side all looks OK. What is intended in your code is actually written in the EtherCAT frames.

So your problem is not EtherCAT but the interaction with the Yaskawa firmware. A brief inspection on the control logic in the drive shows many parameters and inputs that influence the target velocity. So please carefully check if all those are set appropriately,

Perhaps one item that could be important is the watchdog timer in the ESC. According to the ESI xml file you need to set that.

                <ESC>
                    <Reg0400>25000</Reg0400>
                    <Reg0420>100</Reg0420>
                </ESC>

[MartinHolcik]

Hello once again, Many thanks @ArthurKetels for analyzing traces. I was trying to figure out how to set ESC registers. Found ESC register specification here: So far I know only about one way how to write ESC registers: using TC3 But as I see those are already set according the ESI file ESC section. Also I can see they're being set in watchdog section

[ArthurKetels]

From ethercatbase.c:

/** FPWR "configured address write" primitive. Blocking.
 *
 * @param[in] port        = port context struct
 * @param[in] ADP         = Address Position, slave that has address writes.
 * @param[in] ADO         = Address Offset, slave memory address
 * @param[in] length      = length of databuffer
 * @param[in] data        = databuffer to write to slave.
 * @param[in] timeout     = timeout in us, standard is EC_TIMEOUTRET
 * @return Workcounter or EC_NOFRAME
 */
int ecx_FPWR(ecx_portt *port, uint16 ADP, uint16 ADO, uint16 length, void *data, int timeout)

[MartinHolcik]

UPDATE: After flashing FW in Yaskawa GA500 it seems that communication works and (all) registers are written properly. The other issue with zero speed returning from the drive I have described previously caused wrong CW in user program.

I have additional question (regarding Delta MS300), inverter reports:

Interesting thing here is, that using the configlist, everything works without issues.

./slaveinfo -map

Can this be caused because of: SM2 - 1300 (outputs) - > FMMU0 - 1600 (outputs) SM3 - 1600 (inputs) -> FMMU1 - 1300 (inputs)?

Wireshark trace here. I have been using CA and single access register but when using CA I am getting error: Slave # 1, 1600:0, ec_SDOwrite: 0 Slave # 1, 1a00:0, ec_SDOwrite: 0 Slave # 1, 1c12:0, ec_SDOwrite: 0 Slave # 1, 1c13:0, ec_SDOwrite: 0 Is it because CA is not supported or is this (ESI information) related to different parameter?

[MartinHolcik]

Is there any way to obtain configuration from .ESI files "function" (ESI parser - either paid or as an open source)? I have been trying to modify ec_slave structure:

FMMU[x].FMMUactive 
FMMU[x].FMMUactive
SM[x].StartAddr
SM[x].SMflags

to "fit" my "configlist" entry settings (which surprisingly works, despite the fact that I have used there information gained from ./slaveinfo):

{/*Man=*/0x000001dd, /*ID=*/0x10400200, /*Name=*/"MS300(CMM-EC02 Card)", /*dtype=*/0, /*Ibits=*/48, /*Obits=*/48, /*SM2a*/ 0x1300, /*SM2f*/ 0x00010024, /*SM3a*/ 0x1600, /*SM3f*/ 0x00010020, /*FM0ac*/ 1, /*FM1ac*/ 1},

but of no success.

[ArthurKetels]

There is no automated way available on the market that I know of. But I do know several users have successfully implemented an ESI parser on top of SOEM.

For you specific use case it should not be too difficult to manually read the ESI file and from that build a special configuration function that you plug in to SOEM. As long as after the configuration phase the correct data is both in the physical slave and in the SOEM slave structure.

[MartinHolcik]

Hello, thanks for another "piece of puzzle". I am afraid I still have some blind spots here. I did some configuration (like I have described in my last comment) of master but had no idea that master configuration "comes" with writing back (some configuration) to slave (DRAM?)?

In other words: Does that mean, that configlist writes some configuration details back to slave?

If yes, then it would clarify why SOEM works with configlist and I am failing to use my "individual" (=manual ESI read out and write to ec_slave struct) master configuration (without using configlist).