From bklim at autonics.com  Fri Aug 12 03:57:01 2022
From: bklim at autonics.com (=?UTF-8?B?7J6E67OR6re8?=)
Date: Fri, 12 Aug 2022 10:57:01 +0900
Subject: [Etherlab-users] =?utf-8?q?The_phenomenon_that_SAFEOP_does_not_t?=
 =?utf-8?q?ransmit_FMMU_packet?=
In-Reply-To: undefined
References: undefined
Message-ID: <189271810.174884.1660269421081@portal.autonics.com>

Hi all


I have problem is that the state is not changed with SAFEOP -> OP.
Compared to Twincat, it seems that SAFEOP does not blow the FMMU configuration packet.
Where would you like to check?
Also, what kind of information do you need to solve this problem???


I am running it on NXP imx8mp eval board


First of all, the Cstruct of Ethercat slave is as follows.


 /* Master 0, Slave 0, "ARIO-C-EC"
 * Vendor ID: 0x00000759
 * Product code: 0x00000003
 * Revision number: 0x000d0001
 */


ec_pdo_entry_info_t slave_0_pdo_entries[] = {
    {0x7010, 0x01, 8}, /* Byte 1 */
    {0x6000, 0x01, 8}, /* Byte 1 */
};


ec_pdo_info_t slave_0_pdos[] = {
    {0x1601, 1, slave_0_pdo_entries + 0}, /* RxPDO Mapping Slot #01 */
    {0x1a00, 1, slave_0_pdo_entries + 1}, /* TxPDO Mapping Slot #00 */
};


ec_sync_info_t slave_0_syncs[] = {
    {0, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},
    {1, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},
    {2, EC_DIR_OUTPUT, 1, slave_0_pdos + 0, EC_WD_ENABLE},
    {3, EC_DIR_INPUT, 1, slave_0_pdos + 1, EC_WD_DISABLE},
    {0xff}
};


Thank you
<div style="display:none;">
<img src="https://mail.autonics.com/mail/mailNotifyCon/recipientMail.do?q=MTg5MjcxODEwLjE3NDg4NC4xNjYwMjY5NDIxMDgxXXXZXRoZXJsYWItdXNlcnNAZXRoZXJsYWIub3Jn" loading="eager" />
</div>
<p></p>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220812/72221cc6/attachment.htm>

From gavin.lambert at tomra.com  Fri Aug 12 08:54:15 2022
From: gavin.lambert at tomra.com (Gavin Lambert)
Date: Fri, 12 Aug 2022 06:54:15 +0000
Subject: [Etherlab-users] The phenomenon that SAFEOP does not transmit
 FMMU packet
In-Reply-To: <189271810.174884.1660269421081@portal.autonics.com>
References: undefined <189271810.174884.1660269421081@portal.autonics.com>
 <471f8226-0853-49c5-9daa-cf6c15ca0ea2.240fbd61-bfd8-4700-b5db-6dad64766134.c37cc9fd-b45a-482a-92c5-1055e189884c@emailsignatures365.codetwo.com>
 <471f8226-0853-49c5-9daa-cf6c15ca0ea2.7fff08e7-30d4-419a-bb0e-223e1b91003f.740acc9e-12a3-41a1-b1e8-6d34cd3ffb46@emailsignatures365.codetwo.com>
 <471f8226-0853-49c5-9daa-cf6c15ca0ea2.48839160-9959-4be7-994c-41958dbf9d0a.7d0bfa88-cfda-444c-803a-520a11460646@emailsignatures365.codetwo.com>
 <471f8226-0853-49c5-9daa-cf6c15ca0ea2.f428c1e8-9b65-4082-8b87-d0c1551d6566.9456aad3-3f5b-4182-a9f9-00f8d145f4dd@emailsignatures365.codetwo.com>
 <471f8226-0853-49c5-9daa-cf6c15ca0ea2.ee6da8dd-532c-43a9-8cae-3b2dd5aa5e20.c5cdb016-19d3-4190-998b-7ef2ea440465@emailsignatures365.codetwo.com>
 <471f8226-0853-49c5-9daa-cf6c15ca0ea2.39ba2b53-b46d-442f-a7a2-431de4bfaa97.39a959f5-9ed9-462e-8f7b-3ac49b940fc5@emailsignatures365.codetwo.com>
Message-ID: <DB8PR03MB5657706E42FA744F487D90E3E8679@DB8PR03MB5657.eurprd03.prod.outlook.com>

FMMU configuration happens at the PREOP -> SAFEOP transition, not the SAFEOP -> OP.

Gavin Lambert

Senior Software Developer TOMRA Fresh Food



[cid:TOMRA_CMYK_final_size_times_two_cd761a01-1d1f-446e-9316-8012271820b6.png]

[cid:TOMRA_50th-Email_Signature_Food-08_ba63a226-17be-4b94-80e3-3f48ae3d72b3.jpg]

 [cid:TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg] <https://www.facebook.com/TOMRA.Food/>  [cid:TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg] <https://www.linkedin.com/company/tomra-food/>  [cid:TF-twitter-icon_65c62d2e-772c-4a2c-97c5-d84fbfc204d5.jpg] <https://twitter.com/TOMRAFood>  [cid:TF-Youtube-icon_8b2c830c-70d9-48da-a4db-db9191d346ba.jpg] <https://www.youtube.com/playlist?list=PLDD3B1A7BAE919EC6>  [cid:TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg] <https://www.instagram.com/tomrafood/>
 Compac Technologies Ltd | 4 Henderson Place | PO Box 13 516 | Onehunga 1061 | New Zealand

 Phone: +64 96 34 00 88 | https://www.compacsort.com
The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication.
From: ???
Sent: Friday, 12 August 2022 13:57
To: etherlab-users at etherlab.org
Subject: [Etherlab-users] The phenomenon that SAFEOP does not transmit FMMU packet

Hi all

I have problem is that the state is not changed with SAFEOP -> OP.
Compared to Twincat, it seems that SAFEOP does not blow the FMMU configuration packet.
Where would you like to check?
Also, what kind of information do you need to solve this problem???

I am running it on NXP imx8mp eval board

First of all, the Cstruct of Ethercat slave is as follows.

/* Master 0, Slave 0, "ARIO-C-EC"
* Vendor ID: 0x00000759
* Product code: 0x00000003
* Revision number: 0x000d0001
*/

ec_pdo_entry_info_t slave_0_pdo_entries[] = {
{0x7010, 0x01, 8}, /* Byte 1 */
{0x6000, 0x01, 8}, /* Byte 1 */
};

ec_pdo_info_t slave_0_pdos[] = {
{0x1601, 1, slave_0_pdo_entries + 0}, /* RxPDO Mapping Slot #01 */
{0x1a00, 1, slave_0_pdo_entries + 1}, /* TxPDO Mapping Slot #00 */
};

ec_sync_info_t slave_0_syncs[] = {
{0, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},
{1, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},
{2, EC_DIR_OUTPUT, 1, slave_0_pdos + 0, EC_WD_ENABLE},
{3, EC_DIR_INPUT, 1, slave_0_pdos + 1, EC_WD_DISABLE},
{0xff}
};

