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.