CodeSys Import/Library

[MatthewReed303]

Hi There,

This looks like a great project. Will you have similar functions compared to PLC Open Motion? I have been looking through the code to find the Beckhoff library but can't find it, I understand it's not complete yet. How can I import into Beckhoff Twincat to test and then export via PLC Open XML to test with CodeSys and a Raspberry Pi?

I have custom motor drivers (Odrive Robotics and Simple FOC) but they don't support industrial protocols such as CANopen CIA402 etc I would like to use and do some motion control projects at home with them and this looks very promising. I take it I can just map the required variables straight to my drives without using proper axis configs and Axis_Ref etc? Here is a Reddit link I made earlier regarding trying to create a custom Axis_Ref. https://www.reddit.com/r/PLC/comments/p38o1s/plc_open_motion_control_axis_ref_structure_codesys/

Will it be possible to do sync/coordinated motion? Maybe even read G-Code for a simple 3axis pick and place gantry-type robot? How is Encoder Actual position feedback handled? Can motion be paused/halt and stopped etc? Sorry for all the questions, just wondering what the plans and future of this project?

Thanks,
Matthew

[stefanbesler]

Hi @MatthewReed303,

With this project I want to bring trajectory generation into the PLC world with open-source code rather then relying on properitary PLCopen implementations by manufactures as Beckhoff or Codesys. The library will "only" take care of calculating position, velocity, and acceleration for up to 6 sychronized moveable axes. For the actual movement you have to switch the drives that you are using into a mode, where they expect data to be send to it cyclically and then send the generated data (e.g,) to it over the bus (e.g. EtherCAT).

I usually try to avoid ncmotion, because I don't like that it doesn't utilize the computation power of drives at all. Most drives can do trajectory generation themselves just fine with operation modes (profile-position, profile-velocity) and for most cases, where no synchronized movement is required, I use operation modes (e.g. to move from A to B with 1 axis).
When finished, I plan to use Struckig for cases, where I can't rely on the profile-position mode of CiA402, because of synchronized movement. Here, I intend to utilize the cyclic-position mode of CiA402. Once switched to this mode, I cyclically send position to the drives. The additional information about velocity and acceleration I use as feedforward for velocity and current, respectively.
I do not think that it is possible to implement your own AXIS_REF and use the Codesys Functionblocks with it, but I could be mistaken ... However, from what I understand, my use case applies to you as well. I am pretty sure that your drives offer some kind of (hopefully well documented) protocol, which allows you to

• do an error reset
• enable the drive
• stop the drive
• send a position to the drive cyclically (~ CiA402 operation-mode: cyclic-position)

If your drives support these actions then there is nothing really in the way to test this library. The trajectories that this library can calculatd will totally work fine for a 3-axes pick-and-place application.