Thank you


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220812/9fd65177/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 34 bytes
Desc: image001.gif
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220812/9fd65177/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TOMRA_CMYK_final_size_times_two_cd761a01-1d1f-446e-9316-8012271820b6.png
Type: image/png
Size: 6455 bytes
Desc: TOMRA_CMYK_final_size_times_two_cd761a01-1d1f-446e-9316-8012271820b6.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220812/9fd65177/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TOMRA_50th-Email_Signature_Food-08_ba63a226-17be-4b94-80e3-3f48ae3d72b3.jpg
Type: image/jpeg
Size: 58287 bytes
Desc: TOMRA_50th-Email_Signature_Food-08_ba63a226-17be-4b94-80e3-3f48ae3d72b3.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220812/9fd65177/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg
Type: image/jpeg
Size: 10123 bytes
Desc: TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220812/9fd65177/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg
Type: image/jpeg
Size: 10214 bytes
Desc: TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220812/9fd65177/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TF-twitter-icon_65c62d2e-772c-4a2c-97c5-d84fbfc204d5.jpg
Type: image/jpeg
Size: 10254 bytes
Desc: TF-twitter-icon_65c62d2e-772c-4a2c-97c5-d84fbfc204d5.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220812/9fd65177/attachment-0009.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TF-Youtube-icon_8b2c830c-70d9-48da-a4db-db9191d346ba.jpg
Type: image/jpeg
Size: 10218 bytes
Desc: TF-Youtube-icon_8b2c830c-70d9-48da-a4db-db9191d346ba.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220812/9fd65177/attachment-0010.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg
Type: image/jpeg
Size: 10303 bytes
Desc: TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220812/9fd65177/attachment-0011.jpg>

From uwe.stegemann at gi-de.com  Mon Aug 22 16:01:39 2022
From: uwe.stegemann at gi-de.com (Stegemann Uwe)
Date: Mon, 22 Aug 2022 14:01:39 +0000
Subject: [Etherlab-users] Implementation of Safety - Terminals EL6900,
 EL1904 and EL2904
Message-ID: <c94160429f514467af689ea9c9fa6706@gi-de.com>


Hi erveryone,

I want to setup TwinSafe Logic Terminals, EL6900, EL2904 and EL1904.I've created a Safety-Project with TwinCat3 and downloaded the safety-logic to the EL6900. I use the default settings from TwinCat3. Now I want to implement it to the etherlab-master.
The Default PDO-Mapping of the EL6900 - Terminal:

SM0: PhysAddr 0x1000, DefaultSize  256, ControlRegister 0x26, Enable 1
SM1: PhysAddr 0x1100, DefaultSize  256, ControlRegister 0x22, Enable 1
SM2: PhysAddr 0x1200, DefaultSize    2, ControlRegister 0x24, Enable 1
  RxPDO 0x1600 "FSOE RxPDO-Map 001"
    PDO entry 0x7000:01,  8 bit, "FSOE Command"
    PDO entry 0x7001:01,  8 bit, "SubIndex 001"
    PDO entry 0x7000:03, 16 bit, "FSOE CRC 001"
    PDO entry 0x7000:02, 16 bit, "FSOE ConnID"
  RxPDO 0x1601 "FSOE RxPDO-Map 002"
    PDO entry 0x7010:01,  8 bit, "FSOE Command"
    PDO entry 0x7011:01,  8 bit, "SubIndex 001"
    PDO entry 0x7010:03, 16 bit, "FSOE CRC 001"
    PDO entry 0x7010:02, 16 bit, "FSOE ConnID"
  RxPDO 0x17f0 "DEVICE RxPDO-Map Standard In Vars"
    PDO entry 0xf201:01,  1 bit, "SubIndex 001"
    PDO entry 0xf201:02,  1 bit, "SubIndex 002"
    PDO entry 0xf201:03,  1 bit, "SubIndex 003"
    PDO entry 0xf201:04,  1 bit, "SubIndex 004"
    PDO entry 0xf201:05,  1 bit, "SubIndex 005"
    PDO entry 0xf201:06,  1 bit, "SubIndex 006"
    PDO entry 0xf201:07,  1 bit, "SubIndex 007"
    PDO entry 0xf201:08,  1 bit, "SubIndex 008"
  RxPDO 0x17ff "DEVICE RxPDO-Map Control"
    PDO entry 0xf200:01, 16 bit, "Control"
SM3: PhysAddr 0x1d00, DefaultSize    2, ControlRegister 0x20, Enable 1
  TxPDO 0x1a00 "FSOE TxPDO-Map 001"
    PDO entry 0x6000:01,  8 bit, "FSOE Command"
    PDO entry 0x6001:01,  8 bit, "SubIndex 001"
    PDO entry 0x6000:03, 16 bit, "FSOE CRC 001"
    PDO entry 0x6000:02, 16 bit, "FSOE ConnID"
  TxPDO 0x1a01 "FSOE TxPDO-Map 002"
    PDO entry 0x6010:01,  8 bit, "FSOE Command"
    PDO entry 0x6011:01,  8 bit, "SubIndex 001"
    PDO entry 0x6010:03, 16 bit, "FSOE CRC 001"
    PDO entry 0x6010:02, 16 bit, "FSOE ConnID"
  TxPDO 0x1bff "DEVICE TxPDO-Map Status"
    PDO entry 0xf100:01,  3 bit, "Safety Project State"
    PDO entry 0x0000:00,  4 bit, "Gap"
    PDO entry 0xf100:08,  1 bit, "Login Active"
    PDO entry 0xf100:09,  1 bit, "Input Size Mismatch"
    PDO entry 0xf100:0a,  1 bit, "Output Size Mismatch"
    PDO entry 0x0000:00,  4 bit, "Gap"
    PDO entry 0xf100:0f,  1 bit, "TxPDO State"
    PDO entry 0xf100:10,  1 bit, "TxPDO Toggle"

When I want to add PDOs, I get following warnings:

EtherCAT WARNING 0-1: Currently mapped PDO entries: 0x7000:01/8 0x7001:01/8 0x7000:03/16 0x7000:02/16. Entries to map: 0x7000:01/8 0x7001:01/8 0x7000:03/16 0x7000:02/16 0x6000:01/48 0x6000:02/48
EtherCAT WARNING 0-1: Slave does not support changing the PDO mapping!

Slave Info EL6900:

=== Master 0, Slave 1 ===
Alias: 100
Device: Main
State: OP
Flag: +
Identity:
  Vendor Id:       0x00000002
  Product code:    0x1af43052
  Revision number: 0x00130000
  Serial number:   0x00000000
DL information:
  FMMU bit operation: no
  Distributed clocks: yes, delay measurement only
  DC system time transmission delay: 145 ns
Port  Type  Link  Loop    Signal  NextSlave  RxTime [ns]  Diff [ns]   NextDc [ns]
   0  EBUS  up    open    yes             0   2874259272           0         145
   1  EBUS  up    open    yes             2   2874260152         880         145
   2  N/A   down  closed  no              -            -           -           -
   3  N/A   down  closed  no              -            -           -           -
Mailboxes:
  Bootstrap RX: 0x1000/244, TX: 0x10f4/244
  Standard  RX: 0x1000/256, TX: 0x1100/256
  Supported protocols: CoE, FoE
