Příspěvky

1

Hardware / Re:Poraďte UPS do kanceláře

« kdy: 13. 08. 2026, 17:53:55 »

Právěže není. Proto si taky domů nekupuju UPS za miliony a nemám v datacentru UPS za patnáct stovek. Ale s tobě podobnými se stejně nemá smysl o tématu bavit. To má obecně smysl s lidmi, co jsou schopni rozlišovat, ne obtěžovat svou profesionální deformací a neschopností pochopit, že na světě jsou i běžní malí uživatelé. A pak se vám podobní ještě diví, že vás ve firmách kdekdo nemá rád a pokud může se vám vyhne

...
Jenze (to ty nemuzes tusit) spinany zdroje maj takovej problemecek ... docela dost jim vadi, beh naprazdno, a to az tak, ze dokazou odpraskout samy sebe (plati treba pro uplne vsechny PC zdroje). A proto se treba ani takhle nenechaji zapnout, nebo maji snahu se velmi rychle vypnout ... teda takovy, co stojej za hovor a kde vyrobce neusetril 1 cent. (PC zdroje nejsou urceny pro pouzivani bez "odborne" montaze, jak samozrejme taky nevis ze? Proto tu ochranu typicky nemaji)
...

Mohl bys to víc vysvětlit? (Nechci flame, opravdu mě to zajímá).. Spousta spínaných zdrojů přece běží i bez zátěže.. Když mám nabíječku na telefon v zásuvce a nic nenabíjí tak se přece nemůže odpálit.. Napájel jsem s tím bez problémů pár měsíců i ESP32 které se jednou denně probudilo, něco poslalo a zas se uspalo. Když spalo, mělo odběr třeba 0,1mA..
A PC když je uspanej tak taky má odběer minimální a přesto zdroj normálně funguje.
USB-C Adaptérem k noťasu, co má výkon 90W běžně nabíjím sluchátka a taky se nic neděje.
A Věřím, že když si vemu meanwell zdroj, co může dávat 10A a budu s ním napájet jednu LEDku tak se taky nic nestane a bude svítit. Ale rád se nechám poučit

2

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 09. 01. 2026, 13:47:06 »

Tak potvrzeno, v ESXi byl o těch 46 minut špatný (neudržovaný čas). No a když denní drift  je asi -0,8 vteřiny, server jsme pořizovali zhruba před 2,5 lety, tak to krásně vychází, že se od té doby posunul zhruba o 15 minut dozadu. No a jelikož při pořízení byl letní čas, tak proti aktuálnímu času je to těch 45 minut dopředu.
<Facepalm>
Mohlo mě to napadnout dřív, než jsem tady začal plašit; ale diskuze byla myslím alespoň pro mě docela poučná.

Jako anekdotu na závěr můžu zmínit, že virtuálku jsme používali interně ve firmě na vyčítání události z Jablotroní sběrnice (příchody / odchody lidí dle pípnutí karty). Takže lidi, co měli to štěstí a přišli před tím, než si virtuálka ráno chytla správný čas, měli občas zvědavé dotazy, proč mají v systému příchod v 7:46 kyž si pípli v 7:00 

3

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 09. 01. 2026, 12:22:01 »

Povedlo se mi reprodukovat skoky, k posunu dojde i když ručně vypnu a zapnu servicu vmtoolsd. Po naběhnutí okamžite skok.
Z debug logu

Kód: [Vybrat]

