• Toggle taks button
• Task button

Alert colors on task failure.

We want to be able to detect symbol information when the signal is passed as reference parameter to the component (VAR_IN_OUT...)

When you exclude example applications from build they can suddenly stop working when changes are made.

Today I tried to start the example project, but there was an issue with dependency version downgrade - an issue that would have been caught by the compiler sooner.

Last week I discussed the possibility with @PTKu to use STweep to maintain a consistent code style.
STweep is free for active open source contributors > https://www.stweep.com/opensource/

So i'd like to start a discussion about using STweep and a default set of settings for TCOpen,
Do @jozefchmelar and @TomKovac use a default code style right now? Or what would be your preference?

Build and release script is too heavy and there are too many dependencies on the particular configuration/environment. We should run only restore/build ivc and solution build to retrieve dependencies and build solution...
see #85

• Default does not create packages (if 'publishPackages == false' do not create packages)
• Default does not calcs semver (if 'updateAssemblyInfo == false' do not use GitVersion, nor download)

Block should switch between two states and execute one of the states at a given time.

Nightly builds do not pass due to errors when building PLC projects from the command line. There seems to be a problem with TcoDrivesBeckhoff

https://github.com/TcOpenGroup/TcOpen/runs/2574867438?check_suite_focus=true

PLC.TcoDrivesBeckhoff : message: generate boot information...
29>------ Rebuild All started: Project: XaeTcoIoBeckhoff, Configuration: Release TwinCAT RT (x64) ------
30>------ Rebuild All started: Project: XaeTcoPneumatics, Configuration: Release TwinCAT RT (x64) ------
31>------ Rebuild All started: Project: TcProber, Configuration: Release TwinCAT RT (x64) ------
32>------ Rebuild All started: Project: XaeAppExamples, Configuration: Release TwinCAT RT (x64) ------
33>------ Rebuild All started: Project: XAEPlcTemplate, Configuration: Release TwinCAT RT (x64) ------
34>------ Rebuild All started: Project: XAETcoElements, Configuration: Release TwinCAT RT (x64) ------
35>------ Rebuild All started: Project: XaeTcoDrivesBeckhoff, Configuration: Release TwinCAT RT (x64) ------
35>Error: The operation could not be completed. Unspecified error 
36>------ Rebuild All started: Project: XaeTcoCore, Configuration: Release TwinCAT RT (x64) ------
========== Rebuild All: 34 succeeded, 2 failed, 0 skipped ==========

Hello,
I think that all the components should have a certain structure, for example like the motion PTP axis that I have sent to Tomas
estructure components:
.- Config o settings,
.- Status,
.-Commands,
.-Diagnosis o error,
.- Etc...
example:
stControl: ST_AxisControl;
stStatus: ST_AxisStatus;
stConfig: ST_AxisConfig;
stError: ST_AxisError;
stInputs: ST_AxisInputs;

• Refactor fbCylinder to Cylinder to comply with conventions.
• Add Info messages in tasks for diagnostics
• Improve WPFUI of Cylinder

Hello:
In the example of the Sequencer logic as it is known what are the missing conditions to advance to the next step?
Thanks you, Víctor.

• connection must be isolated to prevent possible malicious code from repo running inside the infrastructure.
• create a virtual environment to fast recovery of agents when necessary.

https://github.com/TcOpenGroup/TcOpen/runs/2608421227?check_suite_focus=true

Failed T000_SetSynchronizationParametersFromTcA [102 ms]
Error Message:
Expected: 0
But was: 18446653924199563680

Stack Trace:
at TcoCoreUnitTests.T00_TcoRtcTests.T000_SetSynchronizationParametersFromTcA() in C:\actions-runner_work\TcOpen\TcOpen\src\TcoCore\tests\TcoCoreUnitTests\TcoRtcTests.cs:line 69

Failed T002_ChangeSynchronizationParametersFromTcA [31 ms]
Error Message:
Expected: 18446653924197493528
But was: 18446653924199563680

