These posts focus on controlling intelligent precision electric motors from Windows applications written in C#. Specifically, we will be controlling a Schneider Electric M-Drive stepper motor with an integrated encoder and controller.

Posts in this Series

Discussion

Once your motor is connected to the PC with the RS422 cable, you will need some sort of software to communicate with the motor. Any terminal emulator will do. Schneider offers their own free IMS Terminal program that works fine but does occasionally lock up. Beyond that, there are features I want that are not in IMS Terminal. The obvious solution was to create my own program, called, well, MDrive. Source code for MDrive is freely available at https://mdrive.codeplex.com/.

This post then is a discussion about the MDrive application I wrote – both how to use it and some notes about how C# code was written. Don’t forget to reference this invaluable MCode document which is the official guide to the various commands the motor accepts.

Connection

When the MDrive app starts up, it scans the PC for a list of available comports. It finds all the comports associated with the Schneider USB to RS422 cable, the single port XS890, and the four port UTS-M14. The comports are listed in the upper left corner of the app. To select a comport, click on it. Once a comport is open, MDrive sends the following commands to the motor:

PG ‘ exits program mode (if needed)
E ‘ ends any running programs
EE=1 ‘ enables the encoder
SL 0 ‘ stops movement
ER=0 ‘ clears errors
ST=0 ‘ clears stall
PR AL ‘ get all parameters
L ‘ get program listing

The motor can be placed into “program mode” by sending the command “PG 1”. If the motor just connected to is in program mode, then sending other commands will just be appended to the program being created on the motor. That is why the PG command is sent. It terminates programming the motor. Very conveniently, if the motor is not in program mode, nothing bad happens by sending a “PG”.

Now that we are assured that the motor is out of program mode, we end any program that may have been left running on the motor with the “E” command. Very conveniently, if the motor is not running a program, nothing bad happens by sending an “E”.

The “PR AL” command sends the value of most every parameter back to the computer. The resulting stream of parameter-value pairs is nauseating to watch on a terminal emulator and Schneider’s IMS Terminal. MDrive parses the data stream and places each value in its own neat little box in the center of the app.

The “L” command retrieves the listing of any program that might be stored on the motor. MDrive captures the program listing and places it in an editable, scrollable window on the right side of the app.

In summary, connecting to a motor fills in the MDrive app with the current values of various parameters and displays the current program stored in the motor.

Parameters

All of the parameters that I personally feel are important are displayed in the middle of the app. As mentioned above, the parameter values are retrieved from the motor upon connection. In addition, if the “Poll” checkbox is checked, then MDrive will query the motor every two seconds to update the values. This is especially handy if the motor is moving, so that you can watch parameters like “P” and “V” without having to keep typing in “PR” commands.

You can also type a new value into each of these boxes and that value will be immediately sent to the motor. For example, to set acceleration to 2000, type 2000 in the “A” box. Compare this to IMS Terminal where you would type “A=2000” at the command prompt. This simple feature can save a lot of time and headache when troubleshooting.

Some of the boxes are not parameters, but rather commands. For example, the “SL: Slew” box always shows 0. Typing in a number (like 4000) causes the motor to immediately begin slewing at a velocity of 4000. If polling is active, then you can watch the other parameters continue to change. Compare this to IMS Terminal where you would type “SL 4000” at the command prompt, followed by incessantly typing “PR” commands.

Program

The current program listing is displayed in an editable, scrollable window on the right side of the app. As mentioned above, the program listing is retrieved from the motor upon connection. In addition, clicking Read will retrieve the program listing from the motor again. Clicking Send will transmit the program to the motor. Clicking Run will start running the program on the motor. Clicking End should stop program execution on the motor.

The editable scrollable window supports copy and paste. Use some other means (like Notepad) to save a copy of your program listing to a file on your computer.

Nuances

The protocol suffers from a lack of an end-of-transmission code. It is very difficult to know when the motor is ready for the next command. It would appear at first that looking for the prompt character “>” is all that is needed. Things get a bit more complicated when you realize that the prompt becomes a “?” whenever ER is not 0. To further muddy the waters, when entering program mode, the prompt become a number (memory location) with spaces before and after it. Finally, when listing a program, the output can contain many characters that could be considered a valid prompt. All this leads me to believe that Schneider would have been better off to clearly define an unchanging end-of-transmission / ready for command protocol. These nuances are captured in the various regular expressions found in ComViewModel.cs.

The “PR AL” command causes the motor to send a series of M=N lines. For example “P = -123”. However, for variables that are global or local, a prefix to the variable is sent. For example “X1 = G –123”. This prefix is not documented.

On page 3-5 of the MCode document, Schneider suggests that user variables should begin with the letter “Q”. They say, “… we have used the following example labels because the beginning alpha character is not used in any instruction set mnemonic … User variable label (Q) ....... Example: Q3, Q9, Qz.” Unfortunately, Schneider recently added the command “QD”. It would seem Schneider would be better off using a prefix for user variables, like “_” or something.

The MCode document clearly states the following on page 3-5. “Please note that the maximum length of a single line of program code is 64 characters, this includes program text, spaces and comments.” What is not clearly stated is that if you exceed 64 characters, your motor enters the world of berserk mode. It appears to be a buffer overrun error in the motor firmware. Also, you will find that if you retrieve a program listing where one of the lines exceeds 64 characters, random other lines are altered. Moral of this story… keep your comments short. It would make sense for me to enforce this rule in the MDrive app someday.

The “PR AL” command does not return the value of O1, O2, O3 and O4. This is a shame. Also, it is sad that the command O2=O2^1 does not toggle the value of O2. I think the O parameters were implemented by a different programmer at Schneider.

Source Code Discussion

I still need to write this section …

Source Code

Source code for MDrive is freely available at https://mdrive.codeplex.com/.

MDrive – Part 3 of 4