enable axis from C#

Forum: Motion Control RMCLink
1

Hello,
Trying to enable the 0 axis on the RMC70 (using rmc70.deltamotion.com).
Shouldn’t this code work:

[code]private void btnEnableAxis0_Click(object sender, EventArgs e)
{
try
{
int[] cmd = new int[2];
cmd[0] = 97; // command: enables or disables a single axis
cmd[1] = 1; // 0 -> disable, 1 -> enable

	rmc.WriteLFile((int)FileNumber70.fn70ParameterAxis0, 0, cmd, 0, 2);        
}
catch (ReadWriteFailedException ex)
{
	disconnectButton.PerformClick();
	MessageBox.Show("Exception: " + ex.Message);
}

}[/code]

No exceptions are thrown - but the “Move to set point” function doesn’t work until I enable it via RMCTools.
I’m just working off the sample “RMCLinkBasicUI”.

Thanks,

Skippy

2

The code indicates that you are trying to send the Enable/Disable Axis (97) command. All this command does is allow the axis to accept motion commands. Until an axis is enabled, it will not accept motion commands (except Direct Output). This command will not run a user program. Does the Event Log in RMCTools show that this command is being received?

If you want to start a user program, use the Start Task (90) command.

3

I understand the purpose of the ‘97’ command… perhaps my post did not provide enough detail.
Let me start over.

I downloaded and installed the "RMCLink.NET Assembly and Active X Control (for 64-bit Windows).
(deltamotion.com/files/rmclinkinstall64.exe)

From that installation I obtained the sample C# program located at “C:\Program Files\RMCLink\Samples\VC# 2008\BasicUI”.
The solution is named “RMCLinkBasicUI.sln”.
Using the URL: “rmc70.deltamotion.com” with the project code, I compiled and ran it but with only partial success.

The app did connect and when “Update Status” was clicked - values were obtained and displayed.
However the “Move to Set Point” functionality resulted in a popup window displaying a message about the Axis not being enabled.

Hence my addition of a new button to enable the axis. (See code of my previous post.)

As a sanity check I used the RMCTools IDE to connect to the same remote simulation (i.e. rmc70.deltamotion.com), and with that tool I enabled the axis.
Then I tested the “Move to Set Point” button again on the sample C# program. It worked as expected.

So the question remains, why couldn’t I achieve the same result using the code from my original post?

It should be easy enough for someone to duplicate these steps and verify it one way or another. As long as they “leave” the axis in an un-enabled state before testing the sample program.

4

Use WriteFFile instead of WriteLFile, and use FileNumber70.fn70CommandArea instead of FileNumber70.fn70ParameterAxis0. That should fix it.

And the Event Log in RMCTools is a great troubleshooting tool. It would have alerted you to the fact that the command was never received. You can also change the filter settings in the Event Log to show every read and write, and then it will report the address and length of each read and write.

5

I appreciate your timely responses and help. But your comments don’t complete the picture for me.

Why FFile instead of LFile? What is fn70ParameterAxis0 used for then?
Is there a detailed API that might provide more insight then the chm files included in the installation?

As for the EventLog of RMCTools - we are planning on accessing the RMC and integrated sensors through an HMI built with C#.
Correct me if I’m wrong - but in this scenario there would only be the single dependency on the dll ‘RMCLink.Interop.dll’.
Are you saying that a C# app with that dll dependency is somehow integrated with RMCTools through the dll?!

I think you are still seeing this as an exercise from the perspective of using RMCTools to access the unit.
Certainly RMCTools can benefit during development and debugging but our end goal is a C# app with a single dll dependency.

6

Thank you for your suggestions, Jacob. Regarding the RMCTools Event Log, I see now how useful it is.
By connecting to the RMC with RMCTools AND with the C# program simultaneously - I can watch events happen that originated from the C# app.

As it turns out, ‘WriteFFile’ wasn’t necessary. ‘WriteLFile’ worked fine. But I did need to change the one parameter to ‘fn70CommandArea’.
(I’m assuming ‘fn70LrgCommandArea’ would have also worked but haven’t tested it.)

I just want to describe my endeavors in case it assists others:

From RMCLink Address Map for the RMC70

File | File Constant | Description
12 fn70ParameterAxis0 Control Axis 0 Parameter Registers
…
16 fn70CommandArea Command Area - Small
Element | Register Name
0 Axis 0 Command
1 Axis 0 Parameter 1
…
6-11 Axis 1 Command Registers

The “element” corresponds with 2nd parameter to Write(F/L)File

public void WriteFFile (int file, int element, float[] data, int offset, int count)

My revised code:

[code]int[] cmd = new int[2];
int element = 0; /* 0 for axis 0 (0-5)
* 6 for axis 1 (6-11)
*/
cmd[0] = 97; // command: enables or disables a single axis
cmd[1] = 1; // 0 -> disable, 1 -> enable

// To target a different axis, change the ‘element’ variable
rmc.WriteLFile((int)FileNumber70.fn70CommandArea, element, cmd, 0, 2);[/code]

Part of my confusion stemmed from the use of “file number”.
We have the enum FileNumber70. And from that we get a sub-enum
fn(file number) of whatever, to place in the “file” parameter.
(I think your enums should be renamed.)

I’m still don’t know how FileNumber70.fn70ParameterAxis0 (enum for 12)
would be used… but at least I can enable/disable a specific axis now.

Thanks for the help!

7

Skippy,

Glad you got it working. The F file and L file stems from the Allen-Bradley style addressing of the registers in RMC, in which registers within the F file are 32-bit floats, and registers within the L file are 32-bit signed integers. Any register in the RMC can be addressed as either F or L. Typically, you would use F for floating-point values, and L for integers. I guess C# must have the data types strict enough that using the WriteLFile with a float still preserves the bits of the floats and the write comes through properly.

The addressing in the RMC is a two-level scheme, which we call file and element. Address F8:0 is a floating point with file 8, element 0. The enumerations we have are mostly for the file number. So, rather than writing to a cryptic address of F25:0, which would show up as 25, 0 in the WriteFFile or WriteLFile method, it can be a bit more readable as FileNumber70.fn70CommandArea, 0.

If we were to completely redo RMCLink now (which we aren’t), we would probably call the WriteLFile and WriteFFile something else. The addressing of registers in the RMC used to be heavily biased toward the Allen-Bradley method. Each register in the RMC can be addresses in multiple ways, including Allen-Bradley, IEC 61131 (two-level with the same file and element numbers as the A-B addressing), Modbus (single-level), and FINS (single-level). This allows an external PLC to see the RMC as another PLC. We are going away from A-B centric addressing, although the A-B addressing will of course always exist.

The enumeration FileNumber70.fn70ParameterAxis0 would be used for reading or writing axis parameters, which in many applications is not needed.