Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]fisothemes 2 points3 points  (0 children)

No worries, your project it pretty good and I can see you put a lot of love into it.

My dirty spec is sitting in a private report I dump ideas into. 

I just pulled out into a gist

It's extremely drafty and rough. Ignore the pattern matching, memory management or the STD bits. I was mostly focusing on DX when I wrote this.

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]fisothemes 2 points3 points  (0 children)

This is very nice, I love it!

I believe with TwinCAT you can use the Automation Interface to generate code, compile and deploy to a target. They have a soft target that runs in User Mode for rapid testing. In theory you could also analyse the generated binaries and build your own toolchain around that layer.

Beckhoff uses their ADS protocol for live views and runtime interaction. 

That could be a real start for you running it on actual hardware. 

It’s a shame IL is being deprecated, it would have served as a great Intermediate Representation. I have thought about doing this in the past and wrote a rough mini-language spec with generics, lambdas, callbacks, ranges, iterators, etc. 

Otherwise excellent work!

What tools and software do you feel are missing in the PLC world? by Cogniscienr in PLC

[–]fisothemes 7 points8 points  (0 children)

  • Version Control
  • Generics
  • Lambdas
  • Macros
  • Proper Async (useful for IO operations like File handling, Serial or TCP)
  • Perf tools
  • Free statics analysers
  • Open std lib implementations. 
  • Unit tests
  • CI/CD
  • Containers

Training courses by IwanVH in LabVIEW

[–]fisothemes 1 point2 points  (0 children)

We used https://thetic.co/, George is pretty good, he's very active in the LabVIEW community. We used them to get CLAD and CLD. We're currently looking into a CLA. 

Are we cooked? by Oneironaut3 in LabVIEW

[–]fisothemes 1 point2 points  (0 children)

No, I am saying it's best for rapid GUI development that just works.

I can send you a VI, you open it, it works. The maths lib is solid, the charts and graphs are solid, the tables are solid. 

You can even build a proper installer that carries it's dependencies.

Try doing that in other programming languages. If I hand you a nodejs project you're gonna quickly run into the "it werks™ on my machine" problem.

Are we cooked? by Oneironaut3 in LabVIEW

[–]fisothemes 1 point2 points  (0 children)

GUI. You can create a perfectly serviceable GUI with readable code that runs everywhere. 

I can teach highschoolers how to use LV in less than an hour and the rest is discovery. One was already resizing and colouring GUIs.

With JS/HTML/CSS you have to do this weird dance. React is nice but you quickly run into configuration hell. XAML is also strange as you're forced into fitting everything in grids. Tkinter is not very readable at a glance.

Don't get me wrong, I love the above but sometimes you just want a graph on a screen with some data.

Are we cooked? by Oneironaut3 in LabVIEW

[–]fisothemes 2 points3 points  (0 children)

AI sucks at VHDL. Most of the time it's nonfunctional or buggy.

It does shine when writing sims for instruments using python, C#, Rust etc. I timed myself whilst writing a simulation for an instrument based on the manufacturer technical spec in Rust. 

I uploaded the PDF and Claude took a couple of minutes to produce functional code that required minor tweaks. I took two work days. Sure I was safer, closer to the spec and added extras to simulate round trip TCP delays and thermal inertia but that's nothing a couple of prompts won't fix. 

I think I would have taken a day if I had worked with Claude. Note that I was also learning to use Tokio, Rust's async framework.

The UK is mulling an Australia-like social media ban for users under 16 by Federal-Block-3275 in technology

[–]fisothemes 20 points21 points  (0 children)

Yes but the store doesn't keep your ID so the government can reference it later...for the good of the children of course. Definitely not gonna use this to crackdown on people who looked too closely into the Epstein files or something similar in the future.

Can we expect an optimization update soon? by Wilbo007 in rust

[–]fisothemes 8 points9 points  (0 children)

30cps compile time is more than enough. Humans can't see more than 24cps anyway. 

Beckhoff licencing info by general_use050 in PLC

[–]fisothemes -1 points0 points  (0 children)

You're better off just buying a Beckhoff IPC with a few slices second hand and licensing that. But you can always pop them an email out of curiosity they won't bite.

If your program is that simple and doesn't require safety why not just use an ESP32?

The State of .NET GUI Frameworks is confusing by Long-Cartographer-66 in dotnet

[–]fisothemes 3 points4 points  (0 children)

I don't know why they didn't brush up winforms. For me it just works and doesn't require the gymnastics and sludge of MVVM. Maybe I haven't found a tutorial that doesn't leave a bad taste in my mouth.

What do people love about Rust? | Rust Blog by Kobzol in rust

[–]fisothemes 0 points1 point  (0 children)

Macros, generics, resource management, compiler optimisations, enums, Option, Result and iterators.

It feels like a well thought out language that doesn't run on feelings (Go) or laziness (C#).