...
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'synctime.period' to '0'.
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.enable' to '1'.
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.guest.resync' to '0'.
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.guest.resync.timeout' to '0'.
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.startup.backward' to '0'.
[2026-01-08T17:10:29.807Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.startup' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'toolScripts.afterPowerOn' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'toolScripts.beforePowerOff' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'toolScripts.afterResume' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'toolScripts.beforeSuspend' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.slewCorrection' to '1'.
...
Takže s největší pravděpodobností je na ESXi špatně nastavený systémový čas a v noci dojde k nějakému eventu, který vynutí resync i když je "vypnutý". Dle dokumentace

Virtual machine occasionally synchronizes time with the host even if you do not turn on periodic time synchronization. To completely disable time synchronization, you must set some properties in the virtual machine configuration file.
Power off the virtual machine.
Open the configuration (.vmx) file of the virtual machine in a text editor.
Add lines for the time synchronization properties and set the properties to FALSE.
tools.syncTime = "FALSE"
time.synchronize.continue = "FALSE"
time.synchronize.restore = "FALSE"
time.synchronize.resume.disk = "FALSE"
time.synchronize.shrink = "FALSE"
time.synchronize.tools.startup = "FALSE"
Save and close the file.

Při restartu vmtoolshd procne ten time.synchronize.tools.startup. V noci procne třeba něco jinýho.

Takže mi z toho vychází, že je špatně buď systémový čas v ESXi, nebo zmiňovaný offset (minimálně) pro tuto virtuálku. Čekám až se mi ozve admin. Skoro bych tipnul, že se u nás na firmě zprovoznil server, nastavil se čas a pak na to roky nikdo nešáhnul, ntp nebylo zapnuto, no a čas vesele driftuje o tu 0.8 vteřinu denně (což mi ale přijde docela dost). Ale třeba se pletu.

4

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 08. 01. 2026, 16:40:28 »

Dle dokumentace timesync disable vypne periodickou synchronizaci, ale ne změnu na základě eventů.

...
These options do not disable one-time synchronizations done by VMware Tools for events such as tools startup, taking a snapshot, resuming from a snapshot, resuming from suspend, or vMotion. These events synchronize time in the guest operating system with time in the host operating system even if VMware Tools periodic time sync is disabled, so it is important to ensure that the host operating system's time is correct.

Zapl jsem ješte logování v VMWare Tools na úrověn debug a uvidím, co mě překvapí zítra.

5

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 08. 01. 2026, 15:28:51 »

Tak bohužel, i když

Kód: [Vybrat]

C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe timesync status
DisabledStejně došlo ke skoku. Dneska ve 3:18 v noci skok 2772185ms a v 8:01 to w32tm srovnal zpět, skok -2772046 ms.

Kód: [Vybrat]

Systémový čas se změnil z ?2026?-?01?-?08T02:18:27.473475100Z.
na ?2026?-?01?-?08T03:04:39.659000000Z: 2772185 ms

Důvod změny: An application or system component changed the time.
Proces: '\Device\HarddiskVolume3\Program Files\VMware\VMware Tools\vmtoolsd.exe' (PID 4192).

Čas RTC: ?2026?-?01?-?08T04:04:39.659000000Z
Aktuální posun časového pásma:  -60
Čas RTC je ve formátu UTC: false
Systémový čas byl založen na času RTC: false

Kód: [Vybrat]

Systémový čas se změnil z ?2026?-?01?-?08T07:47:25.565543200Z.
na ?2026?-?01?-?08T07:01:13.519251600Z: -2772046 ms

Důvod změny: An application or system component changed the time.
Proces: '\Device\HarddiskVolume3\Windows\System32\svchost.exe' (PID 1472).

Čas RTC: ?2026?-?01?-?08T08:01:13.519251600Z
Aktuální posun časového pásma:  -60
Čas RTC je ve formátu UTC: false
Systémový čas byl založen na času RTC: false
Teď jsem navíc mluvil se správcem a říkal že ve všech virtuálkách je synchronizace přes VMWare Tools vypnuta. Že se na to ješte zkusí podívat, případně zkusit aktualizovat verzi VMWare Tools (ve virtuálce běží asi 2,5 roku stará verze, co běží v ESXi nevím). Nevím jestli třeba nesoulad verzí host/guest může toto způsobit..

Vážně uvažuju o vypnutí vmtoolsd než se to dořeší, ať nešahá na čas. Může to způsobit nějaké závažnější problémy?

6

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 07. 01. 2026, 15:11:44 »

Pro doplnění, v jiné virtuálce se to děje taky. Fyzické železo je Dell Poweredge R350 a běží na něm ESXi.

7

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 07. 01. 2026, 13:16:08 »

"Synchronize guest time with host" je zapnuto nebo vypnuto?

Těď jsem ji ve virtuálce vypnul. Uvidím zítra, jestli to pomůže

Kód: [Vybrat]

VMwareToolboxCmd.exe timesync disableBohužel jsem se nepodíval předtím na status jestli byla zapnuta nebo nikoliv. Předpokládám ale, že byla. Napsal jsem správci aby sycnchronizaci vypnul v host systému v konfiguraci virtuálky než se přijde na příčinu.

Nedočetl jsem se důležitou informaci: máte důvod se domnívat, že ten VMware (hypervizor) má správný čas?
Díval jste se? Bere si ho odněkud přes NTP?

To je velmi dobrá připomínka, zeptám se správce.

Vrtá mi hlavou, jestli Vám tam běží nějaký další nespecifikovaný software, zda se třeba nesnaží ještě taky po svém zasahovat do systémového času - to už je na Vás.

Našel jsem zásahy jenom od zmíněného wmtoolsd a pak korekce zpět (a případné běžné korekce v řádu milivteřin) od w32tm

8

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 07. 01. 2026, 12:16:53 »

Tak předřečníci měli správné tušení, dělá to VMware tools
Našel jsem správu v Kernel-General (tato konkrétně je z 1.1.)

Kód: [Vybrat]

Systémový čas se změnil z ‎2026‎-‎01‎-‎01T02:18:12.278453600Z.
na ‎2026‎-‎01‎-‎01T03:04:30.211000000Z: 2777932 ms

Důvod změny: An application or system component changed the time.
Proces: '\Device\HarddiskVolume3\Program Files\VMware\VMware Tools\vmtoolsd.exe' (PID 4296).

Čas RTC: ‎2026‎-‎01‎-‎01T04:04:30.211000000Z
Aktuální posun časového pásma:  -60
Čas RTC je ve formátu UTC: false
Systémový čas byl založen na času RTC: false
a pak

Kód: [Vybrat]

Systémový čas se změnil z ‎2026‎-‎01‎-‎01T07:39:59.726921600Z.
na ‎2026‎-‎01‎-‎01T06:53:41.937212200Z: -2777789 ms

Důvod změny: An application or system component changed the time.
Proces: '\Device\HarddiskVolume3\Windows\System32\svchost.exe' (PID 1476).

Čas RTC: ‎2026‎-‎01‎-‎01T07:53:41.937212200Z
Aktuální posun časového pásma:  -60
Čas RTC je ve formátu UTC: false
Systémový čas byl založen na času RTC: false
To samé v různé noční a ranní časy každý den o hodnotu, která se pravidelně snižuje.
třeba
1.1. 2777789 ms
2.1. 2777102 ms
3.1. 2776275 ms
4.1  2775442 ms
...

Teď už zbývá jenom zjistit proč to dělá.

S nadsázkou bych mohl říct, že dobrá správa je, při nějakém průměrném snížení skoku 0,8 vteřiny za den do deseti let problém zmizí sám. Špatná správa je, že možná to pak bude skákat dozadu a ntp to bude srovnávat dopředu.

9

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 07. 01. 2026, 10:55:26 »

Status z dnešní noci (6.1. na 7.1.)
Došlo ke dvěma skokům o 2772 vteřin, z toho jeden byl pod pět minut. Je teda možné, že skoků je víc, jenom jsou tak krátké, že jsem si jich předtím nevšiml.

Kód: [Vybrat]

03:22:43, +00.0630457s
03:23:43, +00.0627538s
04:10:56, -2772.9436147s
03:25:43, +00.0026144s
03:26:43, +00.0025406s

Kód: [Vybrat]

03:50:43, -00.0001596s
03:51:43, -00.0001518s
03:52:43, +00.0063584s
04:39:56, -2772.9333399s
04:40:56, -2772.9331704s
...
05:00:57, -2772.9284102s
05:01:57, -2772.9283991s
04:16:44, +00.0004886s
04:17:44, +00.0002152s
04:18:44, +00.0002774s

Podíval jsem se do event vieweru (to mě předtím nenapadlo, resp. nejsem tak zkušený uživatel aby se mi v hlavě rozsvítilo koukni do event vieweru)

Tady je výcuc z dnešní noci. (od nejstaršího po nejnovější) pro Protokoly aplikací a služeb/Microsoft/Windows/Time-Service/Operational:

Kód: [Vybrat]

07.01.2026 3:24:47
W32time service has set the system time to 2026-01-07T02:24:47.837Z(UTC). Previous system time was 2026-01-07T03:11:00.782Z(UTC). System Tick Count: 2368186156
For more information, see https://go.microsoft.com/fwlink/?linkid=845961.

07.01.2026 3:24:47
W32time Service received notification to rediscover its time sources and/or resynchronize time. Reason Code:3 System Tick Count: 2368186156
Reason code description:
0 : An explicit time resynchronization request from an administrator
1 : Power state changes on this machine
2 : Changes to the network interface or to the network topology
3 : State changes within W32time that require time synchronization
The actions that follow this notifcation may impact fine-grained time synchronization accuracy.For more information, see https://go.microsoft.com/fwlink/?linkid=845961.

07.01.2026 3:24:47
W32time service has set the system time to 2026-01-07T02:24:47.847Z(UTC). Previous system time was 2026-01-07T02:24:47.846Z(UTC). System Tick Count: 2368186156
For more information, see https://go.microsoft.com/fwlink/?linkid=845961.

07.01.2026 4:16:17
W32time service has set the system time to 2026-01-07T03:16:17.416Z(UTC). Previous system time was 2026-01-07T04:02:30.344Z(UTC). System Tick Count: 2371275718
For more information, see https://go.microsoft.com/fwlink/?linkid=845961.

07.01.2026 4:16:17
W32time Service received notification to rediscover its time sources and/or resynchronize time. Reason Code:3 System Tick Count: 2371275718
Reason code description:
0 : An explicit time resynchronization request from an administrator
1 : Power state changes on this machine
2 : Changes to the network interface or to the network topology
3 : State changes within W32time that require time synchronization
The actions that follow this notifcation may impact fine-grained time synchronization accuracy.For more information, see https://go.microsoft.com/fwlink/?linkid=845961.

07.01.2026 4:16:17
W32time service has set the system time to 2026-01-07T03:16:17.426Z(UTC). Previous system time was 2026-01-07T03:16:17.426Z(UTC). System Tick Count: 2371275718
For more information, see https://go.microsoft.com/fwlink/?linkid=845961.
To vypadá, že v logu jsou jenom skoky zpět.

Udelej paralelni cistou instalaci - zda bude mit stejne chovani.
Pokud ano, tak zapni kernel debugging a pripoj se tam debuggerem - uvidis spousty systemovych hlasek.

To asi nechám až jako poslední možnost, navíc jak jsem říkal nemám fyzické železo ve správě, takže bych to mohl maximálně poradit správci

Pokud jste už vyčerpali ostatní možnosti, podíval bych se, zda nemůže jít o tzv. Secure Time Seeding:
https://learn.microsoft.com/cs-cz/archive/blogs/w32time/secure-time-seeding-improving-time-keeping-in-windows
Na té stránce je i úprava registrů, kterou se to deaktivuje.

Podíval jsem se na konfiguraci a tato funkce je zapnuta (předpokládám že to je defaultní stav). Nicméně vzhledem k tomu, že v event viewru logu vidím jenom skoky zpět, tak mám pocit že spíš ta funkce vrací čas zpět, než že by způsobovala problémy. Ale nevím, zkusím to další noc vypnout a uvidím.

 

10

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 06. 01. 2026, 17:33:44 »

Tak je to ještě podivnější než jsem myslel. Dle zmiňovaných logů (běží tam věc, co periodicky každých 256,14 vteřiny udělá log. Neptejte se proč. Tak jsem projel log od července a vyfiltroval záznamy, kde dva po sobě jdoucí logy mají jiný rozdíl než 256,14 (plus pár vteřin rezerva). Našel jsem dvojí chování: Zhruba od července do půlky prosince to jelo většinu dnů bez problémů, jenom některé dny došlo ke skokům dopředu a zpět (třeba log v 1:43:19, další ve 2:36:24, další v 1:48:41, a pak několik třeba po deseti vteřinách. Jako kdyby čas skočil dopředu, pak se vrátil zpět a pak chvíli běžel pomalu a v řádu hodin se to srovná). Tohle se dělo 6.8., 11.8., 13.8., 14.8., 10.9., 26.9., 15.10., 22.10., 29.10., 12.11., 10.12. Jiné dny to jelo přesně log každých 256,14 vteřiny . (Kromě 26.10., kde vidím skok ve dvě o 3600s při změne času).
Od 12.12. Se chování změnilo. Každý den dojde ke dvěma skokům . V noci dopředu a ráno zpět. Počet vteřin o který to to skáče se každý den zmenšuje zhruba o vteřinu

Kód: [Vybrat]

12.12. 2794s
13.12. 2793s
14.12. 2792s
...
5.1. 2774s
6.1. 2773s
Skok dopředu je ve 3:20 +- 10 minut. Skok zpět bývá od pěti do osmi. (Proto jsme si toho všimli až teď, kdy někdo přišel do práce ještě před tím skokem zpět a všiml si to).
Uvedené výsledky stojí na tom, že onen log se generuje každých 256,14 vteřiny. Nicméně sedí s měřením oproti pool.ntp.org, které dnes změřilo taky skok 2773s.

Fakt mi to přijde jak kdyby se tam praly dva různé zdroje času a pak to dělá psí kusy.

11

Windows a jiné systémy / Skok systémového času Windows

« kdy: 06. 01. 2026, 11:21:56 »

Zdravím,
vím že Windows není tady primární zaměření, ale mám zajímavý problém ve virtuálce s Windows 11 pod VMware. Od 29.12.2025 se každý den někdy kolem třetí v noci posune systémový čas o 2773 vteřin a ráno kolem 7 - 8 se vrátí zpět. (Přesné časy skoků bych mohl dohledat z logů).

Nejsem správce fyzického železa, ale mluvil jsem s ním, říkal že nic neměnil a že se na to podívá.

Dávám to sem ze zajímavosti, jestli jste se taky setkali s něčím podobným.

Pro úplnost když jsem přišel na tento problém, zapl jsem w32tm stripchart a tady jsou částečné logy:

Kód: [Vybrat]

w32tm /stripchart /computer:pool.ntp.org /dataonly /period:300 |
>> Tee-Object -FilePath C:\temp\time_drift_2.log -Append
Tracking pool.ntp.org [162.159.200.123:123].
The current time is 05.01.2026 14:25:18.
14:25:18, +00.0129176s
14:30:18, +00.0165300s
14:35:18, +00.0193773s
14:40:18, +00.0223993s
14:45:18, +00.0199100s
14:50:18, +00.0091434s
...
02:55:21, +00.0417110s
03:00:21, +00.0433553s
03:05:21, +00.0433707s
03:10:21, +00.0450076s
03:15:21, +00.0482284s
04:06:34, -2773.7582560s
04:11:34, -2773.7540893s
04:16:34, -2773.7542422s
04:21:35, -2773.7517265s
04:26:35, -2773.7467640s
04:31:35, -2773.7460565s
...
07:26:35, -2773.6656590s
07:31:35, -2773.6626884s
07:36:35, -2773.6611551s
07:41:35, -2773.6579177s
07:00:21, +00.0128807s
07:05:21, +00.0164778s
07:10:21, +00.0196563s
07:15:21, +00.0216492s
07:20:21, +00.0116391s

Status w32tm:

Kód: [Vybrat]

PS C:\Users\xxx> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 2 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0006809s
Root Dispersion: 10.1682249s
ReferenceId: 0xC0A8C814 (source IP:  192.168.200.20)
Last Successful Sync Time: 06.01.2026 10:57:53
Source: xxxx.yyyy.local
Poll Interval: 12 (4096s)
xxxx.yyyy.local je stroj v lokální síti, ale tam běží čas normálně, spustil jsem stripchart i proti němu a výstup byl stejný jako proti pool.ntp.org. A začalo se to dít 29.12, předtím se to nejspíš nedělo. Ale shodou okolností tam běží něco, co generuje periodické logy každých 5 minut někdy od července, takže to můžu projít jestli se skok objevil už někdy dřív.

12

Hardware / Re:USB Wi-Fi adaptér pre pracovné PC

« kdy: 12. 10. 2025, 21:54:13 »

Nikdy jsem nepochopil pouzivani wifi na desktopu mam kabelu az az.. a jeden do gigabitu se tam uz ztrati.

Tak ono ne každý má kabelové rozvody ethernetu po bytě/baráku.. a tahat si kabel od počítače přes pokoj, kuchyň a chodbu do modemu/routeru je třeba pro někoho zbytečné když wi-fi tam má kvůli mobilům a tabletům tak jako tak..

13

Sítě / Vodafone optický internet - chybný DNS

« kdy: 16. 09. 2025, 22:51:21 »

Zdravím,
stala se mi divná věc, chtěl jsem zaplatit kartou na webu o2.sk (dobití předplacenky). Po potvrzení že to chci zaplatit přes Google Pay a přesměrování na acs2p.gpesecure.com jsem dostal chrome upozornění Chyba ochrany soukromí, ..., net::ERR_CERT_COMMON_NAME_INVALID. Detaily certifikátu Subject: www.0oo1.cz, Issuer: R12, Expires on: 10. 12. 2025, Current date: 16. 9. 2025. To už byl docela red flag.
acs2p.gpesecure.com se u mě resolvuje na 62.109.151.80, přitom na nslookup.io je 159.60.146.54
V routeru (nějaký Vodafone fiber station) bylo pod DNS:

The DNS configuration is done automatically when you connect to the network. Alternatively you can manually configure your own DNS settings on your devices."
Secure DNS:  automatically manually (vybráno bylo automatically)
V statuse jsem zjistil DNS
31.30.90.11
31.30.90.12
které vypadají že jsou legit vodafone dns.
Přepnul jsem na manually, nastavil tam 8.8.8.8/1.1.1.1, restartoval, flush dns a už resolvuju správně na 159.60.146.54.

Tak se chci zeptat jestli to je nějakej útok na Vodafone DNS servery, nebo nějaká chyba konfigurace a jestli to pozoruje ještě někdo další a tak.

14

Hardware / Re:Znáte PLC s IDE pro Linux?

« kdy: 10. 04. 2025, 01:24:47 »

Tak se omlouvám, v té rychlosti jsem si nevšiml že to co jsem našel není Codesys IDE pro Linux ale jenom návod jak ho rozchodit ve Wine.
https://forge.codesys.com/tol/codesys-4-linux/home/Home/

15

Hardware / Re:Znáte PLC s IDE pro Linux?

« kdy: 10. 04. 2025, 01:20:32 »

Koukal jsem že Codesys má IDE i pro Linux, takže něco s Codesys runtime. Já dělám většinou jenom Siemens, takže nemám takový přehled kdo nabízí PLC s Codesysem, ale měl jsem v ruce něco myslím od Turcku. A pokud to je nějaký poloprofi projekt, tak Codesys nabízí taky runtime (mimo jíné) pro Linux, takže spoustu firem nabízí hotové PLC založené na Raspberry Pi. Linku v automobilce to asi neuřídí, ale použili jsme to ve firmě na řízení chytrého skleníku (čerpadla, otevírání střechy, světla, atd.)
Akorát teda nemám zkušenosti jak dobře to Codesys IDE funguje pod Linuxem, já ho provozoval jenom ve Windowsech.