General:
  Group: Safety
  Image name: EL69XX
  Order number: EL6900
  Device name: EL6900, TwinSAFE-PLC
  CoE details:
    Enable SDO: yes
    Enable SDO Info: yes
    Enable PDO Assign: no
    Enable PDO Configuration: no
    Enable Upload at startup: no
    Enable SDO complete access: no
  Flags:
    Enable SafeOp: no
    Enable notLRW: no
  Current consumption: 190 mA

I see, that's not possible to assign or to configure PPOs, but what is the right track to setup this system successfully?
The used PDOs are not unique!
Do I have to change settings in TwinCat3? I am not an Expert of this; I only want to use the Safety-Editor to create the Safety - Logic!

In earlier posts here I found, that it is possible to implement Safety Terminals in the etherlab master successfully.
I've already read, that the FSoE - Data (6 Bytes) between the Safety - Terminals must be managed in the cycle_task of the Application; a little bit tricky but make sense.
The last point: In the Safety - Logic I used one variable to set Com/Err - Signal which is also linked to a PDO, I can't mapped!

Thanks in advance for attention and help.

Best regards

Uwe Stegemann

____________________________________
G+D Currency Technology

Uwe Stegemann
Banknote-Engineering - Printing Division / Abt. CTBN 214
Giesecke+Devrient Currency Technology GmbH,
Prinzregentenstraße 159, D-81677 Munich, Germany
T +49 89 4119-2321 F +49 89 4119-1446
mailto:uwe.stegemann at gi-de.com
http://www.gi-de.com<http://www.gi-de.com/>




www.gi-de.com/currency-technology<https://www.gi-de.com/currency-technology/>

[Cash Matters] <http://www.cashmatters.org/>

Geschäftsführer: Dr. Wolfram Seidemann (Vorsitzender, CEO), Guido Koller (CFO), Wolfgang Kneilmann, Bernd Kümmerle
Gesellschaftssitz: München, Handelsregister des AG München, HRB 148256
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220822/64ad7255/attachment-0001.htm>

From tom at wongcornall.com  Tue Aug 23 01:50:45 2022
From: tom at wongcornall.com (Tom Wong-Cornall)
Date: Tue, 23 Aug 2022 11:50:45 +1200
Subject: [Etherlab-users] Implementation of Safety - Terminals EL6900,
 EL1904 and EL2904
In-Reply-To: <c94160429f514467af689ea9c9fa6706@gi-de.com>
References: <c94160429f514467af689ea9c9fa6706@gi-de.com>
Message-ID: <20220822235045.7wi6fjtluhltcbh3@wongcornall.com>

On Tue, Aug 23 '22 at 02.01 NZST, Stegemann Uwe <uwe.stegemann at gi-de.com> wrote:
> I want to setup TwinSafe Logic Terminals, EL6900, EL2904 and EL1904.I've created a Safety-Project with TwinCat3 and downloaded the safety-logic to the EL6900. I use the default settings from TwinCat3. Now I want to implement it to the etherlab-master.
>
> Do I have to change settings in TwinCat3? I am not an Expert of this; I only want to use the Safety-Editor to create the Safety - Logic!

Yes, just set up the project in TwinSAFE and download to the module.  
Depending on the project designed in TwinSAFE you will end up different 
PDOs.

I use ecrt_slave_config_reg_pdo_entry() to deal with the fact the PDO 
assignment is fixed. This does mean the module has to be "there" and 
visible to the etherlab master before starting the application.

You will need to use TwinCAT to find the order of the slaves 
"Connections" (your 0x6000/0x7000 is the first connection, 0x6010/0x7010 
is the second). On the newer EL6910-based hardware this seems to start 
at 0x6080/0x7080.

 
> The last point: In the Safety - Logic I used one variable to set 
> Com/Err - Signal which is also linked to a PDO, I can't mapped!

Yes, you'll also need to map Run and ErrAck as well. Run obviously 
should be asserted the entire time you want to run the safety logic, and 
ErrAck usually needs a rising edge (or two) after startup, as you will 
likely have CommErr faults etc. on startup.

These show up as the "Standard Inputs" and "Standard Outputs" in the PDO 
map. For an EL1918 (=EL6910) these are 0xf688:00 and 0xf788:00 - on the 
older EL6900 you seem to have this at 0xf201 maybe? But you don't have 
any Standard Outputs mapped I guess.

>From what I can see the indices/subindices seem to stay the same 
regardless of the TwinSAFE config at least - just some might come and 
go.

The size of the Standard Inputs/Outputs PDO might change depending on 
how many you added, but they always seem to align to 8 bits at least.

For the StdInputs/StdOutputs you also need to find the offset for each 
Input/Output bit in TwinCAT just like finding the slaves "connection" 
order. These are not fixed position; they can change depending on order 
you add/delete alias devices in TwinSAFE so need to be checked each time 
you do a new safety project.


If you haven't done so already, I would highly recommend you get your 
safety logic running happily in TwinCAT (by setting up a dummy PLC 
project and linking Run/ErrAck/ComErr alias devices etc. to bools). Once 
this is OK, try and make it work with etherlab - debugging is difficult 
otherwise (although mapping Group State/Diag PDOs to your application 
can help somewhat).

From Graeme.Foot at touchcut.com  Tue Aug 23 01:53:03 2022
From: Graeme.Foot at touchcut.com (Graeme Foot)
Date: Mon, 22 Aug 2022 23:53:03 +0000
Subject: [Etherlab-users] Implementation of Safety - Terminals EL6900,
 EL1904 and EL2904
In-Reply-To: <c94160429f514467af689ea9c9fa6706@gi-de.com>
References: <c94160429f514467af689ea9c9fa6706@gi-de.com>
Message-ID: <39cc5a32f84848d8968a1da2bcf8000b@touchcut.com>

Hi Uwe,

We have implemented FSoE with an EK1960, an EL1904 and an EL2904 in the past.  The EK1960 is a bit different to the EL6900 as it also has it's own IO.  However it seems like your PDO configuration is missing a lot of data both in what the device thinks it has configured (Currently mapped PDO entries) and what you are attempting to write (Entries to map).

First check that your project has been loaded on the EL6900 correctly, has been activated and the whole system repowered.  Also verify the project crc.  (We use the Beckhoff TwinSAFE Loader application to load the safety program via Linux.  This requires a Mailbox Gateway Server, which is a patch I submitted to EtherLab a while ago.)  The safety program is what defines the PDO layout on the EL6900.  The master cstruct command may give you the correct PDO mapping but it's a while ago so I'm not sure on that one.  I remember configuring my structs manually based on what was in the safety program as shown by TwinCAT.  E.g.: in TwinCAT 3, if you go to I/O, Devices, Device 1, Term 1 (EL6900), Process Data tab it should show you the expected PDO layout for the terminal.

[cid:image001.png at 01D8B6E2.EB61F800]

[cid:image002.png at 01D8B6E2.EB61F800]

Order the PDO's by Sync Manager, then PDO Assignment, then PDO Content.  Don't worry if you have duplicate index:subindex values.  They should be unique within a particular PDO group.  However you will need to use "ecrt_slave_config_reg_pdo_entry_pos" rather than "ecrt_slave_config_reg_pdo_entry" if you have any duplicates.