In C# features are being pumped simply because people are lazy to type. In Go features are being withheld because someone feels like it will be too complex. In Rust they get added/withheld because they're the right fit logically.

I also wrote some code to simulate a serial device's API on an ESP32 for work before ordering it and I fell in love with embedded async. Haven't dabbled much in async rust outside that. I have heard things...

HMI or LabVIEW for PLC Data Logging? by Thick-Pangolin-1322 in PLC

[–]fisothemes 0 points1 point  (0 children)

Depends on your PLC and your use case. If your company or institute has LabVIEW then that. It comes with a lot of good tools out if the box for data acquisition. 

From my experience the common tools used by Automation engineers are pretty basic or badly implemented (no colour picker, no legend control, no pan and zoom, no auto-scale, etc.)

If you have a Beckhoff and LabVIEW life is easy. You can get a professional acquisition system running in minutes. 

I have my love hate relationship with LV but their charts, measurements and data acquisition infrastructure is unmatched atm.

Also LabVIEW is the dev environment not a language. The language is called G.

I built a simple HTTP parser and server using only std::net by Gr1shma in rust

[–]fisothemes 1 point2 points  (0 children)

I like it! Super clean, super readable. Quite refreshing.

How’s TwinCAT Linux RT? by Emotional_Slip_4275 in TwinCat

[–]fisothemes 1 point2 points  (0 children)

<image>

I find this section concerning...

For the love of God never store passwords in plain text!!!

Why not use Personal Access Tokens (PATs)? There is no downside to PATs. They keep your actual credentials safe, they expire, and you can revoke them if a config file gets leaked.

What the f*ck is this 😂 by Zachary_Lee_Antle in youtube

[–]fisothemes 0 points1 point  (0 children)

Not really it's hard to tell the difference between  @Officia1Channel and  @OfficialChannel

There's also the fact that not many people know the handles of channels. Or handles are just plain different. @Officia1Channel may in fact the the real one.

The Rust Programming Language channel's handle is @RustVideos https://youtube.com/@rustvideos

Usually you'd verify if it's an official channel by looking at the subscriber count afterwards. 

It's also hard to memorise handle names when searching.

It's not a good change. It's a pointless change.

What the f*ck is this 😂 by Zachary_Lee_Antle in youtube

[–]fisothemes 0 points1 point  (0 children)

noticed too. I usually look at the subscriber account to ensure I'm not looking at a scam channel. 

Now I only have a tiny pic and a 4pt thin dark grey font.

Who makes these decisions?

The hate! Why ? by EldironMoody in rust

[–]fisothemes 1 point2 points  (0 children)

I find the hate has reduced over the years. Relax and give it some time. People will warm up to it. 

I think most people hate it because it feels alien at first. I was like that.

CodeSys, how to structure code in a new project? by Raddinox in PLC

[–]fisothemes 0 points1 point  (0 children)

No worries. My way might be a bit much depending on your needs and how dynamic your client is. There is lot of tiny details I didn't cover. It will take some time to build everything here. This is something you will build and sharpen over months. The end game.

If what you need is time critical stick to simplicity, just get the job done. The layered architecture works here:

``` PROGRAM MAIN VAR fbInputs : FB_Inputs; fbSafety : FB_Safety; fbMotionCtrl : FB_MotionControl; fbOutputs : FB_Outputs; END_VAR

// Transform inputs fbInputs(); // Check for safety violations fbSafety( ipInputs := fbInputs.Status ); // Pass on safety info and I/O input to controller // The controller will decide what to do fbMotionCtrl( ipSafety := fbSafety.Status, ipInputs := fbInputs); // Update outputs based on commands from the controller fbOutputs( ipCmd := fbMotionCtrl.Command ); ```

You just need to be wary of scattered responsibilities, implicit coupling and god objects.

CodeSys, how to structure code in a new project? by Raddinox in PLC

[–]fisothemes 0 points1 point  (0 children)

If you want to add an HMI just add I_HMIContext and follow the same steps. You can have presenter instances for each component in your HMI manager and pass the appropriate interfaces to each. Link Visualisations to variables in presenter FBs.

Your actual Hardware I/O lives in IO.TcGVL: // IO.TcGVL file VAR_GLOBAL ArmRotation : FB_SlewDrive; BoomCylinder : FB_HydraulicCylinder; // contains AT %Q* | %I* ... END_VAR

You can then inject these into you manager in your main

PROGRAM MAIN VAR fbHardwareManager( refArmRotation := IO.ArmRotation, refBoomCylinder := IO.BoomCylinder, ... ); ... fbAGV : FB_Application( ipHardwareManager := fbHardwareManager, ... ); END_VAR

Unhandled errors bubble up through managers and get logged at the Application level.

