Stefan Müller
iT Engineering
Setting up a Producer - Consumer Connection with the Sercos Slave Stack V3
Hi,
I'm using the CiFX 50-RE Network Card with the lastet Slave Stack.
As a simple project for getting familar with SERCOS Stack I try to implement a Velocity / Position controlled
Drive.
I use FSP Type Drive V1 and SCP Type Fixed 1.1.1 this brings the SERCOS communication up to CP2.
Based on the cifxdemo.c I wrote a litte program that set up the IDNs :
S-0-0135.0.0 S-0-0040.0.0 S-0-0051 S-0134.0.0 S-0-0036 S-0-0047
The master displays them as available IDNs in CP2
Now I 'm tring to setup the producer connection ..
The Command looks like this :
SIII_SL_IDN_WRITE_REQ_T tIDNReq = {0};
tIDNReq.tData.ulIdn = 0x6041A; // S-0-1050.0.6
tIDNReq.tData.bSlaveIdx = 0;
tIDNReq.tData.bDataBlockElement = SIII_SL_IDN_ELEMENT_OPDATA;
tIDNReq.tData.abData[0] = 0x87; // S-0-0135;
tIDNReq.tData.abData[1] = 0x00;
tIDNReq.tData.abData[2] = 0x00;
tIDNReq.tData.abData[3] = 0x00;
tIDNReq.tData.abData[4] = 0x28; // S-0-0040
tIDNReq.tData.abData[5] = 0x00;
tIDNReq.tData.abData[6] = 0x00;
tIDNReq.tData.abData[7] = 0x00;
tIDNReq.tData.abData[8] = 0x33; // S-0-0051
tIDNReq.tData.abData[9] = 0x00;
tIDNReq.tData.abData[10] = 0x00;
tIDNReq.tData.abData[11] = 0x00;
tIDNReq.tData.usTotalLength = 12 ;
tIDNReq.tHead.ulDest = 0x20;
tIDNReq.tHead.ulSrc = 0;
tIDNReq.tHead.ulId = 0;
tIDNReq.tHead.ulCmd = SIII_SL_IDN_CMD_WRITE_REQ;
tIDNReq.tHead.ulDestId = 0;
tIDNReq.tHead.ulLen = SIII_SL_IDN_WRITE_REQ_MIN_SIZE + tIDNReq.tData.usTotalLength;
tIDNReq.tHead.ulExt = 0;
tIDNReq.tHead.ulState = 0;
But the result is:
Received Packet:
Dest : 0x00000020 ID : 0x00000000
Src : 0x00000000 Sta : 0xC0857003 // Operation Data transmission is too long
DestID : 0x00000000 Cmd : 0x00005A01
SrcID : 0x00000000 Ext : 0x00000000
Len : 0x00000006 Rout : 0x00000000
Data:
1A 04 06 00 00 07
I#m not sure where the misstake is .. maybe anyone here can see it ?
Thx
Hi,
oh okay I see .. i've changed the config from SCP_FixCfg to SCP_VarCfg 1.1.1
but now master is unable to connect to the device. sycon shows on the general diagonsis page
Device State : Ready
Network State: Offline
Configuration State: no LED is on
Is there a difference in configuration of FixCfg and VarCfg?
Andreas Jacob
Hilscher Gesellschaft fuer Systemautomation mbH
Hi,
in that case, you have to add the IDNs S-0-187 and S-0-188 to state what IDNs are consumer or producer mappable.
Regards
AJ
Hi,
I tried to set the IDNs into S-0-0187 and S-0-0188 the same way as für IDN S-0-1050.x.6 and just changed
the IDN to 0xBB or 0xBD and got result:
Received Packet:
Dest : 0x00000020 ID : 0x00000000
Src : 0x00000000 Sta : 0x00000019
DestID : 0x00000000 Cmd : 0x00005A01
SrcID : 0x00000000 Ext : 0x00000000
Len : 0x00000006 Rout : 0x00000000
Data:
BD 00 00 00 00 07
As it seams error code 19 is not documented..
Diagnosticpage ot the device shows an error for the first IniBatchStatus of RX_System
IniBatchResult: Error in confirmaion packet status
Can this be a mater for this error code or is it the result ?
Andreas Jacob
Hilscher Gesellschaft fuer Systemautomation mbH
Hi Stefan,
did you set the field ulCmd in the related request to 0x5A00?
Could you please send the original packet you send?
Can this be a mater for this error code or is it the result ?
they are not related.
Regards
AJ
Hiere is the packet:
tIDNReq.tData.ulIdn = 0x000000BD; // S-0-0189
tIDNReq.tData.bSlaveIdx = 0;
tIDNReq.tData.bDataBlockElement = SIII_SL_IDN_ELEMENT_OPDATA;
tIDNReq.tData.abData[0] = 0x87; // S-0-0135
tIDNReq.tData.abData[1] = 0x00;
tIDNReq.tData.abData[2] = 0x00;
tIDNReq.tData.abData[3] = 0x00;
tIDNReq.tData.abData[4] = 0x28; // S-0-0040
tIDNReq.tData.abData[5] = 0x00;
tIDNReq.tData.abData[6] = 0x00;
tIDNReq.tData.abData[7] = 0x00;
tIDNReq.tData.abData[8] = 0x33; // S-0-0051
tIDNReq.tData.abData[9] = 0x00;
tIDNReq.tData.abData[10] = 0x00;
tIDNReq.tData.abData[11] = 0x00;
tIDNReq.tData.usTotalLength = 12 ;
tIDNReq.tHead.ulDest = 0x20;
tIDNReq.tHead.ulSrc = 0;
tIDNReq.tHead.ulId = 0;
tIDNReq.tHead.ulCmd = SIII_SL_IDN_CMD_WRITE_REQ;
tIDNReq.tHead.ulDestId = 0;
tIDNReq.tHead.ulLen = SIII_SL_IDN_WRITE_REQ_MIN_SIZE + tIDNReq.tData.usTotalLength;
tIDNReq.tHead.ulExt = 0;
tIDNReq.tHead.ulState = 0;
Andreas Jacob
Hilscher Gesellschaft fuer Systemautomation mbH
Hi Stefan,
the packet you had for writing is not correct. However, if you want to write to an IDN with variable length, you have to add the List Header as well.
IDN S-0-189 does not relate to SCP_VarCfg at all.
you can create the needed IDN as follows: (I combined the action of having the value inside the IDN as well as its creation).
S-0-187:
tCreateIDNReq.tData.ulTotalLength = 16;
tCreateIDNReq.tHead.ulDest = 0x20;
tCreateIDNReq.tHead.ulSrc = 0;
tCreateIDNReq.tHead.ulId = 0;
tCreateIDNReq.tHead.ulCmd = SIII_SL_IDN_CMD_CREATE_IDN_REQ; tCreateIDNReq.tHead.ulDestId = 0; tCreateIDNReq.tHead.ulLen = SIII_SL_IDN_CREATE_IDN_MIN_DATA_SIZE + tCreateIdnReq.tData.usTotalLength;
tCreateIDNReq.tHead.ulExt = 0;
tCreateIDNReq.tHead.ulState = 0;
tCreateIDNReq.tData.ulIdn = 187;
tCreateIDNReq.tData.bSlaveIdx = 0;
tCreateIDNReq.tData.bValueInfo = MSK_SIII_SL_IDN_CREATE_IDN_VALUE_INFO_VALUE;
tCreateIDNReq.tData.usMaxNameLength = 240; tCreateIDNReq.tData.usMaxUnitLength = 0; tCreateIDNReq.tData.ulAttribute = MSK_SIII_SL_IDN_ATTR_OPDATA_WRITE_PROTECTED_IN_CP4 |
MSK_SIII_SL_IDN_ATTR_OPDATA_WRITE_PROTECTED_IN_CP3 |
MSK_SIII_SL_IDN_ATTR_OPDATA_WRITE_PROTECTED_IN_CP2 |
VAL_SIII_SL_IDN_ATTR_DISPLAY_FORMAT_IDN |
VAL_SIII_SL_IDN_ATTR_DATA_LENGTH_FOUR_BYTE_LIST |
(1 << SRT_SIII_SL_IDN_ATTR_SCALING);
tCreateIDNReq.tData.abData[0] = 0x0C; /* List Header */
tCreateIDNReq.tData.abData[1] = 0x00;
tCreateIDNReq.tData.abData[2] = 0x0C;
tCreateIDNReq.tData.abData[3] = 0x00;
tCreateIDNReq.tData.abData[4] = 0x87; /* S-0-135 */
tCreateIDNReq.tData.abData[5] = 0x00;
tCreateIDNReq.tData.abData[6] = 0x00;
tCreateIDNReq.tData.abData[7] = 0x00;
tCreateIDNReq.tData.abData[8] = 0x28; /* S-0-40 */
tCreateIDNReq.tData.abData[9] = 0x00;
tCreateIDNReq.tData.abData[10] = 0x00;
tCreateIDNReq.tData.abData[11] = 0x00;
tCreateIDNReq.tData.abData[12] = 0x33; /* S-0-51 */
tCreateIDNReq.tData.abData[13] = 0x00;
tCreateIDNReq.tData.abData[14] = 0x00;
tCreateIDNReq.tData.abData[15] = 0x00;
S-0-188:
tCreateIDNReq.tData.ulTotalLength = 16;
tCreateIDNReq.tHead.ulDest = 0x20;
tCreateIDNReq.tHead.ulSrc = 0;
tCreateIDNReq.tHead.ulId = 0;
tCreateIDNReq.tHead.ulCmd = SIII_SL_IDN_CMD_CREATE_IDN_REQ; tCreateIDNReq.tHead.ulDestId = 0; tCreateIDNReq.tHead.ulLen = SIII_SL_IDN_CREATE_IDN_MIN_DATA_SIZE + tCreateIdnReq.tData.usTotalLength;
tCreateIDNReq.tHead.ulExt = 0;
tCreateIDNReq.tHead.ulState = 0;
tCreateIDNReq.tData.ulIdn = 188;
tCreateIDNReq.tData.bSlaveIdx = 0;
tCreateIDNReq.tData.bValueInfo = MSK_SIII_SL_IDN_CREATE_IDN_VALUE_INFO_VALUE;
tCreateIDNReq.tData.usMaxNameLength = 240; tCreateIDNReq.tData.usMaxUnitLength = 0; tCreateIDNReq.tData.ulAttribute = MSK_SIII_SL_IDN_ATTR_OPDATA_WRITE_PROTECTED_IN_CP4 |
MSK_SIII_SL_IDN_ATTR_OPDATA_WRITE_PROTECTED_IN_CP3 |
MSK_SIII_SL_IDN_ATTR_OPDATA_WRITE_PROTECTED_IN_CP2 |
VAL_SIII_SL_IDN_ATTR_DISPLAY_FORMAT_IDN |
VAL_SIII_SL_IDN_ATTR_DATA_LENGTH_FOUR_BYTE_LIST |
(1 << SRT_SIII_SL_IDN_ATTR_SCALING);
tCreateIDNReq.tData.abData[0] = 0x0C; /* List Header */
tCreateIDNReq.tData.abData[1] = 0x00;
tCreateIDNReq.tData.abData[2] = 0x0C;
tCreateIDNReq.tData.abData[3] = 0x00;
tCreateIDNReq.tData.abData[4] = 0x86; /* S-0-134 */
tCreateIDNReq.tData.abData[5] = 0x00;
tCreateIDNReq.tData.abData[6] = 0x00;
tCreateIDNReq.tData.abData[7] = 0x00;
tCreateIDNReq.tData.abData[8] = 0x24; /* S-0-36 */
tCreateIDNReq.tData.abData[9] = 0x00;
tCreateIDNReq.tData.abData[10] = 0x00;
tCreateIDNReq.tData.abData[11] = 0x00;
tCreateIDNReq.tData.abData[12] = 0x2F; /* S-0-47 */
tCreateIDNReq.tData.abData[13] = 0x00;
tCreateIDNReq.tData.abData[14] = 0x00;
tCreateIDNReq.tData.abData[15] = 0x00;
Regards
AJ
Hi AJ,
thank you for this example. I did not consider that it is possible to create and fill an IDN at once.
This saves me some lines of code.
But now I get the following status codes:
Dest : 0x00000020 ID : 0x00000000
Src : 0x00000000 Sta : 0x00000000
DestID : 0x00000000 Cmd : 0x00005A40
SrcID : 0x00000000 Ext : 0x00000000
Len : 0x00000024 Rout : 0x00000000
Data:
BB 00 00 00 00 20 F0 00 00 00 00 00 01 00 56 70
10 00 00 00 0C 00 0C 00 87 00 00 00 28 00 00 00
33 00 00 00
Received Packet:
Dest : 0x00000020 ID : 0x00000000
Src : 0x00000000 Sta : 0xC0850014 // Invalid max list length
DestID : 0x00000000 Cmd : 0x00005A41
SrcID : 0x00000000 Ext : 0x00000000
Len : 0x00000005 Rout : 0x00000000
Data:
BB 00 00 00 00
Dest : 0x00000020 ID : 0x00000000
Src : 0x00000000 Sta : 0x00000000
DestID : 0x00000000 Cmd : 0x00005A40
SrcID : 0x00000000 Ext : 0x00000000
Len : 0x00000024 Rout : 0x00000000
Data:
BC 00 00 00 00 20 F0 00 00 00 00 00 01 00 56 70
10 00 00 00 0C 00 0C 00 86 00 00 00 24 00 00 00
2F 00 00 00
Received Packet:
Dest : 0x00000020 ID : 0x00000000
Src : 0x00000000 Sta : 0xC0850014 // Invalid max list length
DestID : 0x00000000 Cmd : 0x00005A41
SrcID : 0x00000000 Ext : 0x00000000
Len : 0x00000005 Rout : 0x00000000
Data:
BC 00 00 00 00
I had a look at the 61158 specification but I wasn't able to find anything about list headers.
Are they documented anywhere else ?
Andreas Jacob
Hilscher Gesellschaft fuer Systemautomation mbH
Hi Stefan,
just set usMaxListDataSize to for example 12 for the IDNs S-0-187/S-0-188.
If they get longer, you just have to adjust them.
e.g.
tCreateIDNReq.tData.usMaxListDataSize = 12;
Regards
AJ
Hi AJ,
List seams now ok but stack is not switching to running.
For now theres IDNs are already created:
S-0-0014
S-0-0015
S-0-0021
S-0-0022
S-0-0036
S-0-0040
S-0-0047
S-0-0051
S-0-0127
S-0-0128
S-0-0134
S-0-0135
S-0-1050[0-1].[1,2,3,4,5,6,8,10,11,12,20,21]
Are there other mandatory IDNs for switching to running mode?
Andreas Jacob
Hilscher Gesellschaft fuer Systemautomation mbH
Hi Stefan,
you are missing S-0-187 and S-0-188 in your list.
If you would provide a wireshark trace, it would be easier to know what is the problem. You can trace from the second port of the slave.
Just knowing not going to running can have a lot of reasons.
Regards
AJ
Hi AJ,
I connected Wireshark to the second port of the slave but there is no link.
When I switch to SCP-Type Fix link is etablisted but not for SCP-Type Var.
Andreas Jacob
Hilscher Gesellschaft fuer Systemautomation mbH
Hi Stefan,
there is no relation between link and SCP-Type.
Please check your cable.
Regards
AJ
Hi AJ,
It's the same card and the same cable. I just changed SCP-Type in SYCON.net and nothnig else.
So I think it must be a matter of settings?
Andreas Jacob
Hilscher Gesellschaft fuer Systemautomation mbH
Hi Stefan,
do you have a link on the port connected to the master?
If not, you never did set the BusOn.
Regards
AJ
No Bus is off.. as mentioned before Sycon shows device state ready and no configuration state.
When I try setting BusOn it fails with 0x800C0012 // Device not running
Andreas Jacob
Hilscher Gesellschaft fuer Systemautomation mbH
Hi,
that is why you never get a link. Have you ever configured the slave?
Regards
AJ
Hi,
I'm not sure which configuration. Within Sycon ?
Hello Stefan,
There is a simple mechanism in the Hilscher netX based Master and Slave products. After PowerOn a device is READY. If the device gots the configuration (found a file in the flash/ramdisk or the host sent a configuration packet) it is additional RUNNING. Only if a device is RUNNING, it is allowed to set BusOn. If the device is not RUNNING, there will be no Ethernet Link. So I assume, that you forgot to configure your device (e.g. download the configuration).
Johnny
Hi Johnny,
I created the following configuration in Sycon.NET for the slave and downloaded the configuration to the slave.
The download finishes successful but states does not change.
Andreas Jacob
Hilscher Gesellschaft fuer Systemautomation mbH
Hi,
In addition, SCP_FixCfg does not have a S-0-1050.X.6. It is only existing due to the fact that both SCP_FixCfg and SCP_VarCfg is supported by the stack.
the configuration in S-0-1050.0.6 is not written from the host. It is written from the master in case of SCP_VarCfg.
Regards
AJ