Search talk: FILE

 
<< < 1 .. 25 26 27 (Page 27 of 27)

Post by salvadegianluca on List files in a directory with SysDiropen And SysDirRead CODESYS Forge talk (Post)
Good morning; I'm facing an issue that seems being caused by the library itself. I'm trying to create the list of all the files that are stored inside a psecific directory. Unluckily the first file is allways hidden. VAR CONSTANT arysEmptyArray:ARRAY[iArrayMinDimension..iArrayMAXDimension] OF STRING := [(iArrayMAXDimension - iArrayMinDimension)('')]; iArrayMinDimension:INT := 1; iArrayMAXDimension:INT := 99; END_VAR VAR_INPUT sDirectoryToInspect:STRING; sSearchFilter:STRING; END_VAR VAR_IN_OUT xCheckFileInsideDirectory:BOOL; END_VAR VAR arysListOfFoundFiles:ARRAY[iArrayMinDimension..iArrayMAXDimension] OF STRING; sNullString:STRING; iNullIndex:INT := 0; libInfoAboutThePath:DirInfo; libResultOfThePathMonitoring:CmpErrors.RTS_IEC_RESULT; libInstanceToMonitorThePath:CmpErrors.RTS_IEC_HANDLE; sEntityToSearch:STRING; dMaxEntityDimension:DINT := SIZEOF(sEntityToSearch); libFileInfo:DirInfo; sFilteredFileName:STRING; iIndexToScrollArrays:INT; END_VAR IF xCheckFileInsideDirectory THEN arysListOfFoundFiles:=arysEmptyArray; iIndexToScrollArrays:=iArrayMinDimension; libInstanceToMonitorThePath:= SysDirOpen(szDir:= sDirectoryToInspect,szDirEntry:=sNullString,diMaxDirEntry:= iNullIndex,pDirInfo:= ADR(libInfoAboutThePath),pResult:= ADR(libResultOfThePathMonitoring)); WHILE libResultOfThePathMonitoring = Errors.ERR_OK AND iIndexToScrollArrays <= iArrayMAXDimension DO sEntityToSearch:= ''; libResultOfThePathMonitoring:=SysDirRead(hDir:=libInstanceToMonitorThePath,szDirEntry:=sEntityToSearch,diMaxDirEntry:=dMaxEntityDimension,pDirInfo:=ADR(libFileInfo)); sFilteredFileName:= FUN_06_00_FindItemInString_0(sFilter:=sSearchFilter,sSource:=sEntityToSearch); IF sFilteredFileName <> '' THEN arysListOfFoundFiles[iIndexToScrollArrays]:=sFilteredFileName; iIndexToScrollArrays:=iIndexToScrollArrays + 1; END_IF IF libResultOfThePathMonitoring <> Errors.ERR_OK THEN libResultOfThePathMonitoring:= Errors.ERR_OK; END_IF END_WHILE libResultOfThePathMonitoring:=SysDirClose(hDir:= libInstanceToMonitorThePath); xCheckFileInsideDirectory:=FALSE; END_IF How is possible to solve this issue? Any known work around?
Last updated: 2024-09-17

Post by salvadegianluca on List files in a directory with SysDiropen And SysDirRead CODESYS Forge talk (Post)
Good morning; I'm facing an issue that seems being caused by the library itself. I'm trying to create the list of all the files that are stored inside a psecific directory. Unluckily the first file is allways hidden. VAR CONSTANT arysEmptyArray:ARRAY[iArrayMinDimension..iArrayMAXDimension] OF STRING := [(iArrayMAXDimension - iArrayMinDimension)('')]; iArrayMinDimension:INT := 1; iArrayMAXDimension:INT := 99; END_VAR VAR_INPUT sDirectoryToInspect:STRING; sSearchFilter:STRING; END_VAR VAR_IN_OUT xCheckFileInsideDirectory:BOOL; END_VAR VAR arysListOfFoundFiles:ARRAY[iArrayMinDimension..iArrayMAXDimension] OF STRING; sNullString:STRING; iNullIndex:INT := 0; libInfoAboutThePath:DirInfo; libResultOfThePathMonitoring:CmpErrors.RTS_IEC_RESULT; libInstanceToMonitorThePath:CmpErrors.RTS_IEC_HANDLE; sEntityToSearch:STRING; dMaxEntityDimension:DINT := SIZEOF(sEntityToSearch); libFileInfo:DirInfo; sFilteredFileName:STRING; iIndexToScrollArrays:INT; END_VAR IF xCheckFileInsideDirectory THEN arysListOfFoundFiles:=arysEmptyArray; iIndexToScrollArrays:=iArrayMinDimension; libInstanceToMonitorThePath:= SysDirOpen(szDir:= sDirectoryToInspect,szDirEntry:=sNullString,diMaxDirEntry:= iNullIndex,pDirInfo:= ADR(libInfoAboutThePath),pResult:= ADR(libResultOfThePathMonitoring)); WHILE libResultOfThePathMonitoring = Errors.ERR_OK AND iIndexToScrollArrays <= iArrayMAXDimension DO sEntityToSearch:= ''; libResultOfThePathMonitoring:=SysDirRead(hDir:=libInstanceToMonitorThePath,szDirEntry:=sEntityToSearch,diMaxDirEntry:=dMaxEntityDimension,pDirInfo:=ADR(libFileInfo)); sFilteredFileName:= FUN_06_00_FindItemInString_0(sFilter:=sSearchFilter,sSource:=sEntityToSearch); IF sFilteredFileName <> '' THEN arysListOfFoundFiles[iIndexToScrollArrays]:=sFilteredFileName; iIndexToScrollArrays:=iIndexToScrollArrays + 1; END_IF IF libResultOfThePathMonitoring <> Errors.ERR_OK THEN libResultOfThePathMonitoring:= Errors.ERR_OK; END_IF END_WHILE libResultOfThePathMonitoring:=SysDirClose(hDir:= libInstanceToMonitorThePath); xCheckFileInsideDirectory:=FALSE; END_IF How is possible to solve this issue? Any known work around?
Last updated: 2024-09-17