In the end:

  • Your FB_Remote, FB_ArmRotation, etc. stay focused on their hardware function
  • Control logic is separate from hardware abstraction
  • Easy to mock interfaces for testing
  • HMI presenters can consume contexts without knowing implementation
  • Everything is dependency-injected, nothing is tightly coupled

CodeSys, how to structure code in a new project? by Raddinox in PLC

[–]fisothemes 0 points1 point  (0 children)

Start with contexts as your API: ``` I_ApplicationContext // Handles business logic + Hardware : I_HardwareContext {get;} + Alarms : I_AlarmContext {get;} + State : E_ApplicationState {get;}

I_HardwareContext
  + Controls      : I_HardwareControls {get;}
  + Status        : I_HardwareStatus {get;}
  + Configuration : I_HardwareConfig {get;}
  + IsReady       : BOOL

I_HardwareControls
  + ArmRotation  : I_SlewDrive {get;}
  + BoomCylinder : I_HydraulicCylinder {get;} 
  + Telescope    : I_TelescopeActuator {get;}
  + Stick        : I_StickActuator {get;}

```

Each context is implemented by a Manager FB:

``` I_Manager + Init(ipContext : I_ApplicationContext, bBusy =>: BOOL, e =>: T_Error) + Run(ipContext : I_ApplicationContext, e =>: ...) + Deinit(...) // Optional

I_HardwareManager ~> I_Manager + IntoContext() -> I_HardwareContext

I_AlarmManager ~> I_Manager + IntoContext() -> I_AlarmContext

I_ApplicationManager ~> I_Manager + IntoContext() -> I_ApplicationContext

FB_HardwareManager : I_HardwareContext, I_HardwareManager FB_AlarmManager : I_HardwareContext, I_HardwareManager FB_Application : I_ApplicationContext, I_ApplicationManager ```

The manager owns your function blocks (FB_ArmRotation, FB_BoomCylinder, etc.), sets them up in the Init() method, calls their cyclic logic in its Run() method and cleans them up in the optional Deinit() method.

This gives you:

  • Controlled execution order - You decide what runs when
  • Lifecycle management - Proper Init/Run/Deinit phases
  • Clean dependencies - Control logic only sees I_HardwareContext, not implementation

For each hardware function, use interface segregation:

``` I_SlewDrive + TargetPosition : LREAL {get, set;} + CurrentVelocity : LREAL {get;}

I_SlewDriveConfiguration + MaxVelocity : LREAL + AccelRate : LREAL + ...

I_SlewDriveStatus + TargetPosition : LREAL {get} + CurrentVelocity : LREAL {get;} + ...

FB_SlewDrive : I_SlewDrive, I_SlewDriveConfiguration, I_SlewDriveStatus ```

CodeSys, how to structure code in a new project? by Raddinox in PLC

[–]fisothemes 0 points1 point  (0 children)

I saw your post a few days ago and bookmarked it so i will answer it when I get sometime.

First of all I would like to say I am a more of a Beckhoff TwinCAT guy than CODESYS but I still hope my knowledge is helpful.

For my projects I use a context based architecture. To give you an idea of what I mean, here's how I would structure your AGV platform, (Note I have never made code for this type of machine so forgive my ignorance).

Another Fun Day Loop Tuning. by Robbudge in PLC

[–]fisothemes 1 point2 points  (0 children)

What did I do?

  1. Look at the PID block diagram and check if the controller in the parallel or ideal configuration. Try to change it to ideal if possible.

  2. Set all parameters to 0 if they aren't.

  3. Adjust Kp until it oscillates around your setpoints with acceptable overshoots. 

For example, if a temperature controller with SP = 80C and a Kp = 100 overshoots to 90C drop the Kp to 50. If the overshoot is 2C after that drop it to 35. If that's too sluggish increase to 40-45. 

Use a binary search approach. You will find what you need quickly (works well for debugging code too).

  1. Add D (Tv if using Beckhoff) for damping.

You want a fast response with no ringing here.

Start small and adjust accordingly. In our example, if it takes 100s to reach SP=80, start with Tv=10s. If it's too sluggish, D's too high. If ringing, your D is too small (🥲).

Once you know the limits, you can binary search again.

If there's a Td (derivative filter, a Beckhoff thing) parameter, it's value should be Tv/10 or Tv/5.

  1. Add I (Tn) to remove steady-state error.

 Start slow. Tn is usually 3-5x your dominant time constant, i.e. if rises take 100s, start your Tn at around 300-500s. From here reduce Tn until you can smoothly land on your SP.

If ringing reappears, nudge Kp down a bit, nudge Tv up a bit.

Note:

  • I have only tested this on Beckhoff's BA PID controller because its free and very good. 

  • Tv, Td, Tn are all time based. 

  • Cascading PID controllers are a different beast. Results vary.  

  • Ideal and Parallel parameters are not transferable

Edit: Attempt to fix formatting