For each safety device (EL1904, EL2904) the EL6900 controls, your application must copy 48 input bits and 48 output bits (6 bytes) between the EL6900's PDO and each safety devices PDO's within your realtime read-calc-write loop.  e.g. copy:
EL6900 TxPDO 0x1a00 -> EL1904 RxPDO 0x1600 (length 48 bits)
EL6900 TxPDO 0x1a01 -> EL2904 RxPDO 0x1600 (length 48 bits)
EL1904 TxPDO 0x1a00 -> EL6900 RxPDO 0x1600 (length 48 bits)
EL2904 TxPDO 0x1a00 -> EL6900 RxPDO 0x1601 (length 48 bits)

I think I got those the right way around.  You will also need to check which blocks the EL1904/EL2904 actually map to based on you safety program.

Also for housekeeping, I put all of the safety related PDO's in their own domain.

Regards,
Graeme.


From: Etherlab-users <etherlab-users-bounces at etherlab.org> On Behalf Of Stegemann Uwe
Sent: Tuesday, 23 August 2022 02:02
To: etherlab-users at etherlab.org
Subject: [Etherlab-users] Implementation of Safety - Terminals EL6900, EL1904 and EL2904


Hi erveryone,

I want to setup TwinSafe Logic Terminals, EL6900, EL2904 and EL1904.I've created a Safety-Project with TwinCat3 and downloaded the safety-logic to the EL6900. I use the default settings from TwinCat3. Now I want to implement it to the etherlab-master.
The Default PDO-Mapping of the EL6900 - Terminal:

SM0: PhysAddr 0x1000, DefaultSize  256, ControlRegister 0x26, Enable 1
SM1: PhysAddr 0x1100, DefaultSize  256, ControlRegister 0x22, Enable 1
SM2: PhysAddr 0x1200, DefaultSize    2, ControlRegister 0x24, Enable 1
  RxPDO 0x1600 "FSOE RxPDO-Map 001"
    PDO entry 0x7000:01,  8 bit, "FSOE Command"
    PDO entry 0x7001:01,  8 bit, "SubIndex 001"
    PDO entry 0x7000:03, 16 bit, "FSOE CRC 001"
    PDO entry 0x7000:02, 16 bit, "FSOE ConnID"
  RxPDO 0x1601 "FSOE RxPDO-Map 002"
    PDO entry 0x7010:01,  8 bit, "FSOE Command"
    PDO entry 0x7011:01,  8 bit, "SubIndex 001"
    PDO entry 0x7010:03, 16 bit, "FSOE CRC 001"
    PDO entry 0x7010:02, 16 bit, "FSOE ConnID"
  RxPDO 0x17f0 "DEVICE RxPDO-Map Standard In Vars"
    PDO entry 0xf201:01,  1 bit, "SubIndex 001"
    PDO entry 0xf201:02,  1 bit, "SubIndex 002"
    PDO entry 0xf201:03,  1 bit, "SubIndex 003"
    PDO entry 0xf201:04,  1 bit, "SubIndex 004"
    PDO entry 0xf201:05,  1 bit, "SubIndex 005"
    PDO entry 0xf201:06,  1 bit, "SubIndex 006"
    PDO entry 0xf201:07,  1 bit, "SubIndex 007"
    PDO entry 0xf201:08,  1 bit, "SubIndex 008"
  RxPDO 0x17ff "DEVICE RxPDO-Map Control"
    PDO entry 0xf200:01, 16 bit, "Control"
SM3: PhysAddr 0x1d00, DefaultSize    2, ControlRegister 0x20, Enable 1
  TxPDO 0x1a00 "FSOE TxPDO-Map 001"
    PDO entry 0x6000:01,  8 bit, "FSOE Command"
    PDO entry 0x6001:01,  8 bit, "SubIndex 001"
    PDO entry 0x6000:03, 16 bit, "FSOE CRC 001"
    PDO entry 0x6000:02, 16 bit, "FSOE ConnID"
  TxPDO 0x1a01 "FSOE TxPDO-Map 002"
    PDO entry 0x6010:01,  8 bit, "FSOE Command"
    PDO entry 0x6011:01,  8 bit, "SubIndex 001"
    PDO entry 0x6010:03, 16 bit, "FSOE CRC 001"
    PDO entry 0x6010:02, 16 bit, "FSOE ConnID"
  TxPDO 0x1bff "DEVICE TxPDO-Map Status"
    PDO entry 0xf100:01,  3 bit, "Safety Project State"
    PDO entry 0x0000:00,  4 bit, "Gap"
    PDO entry 0xf100:08,  1 bit, "Login Active"
    PDO entry 0xf100:09,  1 bit, "Input Size Mismatch"
    PDO entry 0xf100:0a,  1 bit, "Output Size Mismatch"
    PDO entry 0x0000:00,  4 bit, "Gap"
    PDO entry 0xf100:0f,  1 bit, "TxPDO State"
    PDO entry 0xf100:10,  1 bit, "TxPDO Toggle"

When I want to add PDOs, I get following warnings:

EtherCAT WARNING 0-1: Currently mapped PDO entries: 0x7000:01/8 0x7001:01/8 0x7000:03/16 0x7000:02/16. Entries to map: 0x7000:01/8 0x7001:01/8 0x7000:03/16 0x7000:02/16 0x6000:01/48 0x6000:02/48
EtherCAT WARNING 0-1: Slave does not support changing the PDO mapping!

Slave Info EL6900:

=== Master 0, Slave 1 ===
Alias: 100
Device: Main
State: OP
Flag: +
Identity:
  Vendor Id:       0x00000002
  Product code:    0x1af43052
  Revision number: 0x00130000
  Serial number:   0x00000000
DL information:
  FMMU bit operation: no
  Distributed clocks: yes, delay measurement only
  DC system time transmission delay: 145 ns
Port  Type  Link  Loop    Signal  NextSlave  RxTime [ns]  Diff [ns]   NextDc [ns]
   0  EBUS  up    open    yes             0   2874259272           0         145
   1  EBUS  up    open    yes             2   2874260152         880         145
   2  N/A   down  closed  no              -            -           -           -
   3  N/A   down  closed  no              -            -           -           -
Mailboxes:
  Bootstrap RX: 0x1000/244, TX: 0x10f4/244
  Standard  RX: 0x1000/256, TX: 0x1100/256
  Supported protocols: CoE, FoE
General:
  Group: Safety
  Image name: EL69XX
  Order number: EL6900
  Device name: EL6900, TwinSAFE-PLC
  CoE details:
    Enable SDO: yes
    Enable SDO Info: yes
    Enable PDO Assign: no
    Enable PDO Configuration: no
    Enable Upload at startup: no
    Enable SDO complete access: no
  Flags:
    Enable SafeOp: no
    Enable notLRW: no
  Current consumption: 190 mA

I see, that's not possible to assign or to configure PPOs, but what is the right track to setup this system successfully?
The used PDOs are not unique!
Do I have to change settings in TwinCat3? I am not an Expert of this; I only want to use the Safety-Editor to create the Safety - Logic!

In earlier posts here I found, that it is possible to implement Safety Terminals in the etherlab master successfully.
I've already read, that the FSoE - Data (6 Bytes) between the Safety - Terminals must be managed in the cycle_task of the Application; a little bit tricky but make sense.
The last point: In the Safety - Logic I used one variable to set Com/Err - Signal which is also linked to a PDO, I can't mapped!