Post by bjarne-pagaard on Communication between applications on same device/controller/runtime (Win RTE 3.5.20.20) CODESYS Forge talk (Post)
Hi, I would like to divide a project into multiple applications - as a minimum: one handling visualization and Alarm Manager, one handling I/O and plant control logic. But how to exchange variables between the applications? What have you done to get such a solution? In versions 3.5.19 and earlier, you can have Child applications, where the children can access a GVL in the Parent application. Children apps is no longer possible in 3.5.20 - but you can have 'sibling' apps - Several apps directly under PLC Logic, that is. But how do they best communicate? The Communication Manager / Data Sources Manager is sort of possible via OPC UA, but it seems like overkill and with some limitations - for example no ARRAY OF STRUCT possible this way. If you have separate devices in your project, you can exchange data via 'CODESYS ApplicationV3', but not other applications in the same device (see attachment Datasources.png). You can do it via 'Select the project type'->'Other Project' and select the same project file, but this leads to crashing the Development system when working with the variables afterwards. It would be great to hear your thoughts / experiences on this topic - Bjarne
Last updated: 2024-09-27

Post by jst69 on Python script: Launch Codesys, Execute Script, Exit Codesys CODESYS Forge talk (Post)
Dear all: Question about scripting: I am creating a .NET program that is supposed to Open codesys, open template project, export a bunch of pou, then exit codesys. Launch works, Open project works, Export works, But how do i tell codesys to close itself? I can tell windows to terminate codesys, but i would prefer to do it properly. from __future__ import print_function import sys import System proj = projects.primary # We're interested in POU nodes: POUGuid = Guid("6f9dac99-8de1-4efc-8465-68ac443b7d08") # We collect all POU nodes in that list. pous = [] # From the parent node on, we recursively add POU nodes: def CollectPous(node): if node.type == POUGuid: pous.append(node) else: for child in node.get_children(): CollectPous(child) # Now we collect all the leaf nodes. for node in proj.get_children(): CollectPous(node) # We print everything just to know what's going on. for i in pous: print("found: ", i.type, i.guid, i.get_name()) # And now we export the files. for candidate in pous: # We create a list of objects to export: # The object itsself objects = [candidate] # And sub-objects (POUs can have actions, properties, ...) objects.extend(candidate.get_children()) # And the parent folders. parent = candidate.parent while ((not parent.is_root) and parent.is_folder): objects.append(parent) parent = parent.parent # Create an unique file name: if len(sys.argv) == 1: filename = "parent\\%s.export" % (candidate.get_name()) else: filename = "%s\\%s.export" % (sys.argv[1],candidate.get_name()) # print some user information print("exporting ", len(objects), " objects to: ", filename) # and actually export the project. proj.export_xml(objects, filename) proj.close() print ("script finished.") System.exit(0) // Dont work .NET: public static void Export(string path,string proj) { if (checkSettings()) { var p = new System.Diagnostics.Process(); p.StartInfo.FileName = Properties.Settings.Default.CSVersion +"\\CODESYS\\Common\\CODESYS.exe"; p.StartInfo.Arguments = " --Profile=" + qoute(Properties.Settings.Default.CSProfile) + " --culture=en" + " --project=" + qoute(path + "\\" + proj) + " --runscript=" + Properties.Settings.Default.LastOpenProjectPath + "\\INPUT_DATA\\SCRIPT\\Export.py" + " --scriptargs:" + qoute(path) ; p.StartInfo.RedirectStandardOutput = true; p.StartInfo.UseShellExecute = false; p.StartInfo.CreateNoWindow = false; p.Start(); p.StandardOutput.ReadToEnd(); p.CloseMainWindow(); p.Close(); } }
Last updated: 2024-01-16

Post by westcountryewe on ac_persistence not working when creating a Boot Application but works with a Direct Download to the PLC CODESYS Forge talk (Post)
I am using V3.5 SP18 Patch 5. I have noticed that when I Create a Boot Application from CODESYS, and upload this to my PLC via a USB stick the AC_Persistence does not work and none of my values that are in my PersistenceChannel are retained. However, if I connect direct to my PLC and I perform a direct download of my CODESYS program, my values that are in my PersistenceChannel are retained and work as they should. This makes me wonder if there are files that are missing when a Boot Application is created. I have tried taking a backup of my configuration files after performing a direct download, which gives me the plclog.zip folder, and appears to have the ac_persistence folder present within the file structure, however when I replace the plclogic.zip with the same folder that was created when I created a Boot Application, it still does not work but I wonder whether this is because the ac_persistence folder isn't stored in the correct location for reading. The .app and .crc files are embedded within the plclogic.zip folder, which obviously when uploading need to be standalone files in the root directory of the USB, so the intention there is clearly to extract the .app and .crc files and put them into the correct location within the USB. I wonder if it could be the same for the ac_persistence folder? I have tried moving it to different locations but none have worked. Has anybody else discovered a fix for this? I know the short-term solution is to do a direct download to the PLC but there are some logistical reasons why this isn't neccesarily the best solution for us.
Last updated: 2024-02-27

Post by umdee on Error when monitoring LAD programs CODESYS Forge talk (Post)
I get the following error when monitoring my program (see attached screenshots): "Unhandled exception has occured in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately. Value cannot be null. Parameter name: source. And the details say: See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ** Exception Text ** System.ArgumentNullException: Value cannot be null. Parameter name: source at System.Linq.Enumerable.Any[TSource] (IEnumerable1 source, Func2 predicate) at _3S.CoDeSys.NWLEditor.NWLTextCell.OnPaintCellLayer(PaintEventArgs e) at _3S.CoDeSys.Controls.Controls.GfxEdControl.PaintCellCellLayer(PaintEventArgs e, GfxCell cell) at _3S.CoDeSys.Controls.Controls.GfxEdControl.PaintCellCellLayer(PaintEventArgs e, GfxCell cell) at _3S.CoDeSys.Controls.Controls.GfxEdControl.PaintCellCellLayer(PaintEventArgs e, GfxCell cell) at _3S.CoDeSys.Controls.Controls.GfxEdControl.OnPaint(PaintEventArgs e) at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer) at System.Windows.Forms.Control.WmPaint(Message& m) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.UserControl.WndProc(Message& m) at _3S.CoDeSys.Controls.Controls.GfxEdControl.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ** Loaded Assemblies ** (3000 lines of assemblies) ** JIT Debugging ** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitdebugging="true"> </system.windows.forms></configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box The windows show red X's where the networks should be. Any advice on how to fix this? Additional Information PLC used: Wago 750-8212, Firmware FW26 Startup profile: CODESYS V3.5 SP19 Patch 5 OS version: Microsoft Windows NT 10.0.22631.0 .NET version: 4.0.30319.42000 Full Version info attached as .txt
Last updated: 2024-03-17

