Is it possible to create an Axis that works through an IO link encoder?

Hello,

Is it possible to create an Axis that works through an IO link encoder?

I want to use this to create axis coupling between an IO link encoder (master) and a servo motor connected to an B&R Acopos drive (slave).

image

1 Like

I see 3 options…

Disclaimer: Please be aware that the pictures are not runing configurations. They only show the locations of the settings!

1.) Use External encoder axis with a “Encoder on network”
The Axis reference can then be used to couple via MC_GearIn or similar functions.
Configuration on ACOPOS

Selection of the Datapoint via Channel selection. All Input-Datapoints of the Hardware Tree can be used.
image

2) Transfer the IO-link encoder Position to Acopos
Use a Parameter Table to Enable the VAR_SPT Functionblock
Send the Position via MC_BR_CyclicProcessParID_AcpAx to a VAR_I4+0
Use the alternative Value Source Axis-Feature
Couple with MC_GearIn to the Alternative Value Source

3.) Pure Virtual Axis + General Purpose Axis Interface

Pure Virtual Axis - General Purpose Axis Interface - External Encoder

The PureVirtualAxis with enabled General Purpose Axis interface can also be used to configure an external Encoder.

Greetings
Michael

1 Like

Hello Michael,

Thank you for your respond, it was very useful. I’ve tried option 3 trough the pure Virtual Axis. The variable I use is from the program cycles not the direct IO channel. I’ve used this one because of shift register I’ve to use to be able to use only the 16 last bits of a 32 bit string from the IO-link signal. The position is working so far in mappCockpit. The PureVirtualAxis with enabled General Purpose Axis interface can also be used to configure an external Encoder. (see figure 1)

There’s only one problem the velocity is fluctuating. I think this has to do with the slow cyclus time of the IO-encoder 3ms and the slow cyclus time of the program 2ms. My question now is, how is the velocity calculated in the pure virtual axis? Is that done every 2ms or every 400us? I suppose that the Acopos is running it’s program/tasks every 400us. (see figure 2)

I’m not sure but maybe you I could be able to fix it with the position filter option. I’ve only no idea what kind of values I’ve to fill in in those boxes? (see figure 3)

The way with option 3 is a good one, with your Explanation. :slight_smile:

The Cycle Time for the PureVirtual Axis (which is calculated on the PLC) is the mapp Motion Processing Task class. If there is no Configuration used, default is “TC#1”.

In the Documentation of the General Purpose Axis Interface i could not find any details about the Filters jet. I personaly did not use it up now. You may also have a look your own.

The calculation of the Velocity will be a numerical deviation in TC#1 "Velocity = (Pos-PosOld)/CycleTime

What i found is the Filter Documenataion for an ACOPOS External Position, i think it will behave similar.

If you make a Trace with mapp Cockpit you can use these Datapoints for the External Encoder Axis to see the Influence of the Filters. The “actual Position” will be the raw Value, and the “Postion” and “Velocity” are the Filtered Values.

If the Data is send to the ACOPOS for the Coupling, it will be send with PLK Cycle. The ACOPOS Position Controller is running in 400 µs, to adapt the values, the Firmware uses an Interpolator Functionblock in the ACOPOS. For some functions you can set up the mode, for some (like GearIn) not. But i think it will be there.

If needed you can make a Trace on the Communicated Data ParID of the ACOPOS. But the used Number has to be read out of the DriveLog.

Greetings
Michael

2 Likes

Hello Michael,

Thank you again, your feedback was very useful. The IO-link encoder is kind of working so far, but still not ideal. Through the filtering the position is slipping away as soon as I turn off the shaft, because of the filter that allows the position to go a little further every time. At constant speed the velocity value stays stable.

In my opinion the cycle time of the IO-link encoder with 3ms, the program cycle time of 2ms and the Acopos cycle time of 400us is not ideal.

The IO-link encoder I was using is the Turck RI360P0-QR24M0-IOLX2-H1141. I found out that Turck has also an alternative for the IO-link encoder the Truck RI360P0-QR24M0-HESG25X3-H1181. This encoder works wit SSI communication that is also supported with the Acopos drives from B&R.

In the meanwhile I’ve been connecting the encoder at the Acopos (see figure below). The Encoder only uses an external power supply of 24volts. The grounds are connected together.

In the B&R hardware configuration I’ve added an synchronous motor to be able to get into the encoder settings of channel one. There I’ve configured the Encoder so far with the SSI-protocol. Currently I’m receiving signal from the Encoder, I’ve to turn the shaft multiple times to let it changes a couple of degrees. That’s not what it is supposed to be (360 degrees should be one turn). I think it has to do with bit order that is provided from the Encoder and the bit order how it has to be received from the Acopos. Maybe you can give a better explanation of the SSI frame configuration of the Acopos? Now I’m also receiving an error in the mappcockpit (type ‘Feature reference’ is not valid for ACOPOS Axis) -1067448310

Regards,

Niels

Hello Michael,

I’m not able to upload several figures, so in the figure below you can see the bits configuration of the Turck encoder and the settings for the encoder in the Acopos. In someway these must match.

Greetings,

Niels

Hi Niels,

According to the last images you sent, I believe that the bit positions are set incorrectly.

Leading zero’s = 9 (3 diagnostic + 6 multiturn)
Position bits = 16
Trailing zeros = 0

Also make sure to doublecheck the encoder configuration. A lot of things could go wrong there.

Kind regards,
Juul

It is true that the Timings and Connection to the PLC is not an optimal setup.
Having an Encoder directly connected to the ACOPOS will make it a lot easier in the topic of timing.

image

If you have a half deleted Feature you can have here “black empty” fields. This is the most common error. If you delete a Feature the line must be “greyed out”. If its black and empty its an error.

This would be a correct empty setting.

This would be a error setting

I am not an Expert for SSI Encoder Konfiguration and i am a little busy, hope you can solve this or an other Member can help. I think Jull Ermens had allredy a good suggestion.

Greetings
Michael

Hello Juul,

Thank you for your reply. My interpretation of the order of the bits was incorrect. I also thought the last two status bit options would be count for 2 bits. Anyways the encoder is functioning now :smiley:

Greetings,

Niels

Hello Michael,

Thanks again for your support! I see that I accidentally clicked on some of the axis features. After deleting the Axis feature the error is gone.

Thank you,

Niels

1 Like