Regarding the usage of this library in codesys I have to say that at the moment I am using a Beckhoff Library (Tc2_System), which probably won't work in Codesys. However, this dependency is only required for monitoring the performance, because I want to implement a Benchmark for the library - I use Tc2_System.GETCPUCOUNTER to test how long trajectories take to compute. When I do the first release I want to get rid of this dependency to make the library directly installable on Codesys as well.
For now, to test this library in TwinCAT or Codesys you would have to compile it yourself - I will provide some documentation on this in the future at this location (https://stefanbesler.github.io/struckig/). And I also want to officially release the Struckig.library at some point. However, since I will be quite busy the next 1-2 months with other stuff, here a short description on how you could try it out in the meantime.

For TwinCAT

• Open the solution and right click the Struckig project
• In the context menu choose "Save as library and install ..."

For Codesys (not tested)

• Open the solution with TwinCAT
• Either remove the Tc2_System reference (manually for now) and delete the references to cpucounter.
• In the context menu of the Struckig project choose "Save as library ..."
• Install the library in Codesys

You could also export to PLCopenXML and then import it in Codesys after removing the references to Tc2_System. For synchronized movement of axes you can have a look at the Example04_2DoFs_Synchronized_Waypoints_2, where 2 axes are moving from (x1, y1) to (x2, y2) such that they arrive there are the same time. I do not plan to implement anything regarding G-Code as I am not very familiar to it. Motion can be paused or halted by updating the trajectory at any time, just make sure to switch the control interface of the ÌnputParameter to InterfaceType.Velocity and supply TargetVelocity = 0 for all drives.

Please keep in mind, that I am not done with testing the implementation more thoroughly and haven't actually field tested it.
I also gladly look into Pullrequests if you find some issues yourself or something like that ...

Cheers,
Stefan

[MatthewReed303]

Hi Stefan,

Thanks for the detailed explanation. I have run the examples you provided and they all work. I have successfully imported the library into CodeSys with no errors. I'm still yet to test it as I'm trying to work out how it all works. I have noticed the OutputParameter FB is a Var Input type? I have noticed there are a lot of other FBs/methods throughout, are these all used internally for the trajectory planner or other functions and options?

I have noticed you have to call an update, Is this update to execute a new move, or needs to be updated cyclically? Can the current position and velocity be used from the motor feedback encoder? If I want the moves to be done within a certain time rather than trying to get there as fast as possible, how can this be done?

Do you have a brief description of which FB does what and the minimum requirements to use these? I would like to optimize the FBs to be used with visual programming, CFC, etc, I don't want to take up to much of your time until you have time to do the Docs but just some info on setting up a simple PtP move from A to B with a set time with a max velocity limit? ( stepped move ) and then a continuous move between different points with different times between these points.

If I was to pause motion with the above method would it come to a stop in a controlled manner with deceleration or an instant stop?

Can multiple instances of this FB be used without too much impact on the system? Such as driving and syncing come conveyors and then sync them to the XYZ robot?

I can figure out the protocol side of things for my drives as they are custom and use low-level Canbus (No CANopen or anything like that). I will provide some information when I do this and how I have done it in the future if you're interested.

Thanks,
Matthew

[stefanbesler]

Yes, I have yet to cleanup the code such that only stuff is visible from the API that should be. Most of the methods and function block is only used internally - actually most of the points you are asking are things that are still on my list of things I have to do (documentation, refactoring, benchmark, performance optimizations)

Brief description how to use it

Here a short description, which I hope helps you a bit.

• You have to instanciate the function blocks as it is done in the examples. You need Ruckig, InputParameter and OutputParameter
• InputParameter is used to parametrize the trajectory. Initially you should supply the values from the encoder here for CurrentPosition. If starting from stillstand I would not bother to set anything from the encoder(s) to CurrentVelocity or CurrentAccelerarion.
• After this initial setup you have to call ruckig.update in every cycle and after the method call assign the current values of the outputparameters to the current values of the input parameters if you just want to keep moving. Also you have to send at least CurrentPostion to your drives (or CurrentVelocity if you have an open loop axes).
• Movement is „finished“ if the trajectory arrived at the specified target values. If you parametrized target velocity or target acceleration to be unequal to 0 you still have to call the update method. The Update method returns a state, which can be polled to test if the movement is finished.
• If you want to change the trajectory you can change the target values, control interface, Synchronisation type (…) of InputParameters at any time. ruckig.update then „sees“ that the trajectory has to be recalculated.
• If you want to stop at any point you have to set the control interface of the InputParameters to „Velocity“ and set the target velocity and target acceleration to 0 for all axes. (This option has not tested by me so far, not by hand and not with unittests).

Visual programming

If you want to use this with visual programming the update method probably has to be called from the FB body, I never use visual programming. I am happy to here your insights on this if you get this working…

Time-based movement

The feature you are asking for is not available so far. At the moment the trajectory planner is calculating the fast possible profile for every axis individually. Then the movement is synchronized by recalculating the profiles of all axes that are not the one with the slowest profile to match the duration of the slowest. Should be quite easy to implement this feature in the future, I will write an issue for that. In the meantime you would have to calculate a maxvelocity that corresponds to the duration that you would like to achieve. E.g.: s = <v_mean> * t; for 100mm in 10s use v_max=5mm/s

Performance

I have yet to implement a benchmark, sorry I actually do not know much about how multiple instances affect performance. Also performance optimizations are still on my list of things I have to do (see README.md). For a glance on how this algorithm performs you can have a look at the original code of the project, which is written in C++ - but keep in mind that the C++ implementation will very likely be faster then my port. Simply because C++ has a much better compiler and optimizations then the codesys compiler. Also the C++ code is implemented in a way that it can benefit from such optimizations a lot. I hope to get somewhere near to a factor of 10 in worse performance of this implementation to the original one.

btw. Once the trajectory is calculated, updates are not costly at all. Only changes to the trajectory InputParameter will cause „spikes“.

[Danielxyz123]

Hey, the cpp implementation is able to do time based movement by setting a minimum duration time. So it should be easy to use..?

[stefanbesler]

@Danielxyz123 yes you are right, I totally forgot about that feature. I will implement some tests for it to see if this works correctly in the port.

[stefanbesler]

@Danielxyz123 & @MatthewReed303 the feature wasn't working correctly, fixed with 7c7800d

Now setting MinDuration is working as expected