Post by mubeta on Some 'pathetic' errors in SoftMotion program CODESYS Forge talk (Post)
Yes, this is the error the sometimes show up. What make me crazy is the fact that it happens randomly and not each times. I know very well where the problem is, in wich one program row it's located. For each actions of the state machine I have all events recorded with log on text file. it is not problematic for me to find the application point of the fault, but I need to understand why occasionally and for no apparent reason, switching the state machine and thus changing the motion FB, sends the axis into failure (but only occasionally). For example, one case that is often problematic is the execution of the Axis Halt instruction. When, after a MoveAbosulte instruction this returns the event as 'done' and indeed the axis is in standstill, the state machine first sets the move instruction to FALSE, and the next cycle sets the Halt request to TRUE. Some of the time everything works out fine. Occasionally, however, in this exchange, the axis goes into fault, also losing the OPERATIONAL state. Meanwhile, I would like to understand why the motion FB instances must still be called even after the Execute is set to FALSE, especially in view of the fact that the next instruction is programmed to abort the previous one, with BufferMode set to 'Aborting'. All these unnecessary FB calls are an unnecessary overhead on the CPU anyway. Is there any precise rule about when to cease calling the various instances? (It should precisely be the 'done' status that says this one has finished its work).
Last updated: 2024-07-18

Post by steven-schalm on Github Actions CI/CD tasks - development topic CODESYS Forge talk (Post)
hello kevinrn, I've been looking for a solution to the CI/CD issue for a long time. Briefly about me... I am 32 and software architect for Codesys V3 and fullstack dev for web (VueJS, NestJS) in a small company in Erfurt (Germany). https://www.rex-at.de/. Through my web part, we already have CI/CD running well via GitLab (YAML-based configuration file (.gitlab-ci.yml), which defines which pipelines and jobs are executed when certain events occur) with everything you know. Stages for npm packages - prepare (GitVersion, npm install or whatever) - build (vite, tsc or whatever) - testing (vitest, jest or whatever) - deploy (npm packages) And similar for monorepo's or backend services (in NestJS) as DockerImages. For Codesys we have been building an OOP framework for years (~50 libraries now), which is currently managed via SVN and a specially written Svn-Watcher (in Python) gets commits and runs and builds everything together and deploys it to an FTP server and network drive. Why do we still have SVN? Because we are unfortunately still tied to the safety integration of Codesys and can therefore only go to SP15 at most with our controller/Eckelmann. But soon there will be an update and there will be no more obstacles to using Git. Hence my questions: 1. the basic idea is to run a local Windows Runner on some machine? 2. install Codesys on the machine where the runner is running? 3. powershell & python scripts are then used to execute builds (compile, build, sign libraries) & deploys? 4. can the Github action also be used in GitLab? ChatGPT has already told me that it's not the same, but it doesn't hurt to ask. Do you have any ideas on this? Greetings :D
Last updated: 2024-08-20

Post by gilbert-mh on CAA net base TCP client cause PLC to crash - Kernel message : N0HZ_local_softirq_pending 80 CODESYS Forge talk (Post)
Hello all, I have been trying to implement a TCP client on a Festo PLC (CPX-E-CEC-M1) and it looks like it works well except that after some time (greatly varies between a few hours to more than 100h) my PLC crash. When I look into the log file the only thing I see is that before the crash happens a few kernel warnings : N0HZ_local_softirq_pending 80 and then the crash. I've looked into this warning and from what I could find on the net it seems that this is warning is triggered when the ethernet link is down. I've tried to correct this bug for quite some time and what I know is that : - The crash is caused by my TCP client, when I remove it from my code I see no crash - The crash happens more quickly the more the TCP client is used. - The time before the crash is not directly proportional to the number of communications or their size. But it looks like it is just more likely to happen if the client connect to the server at a higher frequency. - The precedent observation makes it seem unlikely that the crash is caused by some memory overflow because then the crash speed would be more proportional to the amount of data exchanged. SO from these observations, I believe that the crash could be caused by the PLC trying to connect to a server while there is some kind of issue with the ethernet link resulting in the PLC getting stuck in some indefinite state and making it crash. This still seems a bit unlikely to me because if the ethernet is down it simply shouldn't be able to contact the server and the communication would just fail which doesn't cause my PLC to crash. Has anyone encountered the same kind of problem (with the same kernel message) ? I am pretty sure the warning is not the direct cause of the crash but just an indicator that something is wrong with my PLC. Thanks in advance
Last updated: 2024-01-12

Post by dandyk on Dynamic Images CODESYS Forge talk (Post)
Hello, I have very similar problem, but it seems that your solution does not work for me. I am using TwinCAT XAE Shell v3.1.4024.55 and TwinCAT Runtime. Sorry for writing here on codesys forge, but since I found the only relevant topic here and since TwinCAT is almost the same with CODESYS in many applications, I chose to write here. I simply need to dynamically update image in visualization based on camera trigger (I am doing a machine vision application). Camera triggers an image, my program processes it (applies thresholding, draws contours etc...) and saves the processed image in the runtime location (the same one you were mentioning). This was done successfully. I need to make it work at runtime, while the program is executing and I need to refresh the image in the visualization each time camera triggers a new image and program processes it. When I create image element in the visualization and define the bitmap ID variable as STRING which contains the image ID defined in the image pool, then it displays the image in the image pool, but does not work at runtime, while the program is executing. I also used the Bitmap Version. I declared it in Global variable list as integer with initial value of 0 and wrote the variable in the bitmap version in the image element in visualization. Each time new image is saved to the runtime location, I wrote a program to increment Bitmap Version by 1. It increments and the image does not update in the visualization, unfortunately. I think that bitmap version is working correctly and deletes the cached image as it is supposed to, but the Image Pool does not update the image ID with the new image... the path to the image is always the same... only the actual image changes with the same file name. Image Pool is not dynamic and cannot refresh the image in the path to the actual one at runtime. How can I refresh the image ID in the image pool at runtime? Bitmap version only deletes cached image and reloads the image from the image ID, but the image ID has the same image, because image pool won't update at runtime. Do you know any solution to this problem?
Last updated: 2024-04-06

