Motion Control and Motor Drives

cancel
Showing results for 
Search instead for 
Did you mean: 

How does SoftMotion recognize an Axis in an EtherCAT XML?

Dear all

 

The NI SoftMotion module comes with examples for inverters from AKD or Yaskawa which are working nicely. The XML files specifiy the RxPDOs and TxPDOs for the EtherCAT communication between the controller (e.g. CompactRIO) and the inverter driving the axis motor and the AKD and Yaskawa drives can be defined as SoftMotion axes.

 

We have our own inverters (Baumueller Bmaxx 44xx) and an XML file describing all the RxPDOs and TxPDOs for EtherCAT communication with this inverter type connected do our axis motor. The EtherCAT slave is correctly auto-detected, based on our XML file.

 

But, when trying to define an axis, in SoftMotion, our inverter/drive is not listed among the available axis bindings. Why?

 

What exactly has to be in the XML file that makes SoftMotion interpret the XML file as valid axis definition?

 

Any advice would be very much appreciated! Would anyone have a clue?

 

Many kind regards in advance!

 

Cheers, Markus

0 Kudos
Message 1 of 8
(7,590 Views)

Hi Markus,

 

First, let me clarify a few points. SoftMotion only has native support for the AKD EtherCAT drive. All other EtherCAT drives require you to write a SoftMotion interface. For example, someone wrote an interface for a Yaskawa drive, which can be found here. This will show up as an unbound axis in your project.

 

To use your EtherCAT drives, you would have to write a similar interface. If you open the project from the above link, you will find a VI called Axis Interface. This is the VI that reads and writes PDOs from SoftMotion to the EtherCAT drive. You will have to modify this example so that it will work with the PDOs from your drive. I'm not familar with your drive, so I don't know how easy or difficult this will be, but the Axis Interface VI provides a good framework.

 

Thanks,

0 Kudos
Message 2 of 8
(7,562 Views)

Dear Paul

 

Many thanks for your reply!

 

So you are saying that the AKD interface is hard-coded in LabView?

 

I looked at the example you provided and all the code in there seems to be rather generic, apart from some files under the Dependencies, e.g. the IOVariableReferences.ctl, or the interpretation of the control and status word, which are drive specific.

 

It is not clear to me, what I would have to do in order to write a "similar interface".

 

And I still have not understood, how LabView knows, that the XML file I just loaded under "Import Device Profiles" is a drive type (AKD) for which LabView happens to have a piece of special software.  The information should be somewhere in the XML.

 

"Unbound" axis means to me, that LabView does not know how to send the commands to the drive. It must be possible to bind a generic drive specification to an axis definition.

 

Couldn't I e.g. change the XML file of my 3rd party drive so that it pretends to be an AKD drive (and behaves like one), because all the input/output registers of the AKD are also present in my system.

 

Many cheers

 

 Markus

0 Kudos
Message 3 of 8
(7,549 Views)

Hi Markus,

 

The AKD axis type is hardcoded into SoftMotion. In other words, you will never have the ability to add a Yaskawa axis or Baumueller axis because those axis types don't exist. Even if you are able to trick LabVIEW into thinking that your drive is an AKD (which you could probably do with the XML) and all of the SDOs and PDOs are the same as the AKD, it still wouldn't work since interally, we do things that are specific to the AKD state machine. 

 

The only option is to use the SoftMotion eCAT Drive example as a framework for developing an interface for your particular drive. While this code is specfic to a Yaskawa drive, it shouldn't be too difficult to modify to work with your drive. Here are the things I would do:

 

  1. In the AxisInterfaceMulti_Init_eCAT_IO_Vars.vi, you will have to change the names of the PDOs to match those from your drive. You might have to add some PDOs or remove some PDOs. You also might have to change the data types of the shared variables.
  2. In the AxisInterfaceMulti_eCAT_IO_Var_Data.vi, you will read/write values to the PDOs. When you call the Read Data (DBL) method, you are getting data from SoftMotion (things like trajctory data, axis I/O, etc) and when you call the Write Data method, you are writing data back to SoftMotion.
  3. In the AxisInterfaceMulti_Close_eCAT_IO_Vars.vi, you will want to make sure you are closing all of the variables that you created.