Thanks in advance for attention and help.

Best regards

Uwe Stegemann

____________________________________
G+D Currency Technology

Uwe Stegemann
Banknote-Engineering - Printing Division / Abt. CTBN 214
Giesecke+Devrient Currency Technology GmbH,
Prinzregentenstraße 159, D-81677 Munich, Germany
T +49 89 4119-2321 F +49 89 4119-1446
mailto:uwe.stegemann at gi-de.com
http://www.gi-de.com<http://www.gi-de.com/>




www.gi-de.com/currency-technology<https://www.gi-de.com/currency-technology/>

[Cash Matters]<http://www.cashmatters.org/>

Geschäftsführer: Dr. Wolfram Seidemann (Vorsitzender, CEO), Guido Koller (CFO), Wolfgang Kneilmann, Bernd Kümmerle
Gesellschaftssitz: München, Handelsregister des AG München, HRB 148256
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220822/5c7f89aa/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 10753 bytes
Desc: image001.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220822/5c7f89aa/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 31664 bytes
Desc: image002.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220822/5c7f89aa/attachment-0003.png>

From Amos.Merkel at ifas.rwth-aachen.de  Tue Aug 30 13:40:43 2022
From: Amos.Merkel at ifas.rwth-aachen.de (Merkel, Amos)
Date: Tue, 30 Aug 2022 11:40:43 +0000
Subject: [Etherlab-users] Random Matlab crashes with Stateflow
In-Reply-To: <39cc5a32f84848d8968a1da2bcf8000b@touchcut.com>
References: <c94160429f514467af689ea9c9fa6706@gi-de.com>
 <39cc5a32f84848d8968a1da2bcf8000b@touchcut.com>
Message-ID: <6df4031353a440c68d6d62af1fe6dbe1@ifas.rwth-aachen.de>

Hi everyone,

I am using the Etherlab environment together with the etherlab Simulink library. For the actual program procedure, I rely mostly on the Stateflow blocks in Simulink. Usually  this works quite well, but I have encountered random crashes while compiling several times now. Typically it is an working Simulink file, you do a small change and encounter the crashes. Reverting the change does not solve the issue, however deleting the stateflow block does. Copy & pasting the stateflow block to another model crashes that one as well, reprogramming the stateflow block exactly the same, but from scratch without copy+pasting anything works without problem.

Does anybody now this effect, or a better solution than programming everything anew?

All the best,
Amos

--
Amos Merkel, M.Sc.
Group leader
Digitalization

ifas - Institute for Fluid Power Drives and Systems
RWTH Aachen University
Campus-Boulevard 30
52074 Aachen

Tel: +49 241 80-47737
Fax: +49 241 80-647712

www.ifas.rwth-aachen.de<http://www.ifas.rwth-aachen.de/> | Twitter<https://twitter.com/IFAS_RWTH> | Facebook<https://www.facebook.com/IFAS-Institut-f%C3%BCr-fluidtechnische-Antriebe-und-Steuerungen-260714043957873/> | YouTube<https://www.youtube.com/channel/UC0vIq8jtra8E_--Sx8DALkQ> | LinkedIn<https://www.linkedin.com/company/ifas-rwth/>









--
Amos Merkel, M.Sc.
Gruppenleiter
Digitalisierung

ifas - Institut für fluidtechnische Antriebe und Systeme
RWTH Aachen University
Campus-Boulevard 30
52074 Aachen

Tel: +49 241 80-47737
Fax: +49 241 80-647712

www.ifas.rwth-aachen.de<http://www.ifas.rwth-aachen.de/> | Twitter<https://twitter.com/IFAS_RWTH> | Facebook<https://www.facebook.com/IFAS-Institut-f%C3%BCr-fluidtechnische-Antriebe-und-Steuerungen-260714043957873/> | YouTube<https://www.youtube.com/channel/UC0vIq8jtra8E_--Sx8DALkQ> | LinkedIn<http://www.linkedin.com/company/ifas-rwth/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220830/bf13dd93/attachment.htm>

From Amos.Merkel at ifas.rwth-aachen.de  Tue Aug 30 17:35:43 2022
From: Amos.Merkel at ifas.rwth-aachen.de (Merkel, Amos)
Date: Tue, 30 Aug 2022 15:35:43 +0000
Subject: [Etherlab-users] Random Matlab crashes with Stateflow
In-Reply-To: <6df4031353a440c68d6d62af1fe6dbe1@ifas.rwth-aachen.de>
References: <c94160429f514467af689ea9c9fa6706@gi-de.com>
 <39cc5a32f84848d8968a1da2bcf8000b@touchcut.com>
 <6df4031353a440c68d6d62af1fe6dbe1@ifas.rwth-aachen.de>
Message-ID: <2a7f583d718a44e6abb3fadaa1b88a6f@ifas.rwth-aachen.de>

Hi,

correction: While the problem described below exists, the current crashes are not random but related to the use of messages in "Chart" stateflow blocks in Simulink.

The whole thing seems like a bug, I just cannot say if it is Matlab or Etherlab. The problem didn't exist a week or two ago, now a Chart containing a message crashes Matlab when compiling with the etherlab target. As I didn't change my Matlab installation, but pulled an update for my system some time ago, I guess the problem is caused by some change in the etherlab toolchain.

If you are interested, you will find two minimum examples attached, one that crashes and one that doesn't crash. Note that once Matlab crashed, it will crash every time until all compile files are deleted (folders slprj and <model>_etl_hrt). I am using openSUSE 15.2 with Linux 5.3.18-lp152.3.14-rt, the current etherlab environment from the openSUSE repository and Matlab R2020a.

All the best,
Amos

--
Amos Merkel, M.Sc.
Gruppenleiter
Digitalisierung

ifas - Institut für fluidtechnische Antriebe und Systeme
RWTH Aachen University
Campus-Boulevard 30
52074 Aachen

Tel: +49 241 80-47737
Fax: +49 241 80-647712

www.ifas.rwth-aachen.de<http://www.ifas.rwth-aachen.de/> | Twitter<https://twitter.com/IFAS_RWTH> | Facebook<https://www.facebook.com/IFAS-Institut-f%C3%BCr-fluidtechnische-Antriebe-und-Steuerungen-260714043957873/> | YouTube<https://www.youtube.com/channel/UC0vIq8jtra8E_--Sx8DALkQ> | LinkedIn<http://www.linkedin.com/company/ifas-rwth/>









Von: Etherlab-users <etherlab-users-bounces at etherlab.org> Im Auftrag von Merkel, Amos
Gesendet: Dienstag, 30. August 2022 13:41
An: etherlab-users at etherlab.org
Betreff: [Etherlab-users] Random Matlab crashes with Stateflow

Hi everyone,

I am using the Etherlab environment together with the etherlab Simulink library. For the actual program procedure, I rely mostly on the Stateflow blocks in Simulink. Usually  this works quite well, but I have encountered random crashes while compiling several times now. Typically it is an working Simulink file, you do a small change and encounter the crashes. Reverting the change does not solve the issue, however deleting the stateflow block does. Copy & pasting the stateflow block to another model crashes that one as well, reprogramming the stateflow block exactly the same, but from scratch without copy+pasting anything works without problem.

