Using pyxcp to communicate via a xcp and asap2/cdf #172

tuttoaldoc · 2024-10-01T14:47:06Z

tuttoaldoc
Oct 1, 2024

Hi,
I would like to use pyxcp to communicate with an embedded HW running an application generated via matlab Simulink Embedded Coder. By default matlab support communication via xcp and asap2/cdf protocol. Is the pyxcp the right choice? Matlab provides 2 "calibration files": ASAP2 and CDF format. Is there a simple example to see how I could use them?
thanks
Michele

christoph2 · 2024-10-01T16:16:45Z

christoph2
Oct 1, 2024
Maintainer

Yes, this could be basically done with pyXCP, together with some other projects.

As a starting point (after installation), please refer to discussion #165 for some useful information -- documentation is hopefully coming soon.

0 replies

christoph2 · 2024-10-01T16:23:44Z

christoph2
Oct 1, 2024
Maintainer

I'm pretty sure your .a2l file contains some MEASUREMENTs, use them to do some measurements based on run_daq.py.
There`s also a useful xcp-info script (should be now in your PATH).

0 replies

tuttoaldoc · 2024-10-09T12:01:42Z

tuttoaldoc
Oct 9, 2024
Author

Hello, I'm sorry to bother you. I'm trying to run xcphello.py file.
I created a conf_eth.toml

TRANSPORT = "ETH"
HOST = "192.168.1.101"
PORT = 22
PROTOCOL = "TCP"
IPV6 = false
CREATE_DAQ_TIMESTAMPS = false
#SEED_N_KEY_DLL="SeedNKeyXcp.dll"

and I created a pyxcp_conf.py from it.
I than tried to launch the xcphello.py. It seems it connects, wait a little bit but than it gives me an error "OSError: [WinError 10056] Richiesta di connessione inoltrata ad un socket già connesso" like it's connecting again to a socket already connected. I'm trying to connect to my target in TCP. As I wrote at the beginning I don't really know if I set up well the xcp communication in the mathworks simulink part, but it seems to me that the error is something different.
thanks for the supprot
Michele

C:\Dev\hot_upgrade\fw_update_atp>python xcphello.py
C:\Dev\hot_upgrade\fw_update_atp\xcphello.py:19: DeprecationWarning: callout argument is currently not supported.
ap = ArgumentParser(description="pyXCP hello world.", callout=callout)
C:\Dev\hot_upgrade\fw_update_atp\xcphello.py:20: DeprecationWarning: Argument parser extension is currently not supported.
ap.parser.add_argument(
2024-10-09 13:54:59 INFO XCPonEth - Connected to: 192.168.1.101:22 local address: 192.168.1.105:56526 [AF_INET][SOCK_STREAM] eth.py:1032024-10-09 13:55:21 ERROR Traceback (most recent call last): master.py:130 File "C:\Dev\hot_upgrade\fw_update_atp\xcphello.py", line 30, in
x.connect()
File "C:\Dev\hot_upgrade\atp_core\socomecenv\socomecenv\lib\site-packages\pyxcp\master\errorhandler.py", line 431, in inner
res = executor(inst, func, arguments)
File "C:\Dev\hot_upgrade\atp_core\socomecenv\socomecenv\lib\site-packages\pyxcp\master\errorhandler.py", line 363, in call
res = handler.execute()
File "C:\Dev\hot_upgrade\atp_core\socomecenv\socomecenv\lib\site-packages\pyxcp\master\errorhandler.py", line 230, in execute
return self.func(self.instance, *self.arguments.args, **self.arguments.kwargs)
File "C:\Dev\hot_upgrade\atp_core\socomecenv\socomecenv\lib\site-packages\pyxcp\master\master.py", line 175, in connect
self.transport.connect()
File "C:\Dev\hot_upgrade\atp_core\socomecenv\socomecenv\lib\site-packages\pyxcp\transport\eth.py", line 102, in connect
self.sock.connect(self.sockaddr)
OSError: [WinError 10056] Richiesta di connessione inoltrata ad un socket già connesso

1 reply

tuttoaldoc Oct 9, 2024
Author

I debugged a little bit and I think it's a problem of my target that is not replying me after xcp connect request

christoph2 · 2024-10-09T13:01:06Z

christoph2
Oct 9, 2024
Maintainer

One thing looks really odd: XCP slaves are usually listening on port 5555 per default, while 22 is reserved for SSH...
UDP is also more common in the XCP world.

2 replies

tuttoaldoc Oct 9, 2024
Author

I'm trying to understand how mathworks set up this communication because all the documentation provided are focused on the communication between matlab and the embedded target. In my case I want to substitute matlab with a python application. Theoretically mathworks embedded coder automatically embeds XCP when generating code for an embedded coder .. as far as I understood.
thanks

danielhrisca Oct 9, 2024

In our case it's mostly TCP and we have also some other ports used, but not overriding the traditional TCP port numbers

christoph2 · 2024-10-09T13:11:58Z

christoph2
Oct 9, 2024
Maintainer

OK, if the communication between Matlab and your target is working, then the packet sniffer Wireshark would be a great help to see whats going on.

0 replies

tuttoaldoc · 2024-10-28T16:44:28Z

tuttoaldoc
Oct 28, 2024
Author

Hello Christophe,
I'm back on the topic. I was able to setup the generation of my matlab application in order to communicate with pyxcp. I can connect and I'm able to run the xcp_read_benchmark.py example. I have instead some problems with the others because it seems the matlab application doens't support all the command defined for example in getDaqInfo(). I need to set some parameters and read some measurements. Are there some "raw" commands to do that?
thanks a lot for the support
Michele

1 reply

tuttoaldoc Oct 29, 2024
Author

I commented out some commands not supported by mathworks and now I'm able to connect and read parameters. I'm struggling to get something from measurement. I'm trying using the daq_run example or the manual upload example. With the first I receive 0 even if I see from the application console that the configurations are received, daq is started and stopped, .. With the manual upload I get always 0 even if using it with parameters I get correct values.
thanks

christoph2 · 2024-10-29T16:35:32Z

christoph2
Oct 29, 2024
Maintainer

Yes, the neccessary raw commands for measurement and calibration stuff are of cause available.

But you don't need to start on this level -- on multiple requests I added some high-level functions for DAQ list recording;
please refer to run_daq.py as a starting point, I hope the setup process is rather self-explainatory.

I any case, please also have a look a this discussion, which I'll re-use for documentation purposes.

The high-level calibaration functions are partly available as part of asamint, basically missing is a common internal representation for the various calibration data formats (CDFX, DAMOS, CVX, ...), but I'm currently working hard on this issue.

And the script xcp_info.py should be much more useful than xcp_read_benchmark.py ...

1 reply

tuttoaldoc Oct 30, 2024
Author

Hi,
I finally was able to understand that there was a problem with compiler used with matlab. Now the executable seems to work and if I read measurement via upload function I get some reasonable value. Following the run_daq example it seems istead that I don't receive anything. It's not clear to me how and where data are stored. Could you give me some insight? Which function is used to get the data? Where I can find them? In daq_parser.start() daq_parser.stop() I just see the XCP command sent but I cannot get where and how data are recorded.
thanks

christoph2 · 2024-10-30T17:45:57Z

christoph2
Oct 30, 2024
Maintainer

While there is also the possibility to do live processing (callback based), in case of run_daq.py the DAQ recordings are written to a proprietary file format; the relevant line in the example code is:

daq_parser = DaqRecorder(DAQ_LISTS, "run_daq", 2)  # Record to ".xmraw" file.

i.e. the result file is run_daq.xmraw

Then there are five further example files (starting with ex_), demonstrating how-to extract the recordings from .xmraw to ASAM MDF, Arrow/Parquet, CSV, Excel workbook, resp. SQLite3.
Let me know if there are any questions.

1 reply

tuttoaldoc Oct 31, 2024
Author

My problem is that, as I wrote, via upload functions I read a value but with DaqRecorder I get a void raw file and I'm not able to understand what is wrong with it

christoph2 · 2024-10-31T10:00:08Z

christoph2
Oct 31, 2024
Maintainer

OK, then you need to trace the XCP traffic -- use command line parameter -l DEBUG
The output of xcp-info would also be interesting.

2 replies

tuttoaldoc Oct 31, 2024
Author

I did.
I don't see any problem or error but the generated raw file has nothing.

I got this output at python level

run_daq -l DEBUG
[PyXCP] pyxcp version: 0.22.8
[PyXCP] Looking for pyxcp_conf in C:\Dev\hot_upgrade\fw_update_atp
[PyXCP] Loaded config file: C:\Dev\hot_upgrade\fw_update_atp\pyxcp_conf.py
2024-10-31 12:14:19 DEBUG Execute(Master.connect -- Arguments(ARGS = (), KWS = {})) errorhandler.py:226 INFO XCPonEth - Connected to: 127.0.0.1:17725 local address: 127.0.0.1:58315 [AF_INET][SOCK_STREAM] eth.py:103 DEBUG CONNECT base.py:294 DEBUG -> [02 00 00 00 ff 00] base.py:310 DEBUG <- L8 C1 [ff 05 00 ff fc ff 01 01] base.py:376 DEBUG Execute(Master.getStatus -- Arguments(ARGS = (), KWS = {})) errorhandler.py:226 DEBUG GET_STATUS base.py:294 DEBUG -> [01 00 01 00 fd] base.py:310 DEBUG <- L6 C2 [ff 00 00 00 00 00] base.py:376setup DAQ lists.
DEBUG Execute(Master.getDaqProcessorInfo -- Arguments(ARGS = (), KWS = {})) errorhandler.py:226 DEBUG GET_DAQ_PROCESSOR_INFO base.py:294 DEBUG -> [01 00 02 00 da] base.py:310 DEBUG <- L8 C3 [ff 11 ff ff 80 00 00 00] base.py:376 DEBUG Execute(Master.getDaqResolutionInfo -- Arguments(ARGS = (), KWS = {})) errorhandler.py:226 DEBUG GET_DAQ_RESOLUTION_INFO base.py:294 DEBUG -> [01 00 03 00 d9] base.py:310 DEBUG <- L8 C4 [ff 01 ff 01 ff 34 01 00] base.py:376 DEBUG Execute(Master.freeDaq -- Arguments(ARGS = (), KWS = {})) errorhandler.py:226 DEBUG FREE_DAQ base.py:294 DEBUG -> [01 00 04 00 d6] base.py:310 DEBUG <- L1 C5 [ff] base.py:376 DEBUG Execute(Master.allocDaq -- Arguments(ARGS = (1,), KWS = {})) errorhandler.py:226 DEBUG ALLOC_DAQ base.py:294 DEBUG -> [04 00 05 00 d5 00 01 00] base.py:310 DEBUG <- L1 C6 [ff] base.py:376 DEBUG Execute(Master.allocOdt -- Arguments(ARGS = (0, 1), KWS = {})) errorhandler.py:226 DEBUG ALLOC_ODT base.py:294 DEBUG -> [05 00 06 00 d4 00 00 00 01] base.py:310 DEBUG <- L1 C7 [ff] base.py:376 DEBUG Execute(Master.allocOdtEntry -- Arguments(ARGS = (0, 0, 1), KWS = {})) errorhandler.py:226 DEBUG ALLOC_ODT_ENTRY base.py:294 DEBUG -> [06 00 07 00 d3 00 00 00 00 01] base.py:310 DEBUG <- L1 C8 [ff] base.py:376 DEBUG Execute(Master.setDaqPtr -- Arguments(ARGS = (0, 0, 0), KWS = {})) errorhandler.py:226 DEBUG SET_DAQ_PTR base.py:294 DEBUG -> [06 00 08 00 e2 00 00 00 00 00] base.py:310 DEBUG <- L1 C9 [ff] base.py:376 DEBUG Execute(Master.writeDaq -- Arguments(ARGS = (255, 16, 0, 637720), KWS = {})) errorhandler.py:226 DEBUG WRITE_DAQ base.py:294 DEBUG -> [08 00 09 00 e1 ff 10 00 18 bb 09 00] base.py:310 DEBUG <- L1 C10 [ff] base.py:376 DEBUG Execute(Master.setDaqListMode -- Arguments(ARGS = (), KWS = {'daqListNumber': 0, 'mode': 16, 'eventChannelNumber': 0, 'prescaler': 1, errorhandler.py:226 'priority': 0}))
DEBUG SET_DAQ_LIST_MODE base.py:294 DEBUG -> [08 00 0a 00 e0 10 00 00 00 00 01 00] base.py:310 DEBUG <- L1 C11 [ff] base.py:376 DEBUG Execute(Master.startStopDaqList -- Arguments(ARGS = (2, 0), KWS = {})) errorhandler.py:226 DEBUG START_STOP_DAQ_LIST base.py:294 DEBUG -> [04 00 0b 00 de 02 00 00] base.py:3102024-10-31 12:14:20 DEBUG <- L2 C12 [ff 00] base.py:376TS-V: 4294967296 scale: 1000
OVRF-Value: 4294967296000
Overflow value: 4294967296000, Overflow counter: 0
start DAQ lists.
DEBUG Execute(Master.startStopSynch -- Arguments(ARGS = (1,), KWS = {})) errorhandler.py:226 DEBUG START_STOP_SYNCH base.py:294 DEBUG -> [02 00 0c 00 dd 01] base.py:310 DEBUG <- L1 C13 [ff] base.py:376Stop DAQ....
2024-10-31 12:14:30 DEBUG Execute(Master.startStopSynch -- Arguments(ARGS = (0,), KWS = {})) errorhandler.py:226 DEBUG START_STOP_SYNCH base.py:294 DEBUG -> [02 00 0d 00 dd 00] base.py:310 DEBUG <- L1 C14 [ff] base.py:376finalize DAQ lists.

                DEBUG    Execute(Master.disconnect -- Arguments(ARGS = (), KWS = {}))                                                                                    errorhandler.py:226                    DEBUG    DISCONNECT                                                                                                                                              base.py:294                    DEBUG    -> [01 00 0e 00 fe]                                                                                                                                     base.py:310                    DEBUG    <- L1 C0 [ff]                                                                                                                                           base.py:376

and this at my application level (where I also enabled debug)

rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 02 00 00 00 ff
rtIOStreamRecv (connection id 0): size = 1, sizeRecvd = 1: 00
CONNECT: entering XCP_CONNECTED status

Resource: 5H
Comm Mode Basic: 0H
Max CTO size: 255
Max DTO size: 65532
Protocol Version: 1
Transport Version: 1
rtIOStreamSend (connection id 0): size = 12, sizeSent = 12: 08 00 01 00 ff 05 00 ff fc ff 01 01
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 01 00 01 00 fd
GET STATUS
Session Status: 0H
Resource Protection Status: 0H
Session Config Id: 0
rtIOStreamSend (connection id 0): size = 10, sizeSent = 10: 06 00 02 00 ff 00 00 00 00 00
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 01 00 02 00 da
GET DAQ PROCESSOR INFO
DAQ Properties: 11H
MAX_DAQ: 65535
MAX_EVENT_CHANNEL: 128
MIN_DAQ: 0
Daq Key Byte: 0H
rtIOStreamSend (connection id 0): size = 12, sizeSent = 12: 08 00 03 00 ff 11 ff ff 80 00 00 00
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 01 00 03 00 d9
GET DAQ RESOLUTION INFO
DAQ ODT Entry size granularity: 1
Max DAQ ODT Entry size: 255
STIM ODT Entry size granularity: 1
Max STIM ODT Entry size: 255
Timestamp Mode = 34H
Timestamp Ticks = 1
rtIOStreamSend (connection id 0): size = 12, sizeSent = 12: 08 00 04 00 ff 01 ff 01 ff 34 01 00
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 01 00 04 00 d6
FREE_DAQ: clearing existing dynamic DAQ lists
rtIOStreamSend (connection id 0): size = 5, sizeSent = 5: 01 00 05 00 ff
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 04 00 05 00 d5
rtIOStreamRecv (connection id 0): size = 3, sizeRecvd = 3: 00 01 00
ALLOC_DAQ: allocating 1 DAQ lists (32 B)
rtIOStreamSend (connection id 0): size = 5, sizeSent = 5: 01 00 06 00 ff
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 05 00 06 00 d4
rtIOStreamRecv (connection id 0): size = 4, sizeRecvd = 4: 00 00 00 01
ALLOC_ODT: allocating 1 ODTs in DAQ list 0 (56 B)
rtIOStreamSend (connection id 0): size = 5, sizeSent = 5: 01 00 07 00 ff
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 06 00 07 00 d3
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 00 00 00 00 01
ALLOC_ODT_ENTRY: allocating 1 ODT Entries in DAQ list 0 ODT 0 (8 B)
rtIOStreamSend (connection id 0): size = 5, sizeSent = 5: 01 00 08 00 ff
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 06 00 08 00 e2
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 00 00 00 00 00
SET_DAQ_PTR: updating current ODT entry pointer to DAQ 0, ODT 0, Entry 0
rtIOStreamSend (connection id 0): size = 5, sizeSent = 5: 01 00 09 00 ff
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 08 00 09 00 e1
rtIOStreamRecv (connection id 0): size = 7, sizeRecvd = 7: ff 10 00 18 bb 09 00
XCP_WRITE_DAQ: writing DAQ 0 ODT 0 Entry 0: bitOffset = ffH size = 16 addressExtension = 0H address = 9bb18H
rtIOStreamSend (connection id 0): size = 5, sizeSent = 5: 01 00 0a 00 ff
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 08 00 0a 00 e0
rtIOStreamRecv (connection id 0): size = 7, sizeRecvd = 7: 10 00 00 00 00 01 00
SET_DAQ_LIST_MODE: setting DAQ list 0: mode = 10H, eventId = 0, prescaler = 1, priority = 0
rtIOStreamSend (connection id 0): size = 5, sizeSent = 5: 01 00 0b 00 ff
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 04 00 0b 00 de
rtIOStreamRecv (connection id 0): size = 3, sizeRecvd = 3: 02 00 00
START_STOP_DAQ_LIST: selected DAQ list 0
rtIOStreamSend (connection id 0): size = 6, sizeSent = 6: 02 00 0c 00 ff 00
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 02 00 0c 00 dd
rtIOStreamRecv (connection id 0): size = 1, sizeRecvd = 1: 01
START_STOP_SYNCH: starting DAQ list 0
rtIOStreamSend (connection id 0): size = 5, sizeSent = 5: 01 00 0d 00 ff
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 02 00 0d 00 dd
rtIOStreamRecv (connection id 0): size = 1, sizeRecvd = 1: 00
START_STOP_SYNCH: stopping DAQ list 0
rtIOStreamSend (connection id 0): size = 5, sizeSent = 5: 01 00 0e 00 ff
rtIOStreamRecv (connection id 0): size = 5, sizeRecvd = 5: 01 00 0e 00 fe
DISCONNECT: entering XCP_DISCONNECTED status
rtIOStreamSend (connection id 0): size = 5, sizeSent = 5: 01 00 00 00 ff

tuttoaldoc Oct 31, 2024
Author

mco_test.txt

I reneamed the output extension as txt in order to upload it.
thanks a lot

christoph2 · 2024-10-31T12:02:53Z

christoph2
Oct 31, 2024
Maintainer

OK, looks good at the first sight -- the only really strange thing seems to be an immediate shutdown after starting the DAQ lists,
without any errors or exceptions; in this case

finalize DAQ lists.

would never be reached...

1 reply

tuttoaldoc Oct 31, 2024
Author

Hi,
I'm not so used with the xcp log. If I disable the debug I get this where I see that the "finalize DAQ lists" is reached. It's the first time I work with the XCP but I still don't understand when the data are recovered. I would expect to see some TCP transaction between master and slave to get the samples measures but here I don't see anything.
I guess it should be the master to request the data, isn't it?
thanks

2024-10-31 15:09:57 INFO XCPonEth - Connected to: 127.0.0.1:17725 local address: 127.0.0.1:62336 [AF_INET][SOCK_STREAM] eth.py:103setup DAQ lists.
TS-V: 4294967296 scale: 1000
OVRF-Value: 4294967296000
Overflow value: 4294967296000, Overflow counter: 0
start DAQ lists.
Stop DAQ....
finalize DAQ lists.

christoph2 · 2024-10-31T15:21:16Z

christoph2
Oct 31, 2024
Maintainer

In DAQ-list mode, the measurements are send periodically from slave to master.

The thing is: the setup procedure seems to run without any problems (otherwise there where Python exceptions),
then the measurement should run for 15 minutes

    daq_parser.start()  # Start DAQ lists.
    time.sleep(15.0 * 60.0)  # Run for 15 minutes.
    print("Stop DAQ....")

but pyXCP seems to terminate immediately (cleanly) for no reason, which is really strange ...

1 reply

tuttoaldoc Oct 31, 2024
Author

no I set the measure to run just 10s to speed it up. Is it a problem?

christoph2 · 2024-10-31T15:36:38Z

christoph2
Oct 31, 2024
Maintainer

Maybe, just try a few minutes.

2 replies

tuttoaldoc Oct 31, 2024
Author

I guess there is an issue with matlab generated executable. I will try to investigate more. Thanks

tuttoaldoc Nov 5, 2024
Author

Hi,
just to update you regarding the point. I was finally able to get data. The event number in the list was set to the wrong number, that's why I wasn't receiving anything
Now it works fine. Thanks!
I had to do 2 modifications of the library:

I changed the DaqProcessor setup because this syntax was not supported "start_datetime: CurrentDatetime | None = None"
in the same function calliong setDaqListMode I had to set the priority to 0 instead of FF because it's not supported by mathworks

self.xcp_master.setDaqListMode(
daqListNumber=i, mode=mode, eventChannelNumber=daq_list.event_num, prescaler=1, priority=0x0 # : priority not supported by mathworks priority=0xFF
)

thanks a lot again for the support

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Using pyxcp to communicate via a xcp and asap2/cdf #172

{{title}}

Replies: 12 comments 12 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Using pyxcp to communicate via a xcp and asap2/cdf #172

tuttoaldoc Oct 1, 2024

Replies: 12 comments · 12 replies

christoph2 Oct 1, 2024 Maintainer

christoph2 Oct 1, 2024 Maintainer

tuttoaldoc Oct 9, 2024 Author

tuttoaldoc Oct 9, 2024 Author

christoph2 Oct 9, 2024 Maintainer

tuttoaldoc Oct 9, 2024 Author

danielhrisca Oct 9, 2024

christoph2 Oct 9, 2024 Maintainer

tuttoaldoc Oct 28, 2024 Author

tuttoaldoc Oct 29, 2024 Author

christoph2 Oct 29, 2024 Maintainer

tuttoaldoc Oct 30, 2024 Author

christoph2 Oct 30, 2024 Maintainer

tuttoaldoc Oct 31, 2024 Author

christoph2 Oct 31, 2024 Maintainer

tuttoaldoc Oct 31, 2024 Author

tuttoaldoc Oct 31, 2024 Author

christoph2 Oct 31, 2024 Maintainer

tuttoaldoc Oct 31, 2024 Author

christoph2 Oct 31, 2024 Maintainer

tuttoaldoc Oct 31, 2024 Author

christoph2 Oct 31, 2024 Maintainer

tuttoaldoc Oct 31, 2024 Author

tuttoaldoc Nov 5, 2024 Author

tuttoaldoc
Oct 1, 2024

Replies: 12 comments 12 replies

christoph2
Oct 1, 2024
Maintainer

christoph2
Oct 1, 2024
Maintainer

tuttoaldoc
Oct 9, 2024
Author

tuttoaldoc Oct 9, 2024
Author

christoph2
Oct 9, 2024
Maintainer

tuttoaldoc Oct 9, 2024
Author

christoph2
Oct 9, 2024
Maintainer

tuttoaldoc
Oct 28, 2024
Author

tuttoaldoc Oct 29, 2024
Author

christoph2
Oct 29, 2024
Maintainer

tuttoaldoc Oct 30, 2024
Author

christoph2
Oct 30, 2024
Maintainer

tuttoaldoc Oct 31, 2024
Author

christoph2
Oct 31, 2024
Maintainer

tuttoaldoc Oct 31, 2024
Author

tuttoaldoc Oct 31, 2024
Author

christoph2
Oct 31, 2024
Maintainer

tuttoaldoc Oct 31, 2024
Author

christoph2
Oct 31, 2024
Maintainer

tuttoaldoc Oct 31, 2024
Author

christoph2
Oct 31, 2024
Maintainer

tuttoaldoc Oct 31, 2024
Author

tuttoaldoc Nov 5, 2024
Author