⬆Support this channel using the "Thanks" button⬆ or by making a donation through PayPal → www.paypal.com/donate/?hosted_button_id=7FBED5B26KT7S, or by becoming a Patron → www.patreon.com/sagatowski
DARK MODE TEXT EDITOR. Please! Amazing collaboration gentlemen, your insights are invaluable, well stated, and well intentioned. I had never considered your point that many of the standards primarily serve and favor large corporate business interests rather than developer needs. I think these “bottom up” suggestions would move our industry and way of working forward in a huge way! Thank you both for sharing your thoughts and experience openly. You are truly expanding the spirit of collaboration and innovation, which is so prevalent amongst other forms of software development, into the automation realm, and for that, I am truly grateful! I can’t wait to continue learning from you, and along side you!
The dark mode editor is allready integrated within CODESYS IDE since version 3.5. SP14 (and in a different way even earlier) so Beckhoff will have to adapt the vanilla CODESYS solution and integrate it, like it has done with many parts of the basics of TwinCAT3
I have 4 major problems with TC3... and they are all listed in this video. With people with your mind we will be able to shake the automation world and make things better
TwinCAT3 is like a cat.🐱 Sometimes cute and pleasuring to tend to, sometimes overly annoying. The behavior of TwinCAT3 is is quite self-explanatory of its name. That's had me thought a while. It's quite good overview of TwinCAT3 on this video.
It's good to hear that ! The problem is unfortunately omnipresent in our industry... and it is difficult to change the minds of people who develop with these standards...
Yes, method or function overloads would be great to have. Also consider pointers to function or method calls. Maybe even dynamic arguments to methods and functions.
Nice! Thanks Jakob! #3: i've been successfully using VMs to avoid that problem. One per version. Lots of gigabyte wasted... #4: yes. Overload, reflection, those aren't just nice buzzwords... Now I'm interested in the TcOpen group...
You guys speak directly from my soul. Another thing I would like to amend: A package management system (like NuGet) is highly needed. In a complex PLC project you often end up in something like a .DLL-Hell if you try to solve complex chained dependencies. Besides from that: I am wondering why we need to keep stick with structured text. This pascal style language is a bit bloated and outdated. Why not utilizing modern languages like C#, Python, Java, Kotlin, F#? There was so much progress in the software world in the last twenty years, but TwinCAT programming much too often feels like travelling back in time to the 90ies.
You could blink IO-s from C#, Python or whatever, but you don't. Why not? Because no matter how pretty the language is, machinery won't work properly if it isn't hard real time. That's what you are suffering all these restrictions for that come with any PLC, they force you to write code that turns out real time without any special effort. You could write hard real time code in something more generic like c++ or whatnot, it's perfectly possible, but you would either fail to achieve proper real time, or you would blow through your development budget chasing subtle and very hard to debug problems you accidentally created. PLC-s do one thing very well - they make real time control simple, by tying both your hands behind your back so you would have a harder time hurting yourself.
@@aleksandersuur9475(disclaimer haven't touched a plc in over 10 years) but how does structured text make real time easier than C/C++? The later are used extensively in hard real time microcontroller/DSP implementations. Does structured text link calls to clock ticks in some way? (Like 1 instruction 1 cycle)
Better intellisense would be a good start, where it ranks the options on how likely they are going to be used. Prioritizing local variables, already used variables, etc. over random system variables I only use once every 10 projects.
I totally agree with you guys. There is actually one very simple way that Beckhoff could ease the pain we have with their xml storage thingy. Including extra empty lines in the declaration and implementation part makes reading diffs and merges much easier... Instead of
Save it as
Yes, we can do this manually, but it is cumbersome and there is at least one guy that doesn't know the intention and is pedantic about empty lines at the start of the code, so he removes them ( me 10 years ago :-D ) If Beckhoff stored files like this per default at least some of the plain text issues you mention were solved. I still agree that they should just use plain text and nothing more, but storing the file like this would cost them practically nothing in development, while still helping us developers.
Thanks for this suggestions, I never thought of this hack! Probably going to be tricky to impose this to all team-members though, and it will also look ugly in the IDE. I'm still hoping for non-markup!
@@JakobSagatowski It actually doesn’t look sooo ugly, but newcomers have to be told why there is an empty line at the beginning of every declaration and implementation ;) Overall the benefits you get from doing this outweigh the ugliness of these empty lines. Imposing is not that big of a deal as it is implementable by hooks. However, if Beckhoff implemented it in their save and load routines there would not be any difference at all to be seen in the IDE and the time to invest for this feature is marginal.
Very interesting, and I have to say I really hope Beckhoff product managers have seen this video. Every point you make is valuable and I think they should be shortlisting all of your ideas and some improvements to NC
A stable CLI-based compiler and deployment method (including HMI and other auxiliary projects like OPC-UA and Database connections) is a must. Please, Beckhoff.
Hey James! I've written a little about it on my blog (from a different perspective though, but touching the same topic): alltwincat.com/2020/11/02/handling-different-versions-of-twincat/
Great list. I am new to TwinCAT and Beckhoff and I am in the process of developing our first integration. The ability to do version control is one point that pushed our change from AB to Beckhoff. Is there also a way to do automated build (and maybe unit tests) on Jenkins?
Seems you won't have to wait for TC4 to get something akin to the CLI you're hoping for. Although I don't know how lightweight it will be, Beckhoff is working on the "system manager" which I've been told can be viewed as "Automation interface headless -mode". It will have the option to run with or without GUI.
That would be great! You can run automation interface without GUI now, but you cannot get rid of 'devenv' process. CLI experience can be achieved using powershell wrapper, the performance is not much better though.
I agree with you, the traditional automation is blocked in the past age. Sure, it's moving because some other actors are coming with this kind of features like Bosch and Phoenix contact, and Beckhoff is introducing TcBSD (Unix base 🤩). For me one the biggest key, like you they, is the ability to improve code quality with linter and tests functionalities, with the tools that We can use in the traditional software development.
My dreams: 1) TRY/CATCH in 64bit 2) Debug FB_init / FB_exit with debugger like other methods 3) Direct library code debugging (open source code from library and set breakpoint) 4) Arrays with dynamic length (like in Delphi for example) 5) Generics 6) Type introspection or even reflection 7) Improved working with strings (null terminated with unlimited length, simple concatenation 'str1' + 'Str2' + 'Str3') Hope this can be achieved without new language. And yes, StucturedText is very outdated...
One thing that is very difficult to ask from a PLC language is dynamic memory, it does have to be real time at the end of day and having static memory is a very big part of achieving it. There is __NEW() and __DELETE() to be used very carefully, but to make such things implicit would quickly run into unacceptable problems for majority of users. Best to keep such things out of real time domain.
Hear hear! Those would be some excellent features! But what about using an existing language (C#, Python, or a functional one ;D) as a PLC programming language and not inventing and maintaining a new one? Recently I switched jobs and had to make a CLI with Python for a camera. It was such a please to use a language which has a solid tooling foundation. Not to mention all the open source libraries which I could use to communicate with the camera. I had the whole thing running in no time. Then I thought back about the devices which I had to interface with TwinCAT. Every time you had to start from scratch and the interfaces were often crap (bit 1 is an error, bit 2 is a warning, bit 3-8 is the rpm etc.). Not to mention Visual Studio crashing at random times or taking ages to load. It would often suggest to disable TcHMI, because it was slowing Visual Studio too much :'). Why reinvent the wheel and build a new ecosystem? PLC programming is a niche and will always be one--at least compared to general programming languages. Choose a popular language and a whole world of tooling opens up. They even support dark themes ;D.
I was contemplating the possibility to use existing language syntax. I'd love to discuss this into more depth with wider community. I started a pet project last Christmas of a transpiler that ingests C# like syntax and converts it into ST or IL. There are many details that should be sorted out in this approach. When one says C# or Python it is not just the language but also the base libraries, that for most people are inseparable from the language itself (e.g. Collections, Lists), and then there is the thing with GC that we got used to so much, but it would not be feasible PLC... now we would have the same language that would handle the memory resources differently... but may be this is not a real problem...
@@PTKu I can imagine it will cause some headaches, but it might be worthwhile in the end. Especially if it is not compiled to ST first, but directly to PLC machine code (not sure what that would be).
I think issue #1 stems from multiple issues: 1. TwinCAT is heavily dependent on both Visual Studio and CODESYS. In fact, the way the project file is structured is basically CODESYS in VS format. That's why it is difficult for them to replace XML, it's basically how VS and CODESYS recognize each files and structure the code accordingly. I believe many PLC programming software also formatting their files in XML, but why? It's for the 2nd reason: 2. IEC 61131. When you are required to provide access to 5 different programming languages, and 3 of them are visual heavy (LD, FBD, and SFC), there's no better alternative than XML. XML helps the format to be universal enough to be carried over between any IEC 61131 languages, since XML is there to store data, while the visualization of the languages can be done by GUI by means of interpreting XML. If Beckhoff format their files as plain text, It's going to be very difficult to convert them from a text-heavy language like ST to something more visual like FBD or SFC. In XML, everything is just either object tags, attributes, and parents-child relations. GUI just have to render objects tags, add connections based on their parent-child relations, and fill the properties by reading their XML attributes. I think that for version control, we should learn from Web Devs and their method of version control. HTML is just XML with standardized schema for the HTML, and they've been version controlling with git just fine. Maybe what we need is just a version of git that can understand Beckhoff's schema, not turning the whole TwinCAT upside-down and replacing XML. Although, to be honest, I hope Beckhoff can develop their own programming GUI and replace VS altogether, especially since the VS Shell have been discontinued, and we either have to shell out thousand of USD to get professional license, or stuck with old VS Shell. Plus, with TC/BSD, I think it's time they move on from VS too.
Hi & thanks for feedback. When talking about #1, I was referring to structured text (ST) and not the graphical languages. There is no reason to store the ST in XML. The markup doesn't add any value for ST (while for HTML it does).
You are right it would be nice to have Tc3 decoupled from VS. I believe the integration into VS was not a bad idea, the implementation has its issues though. One could use VS Community in many instances (that is free of charge). VS Professional subscription $45 / month with plenty of additional benefits besides VS.
I think a big issue is, that the industry hasn't even widely adopted Structured Text yet and it won't do that for years to come. Now the problem with adding more complex language features is, that the machine code should actually be so debug-friendly and easy to understand that some skilled maintenance-electrician could fix a machine by himself while looking at the code with little to no coding experience. If one wrote complex multi paradigm machine code in lets say C++, the maintainability of those machines at the customer level decreases dramatically (which is already the biggest problem with using ST in the first place), but you might not even have to be able to read in order to understand ladder logic for example. Sometimes 2 or 3 generations of people have to deal with the same machine, hence also the same (type of) code. Now imagine how stressful it would be if machine-code-standards changed every year or so, it's like if everybody had to relearn coding/debugging a machine depending on which year it was built.
I've been working with twincat 2 and 3 for 5 years now, and I've wasted the most time by just getting the NC to play ball with whatever motion I want a drive to execute. It can be so insanely annoying. Take for instance NC error 427F: "The new target position either has been overrun or will be overrun" The new target position either has been overrun or will be overrun, since until there it is impossible to stop. An internal stop command is commended. " This means that a new position command will result in an overrun of the old position command. For some machines, this could be bad. For many other machines, this does not need to be a problem. Beckhoff however decides this is always bad and your machine needs to stop. No warning, just an error and the axis needs to be re set. This behaviour is not warned for anywhere in the motion control documentation, you just get these 427F errors out of the blue, and slowly figure out how fucked you are. So if this type of motion is built in in the design of the machine, you need to spend an enormous amount of time to put in a calculation that checks each and every new position commands if they could induce an overrun of the old position command. This took me an enormous amount of time, is computationally expensive and to me it is beyond ridiculous that I cannot interpret the severity of the condition myself. This is just one example in the long long list of NC crap I've had to deal with. I get that we as programmers want to have modern tools, but our customers also want modern machines that are fast and dynamic, and if you're using the Beckhoff NC, this is not impossible, but just takes a lot of unbelievably frustrating effort. So I'm hoping for Beckhoff to first get the NC modernized (I've got quite a wish list), before doing anything else.
⬆Support this channel using the "Thanks" button⬆ or by making a donation through PayPal → www.paypal.com/donate/?hosted_button_id=7FBED5B26KT7S, or by becoming a Patron → www.patreon.com/sagatowski
DARK MODE TEXT EDITOR. Please! Amazing collaboration gentlemen, your insights are invaluable, well stated, and well intentioned. I had never considered your point that many of the standards primarily serve and favor large corporate business interests rather than developer needs. I think these “bottom up” suggestions would move our industry and way of working forward in a huge way! Thank you both for sharing your thoughts and experience openly. You are truly expanding the spirit of collaboration and innovation, which is so prevalent amongst other forms of software development, into the automation realm, and for that, I am truly grateful! I can’t wait to continue learning from you, and along side you!
The dark mode editor is allready integrated within CODESYS IDE since version 3.5. SP14 (and in a different way even earlier) so Beckhoff will have to adapt the vanilla CODESYS solution and integrate it, like it has done with many parts of the basics of TwinCAT3
Next year (2023) the TwinCAT version 4026 will be release with dark mode and some more fancy text editor features.
Wow! I’m not the only one thinking of these things. All four would be HUGE!
I have 4 major problems with TC3... and they are all listed in this video. With people with your mind we will be able to shake the automation world and make things better
You both are speaking out of my heart in every aspect!
TwinCAT3 is like a cat.🐱 Sometimes cute and pleasuring to tend to, sometimes overly annoying. The behavior of TwinCAT3 is is quite self-explanatory of its name. That's had me thought a while. It's quite good overview of TwinCAT3 on this video.
It's good to hear that ! The problem is unfortunately omnipresent in our industry... and it is difficult to change the minds of people who develop with these standards...
Happy to have you in the TwinCAT environment
Happy to have you in the TwinCAT environment too!
Yes, method or function overloads would be great to have. Also consider pointers to function or method calls. Maybe even dynamic arguments to methods and functions.
Nice! Thanks Jakob!
#3: i've been successfully using VMs to avoid that problem. One per version. Lots of gigabyte wasted...
#4: yes. Overload, reflection, those aren't just nice buzzwords...
Now I'm interested in the TcOpen group...
same here!
VMs are a good alternative, but as you say, they bring overhead and maintenance.
You guys speak directly from my soul. Another thing I would like to amend:
A package management system (like NuGet) is highly needed. In a complex PLC project you often end up in something like a .DLL-Hell if you try to solve complex chained dependencies.
Besides from that: I am wondering why we need to keep stick with structured text. This pascal style language is a bit bloated and outdated. Why not utilizing modern languages like C#, Python, Java, Kotlin, F#? There was so much progress in the software world in the last twenty years, but TwinCAT programming much too often feels like travelling back in time to the 90ies.
You could blink IO-s from C#, Python or whatever, but you don't. Why not? Because no matter how pretty the language is, machinery won't work properly if it isn't hard real time. That's what you are suffering all these restrictions for that come with any PLC, they force you to write code that turns out real time without any special effort. You could write hard real time code in something more generic like c++ or whatnot, it's perfectly possible, but you would either fail to achieve proper real time, or you would blow through your development budget chasing subtle and very hard to debug problems you accidentally created. PLC-s do one thing very well - they make real time control simple, by tying both your hands behind your back so you would have a harder time hurting yourself.
@@aleksandersuur9475(disclaimer haven't touched a plc in over 10 years) but how does structured text make real time easier than C/C++? The later are used extensively in hard real time microcontroller/DSP implementations. Does structured text link calls to clock ticks in some way? (Like 1 instruction 1 cycle)
I absolutely agree with you. It would be great if there will be included these requests. And we can develop a modern code finally. Great video! Thx
Better intellisense would be a good start, where it ranks the options on how likely they are going to be used. Prioritizing local variables, already used variables, etc. over random system variables I only use once every 10 projects.
I totally agree with you guys. There is actually one very simple way that Beckhoff could ease the pain we have with their xml storage thingy.
Including extra empty lines in the declaration and implementation part makes reading diffs and merges much easier...
Instead of
Save it as
Yes, we can do this manually, but it is cumbersome and there is at least one guy that doesn't know the intention and is pedantic about empty lines at the start of the code, so he removes them ( me 10 years ago :-D )
If Beckhoff stored files like this per default at least some of the plain text issues you mention were solved.
I still agree that they should just use plain text and nothing more, but storing the file like this would cost them practically nothing in development, while still helping us developers.
Thanks for this suggestions, I never thought of this hack! Probably going to be tricky to impose this to all team-members though, and it will also look ugly in the IDE. I'm still hoping for non-markup!
@@JakobSagatowski
It actually doesn’t look sooo ugly, but newcomers have to be told why there is an empty line at the beginning of every declaration and implementation ;) Overall the benefits you get from doing this outweigh the ugliness of these empty lines. Imposing is not that big of a deal as it is implementable by hooks.
However, if Beckhoff implemented it in their save and load routines there would not be any difference at all to be seen in the IDE and the time to invest for this feature is marginal.
Thank you guys,I believe in progress for TwinCAT, Beckhoff looks ahead..
This video should be obligatory to watch for each beckhoff employee (including janitors and cleaners)!
Very interesting, and I have to say I really hope Beckhoff product managers have seen this video. Every point you make is valuable and I think they should be shortlisting all of your ideas and some improvements to NC
I hope so too!
A stable CLI-based compiler and deployment method (including HMI and other auxiliary projects like OPC-UA and Database connections) is a must. Please, Beckhoff.
About 3rd part，will you offer a more detail video about your ways for exchange differet TC3 versions,it can avoid online change windows
Hey James! I've written a little about it on my blog (from a different perspective though, but touching the same topic): alltwincat.com/2020/11/02/handling-different-versions-of-twincat/
Great list.
I am new to TwinCAT and Beckhoff and I am in the process of developing our first integration.
The ability to do version control is one point that pushed our change from AB to Beckhoff.
Is there also a way to do automated build (and maybe unit tests) on Jenkins?
Yes there is. I have developed an free unit testing framework. Just Google "TcUnit", there you'll find everything you need.
Seems you won't have to wait for TC4 to get something akin to the CLI you're hoping for. Although I don't know how lightweight it will be, Beckhoff is working on the "system manager" which I've been told can be viewed as "Automation interface headless -mode". It will have the option to run with or without GUI.
That's great news!
That would be great! You can run automation interface without GUI now, but you cannot get rid of 'devenv' process. CLI experience can be achieved using powershell wrapper, the performance is not much better though.
I agree with you, the traditional automation is blocked in the past age.
Sure, it's moving because some other actors are coming with this kind of features like Bosch and Phoenix contact, and Beckhoff is introducing TcBSD (Unix base 🤩).
For me one the biggest key, like you they, is the ability to improve code quality with linter and tests functionalities, with the tools that We can use in the traditional software development.
TwinCat “4” XAE supported in Linux and MacOS system 🙌
Fully agree!
XAE as an extension in VSCode?
Hi jacob, do you have video how to use event table in twincat 3 to show a message.
Unfortunately not.
Great video. I hope Beckhoff is watching this channel. 👍
thx for this video (again ;-)).
My pleasure!
I have used Wago and beckhoff, I thought beckhoff was better, but it seems like Wago are pushing faster into future coding
If TwinCAT 4 is going to be in the style of C#... I can die as a happy man
Love the azure references :D
Plain text source code would be amazing.
My dreams:
1) TRY/CATCH in 64bit
2) Debug FB_init / FB_exit with debugger like other methods
3) Direct library code debugging (open source code from library and set breakpoint)
4) Arrays with dynamic length (like in Delphi for example)
5) Generics
6) Type introspection or even reflection
7) Improved working with strings (null terminated with unlimited length, simple concatenation 'str1' + 'Str2' + 'Str3')
Hope this can be achieved without new language.
And yes, StucturedText is very outdated...
One thing that is very difficult to ask from a PLC language is dynamic memory, it does have to be real time at the end of day and having static memory is a very big part of achieving it. There is __NEW() and __DELETE() to be used very carefully, but to make such things implicit would quickly run into unacceptable problems for majority of users. Best to keep such things out of real time domain.
Hear hear! Those would be some excellent features!
But what about using an existing language (C#, Python, or a functional one ;D) as a PLC programming language and not inventing and maintaining a new one?
Recently I switched jobs and had to make a CLI with Python for a camera. It was such a please to use a language which has a solid tooling foundation. Not to mention all the open source libraries which I could use to communicate with the camera. I had the whole thing running in no time.
Then I thought back about the devices which I had to interface with TwinCAT. Every time you had to start from scratch and the interfaces were often crap (bit 1 is an error, bit 2 is a warning, bit 3-8 is the rpm etc.). Not to mention Visual Studio crashing at random times or taking ages to load. It would often suggest to disable TcHMI, because it was slowing Visual Studio too much :').
Why reinvent the wheel and build a new ecosystem? PLC programming is a niche and will always be one--at least compared to general programming languages. Choose a popular language and a whole world of tooling opens up. They even support dark themes ;D.
I was contemplating the possibility to use existing language syntax. I'd love to discuss this into more depth with wider community. I started a pet project last Christmas of a transpiler that ingests C# like syntax and converts it into ST or IL. There are many details that should be sorted out in this approach. When one says C# or Python it is not just the language but also the base libraries, that for most people are inseparable from the language itself (e.g. Collections, Lists), and then there is the thing with GC that we got used to so much, but it would not be feasible PLC... now we would have the same language that would handle the memory resources differently... but may be this is not a real problem...
@@PTKu I can imagine it will cause some headaches, but it might be worthwhile in the end. Especially if it is not compiled to ST first, but directly to PLC machine code (not sure what that would be).
@@RoRu87 Sure, that would be way more efficient than transpliler... and also way more challenging.
I think issue #1 stems from multiple issues:
1. TwinCAT is heavily dependent on both Visual Studio and CODESYS. In fact, the way the project file is structured is basically CODESYS in VS format. That's why it is difficult for them to replace XML, it's basically how VS and CODESYS recognize each files and structure the code accordingly. I believe many PLC programming software also formatting their files in XML, but why? It's for the 2nd reason:
2. IEC 61131. When you are required to provide access to 5 different programming languages, and 3 of them are visual heavy (LD, FBD, and SFC), there's no better alternative than XML. XML helps the format to be universal enough to be carried over between any IEC 61131 languages, since XML is there to store data, while the visualization of the languages can be done by GUI by means of interpreting XML. If Beckhoff format their files as plain text, It's going to be very difficult to convert them from a text-heavy language like ST to something more visual like FBD or SFC. In XML, everything is just either object tags, attributes, and parents-child relations. GUI just have to render objects tags, add connections based on their parent-child relations, and fill the properties by reading their XML attributes.
I think that for version control, we should learn from Web Devs and their method of version control. HTML is just XML with standardized schema for the HTML, and they've been version controlling with git just fine. Maybe what we need is just a version of git that can understand Beckhoff's schema, not turning the whole TwinCAT upside-down and replacing XML. Although, to be honest, I hope Beckhoff can develop their own programming GUI and replace VS altogether, especially since the VS Shell have been discontinued, and we either have to shell out thousand of USD to get professional license, or stuck with old VS Shell. Plus, with TC/BSD, I think it's time they move on from VS too.
Hi & thanks for feedback. When talking about #1, I was referring to structured text (ST) and not the graphical languages. There is no reason to store the ST in XML. The markup doesn't add any value for ST (while for HTML it does).
You are right it would be nice to have Tc3 decoupled from VS. I believe the integration into VS was not a bad idea, the implementation has its issues though. One could use VS Community in many instances (that is free of charge). VS Professional subscription $45 / month with plenty of additional benefits besides VS.
I think a big issue is, that the industry hasn't even widely adopted Structured Text yet and it won't do that for years to come.
Now the problem with adding more complex language features is, that the machine code should actually be so debug-friendly and easy to understand that some skilled maintenance-electrician could fix a machine by himself while looking at the code with little to no coding experience.
If one wrote complex multi paradigm machine code in lets say C++, the maintainability of those machines at the customer level decreases dramatically (which is already the biggest problem with using ST in the first place), but you might not even have to be able to read in order to understand ladder logic for example.
Sometimes 2 or 3 generations of people have to deal with the same machine, hence also the same (type of) code. Now imagine how stressful it would be if machine-code-standards changed every year or so, it's like if everybody had to relearn coding/debugging a machine depending on which year it was built.
I've been working with twincat 2 and 3 for 5 years now, and I've wasted the most time by just getting the NC to play ball with whatever motion I want a drive to execute. It can be so insanely annoying. Take for instance NC error 427F:
"The new target position either has been overrun or will be overrun" The new target position either has been overrun or will be overrun, since until there it is impossible to stop. An internal stop command is commended.
"
This means that a new position command will result in an overrun of the old position command. For some machines, this could be bad. For many other machines, this does not need to be a problem. Beckhoff however decides this is always bad and your machine needs to stop. No warning, just an error and the axis needs to be re set. This behaviour is not warned for anywhere in the motion control documentation, you just get these 427F errors out of the blue, and slowly figure out how fucked you are.
So if this type of motion is built in in the design of the machine, you need to spend an enormous amount of time to put in a calculation that checks each and every new position commands if they could induce an overrun of the old position command. This took me an enormous amount of time, is computationally expensive and to me it is beyond ridiculous that I cannot interpret the severity of the condition myself.
This is just one example in the long long list of NC crap I've had to deal with. I get that we as programmers want to have modern tools, but our customers also want modern machines that are fast and dynamic, and if you're using the Beckhoff NC, this is not impossible, but just takes a lot of unbelievably frustrating effort.
So I'm hoping for Beckhoff to first get the NC modernized (I've got quite a wish list), before doing anything else.
Fully agree that the NC could be improved. Things got a lot better with the new drive manager 2 though!
I don't want these 4 things.... I NEED THEM 😀😥