Does anybody now this effect, or a better solution than programming everything anew?

All the best,
Amos

--
Amos Merkel, M.Sc.
Group leader
Digitalization

ifas - Institute for Fluid Power Drives and Systems
RWTH Aachen University
Campus-Boulevard 30
52074 Aachen

Tel: +49 241 80-47737
Fax: +49 241 80-647712

www.ifas.rwth-aachen.de<http://www.ifas.rwth-aachen.de/> | Twitter<https://twitter.com/IFAS_RWTH> | Facebook<https://www.facebook.com/IFAS-Institut-f%C3%BCr-fluidtechnische-Antriebe-und-Steuerungen-260714043957873/> | YouTube<https://www.youtube.com/channel/UC0vIq8jtra8E_--Sx8DALkQ> | LinkedIn<https://www.linkedin.com/company/ifas-rwth/>









--
Amos Merkel, M.Sc.
Gruppenleiter
Digitalisierung

ifas - Institut für fluidtechnische Antriebe und Systeme
RWTH Aachen University
Campus-Boulevard 30
52074 Aachen

Tel: +49 241 80-47737
Fax: +49 241 80-647712

www.ifas.rwth-aachen.de<http://www.ifas.rwth-aachen.de/> | Twitter<https://twitter.com/IFAS_RWTH> | Facebook<https://www.facebook.com/IFAS-Institut-f%C3%BCr-fluidtechnische-Antriebe-und-Steuerungen-260714043957873/> | YouTube<https://www.youtube.com/channel/UC0vIq8jtra8E_--Sx8DALkQ> | LinkedIn<http://www.linkedin.com/company/ifas-rwth/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220830/f09ffe33/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: matlab_crash_dump.23232-1
Type: application/octet-stream
Size: 16240 bytes
Desc: matlab_crash_dump.23232-1
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220830/f09ffe33/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Minimum_Crash_R2013a.slx
Type: application/octet-stream
Size: 27394 bytes
Desc: Minimum_Crash_R2013a.slx
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220830/f09ffe33/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Minimum_NoCrash_R2013a.slx
Type: application/octet-stream
Size: 15438 bytes
Desc: Minimum_NoCrash_R2013a.slx
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220830/f09ffe33/attachment-0005.obj>

From andreas.stewering-bone at gmx.de  Wed Aug 31 08:36:10 2022
From: andreas.stewering-bone at gmx.de (Andreas Stewering-Bone)
Date: Wed, 31 Aug 2022 08:36:10 +0200
Subject: [Etherlab-users] Random Matlab crashes with Stateflow
In-Reply-To: <2a7f583d718a44e6abb3fadaa1b88a6f@ifas.rwth-aachen.de>
References: <c94160429f514467af689ea9c9fa6706@gi-de.com>
 <39cc5a32f84848d8968a1da2bcf8000b@touchcut.com>
 <6df4031353a440c68d6d62af1fe6dbe1@ifas.rwth-aachen.de>
 <2a7f583d718a44e6abb3fadaa1b88a6f@ifas.rwth-aachen.de>
Message-ID: <d56f4ac8e5ff12e84f81829eaed53492a97b66df.camel@gmx.de>

Dear Amos,

The matlab library dependencies under linux are very specific and
critical.
You talked about an system upgrade, this can cause the crash because of
an library incompatibility.

Etherlab itself has nearly no influence on the code generation and
compilation. 
A failure in Etherlab can only cause a compilation failure or a runtime
failure in the included S-Functions.

Try to generate the code for the grt-Target. I think you will get the
same result.

You talk about messages in a stateflow chart, Etherlab messages??

Best regards

Andreas

Am Dienstag, dem 30.08.2022 um 15:35 +0000 schrieb Merkel, Amos:
> Hi,
>  
> correction: While the problem described below exists, the current
> crashes are not random but related to the use of messages in “Chart”
> stateflow blocks in Simulink.
>  
> The whole thing seems like a bug, I just cannot say if it is Matlab
> or Etherlab. The problem didn’t exist a week or two ago, now a Chart
> containing a message crashes Matlab when compiling with the etherlab
> target. As I didn’t change my Matlab installation, but pulled an
> update for my system some time ago, I guess the problem is caused by
> some change in the etherlab toolchain.
>  
> If you are interested, you will find two minimum examples attached,
> one that crashes and one that doesn’t crash. Note that once Matlab
> crashed, it will crash every time until all compile files are deleted
> (folders slprj and <model>_etl_hrt). I am using openSUSE 15.2 with
> Linux 5.3.18-lp152.3.14-rt, the current etherlab environment from the
> openSUSE repository and Matlab R2020a.
>  
> All the best,
> Amos
>  
> --
> Amos Merkel, M.Sc.
> Gruppenleiter
> Digitalisierung 
> 
> ifas – Institut für fluidtechnische Antriebe und Systeme
> RWTH Aachen University
> Campus-Boulevard 30
> 52074 Aachen
> 
> Tel: +49 241 80-47737
> Fax: +49 241 80-647712
> 
> www.ifas.rwth-aachen.de |Twitter |Facebook | YouTube |LinkedIn
>  
>  
>  
>  
>  
>  
> Von: Etherlab-users <etherlab-users-bounces at etherlab.org>Im Auftrag
> von Merkel, Amos
> Gesendet: Dienstag, 30. August 2022 13:41
> An: etherlab-users at etherlab.org
> Betreff: [Etherlab-users] Random Matlab crashes with Stateflow
>  
> Hi everyone,
>  
> I am using the Etherlab environment together with the etherlab
> Simulink library. For the actual program procedure, I rely mostly on
> the Stateflow blocks in Simulink. Usually  this works quite well, but
> I have encountered random crashes while compiling several times now.
> Typically it is an working Simulink file, you do a small change and
> encounter the crashes. Reverting the change does not solve the issue,
> however deleting the stateflow block does. Copy & pasting the
> stateflow block to another model crashes that one as well,
> reprogramming the stateflow block exactly the same, but from scratch
> without copy+pasting anything works without problem.
>  
> Does anybody now this effect, or a better solution than programming
> everything anew?
>  
> All the best,
> Amos
>  
> --
> Amos Merkel, M.Sc.
> Group leader
> Digitalization 
> 
> ifas – Institute for Fluid Power Drives and Systems
> RWTH Aachen University
> Campus-Boulevard 30
> 52074 Aachen
> 
> Tel: +49 241 80-47737
> Fax: +49 241 80-647712
>  
> www.ifas.rwth-aachen.de | Twitter | Facebook | YouTube | LinkedIn
>  
>  
>  
>  
>  
>  
>  
>  
> --
> Amos Merkel, M.Sc.
> Gruppenleiter
> Digitalisierung 
> 
> ifas – Institut für fluidtechnische Antriebe und Systeme
> RWTH Aachen University
> Campus-Boulevard 30
> 52074 Aachen
> 
> Tel: +49 241 80-47737
> Fax: +49 241 80-647712
> 
> www.ifas.rwth-aachen.de |Twitter |Facebook | YouTube |LinkedIn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220831/60d309ed/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220831/60d309ed/attachment.sig>