These are the basic steps for modifying the example. The first thing you will have to do is make sure that the right I/O variables are appearing in the LabVIEW project. When I imported the XML file for your drive, I only got two variables: Inputs-statusword and Outputs-controlword. This won't be enough to use your drive. I actually don't know enough about EtherCAT to tell you how to expose more variables, but if you are having trouble, you can try posting to the Industrial Communications board.

0 Kudos
Message 4 of 8
(7,541 Views)

Dear Paul

 

Again my sincere thanks for your advice.

 

So far I adapted the ...Init and ...Close VIs and the Control and Status definitions. As I see it, the AxisInterfaceMulti_eCAT_IO_Var_Data.vi deals with the adaptation of the inverter specific control parameters to the axis interface. I am still struggling with this, but I am on the way 🙂 You were right, my setup had only two fields, but this was only to strip it down to a minimal case. I added some more fields by now.

 

The AxisInterface.vi is the main loop which contains a timed loop for synchronous communication. The 

 

As I see it, the XML file is not really used for communication, but only to import and create the EtherCAT slave devices. The slave device is finally identified by its index and all the communication goes through the AxisInterface adaptation. Is that correct?

 

The nice Axis properties dialog cannot be used with any other inverter than AKD or the NI 951x modules, right?

 

Thanks again and many cheers

 

 Markus

0 Kudos
Message 5 of 8
(7,512 Views)

Hi Markus,

 

I'm pretty sure you are right on both questions.

 

Paul, would you happen to know for sure?

Michael B.
Applications Engineer
0 Kudos
Message 6 of 8
(7,501 Views)

Hi Markus,

 

You are write that the XML configuration file is not used for communication. You need it initially so that the master knows how to communicate, but once you've imported it, you're done.

 

You can use the Axis Properties dialog for unbound axes, but you have to write the implementation yourself in your VI. When using a 951x or AKD, SoftMotion sends the axis properties to the hardware without you needing to code anything. With your EtherCAT drive, you can read any of the axis properties by using an axis property node. You can right click on an axis on the block diagram, select 'Create >> Property Node' and you will see a list of properties. These are all of the properties that you set on the Axis Configuration screen. You can read any of these and then manipulate the data format so that you can send it to your drive. It is not native support like the 951x or AKD, but it will allow you to use the Axis Configuration dialog.

 

Thanks,

0 Kudos
Message 7 of 8
(7,483 Views)

For all of the goobers out there like me trying to figure out these ether cats.

 

1. the xml file is imported once into the project after  you add the ethercat master.  It simply provides handles to the ethercat variables such as position, position setpoint, torque... etc...  For my particular motor, JVL MAC800, it only provides for 5 read and 5 write variables, the functions of which are configured into the motor by a setup program provided by JVL.  After the import if you start a new project on this controller it will automatically detect and add the motor(s) to the project.

 

2.  If you are using a motor, such as the AKD one that is blessed by NI then after you create an axis in the project you can "bind" or select it and thats that.  All ethercat variables, such as position and setpoint are being handled by a hidden axis routine somewhere above in the RT heaven.  However, if you are like me and choose the motor partly because of its great packaging, then you have to select "unbound" and must also write that axisloop vi.  In your new vi you will use the ReadData and WriteData invoke nodes as a window into the inner workings of softmotion.  The ReadData in part has the trajectory and or pid loop outputs that you can scale and write to your ethercat variables, while from the ethercat position variable will be written out to the WriteData invoke nodes.  There are other items in both, such as limit switches and enables and the like, but  basically this is where you handle the data from your ethercat variables.

 

It is pretty straight forward once you get past this.  Getting the error handling details down is maybe the most confusing to me.

0 Kudos
Message 8 of 8
(7,040 Views)