Post by ppix on Establishing TLS Connection with MQTT Broker using MQTT Client SL Package CODESYS Forge talk (Post)
I’m currently working on establishing a TLS connection with an MQTT broker using the MQTT Client SL package in CODESYS. While I’ve successfully established communication with the broker without TLS, I'm encountering issues when trying to enable TLS. In the 'MQTT Explorer' application, I can easily upload the server certificate (.crt), client certificate (.crt), and client key (.key). However, in CODESYS, I can’t find a way to upload my client key (.key file). Here's a summary of my current setup: Certificates: I have uploaded both the client and server certificates to the certificate store under the 'Trusted Certificates' folder in the security screen. TLS Context Initialization: Despite setting the _sCommonName as the name of my client certificate, a new self-signed certificate is created and placed within the device’s certificates. I then need to manually move this certificate to the trusted certificates folder. This results in three certificates in my trusted certs folder: client cert, server cert, and the newly created cert. _ciDefaultCertInfo : MQTT.NBS.CERT_INFO := (psInfo := ADR(_sCommonName), udiSize := TO_UDINT(LEN(_sCommonName))); // CN of the certificate (common name) _sCipherList : MQTT.NBS.CIPHER_LIST := STRUCT(psList := ADR('HIGH'), udiSize := 4); // Cipher string see https://www.openssl.org/docs/man1.1.1/man1/ciphers.html _tlsContext : MQTT.NBS.TLSContext := ( sUseCaseName := _sCommonName, // A certificate is stored in the certificate store with the use case name. You can choose any name. Here we use the common name. ePurpose := MQTT.NBS.PURPOSE.CLIENT_SIDE, // For client certificates set this to NBS.PURPOSE.CLIENT_SIDE sTLSVersion := '1.3', // The TLS version sCipherList := _sCipherList, // Set the cipher list sHostname := sHostname, // The hostname of the broker udiVerificationMode := 2, // 2 => Active Peer verification ciCertInfo := _ciDefaultCertInfo, // Set the cert info itfCertVerifer := 0); // 0 => No Verifier mqttClient : MQTT.MQTTClient := (xUseTLS:=TRUE, itfTLSContext := _tlsContext, itfAsyncProperty := _asyncProperty); Additional Details: In the client FB, I’ve set uiPort:= 8883, xUseTLS:= TRUE, and configured itfTLSContext as mentioned above. The certificates are encrypted with SHA256RSA. sHostname is the IP address of my broker. I’ve attached a copy of the client FB, which shows straight lines where variables are assigned and boxes where they are not. I am currently trying this on the only 2 compatible versions of COSDESYS with my controller (V3.5.15.20 and V3.5.18.40) My Question: How do I correctly set up this mTLS connection? What might I be missing? Any guidance or suggestions would be greatly appreciated, especially considering I’ve already successfully established a non-TLS connection with the same broker. Thank you in advance for your help!
Last updated: 2024-06-19

Post by dantheman on Connecting to SoftPLC Only Works By Turning Off Modbus Ethernet Port CODESYS Forge talk (Post)
I have an IPC with 2 ethernet ports and 1 Wi-Fi. I'm using ModbusTCP with the ethernet port named "enp2s0" connected to my remote I/O. This works fine when testing with Python and also works with CODESYS, but CODESYS is only able to scan for the Linux SoftPLC when I turn off the "enp2s0" interface. In other words, I can't get online with the IDE if I want my ModbusTCP comms to run with CODESYS. I'm using a Linux SoftPLC that has the following entry in CODESYSControl.cfg, hoping that this will allow me to connect with "enp1s0" or "wlp3s0", and leave "enp2s0" for field comms, but this seems to only make the source IP of the ModbusTCP comms to be bound to "enp2s0". That last point is the case only if I don't restart the service, but if I do restart the service after changing the config file, the source IP for the ModbusTCP comms then becomes the one for "enp1s0", which is very confusing to me: [SysSocket] Adapter.0.Name="enp2s0" Adapter.0.EnableSetIpAndMask=1 On the device list, I only have "enp2s0" given as the ethernet device that has the ModbusTCP master & slave beneath it, shown in Screenshot 1. On the IPC, I can ping the ModbusTCP client (remote I/O) from "enp2s0", and I've attached a Wireshark capture of running ModbusTCP from the CODESYS runtime as Screenshot 2, 3 & 4 (again, I can't get online when this is running, I have to turn off "enp2s0" to connect even when it's idle and I don't have an active TCP session with my Python tests). Like I explained above, the source IP is "enp1s0", even though the ethernet device on the project is "enp2s0". I was lucky to catch the red message that showed the source IP that makes sense to me (the one for "enp2s0"), but for some reason that connection was reset and I never saw that packet again. I've also tried this with Auto-reconnect both enabled & disabled, for the ModbusTCP Master device. I also have to turn off "enp1s0" and then turn it on, just so that I can have the ModbusTCP comms running from "enp2s0" (which is not intuitive in any way to me, I'd love some help understanding that phenomenon as well) in the weird manner that I've described above. I would be very appreciative if someone can help me figure out this pickle. I'd love to just connect to CODESYS through my Wi-Fi interface and leave my ethernet ports for field comms.
Last updated: 2024-08-01