From Amos.Merkel at ifas.rwth-aachen.de  Wed Aug 31 10:00:09 2022
From: Amos.Merkel at ifas.rwth-aachen.de (Merkel, Amos)
Date: Wed, 31 Aug 2022 08:00:09 +0000
Subject: [Etherlab-users] Random Matlab crashes with Stateflow
In-Reply-To: <d56f4ac8e5ff12e84f81829eaed53492a97b66df.camel@gmx.de>
References: <c94160429f514467af689ea9c9fa6706@gi-de.com>
 <39cc5a32f84848d8968a1da2bcf8000b@touchcut.com>
 <6df4031353a440c68d6d62af1fe6dbe1@ifas.rwth-aachen.de>
 <2a7f583d718a44e6abb3fadaa1b88a6f@ifas.rwth-aachen.de>
 <d56f4ac8e5ff12e84f81829eaed53492a97b66df.camel@gmx.de>
Message-ID: <301a19ca93d748e5b0ac8764c25d3198@ifas.rwth-aachen.de>

Dear Andreas,

Thanks a lot for your input! You definitely put me on the right track – the crash did not occur with the grt Target, so I searched for differences and found we had the classic call interface activated by default in our templates. That is what caused the crashes – without both grt and etherlab work, with Classic Call Interface activated, grt fails with an error message and etherlab crashes all of Matlab.

