RMP & INtime Nodes (single-core & multi-core licenses)

RMP 10.7.0, INtime version 7.1.24270.1

Hi community,

I would like to ask some questions regarding RMP with INtime nodes pertaining to the single-core & multi-core licenses in INtime (apologies as my understanding is limited on this)

As per my understanding, an INtime multi-core license enables you to create multiple nodes to assign a core to each node:

  • You can then deploy/assign tasks to multiple nodes which allocates a processor core for that specific process

Eg. If I have 40 axes and would like to spread resources between them evenly:
Would it be possible for RMP to be segmented into multiple INtime nodes instead of just NodeA in a multi-core license?

  • that way we would be able to utilize more cores to perform RMP tasks for the axes to improve performance instead of only using one core in NodeA
  • Like 10 axes running on NodeA, 10 axes running on NodeB and so on…

or

We would have to acquire 4 different RSI Licenses (10 axes each) + 4 USBs to achieve this?

  • Then each USB RSI instance would have to occupy NodeA, NodeB, NodeC and NodeD
  • I’m not sure if this would work or not as you would then have to plug in 4 different USB dongles

**If this is possible, can it be done with RapidCode and/or INtime SDK

tl;dr Would it be possible to assign RMP to run on more than 1 core?

Thank you and your help is much appreciated.

1 Like

Hi @gregory,

RMP (The Motion Controller) works within a single core and has a single RMPNetwork (EtherCAT network) associated with it. You can’t currently split the RMP over different cores.

You could run multiple RMP instances on different INtime cores. Each would have its own RMPNetwork and associated NIC for communicating with the network. This wouldn’t include any coordination between the groups unless you did the lifting at the application layer (a possibility).

So you would have
1 Intime Multicore license/usb
4 isolated Cores, RMPs, RMPNetworks, & Nics.

Is this an effort to save on PC cost or is there another goal in mind?

Hi jacob,

I see, thank you for the clarification on this. And thank you for the advice/suggestion on running multiple RMP instances. As for coordination between the groups, this might require interprocess communication between the nodes?

And for generating ENI files for the RMP instances, how does RapidSetup know which instance we are setting up for, does that mean there will be multiple ENI files?

We would like to try to mitigate some slight performance issues as there has been fluctuations and slight delays in the cycle time and also spikes in the firmware time (%) - controller.ProcessorUsageGet()

As lately the inconsistency and delays in the cycle time (up to 200ms) is becoming frequent and the firmware time (%) will sometimes spike up to high numbers ( > 100%), hitting the max CPU usage.

Your help and feedback is much appreciated, thank you!

Hi @gregory,

I would use RapidSetupX over RapidSetup as it lets you specify the Intime Node Name (e.g. NodeA, NodeB etc). You would have unique ENI files for each of the 4 networks. Each would be working out of their own separate folders.

I would investigate the computer you are running on if you want to improve performance. We spend a lot of time researching the industrial pcs we sell to ensure they are reliable. Trying to split out the processes is likely going to cost more engineering time than you’d save on specing/testing a pc that can hit your performance goals. I don’t think setting up a coordinated multi-node/network setup is going to easy. We’ve tested it out, but don’t have anyone currently doing something like this. In practice, I think its better to address the spikes at the hardware level.

What PC are you using? Do you have a TPAT jitter report for it? What is your axis count and sample rate. You can improve performance on any given PC a lot with proper tuning. I’d start with here.

Hi @jacob,

Just wanted to clarify on whether the following method is correct for creating multiple RMPNetwork instances:

  • This is for using a single PC to control multiple RMPNetworks where each network does not have interprocess communication between them
  • Main reason for this is to run separate modules (which each have their own axes) on different RMPNetworks so if one module/RMPNetwork goes down, the others will still be running fine unlike if all of them are grouped in one network, all the other axes stop running when the entire RMPNetwork shuts down if one node fails

Test setup and configuration

  • 1x Multi-core INtime dongle
  • 1x IPC with multiple NICs
  • 2x INtime nodes
  • 2x RSI Installation paths (C:\RSI\X.X.X\ folders) – Both have same rsi.lic
  • 2x RMP networks (RapidSetup) and RMP controller instances

A NodeB is created with the same configuration as NodeA (512mb, 50us kernel clock rate etc.) but passed with different NICs.

There are 2 RSI installation folders which represent the multiple controller instances.

In RapidSetup.exe.config file for filepath “C:\RSI\11.0.5 - B”, the parameter for INTIME_NODE is set to NodeB.