Post by lsislsis on SIGABRT Error CODESYS Forge talk (Post)
Please help us. Why we take this errors. We try different versions like 4.12.0 and 4.13.0 with same results. ;*********;<loggername>codesyscontrol.log</loggername>;<logoptions>; <enable>1</enable>; <type>normal</type>; <timestamp>rtc high resolution</timestamp>; <deactivatable>0</deactivatable>; <dump>always</dump>; <filter>0x0000000f<filter>; <maxentries>100000</maxentries>; <maxfiles>1</maxfiles>; <maxfilesize>1000000</maxfilesize>;</filter></filter></logoptions>;<entries>;Timestamp, CmpId, ClassId, ErrorId, InfoId, InfoText;ClassId: LOG_INFO =1;ClassId: LOG_WARNING =2;ClassId: LOG_ERROR =4;ClassId: LOG_EXCEPTION =8;ClassId: LOG_DEBUG =16;ClassId: LOG_PRINTF =32;ClassId: LOG_COM =64;</entries>;*********2024-11-05T08:23:59.728Z, 0x0000100c, 1, 0, 0, VisuFctCheckForUnusedClients: Removing Client with IEC-ID: 1 Time delta: T#33s1ms Locks: Paintbuffer: TRUE 2024-11-05T08:23:59.728Z, 0x0000100c, 1, 0, 0, VisuFctCheckForUnusedClients: Successfully Removed Client at Address: 547195449944, IEC-ID was: 1, EXT-ID: 431000373 2024-11-05T08:28:57.913Z, 0x0000100c, 1, 0, 0, Visu_PRG: Creating Client for Extern-ID: 347055752 2024-11-05T08:28:57.926Z, 0x0000100c, 1, 0, 0, Visu_PRG: Creating Client successful for Extern-ID: 347055752 Returned IEC-ID: 1 2024-11-05T08:30:51.103Z, 0x0000100c, 1, 0, 0, Visu_PRG: Successfully Removed Client with IEC-ID: 1, Extern-ID: 347055752 2024-11-05T08:37:36.517Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state* We recommend a reboot of the controller now! 2024-11-05T08:37:36.517Z, 0x00000111, 8, 260, 3, #### Exception: HANDLED EXCPT <excpt>NonContinuable</excpt> in CH_COMM_CYCLE 2024-11-05T08:47:42.117Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state We recommend a reboot of the controller now! 2024-11-05T08:47:42.117Z, 0x00000111, 8, 260, 3, #### Exception: HANDLED EXCPT <excpt>NonContinuable</excpt> in CH_COMM_CYCLE 2024-11-05T09:14:41.316Z, 0x00000071, 1, 0, 13, Webserver stopped 2024-11-05T09:14:44.485Z, 0x0000013d, 1, 0, 4, Number of licensed cores for IEC-tasks: 1 from 4 2024-11-05T09:14:44.487Z, 0x0000013d, 1, 0, 4, Number of licensed cores for IEC-tasks: 4 from 4 2024-11-05T09:14:44.540Z, 0x00000002, 1, 0, 2, Application [<app>Application</app>] loaded via [Download] 2024-11-05T09:14:55.894Z, 0x00001012, 1, 0, 0, Opened alarm storage file, version: 6 2024-11-05T09:14:55.951Z, 0x0000100c, 1, 0, 0, Visuinitialization starting. 2024-11-05T09:14:55.983Z, 0x0000100c, 1, 0, 0, Visuinitialization done. 2024-11-05T09:14:55.995Z, 0x00000071, 1, 0, 12, Webserver started 2024-11-05T09:15:01.753Z, 0x0000100c, 1, 0, 0, Visu_PRG: Creating Client for Extern-ID: 2279884529 2024-11-05T09:15:01.753Z, 0x0000100c, 1, 0, 0, Visu_PRG: Creating Client successful for Extern-ID: 2279884529 Returned IEC-ID: 0 2024-11-05T09:34:44.667Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state We recommend a reboot of the controller now! 2024-11-05T09:34:44.667Z, 0x00000111, 8, 260, 3, #### Exception: More than 2 exceptions in CH_COMM_CYCLE: Stop logging 2024-11-05T10:13:26.867Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state We recommend a reboot of the controller now! 2024-11-05T10:15:21.966Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state We recommend a reboot of the controller now! 2024-11-05T10:19:12.167Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state We recommend a reboot of the controller now! 2024-11-05T10:26:02.566Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state We recommend a reboot of the controller now! 2024-11-05T10:31:42.866Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state We recommend a reboot of the controller now! 2024-11-05T11:01:54.468Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state We recommend a reboot of the controller now! 2024-11-05T11:09:29.868Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state We recommend a reboot of the controller now! 2024-11-05T11:14:44.540Z, 0x0000100d, 1, 0, 0, Demo mode expired. 2024-11-05T11:27:20.868Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state We recommend a reboot of the controller now! * Regards
Last updated: 2024-11-05