Stack Trace:
at TcoCoreUnitTests.T00_TcoRtcTests.T002_ChangeSynchronizationParametersFromTcA() in C:\actions-runner_work\TcOpen\TcOpen\src\TcoCore\tests\TcoCoreUnitTests\TcoRtcTests.cs:line 146

Results File: C:\actions-runner_work\TcOpen\TcOpen\src\TcoCore\tests\TcoCoreUnitTests\TestResults\TEST-TcoCore.xml

Failed! - Failed: 2, Passed: 312, Skipped: 0, Total: 314, Duration: 2 m 22 s - TcoCoreUnitTests.dll (net48)

Describe the bug

At the start of the examples application and component's sandbox application sometimes the console stops at reading identities.

To Reproduce
Steps to reproduce the behavior:

1. Run the application from https://github.com/TcOpenGroup/TcOpen/tree/initial-dev/src/TcoApplicationExamples/TcoApplicationExamples.Wpf
2. 1 or > of 10 times the application will not start.

Expected behavior
The application starts every time.

Additional context
Seems the connector deadlocks due to the premature start of batch operations. If any batch operations are started after first cyclic R/W the behavior does not occur.

Hello,
For the demo example of the sequencer to work,
it is necessary to have something installed in the C:\Inxton folder?
Thanks you, Víctor.

Implement features provided by @runtimevic

• Read detailed axis information etc.

Prototype an example of wrapper class... + design testing and documentation.

Following discussion:

#13 (comment) and related

and
#13 (comment)
#21 (reply in thread)

Talk directly to @PTKu about this.

@jozefchmelar Same issue we had when installing the agents with the GitVersion path. Let's just skip versioning when 'updateAssemblyInfo' is false.
See #85

We should also call build on a connector project on a dummy project without partial extensions.

Following #13 (comment)

• All components should be usable outside TcOpen framework

• Some framework features can be lost (messaging, RPC, etc.)

• Elaborate pattern for non-framework use

• Create example(s) of component implementation outside TcOpen framework

I have gone through the instructions for setting up the development environment on my host machine and a fresh VM and I get a lot of errors in the CopyInxton stage and the GitVersion state and my build fails.

I have attached the log file from my most recent attempt in a VM. Am I missing a step here?

PS Build Log.txt

• Update API documentation describing each category with 'Use when ...
• Create a document that describes best practices for the messaging.

#116

Some references
#15
#75 (comment)

Document in the making here

Hello,
The app buttons do not work to send the cylinder to rest or work, and I don't know why?

• OnEntry executes only once when entering the step execution
• OnExit executes only once when leaving step execution

Hello,
I have installed everything and I keep getting the following error from the libraries, I attach a photo so that it can be seen?

Conventions document here

Please contribute to discussion bellow

• Let's keep the discussions here for tracking.
• Quick chats here:

• Naming conventions for variables (VAR, VAR_INPUT, VAR_OUTPUT, VAR_IN_OUT, VAR_INST, TEMP)
• Naming convention for methods
• Naming convention for properties
• Naming convention for blocks (FB, FC, PRG etc.)

• detect change on dev branch
• pull TcOpenGroup/TcoOpen repo
• build documentation in TcOpenGroup/TcOpen.Documentation

• can be executed only on demand from dev branch

• Primary
• Secondary
• Accent
• Alert
• Error

• Ons colors

Find the naming and usage consistent with Material Desing.

TcoCore.TcoSequencer.CurrentStep property should be REFERENCE TO StepDetails... to prevent troubles with dereferencing.

TcoTaskView should have some signalization to identify that the related task ends up in the error state.

Originally posted by @HAHermsen #13 (comment)

PS If you really wish to go agnostic consider building it without any Beckhoff specific dependencies. After all, ultimately Beckhoff's TwinCAT is just another flavor of CODESYS.

Originally posted by @PTKu in #13 (comment)

You are right we should bear this in mind.... at this point, there are some implementations that are tight to TwinCAT libraries (I guess Rtc implementation) There are more ways we can do this I would opt for abstractions with interfaces (then each platform can have its own implementation, where necessary).