Das reine Einbinden von Libaries mit vielen Bausteinen hat damit definitiv nix zu tun. Es geht nur um die Aufrufe.
Ich kann den anderen nur Beipflichten.
Erst mal Programm prüfen auf nicht mehr verwendete Instanzen und Variablen.
Wenn da alles unnötige entfernt wurde und es trotzdem nix Hilft bleibt wohl nur eine größere CPU.
P.s. Die Größe der Librarys spielt nur eine Rolle wenn die Quellen incl. Librarys eingespielt wird.
Gesendet von meinem SM-A300FU mit Tapatalk
das was du hier erzählst wäre ansich logisch und richtig ist aber ab einer gewissen firmware bzw. compiler core eben nicht so
ich habe ein beispielprojekt genommen wo über bibliotheken ca. 600 bausteine und im projekt selber nochmals ca. 100 bausteine eingebunden sind
wirklich verwendet sind aber nur ca. 20 bausteine
dann habe ich das projekt mit den verschiedenen core versionen compiliert und an den folgenden daten kannst du sehen was dir wahrheit ist
Ob genau das problem nun bei "portisch" schuld ist kann ich nicht beurteilen ob es ist leicht möglich
kommt drauf an welche firmware und pcworx version bzw. core version bei ihm voreingestellt ist
beispiel:
ILC 151 FW4.3 mit Core v2.8.5 compiliert
Benötigter Speicher für Programmcode: 48676 Byte
Benötigter Speicher für remanente Daten: 96 Byte
Benötigter Speicher für das Application Image: 158884 Byte
Voraussichtlich benötigter Speicher für Daten: 166226 Byte
ILC 151 FW4.3 mit Core v3.0.2 compiliert
Benötigter Speicher für Programmcode: 49828 Byte
Benötigter Speicher für remanente Daten: 96 Byte
Benötigter Speicher für das Application Image: 180388 Byte
Voraussichtlich benötigter Speicher für Daten: 279698 Byte
und das kann dann gar nicht mehr auf die sps geladen werden
das alles nur weil zusätzlichen debug infos auf der sps hinterlegt werden
einzige lösung ist das du auf die core 2.8.5 zurücksteigst und mit weniger debug infos leben
übrigens hat
codesys genau das gleiche problem mit den vielen bausteinen
da die meisten dieses dialog fenster nich mal kennen wundert mich ja auch nicht