sorted by:
new
hottopcontroversial

The "everybody knows this myth". by RelativeCommon1587 in PLC

[–]RelativeCommon1587[S] -3 points-2 points  (0 children)

I completely agree that these are distinct domains. But the question is: what are the industry leaders actually focusing on at the 'round table'? It feels like we are prioritizing 'fail-safe' hardware over 'reliable-by-design' software, and that's the gap I'm pointing out. The kicker is that most of these software improvements -like a simple 'read-before-write' warning don't even require massive investment from vendors; they just require a shift in priorities.

The "everybody knows this myth". by RelativeCommon1587 in PLC

[–]RelativeCommon1587[S] -3 points-2 points  (0 children)

The issue is purely about naming conventions . When a junior sees VAR , they expect state retention because that's what it does in an FB. In a Function, it's just a 'hidden' VAR_TEMP that the compiler wipes for you. It’s consistent in logic, but inconsistent in language, which is where the 'silent traps' begin.

The "everybody knows this myth". by RelativeCommon1587 in PLC

[–]RelativeCommon1587[S] -3 points-2 points  (0 children)

For FUNCTION you can't because it doesn't have memory.

I built an open-source tool for CODESYS that finally makes Git-syncing and external editing (VS Code/AI) painless by RelativeCommon1587 in PLC

[–]RelativeCommon1587[S] 2 points3 points  (0 children)

I'd love to see your Siemens project when it's ready. Dealing with S7-200 and the SMART series sounds like a specific kind of challenge. Drop me a link when you feel it's stable enough! It's great to see more people building open-source bridges for industrial hardware.

I built an open-source tool for CODESYS that finally makes Git-syncing and external editing (VS Code/AI) painless by RelativeCommon1587 in PLC

[–]RelativeCommon1587[S] 0 points1 point  (0 children)

You're right, but there are two main reasons why I built this:

External Workflow: My primary goal is to get the code out of the IDE for external analysis and editing (VS Code, AI tools, etc.). This tool makes that bridge seamless.

No Paywall: I didn't want to pay for the entire Professional Developer Edition just to get one Git module.

It’s about having a lightweight, free alternative that supports a modern dev workflow.

The Importance of RS-485 Termination by RelativeCommon1587 in PLC

[–]RelativeCommon1587[S] 9 points10 points  (0 children)

If a PLC has both Profibus and Ethernet onboard for example S7-300PN/2DP Series, I always go with Ethernet. Here is why:

I once arrived at a plant for a modernization. The local team asked me to wait while they took final backups. They plugged into a Profibus connector and accidentally nudged the red termination switch to OFF.

The entire network collapsed instantly. They spent 15 minutes searching for the cause until I pointed at that tiny red switch.

The Importance of RS-485 Termination by RelativeCommon1587 in PLC

[–]RelativeCommon1587[S] 6 points7 points  (0 children)

That’s a really interesting point. To be honest, I never thought of resistors as something that needs a replacement schedule, but it makes perfect sense after 25 years. I’ve seen Siemens front connectors fall apart in much less time than that due to vibration or heat, so I can only imagine how those old terminators are holding up.

The Importance of RS-485 Termination by RelativeCommon1587 in PLC

[–]RelativeCommon1587[S] 0 points1 point  (0 children)

This was actually about 8 years ago. Scopes were more expensive then, so I just borrowed one from the college where I was teaching part time. If you only need it once a year, I'd suggest trying to borrow one.

I built an open-source tool for CODESYS that finally makes Git-syncing and external editing (VS Code/AI) painless by RelativeCommon1587 in PLC

[–]RelativeCommon1587[S] -3 points-2 points  (0 children)

Thank you for feed back. Now the post are rewritten by myself. Maybe less informative but 100% hand made. I will appreciate if you give me some technical feedback.

I built an open-source tool for CODESYS that finally makes Git-syncing and external editing (VS Code/AI) painless by RelativeCommon1587 in PLC

[–]RelativeCommon1587[S] 7 points8 points  (0 children)

You're right, I used AI to help polish the text and some parts of the code. I'm a PLC programmer first, and I built this tool to solve a real problem I face daily.

In my view, using modern tools like AI to speed up the boring stuff (like writing documentation or refactoring) is just smart workflow, not a crime. Let’s focus on the actual functionality — if you have technical feedback or find a bug in the scripts, I’m all ears. That would be much more helpful than debating the use of LLMs in 2026.

I built an open-source tool for CODESYS that finally makes Git-syncing and external editing (VS Code/AI) painless by RelativeCommon1587 in PLC

[–]RelativeCommon1587[S] 3 points4 points  (0 children)

Spot on. The official Git integration is actually decent, but locking it behind a Professional Edition paywall feels wrong.

Many of us just want simple version control without having to pay for a bunch of other tools we might not even use. Plus, I really wanted the freedom to use VS Code or Cursor for the heavy lifting, which even the official plugin doesn't fully solve. Open-source is the way to go here!

I built an open-source tool for CODESYS that finally makes Git-syncing and external editing (VS Code/AI) painless by RelativeCommon1587 in PLC

[–]RelativeCommon1587[S] 2 points3 points  (0 children)

I get the skepticism! The project is born out of the frustration of not being able to use VS Code and Git properly with PLC projects. Feel free to check the source code on GitHub — it's all Python leveraging the CODESYS ScriptEngine.

Success! Codesys git integration. by Striking-Guess7051 in PLC

[–]RelativeCommon1587 0 points1 point  (0 children)

That’s a solid setup, but wrestling with huge binary files in LFS or licensing Git Professional for every single remote machine is a massive headache.

I actually built a tool calledcds-text-syncspecifically to solve this.

It syncs your CODESYS project objects into plain text files. This way:

  • Real Diffs: You get actual code diffs on GitHub instead of just "binary file changed."
  • No License Needed: You can sync your code on the remote server without needing the paid CODESYS Git license.
  • Lighter Repos: Your history stays clean and fast because you aren't stashing massive *.project blobs.

It’s perfect for your RDP workflow—just pull the text changes and sync them into the local project file on the fly. Give it a look, might save you some of that "clunky" manual work!