When I was wrote about messages, I meant the Simulink messages (https://de.mathworks.com/help/simulink/ug/simulink-messages-overview.html). We use them to implement communication between state machines in our Controls.

Best regards and thanks again,
Amos


--
Amos Merkel, M.Sc.
Gruppenleiter
Digitalisierung

ifas – Institut für fluidtechnische Antriebe und Systeme
RWTH Aachen University
Campus-Boulevard 30
52074 Aachen

Tel: +49 241 80-47737
Fax: +49 241 80-647712

www.ifas.rwth-aachen.de<http://www.ifas.rwth-aachen.de/> | Twitter<https://twitter.com/IFAS_RWTH> | Facebook<https://www.facebook.com/IFAS-Institut-f%C3%BCr-fluidtechnische-Antriebe-und-Steuerungen-260714043957873/> | YouTube<https://www.youtube.com/channel/UC0vIq8jtra8E_--Sx8DALkQ> | LinkedIn<http://www.linkedin.com/company/ifas-rwth/>









Von: Etherlab-users <etherlab-users-bounces at etherlab.org> Im Auftrag von Andreas Stewering-Bone
Gesendet: Mittwoch, 31. August 2022 08:36
An: etherlab-users at etherlab.org
Betreff: Re: [Etherlab-users] Random Matlab crashes with Stateflow

Dear Amos,

The matlab library dependencies under linux are very specific and critical.
You talked about an system upgrade, this can cause the crash because of an library incompatibility.

Etherlab itself has nearly no influence on the code generation and compilation.
A failure in Etherlab can only cause a compilation failure or a runtime failure in the included S-Functions.

Try to generate the code for the grt-Target. I think you will get the same result.

You talk about messages in a stateflow chart, Etherlab messages??

Best regards

Andreas

Am Dienstag, dem 30.08.2022 um 15:35 +0000 schrieb Merkel, Amos:
Hi,

correction: While the problem described below exists, the current crashes are not random but related to the use of messages in “Chart” stateflow blocks in Simulink.

The whole thing seems like a bug, I just cannot say if it is Matlab or Etherlab. The problem didn’t exist a week or two ago, now a Chart containing a message crashes Matlab when compiling with the etherlab target. As I didn’t change my Matlab installation, but pulled an update for my system some time ago, I guess the problem is caused by some change in the etherlab toolchain.

If you are interested, you will find two minimum examples attached, one that crashes and one that doesn’t crash. Note that once Matlab crashed, it will crash every time until all compile files are deleted (folders slprj and <model>_etl_hrt). I am using openSUSE 15.2 with Linux 5.3.18-lp152.3.14-rt, the current etherlab environment from the openSUSE repository and Matlab R2020a.

All the best,
Amos

--
Amos Merkel, M.Sc.
Gruppenleiter
Digitalisierung

ifas – Institut für fluidtechnische Antriebe und Systeme
RWTH Aachen University
Campus-Boulevard 30
52074 Aachen

Tel: +49 241 80-47737
Fax: +49 241 80-647712

www.ifas.rwth-aachen.de<http://www.ifas.rwth-aachen.de/> |Twitter<https://twitter.com/IFAS_RWTH> |Facebook<https://www.facebook.com/IFAS-Institut-f%C3%BCr-fluidtechnische-Antriebe-und-Steuerungen-260714043957873/> | YouTube<https://www.youtube.com/channel/UC0vIq8jtra8E_--Sx8DALkQ> |LinkedIn<http://www.linkedin.com/company/ifas-rwth/>











Von: Etherlab-users <etherlab-users-bounces at etherlab.org<mailto:etherlab-users-bounces at etherlab.org>>Im Auftrag von Merkel, Amos
Gesendet: Dienstag, 30. August 2022 13:41
An: etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Betreff: [Etherlab-users] Random Matlab crashes with Stateflow

Hi everyone,

I am using the Etherlab environment together with the etherlab Simulink library. For the actual program procedure, I rely mostly on the Stateflow blocks in Simulink. Usually  this works quite well, but I have encountered random crashes while compiling several times now. Typically it is an working Simulink file, you do a small change and encounter the crashes. Reverting the change does not solve the issue, however deleting the stateflow block does. Copy & pasting the stateflow block to another model crashes that one as well, reprogramming the stateflow block exactly the same, but from scratch without copy+pasting anything works without problem.

Does anybody now this effect, or a better solution than programming everything anew?

All the best,
Amos

--
Amos Merkel, M.Sc.
Group leader
Digitalization

ifas – Institute for Fluid Power Drives and Systems
RWTH Aachen University
Campus-Boulevard 30
52074 Aachen

Tel: +49 241 80-47737
Fax: +49 241 80-647712

www.ifas.rwth-aachen.de<http://www.ifas.rwth-aachen.de/> | Twitter<https://twitter.com/IFAS_RWTH> | Facebook<https://www.facebook.com/IFAS-Institut-f%C3%BCr-fluidtechnische-Antriebe-und-Steuerungen-260714043957873/> | YouTube<https://www.youtube.com/channel/UC0vIq8jtra8E_--Sx8DALkQ> | LinkedIn<https://www.linkedin.com/company/ifas-rwth/>









--
Amos Merkel, M.Sc.
Gruppenleiter
Digitalisierung

ifas – Institut für fluidtechnische Antriebe und Systeme
RWTH Aachen University
Campus-Boulevard 30
52074 Aachen

Tel: +49 241 80-47737
Fax: +49 241 80-647712

www.ifas.rwth-aachen.de<http://www.ifas.rwth-aachen.de/> |Twitter<https://twitter.com/IFAS_RWTH> |Facebook<https://www.facebook.com/IFAS-Institut-f%C3%BCr-fluidtechnische-Antriebe-und-Steuerungen-260714043957873/> | YouTube<https://www.youtube.com/channel/UC0vIq8jtra8E_--Sx8DALkQ> |LinkedIn<http://www.linkedin.com/company/ifas-rwth/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220831/1f4dc026/attachment-0001.htm>

From andreas.stewering-bone at gmx.de  Wed Aug 31 10:10:01 2022
From: andreas.stewering-bone at gmx.de (Andreas Stewering-Bone)
Date: Wed, 31 Aug 2022 10:10:01 +0200
Subject: [Etherlab-users] Random Matlab crashes with Stateflow
In-Reply-To: <301a19ca93d748e5b0ac8764c25d3198@ifas.rwth-aachen.de>
References: <c94160429f514467af689ea9c9fa6706@gi-de.com>
 <39cc5a32f84848d8968a1da2bcf8000b@touchcut.com>
 <6df4031353a440c68d6d62af1fe6dbe1@ifas.rwth-aachen.de>
 <2a7f583d718a44e6abb3fadaa1b88a6f@ifas.rwth-aachen.de>
 <d56f4ac8e5ff12e84f81829eaed53492a97b66df.camel@gmx.de>
 <301a19ca93d748e5b0ac8764c25d3198@ifas.rwth-aachen.de>
Message-ID: <abd47b71057940210867f2445820ab6d2348099a.camel@gmx.de>

Dear Amos,

The message subsystem can cause some problems with the Etherlab
runtime.
I do not know this system exactly, but maybe the compilation fails
caused by missing dependencies in hrt_main.c (from Etherlab).
The message subsystem is a preperation for a middleware system and I
expect special runtime requirements for it outside the generated code.

If you use an actual EtherLab installation, you do not need the Classic
call interface anymore.

Am Mittwoch, dem 31.08.2022 um 08:00 +0000 schrieb Merkel, Amos:
> Dear Andreas,
>  
> Thanks a lot for your input! You definitely put me on the right track
> – the crash did not occur with the grt Target, so I searched for
> differences and found we had the classic call interface activated by
> default in our templates. That is what caused the crashes – without
> both grt and etherlab work, with Classic Call Interface activated,
> grt fails with an error message and etherlab crashes all of Matlab.
>  
> When I was wrote about messages, I meant the Simulink messages
> (https://de.mathworks.com/help/simulink/ug/simulink-messages-overview.html
> ). We use them to implement communication between state machines in
> our Controls.
>  
> Best regards and thanks again,
> Amos
>  
>  
> --
> Amos Merkel, M.Sc.
> Gruppenleiter
> Digitalisierung 
> 
> ifas – Institut für fluidtechnische Antriebe und Systeme
> RWTH Aachen University
> Campus-Boulevard 30
> 52074 Aachen
> 
> Tel: +49 241 80-47737
> Fax: +49 241 80-647712
> 
> www.ifas.rwth-aachen.de |Twitter |Facebook | YouTube |LinkedIn
>  
>  
>  
>  
>  
>  
> Von: Etherlab-users <etherlab-users-bounces at etherlab.org>Im Auftrag
> von Andreas Stewering-Bone
> Gesendet: Mittwoch, 31. August 2022 08:36
> An: etherlab-users at etherlab.org
> Betreff: Re: [Etherlab-users] Random Matlab crashes with Stateflow
>  
> Dear Amos,
>  
> The matlab library dependencies under linux are very specific and
> critical.
> You talked about an system upgrade, this can cause the crash because
> of an library incompatibility.
>  
> Etherlab itself has nearly no influence on the code generation and
> compilation. 
> A failure in Etherlab can only cause a compilation failure or a
> runtime failure in the included S-Functions.
>  
> Try to generate the code for the grt-Target. I think you will get the
> same result.
>  
> You talk about messages in a stateflow chart, Etherlab messages??
>  
> Best regards
>  
> Andreas
>  
> Am Dienstag, dem 30.08.2022 um 15:35 +0000 schrieb Merkel, Amos:
> > Hi,
> >  
> > correction: While the problem described below exists, the current
> > crashes are not random but related to the use of messages in
> > “Chart” stateflow blocks in Simulink.
> >  
> > The whole thing seems like a bug, I just cannot say if it is Matlab
> > or Etherlab. The problem didn’t exist a week or two ago, now a
> > Chart containing a message crashes Matlab when compiling with the
> > etherlab target. As I didn’t change my Matlab installation, but
> > pulled an update for my system some time ago, I guess the problem
> > is caused by some change in the etherlab toolchain.
> >  
> > If you are interested, you will find two minimum examples attached,
> > one that crashes and one that doesn’t crash. Note that once Matlab
> > crashed, it will crash every time until all compile files are
> > deleted (folders slprj and <model>_etl_hrt). I am using openSUSE
> > 15.2 with Linux 5.3.18-lp152.3.14-rt, the current etherlab
> > environment from the openSUSE repository and Matlab R2020a.
> >  
> > All the best,
> > Amos
> >  
> > --
> > Amos Merkel, M.Sc.
> > Gruppenleiter
> > Digitalisierung 
> > 
> > ifas – Institut für fluidtechnische Antriebe und Systeme
> > RWTH Aachen University
> > Campus-Boulevard 30
> > 52074 Aachen
> > 
> > Tel: +49 241 80-47737
> > Fax: +49 241 80-647712
> > 
> > www.ifas.rwth-aachen.de |Twitter |Facebook | YouTube |LinkedIn
> >  
> >  
> >  
> >  
> >  
> >  
> > Von: Etherlab-users <etherlab-users-bounces at etherlab.org>Im Auftrag
> > vonMerkel, Amos
> > Gesendet: Dienstag, 30. August 2022 13:41
> > An: etherlab-users at etherlab.org
> > Betreff: [Etherlab-users] Random Matlab crashes with Stateflow
> >  
> > Hi everyone,
> >  
> > I am using the Etherlab environment together with the etherlab
> > Simulink library. For the actual program procedure, I rely mostly
> > on the Stateflow blocks in Simulink. Usually  this works quite
> > well, but I have encountered random crashes while compiling several
> > times now. Typically it is an working Simulink file, you do a small
> > change and encounter the crashes. Reverting the change does not
> > solve the issue, however deleting the stateflow block does. Copy &
> > pasting the stateflow block to another model crashes that one as
> > well, reprogramming the stateflow block exactly the same, but from
> > scratch without copy+pasting anything works without problem.
> >  
> > Does anybody now this effect, or a better solution than programming
> > everything anew?
> >  
> > All the best,
> > Amos
> >  
> > --
> > Amos Merkel, M.Sc.
> > Group leader
> > Digitalization 
> > 
> > ifas – Institute for Fluid Power Drives and Systems
> > RWTH Aachen University
> > Campus-Boulevard 30
> > 52074 Aachen
> > 
> > Tel: +49 241 80-47737
> > Fax: +49 241 80-647712
> >  
> > www.ifas.rwth-aachen.de | Twitter | Facebook | YouTube | LinkedIn
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> > --
> > Amos Merkel, M.Sc.
> > Gruppenleiter
> > Digitalisierung 
> > 
> > ifas – Institut für fluidtechnische Antriebe und Systeme
> > RWTH Aachen University
> > Campus-Boulevard 30
> > 52074 Aachen
> > 
> > Tel: +49 241 80-47737
> > Fax: +49 241 80-647712
> > 
> > www.ifas.rwth-aachen.de |Twitter |Facebook | YouTube |LinkedIn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220831/17f149e2/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220831/17f149e2/attachment-0001.sig>