After completing the configuration, RapidSetup and the RMPController instances are able to run independently on their respective INtime nodes:

  • RMP 11.0.5 – A starts on NodeA
  • RMP 11.0.5 – B starts on NodeB

The separation prevents conflicts between the two controller instances as each controller operates on its own INtime node and NIC

  • If one RMPNetwork goes down, the other network remains Operational
  • No interprocess communication exists between the networks and they do not have visibility into the status, devices or processes of one another


May I know if this is the correct way to create multiple RMPNetwork/Controller instances on a single PC with a Multicore dongle?

  • Or there will be any complications that may arise from creating multiple RMPNetworks this way without using RapidSetupX to specify the node

Your help and clarification on this is much appreciated. Thank you!

Hi @gregory,

Yes, I believe this will let two different processes like RapidSetup/X to work at the same time. Unfortunately, I don’t think this will work currently for a single process/application instance as RapidCode creation methods are going to return the first MotionController created each time. The current RapidCode singleton returns the first created controller, so creating NodeA then NodeB in the same process does not create two independent controllers.

We are currently approaching a solution for this in two directions. Working along the lines of this post, we are testing with a branch which has enhanced MotionController creation and attachment logic. This would allow your application to create MotionControllerA and MotionControllerB with respective nodes and networks. You wouldn’t be able to have any MultiAxis objects between them though.

We are also working towards SyncUnits and other features which allow Nodes to fall into error or completely disappear while allowing the rest of the network to continue in operation as long as possible. This seems like the better solution to lower application development costs, but is going to take longer to get right. We have to make sure the diagnostics, recovery, and tools are available to protect a partially functioning machine and anyone operating it.

1 Like

Hi @jacob,

Much appreciated on the explanation and clarification. Noted on the controller instances as we did saw that selecting the controller number was in the works in the API documentation.

Sorry that I’ve forgotten to clarify that I tried using RapidCode as well for the 2 RMPNetworks listed above and they seem to be working as intended when I call different controller instances to get their associated RMPNetwork based on their RmpPath and Node:

The programs are as shown below for a simple test to retrieve data from the RMPNetwork:
For controller/RMPNetwork in RmpPath 11.0.5 - A

MotionController.CreationParameters cp = new MotionController.CreationParameters();

cp.RmpPath = @"C:\RSI\11.0.5 - A";
cp.NodeName = "NodeA";
MotionController controller = MotionController.Create(cp);
CheckErrors(controller);

StartTheNetwork(controller);

Axis axis = controller.AxisGet(0);

Console.WriteLine("[" + DateTime.Now.TimeOfDay.ToString("hh\\:mm\\:ss") + "] Product from 11.0.5 - A: " + controller.NetworkNodeGet(1).ProductNameGet());
Console.WriteLine("[" + DateTime.Now.TimeOfDay.ToString("hh\\:mm\\:ss") + "] Axis position from 11.0.5 - A: " + axis.ActualPositionGet().ToString("F8"));
Example Output
[09:10:33]  Product from 11.0.5 - A: Fuji Alpha7
[09:10:45]  Axis position from 11.0.5 - A: 1.00123000

For controller/RMPNetwork in RmpPath 11.0.5 - B

MotionController.CreationParameters cp = new MotionController.CreationParameters();

cp.RmpPath = @"C:\RSI\11.0.5 - B";
cp.NodeName = "NodeB";
MotionController controller = MotionController.Create(cp);
CheckErrors(controller);

StartTheNetwork(controller);

Axis axis = controller.AxisGet(0);

Console.WriteLine("[" + DateTime.Now.TimeOfDay.ToString("hh\\:mm\\:ss") + "] Product from 11.0.5 - B: " + controller.NetworkNodeGet(0).ProductNameGet());
Console.WriteLine("[" + DateTime.Now.TimeOfDay.ToString("hh\\:mm\\:ss") + "] Axis position from 11.0.5 - B: " + axis.ActualPositionGet().ToString("F8"));
Example Output
[09:11.22]  Product from 11.0.5 - B: MOONS STF06-ECX
[09:11:30]  Axis position from 11.0.5 - B: 10000

May I confirm whether the following architecture is expected to work without issues, or if there are any known limitations or conflicts we should be aware of?

  • Eg. 2 different projects/programs creating different controller instances from different RMP filepaths (different folders) and different INtime nodes
  • Or an architecture like 1same project but creating multiple controller instances from different RMP filepaths and INtime nodes

Much appreciated on the clarification for this. Thank you!