Post by svenkaro on Codesyscontrol.service stoppt nach 30s CODESYS Forge talk (Post)
Hallo nano, anbei das Logfile ;********* ;<loggername>codesyscontrol.log</loggername> ;<logoptions> ; <enable>1</enable> ; <type>normal</type> ; <timestamp>rtc high resolution</timestamp> ; <deactivatable>0</deactivatable> ; <dump>always</dump> ; <filter>0x0000000f<filter> ; <maxentries>100000</maxentries> ; <maxfiles>1</maxfiles> ; <maxfilesize>1000000</maxfilesize> ;</filter></filter></logoptions> ;<entries> ;Timestamp, CmpId, ClassId, ErrorId, InfoId, InfoText ;ClassId: LOG_INFO =1 ;ClassId: LOG_WARNING =2 ;ClassId: LOG_ERROR =4 ;ClassId: LOG_EXCEPTION =8 ;ClassId: LOG_DEBUG =16 ;ClassId: LOG_PRINTF =32 ;ClassId: LOG_COM =64 ;</entries> ;********* 2024-06-20T06:07:12.085Z, 0x0000013d, 16, 0, 0, OpenCpusetCpusEffective: using core(s) "0-3" from /sys/fs/cgroup/cpuset.cpus.effective 2024-06-20T06:07:12.085Z, 0x00000109, 16, 0, 0, SysModuleLoad: libCmpBACnet.so: 0x92ae530 2024-06-20T06:07:12.085Z, 0x00000109, 16, 0, 0, SysModuleLoad: libCmpBACnet2.so: 0x92af008 2024-06-20T06:07:12.085Z, 0x00000109, 16, 0, 0, SysModuleLoad: libCmpPLCHandler.so: 0x92afb08 2024-06-20T06:07:12.085Z, 0x00000109, 16, 0, 0, SysModuleLoad: libCmpGwClient.so: 0x92affe8 2024-06-20T06:07:12.085Z, 0x00000109, 16, 0, 0, SysModuleLoad: libCmpXMLParser.so: 0x92b04c0 2024-06-20T06:07:12.085Z, 0x00000109, 16, 0, 0, SysModuleLoad: libCmpGwClientCommDrvTcp.so: 0x92b09a0 2024-06-20T06:07:12.086Z, 0x00000013, 1, 0, 0, <logoptions> 2024-06-20T06:07:12.086Z, 0x00000013, 1, 0, 0, <benable>1</benable> 2024-06-20T06:07:12.086Z, 0x00000013, 1, 0, 0, <type>normal</type> 2024-06-20T06:07:12.086Z, 0x00000013, 1, 0, 0, <timestamp>rtc high resolution</timestamp> 2024-06-20T06:07:12.086Z, 0x00000013, 1, 0, 0, <disableable>0</disableable> 2024-06-20T06:07:12.086Z, 0x00000013, 1, 0, 0, <filter>0x0000000f</filter> 2024-06-20T06:07:12.086Z, 0x00000013, 1, 0, 0, <maxentries>100000</maxentries> 2024-06-20T06:07:12.086Z, 0x00000013, 1, 0, 0, <maxfiles>1</maxfiles> 2024-06-20T06:07:12.086Z, 0x00000013, 1, 0, 0, <maxfilesize>1000000</maxfilesize> 2024-06-20T06:07:12.086Z, 0x00000013, 1, 0, 0, </logoptions> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>CM</cmp>, <id>0x00000001</id> <ver>3.5.19.61</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>CmpMemPool</cmp>, <id>0x0000001e</id> <ver>3.5.19.60</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>CmpLog</cmp>, <id>0x00000013</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>CmpSettings</cmp>, <id>0x0000001a</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysFile</cmp>, <id>0x00000104</id> <ver>3.5.19.50</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>CmpMemGC</cmp>, <id>0x0000001f</id> <ver>3.5.19.20</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysCom</cmp>, <id>0x00000100</id> <ver>3.5.19.10</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysCpuHandling</cmp>, <id>0x00000101</id> <ver>3.5.19.20</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysCpuMultiCore</cmp>, <id>0x0000013d</id> <ver>3.5.19.20</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysCrypto</cmp>, <id>0x00000141</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysDir</cmp>, <id>0x0000011b</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysEthernet</cmp>, <id>0x0000011c</id> <ver>3.5.19.20</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysEvent</cmp>, <id>0x00000102</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysExcept</cmp>, <id>0x00000103</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysInternalLib</cmp>, <id>0x00000107</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysMem</cmp>, <id>0x00000108</id> <ver>3.5.19.50</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysModule</cmp>, <id>0x00000109</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysMsgQ</cmp>, <id>0x0000010a</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysMutex</cmp>, <id>0x0000013a</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysOut</cmp>, <id>0x0000010b</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysProcess</cmp>, <id>0x0000010e</id> <ver>3.5.19.50</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysSem</cmp>, <id>0x0000010f</id> <ver>3.5.19.10</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysSemCount</cmp>, <id>0x00000139</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysSemProcess</cmp>, <id>0x00000119</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysShm</cmp>, <id>0x00000110</id> <ver>3.5.19.50</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysSocket</cmp>, <id>0x00000111</id> <ver>3.5.19.30</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysTarget</cmp>, <id>0x00000112</id> <ver>3.5.19.61</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysTask</cmp>, <id>0x00000114</id> <ver>3.5.19.10</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysTime</cmp>, <id>0x00000115</id> <ver>3.5.19.10</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysTimeRtc</cmp>, <id>0x00000127</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, System: <cmp>SysTimer</cmp>, <id>0x00000116</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpAlarmManager</cmp>, <id>0x0000007c</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpApp</cmp>, <id>0x00000002</id> <ver>3.5.19.60</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpAppBP</cmp>, <id>0x00000073</id> <ver>3.5.19.20</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpAppForce</cmp>, <id>0x00000074</id> <ver>3.5.19.20</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpAsyncMgr</cmp>, <id>0x0000005f</id> <ver>3.5.19.20</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpAuditLog</cmp>, <id>0x000000a1</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpBinTagUtil</cmp>, <id>0x00000004</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpBinTagUtilIec</cmp>, <id>0x0000005c</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpBitmapPool</cmp>, <id>0x00000050</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpBlkDrvTcp</cmp>, <id>0x00000030</id> <ver>3.5.19.50</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpBlkDrvUdp</cmp>, <id>0x00000007</id> <ver>3.5.19.30</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAAAsyncMan</cmp>, <id>0x00004007</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAABehaviourModel</cmp>, <id>0x00004015</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAACallback</cmp>, <id>0x00004001</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAACanL2</cmp>, <id>0x00004004</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAADTUtil</cmp>, <id>0x00004013</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAAFile</cmp>, <id>0x00004008</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAAMemBlockMan</cmp>, <id>0x00004003</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAANetBaseServices</cmp>, <id>0x00004018</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAARealTimeClock</cmp>, <id>0x00004014</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAASdoClient</cmp>, <id>0x00004011</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAASdoServer</cmp>, <id>0x00004017</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAASegBufferMan</cmp>, <id>0x00004019</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAASerialCom</cmp>, <id>0x00004012</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAAStorage</cmp>, <id>0x0000007e</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAATick</cmp>, <id>0x00004009</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAATickUtil</cmp>, <id>0x00004010</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAATimer</cmp>, <id>0x00004016</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCAATypes</cmp>, <id>0x00004006</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpChannelClient</cmp>, <id>0x00000008</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpChannelClientIec</cmp>, <id>0x0000005d</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpChannelMgr</cmp>, <id>0x00000009</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpChannelServer</cmp>, <id>0x0000000a</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCharDevice</cmp>, <id>0x00000300</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpChecksum</cmp>, <id>0x0000000b</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCodeMeter</cmp>, <id>0x0000007a</id> <ver>3.5.19.50</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCommunicationLib</cmp>, <id>0x0000000c</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCoreDump</cmp>, <id>0x00000083</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpCryptMD5</cmp>, <id>0x0000006a</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpDevice</cmp>, <id>0x0000000e</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpDynamicText</cmp>, <id>0x00000051</id> <ver>3.5.19.30</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpEL6751CanDrv</cmp>, <id>0x00005f0b</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpEventMgr</cmp>, <id>0x0000005b</id> <ver>3.5.19.30</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpEventMgrUnixBackend</cmp>, <id>0x000000a4</id> <ver>4.11.0.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpFileTransfer</cmp>, <id>0x0000005e</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpIecStringUtils</cmp>, <id>0x0000007f</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpIecTask</cmp>, <id>0x00000011</id> <ver>3.5.19.30</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpIecVarAccess</cmp>, <id>0x00000060</id> <ver>3.5.19.30</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpIoDrvIec</cmp>, <id>0x0000005a</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpIoMgr</cmp>, <id>0x00000012</id> <ver>3.5.19.30</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpKnxStack</cmp>, <id>0x0000004d</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpLinuxInterrupt</cmp>, <id>0x000000a2</id> <ver>3.5.17.10</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpLinuxRTDiag</cmp>, <id>0x000000a7</id> <ver>4.11.0.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpMonitor2</cmp>, <id>0x00000032</id> <ver>3.5.19.20</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpNameServiceClient</cmp>, <id>0x00000015</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpNameServiceClientIec</cmp>, <id>0x0000011d</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpNameServiceServer</cmp>, <id>0x00000016</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpOPCUAClient</cmp>, <id>0x00000096</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpOPCUAProviderIecVarAccess</cmp>, <id>0x00000126</id> <ver>3.5.19.50</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpOPCUAServer</cmp>, <id>0x00000124</id> <ver>3.5.19.30</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpOPCUAStack</cmp>, <id>0x0000008d</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpOpenSSL</cmp>, <id>0x00000033</id> <ver>3.5.19.61</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpPlcShellLinux</cmp>, <id>0x00000128</id> <ver>4.11.0.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpPlcShellLinuxBackend</cmp>, <id>0x000000a5</id> <ver>4.11.0.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpRasPi</cmp>, <id>0x00000089</id> <ver>4.11.0.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpRedundancy</cmp>, <id>0x00000129</id> <ver>3.5.19.30</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpRedundancyConnectionIP</cmp>, <id>0x0000ff03</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpRetain</cmp>, <id>0x00000017</id> <ver>3.5.19.50</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpRouter</cmp>, <id>0x00000018</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpRunStopSwitch</cmp>, <id>0x000000a6</id> <ver>4.11.0.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpSchedule</cmp>, <id>0x00000019</id> <ver>3.5.19.50</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpSecureChannel</cmp>, <id>0x00000090</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpSecurityManager</cmp>, <id>0x0000008e</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpSessionInformation</cmp>, <id>0x00000097</id> <ver>3.5.19.20</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpSocketCanDrv</cmp>, <id>0x00005f0d</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpSocketUnix</cmp>, <id>0x000000a3</id> <ver>4.11.0.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpSrv</cmp>, <id>0x0000001c</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpTraceMgr</cmp>, <id>0x00000070</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpUserDBFile</cmp>, <id>0x00000098</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpUserGroupsDBFile</cmp>, <id>0x00000099</id> <ver>3.5.19.50</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpUserMgr</cmp>, <id>0x00000061</id> <ver>3.5.19.50</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpUserObjectsDBFile</cmp>, <id>0x0000009c</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpVisuHandler</cmp>, <id>0x00000054</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpVisuServer</cmp>, <id>0x00000057</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpWebServer</cmp>, <id>0x00000071</id> <ver>3.5.19.30</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, <cmp>CmpWebServerHandlerV3</cmp>, <id>0x00000072</id> <ver>3.5.19.10</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, Dynamic: <cmp>CmpBACnet</cmp>, <id>0x00000400</id> <ver>3.5.19.50</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, Dynamic: <cmp>CmpBACnet2</cmp>, <id>0x00000401</id> <ver>3.5.19.10</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, Dynamic: <cmp>CmpPLCHandler</cmp>, <id>0x0000002a</id> <ver>3.5.19.61</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, Dynamic: <cmp>CmpGwClient</cmp>, <id>0x00000021</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, Dynamic: <cmp>CmpXMLParser</cmp>, <id>0x00000058</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.086Z, 0x00000001, 1, 0, 10, Dynamic: <cmp>CmpGwClientCommDrvTcp</cmp>, <id>0x00000022</id> <ver>3.5.19.0</ver> 2024-06-20T06:07:12.125Z, 0x0000013d, 1, 0, 4, MultiCore support: [activated], all cores are used 2024-06-20T06:07:12.125Z, 0x0000013d, 1, 0, 4, Number of available cores: 4 2024-06-20T06:07:12.134Z, 0x00000401, 2, 0, 0, !!!! Warning: component CmpBACnet loaded already 2024-06-20T06:07:12.184Z, 0x00000007, 1, 0, 6, Network interface: <ipaddress>10.94.25.39</ipaddress>, subnetmask <subnetmask>255.255.255.0</subnetmask> 2024-06-20T06:07:12.184Z, 0x00000018, 1, 0, 4, Network interface <interface>ether 2</interface> at router <instance>0</instance> registered 2024-06-20T06:07:12.185Z, 0x00000009, 1, 0, 2, Running as network server 2024-06-20T06:07:12.185Z, 0x00000009, 1, 0, 1, Running as network client 2024-06-20T06:07:12.186Z, 0x0000000a, 1, 0, 0, <numofchannels>4</numofchannels> channels available, each of the size <buffersize>100000</buffersize> Bytes 2024-06-20T06:07:12.254Z, 0x00000400, 1, 0, 0, CmpBACnet 1024 BACstack information 2024-06-20T06:07:12.254Z, 0x00000400, 1, 0, 0, version = 15.0.1.1 2024-06-20T06:07:12.254Z, 0x00000400, 1, 0, 0, __BYTE_ORDER = 1234 2024-06-20T06:07:12.254Z, 0x00000400, 1, 0, 0, TARGET_IEEE_FP_FORMAT = 1 2024-06-20T06:07:12.254Z, 0x00000400, 1, 0, 0, TARGET_FP_BIG_ENDIAN = 0 2024-06-20T06:07:12.254Z, 0x00000400, 1, 0, 0, TARGET_DP_BIG_ENDIAN = 0 2024-06-20T06:07:12.254Z, 0x00000400, 1, 0, 0, TARGET_INTEGRAL_BIG_ENDIAN = 0 2024-06-20T06:07:12.254Z, 0x00000400, 1, 0, 0, TARGET_USED_ALIGNMENT = 4 2024-06-20T06:07:12.254Z, 0x00000401, 1, 0, 0, CmpBACnet2 1025 BACstack information 2024-06-20T06:07:12.254Z, 0x00000401, 1, 0, 0, version = 25.1.5.1 2024-06-20T06:07:12.254Z, 0x00000401, 1, 0, 0, __BYTE_ORDER = 1234 2024-06-20T06:07:12.254Z, 0x00000401, 1, 0, 0, TARGET_IEEE_FP_FORMAT = 1 2024-06-20T06:07:12.254Z, 0x00000401, 1, 0, 0, TARGET_FP_BIG_ENDIAN = 0 2024-06-20T06:07:12.254Z, 0x00000401, 1, 0, 0, TARGET_DP_BIG_ENDIAN = 0 2024-06-20T06:07:12.254Z, 0x00000401, 1, 0, 0, TARGET_INTEGRAL_BIG_ENDIAN = 0 2024-06-20T06:07:12.254Z, 0x00000401, 1, 0, 0, TARGET_MCU_USED_ALIGNMENT = 4 2024-06-20T06:07:12.261Z, 0x00000129, 1, 0, 0, Debug Messages not activated 2024-06-20T06:07:12.262Z, 0x0000ff03, 1, 0, 0, Read connection settings... 2024-06-20T06:07:12.266Z, 0x00000030, 1, 0, 6, Local network address: <ipaddress>10.94.25.39</ipaddress> 2024-06-20T06:07:12.266Z, 0x00000018, 1, 0, 4, Network interface <interface>BlkDrvTcp</interface> at router <instance>1</instance> registered 2024-06-20T06:07:12.272Z, 0x00000124, 1, 0, 0, No certificate for the OPC UA server available. 2024-06-20T06:07:12.272Z, 0x00000124, 1, 0, 0, Security policy allows plain text communication. Secure communication is deactivated. 2024-06-20T06:07:12.272Z, 0x00000124, 1, 0, 0, ********** 2024-06-20T06:07:12.272Z, 0x00000124, 1, 0, 0, OPC UA Server Started: 2024-06-20T06:07:12.272Z, 0x00000124, 1, 0, 0, Hostname: raspberrypi, Port: 4840 2024-06-20T06:07:12.272Z, 0x00000124, 1, 0, 0, URL: opc.tcp://raspberrypi:4840 2024-06-20T06:07:12.272Z, 0x00000124, 1, 0, 0, Loopbackadapter activated. 2024-06-20T06:07:12.272Z, 0x00000124, 1, 0, 0, All available networkadapters are used. 2024-06-20T06:07:12.272Z, 0x00000124, 1, 0, 0, Multithreading activated. 3 workers used. 2024-06-20T06:07:12.272Z, 0x00000124, 1, 0, 0, ************ 2024-06-20T06:07:12.286Z, 0x00000124, 1, 0, 0, Provider 'CODESYS_DefaultProvider' (version 0x305131e) registered at the OPC UA server. 2024-06-20T06:07:12.287Z, 0x000000a6, 1, 0, 0, Not able to read file of Run/Stop switch. Functionality of component disabled 2024-06-20T06:07:12.306Z, 0x00000001, 1, 0, 0, ========================================================================= 2024-06-20T06:07:12.306Z, 0x00000001, 1, 0, 4, CODESYS Control for Raspberry Pi MC SL 2024-06-20T06:07:12.306Z, 0x00000001, 1, 0, 4, OS=Linux, CPU=ARM, Arch=32Bit, Coding=C 2024-06-20T06:07:12.306Z, 0x00000001, 1, 0, 6, <version>3.5.19.61</version> <builddate>Feb 22 2024</builddate> 2024-06-20T06:07:12.306Z, 0x00000001, 1, 0, 5, Copyright CODESYS Development GmbH 2024-06-20T06:07:12.306Z, 0x00000001, 1, 0, 0, ========================================================================= 2024-06-20T06:07:12.308Z, 0x00000124, 1, 0, 0, Provider 'AddressSpaceFragment Provider' (version 0x3051332) registered at the OPC UA server. 2024-06-20T06:07:12.309Z, 0x00000124, 1, 0, 0, Provider 'OPC UA for IEC-61131-3' (version 0x3051332) registered at the OPC UA server. 2024-06-20T06:07:12.309Z, 0x00000124, 1, 0, 0, Provider 'AlarmManager' (version 0x3051332) registered at the OPC UA server. 2024-06-20T06:07:12.321Z, 0x00000018, 1, 0, 1, Setting router <instance>0</instance> address to (0027) 2024-06-20T06:07:12.321Z, 0x00000018, 1, 0, 1, Setting router <instance>1</instance> address to (2ddc:0a5e:1927) 2024-06-20T06:07:12.332Z, 0x00000001, 1, 0, 34, CODESYS Control ready 2024-06-20T06:07:12.333Z, 0x00000001, 2, 0, 0, !!!! Warning: no runtime license - running in demo mode(~2 hours) Wäre der Zeitraum nicht nur 30s könnte ich das beenden auf Grund der letzten Zeile nachvollziehen. Hoffe Du hast eine Idee, vielen Dank.
Last updated: 2024-06-20

<< < 1 .. 25 26 27 (Page 27 of 27)

Showing results of 664

Sort by relevance or date