Skip to content

MBP-369: Slits multimaster#43

Merged
szilard-ess merged 39 commits intomasterfrom
MBP-369-slits-multimaster
Mar 25, 2026
Merged

MBP-369: Slits multimaster#43
szilard-ess merged 39 commits intomasterfrom
MBP-369-slits-multimaster

Conversation

@szilard-ess
Copy link
Copy Markdown
Collaborator

@szilard-ess szilard-ess commented Mar 4, 2026

This intends to be a tested and working version of rubenm/slits-code-multimaster.

The test was executed based on the original branch and the Confluence Page

Improvements that should be considered:

  1. Removing global variables from inside of the FB, e.g. GVL.astAxes[x], recommending the use of VAR_IN_OUT of the struct, where its passed by reference and must be asigned.
  2. Currently the clearing of the calibrated flag is inside FB_Slits with MC_Home, where homing mode is set to MC_ResetCalibration. There should be a E_MotionFunctions for ResetCalibration, to reset it through FB_Axis instead.
  3. I did not look into it to deep, but at the first glance, the necessary parameters for the virtual axes (size and centre) could be automatically set up. Maybe adding a startup state, where the parameters are updated according to the notes. The only issue I am seeing with this, if you link the wrong axes, then the parameters for them would be also overwritten. Other option is to simply check parameters and go to error state, if they are mismatching the required ones.
  4. Set the initial value of bAnticollisionEnable to TRUE, I cant really seem to find any disadvantage of it being enabled by default.

rubenmess and others added 25 commits February 26, 2026 13:38
Update soft limits to have a better understanding of the sequence. New step finish added
Aligns the FB_SlitPair with the coding style guide.
Removes unused VAR_INPUTRemoves unused VAR_INPUT.
Corrects spelling.
The original issue was, that if the MC_GearInMultiMaster has an
axis reference to the same axis, both as slave and as master, then
it throws an error. This was the case usually if the physical axis
had the id of 1, which is also the initial values of the masters.

But by commenting out these, you also block yourself from using
master3 and master4 through other means, e.g. MainVisu.
Homing of blades were not starting, it was waiting for the homing
command for either of the virtual axis.
Previously after 10 automatic error reset tries, the state machine
jumped back to error state and the automatic reset started again,
repeating infinitly. Now it should stop after 10 tries and wait
for manual intervention.
To avoid the issues with master3 and master4 matches their id with the
slave axis, we use one of the virtual axis with a gear ratio of 0.0
Sometimes while the virtual axis was stopping in time, the phyiscal
axis just barely sliped trough their own soft limits.

Adding a small marginal gap to the soft limit solves the issue.
If the slits are operational, executing a homing command on any
of the virtual masters should also initiate a homing for the physical
axes.

For a clean homing, we should reset the calibration flag of the axes,
then jump back to homing check, where the state machine takes care
of the rest of the process.
Previously fPosition was checked generally, but it should be used
differently based on the movement type we are executing.
This way the message will be displayed when hovering over the FB.

Also extended the notes with some extra information.
Anticollision have to consider that the phsysical axes are not
calibrated, and their positions cannot be assessed.
Previously bAnticollisionEnabled was not used, when the interlocks
were updated. This caused an issue, where disabling anticollision,
while the axis was interlocked, did not removed the interlock.
@rubenmess
Copy link
Copy Markdown
Collaborator

Hi

  1. That can be done.
  2. I do not get what you are trying to suggest.
  3. I would not make any auto-configuration of any axes. I think it would be good to have a check and set a warning in case of something is not right.
  4. Right now the anticollision is not doing nothing. This is part of the initial configuration of the virtual gap axis, which a softlimit <0 means no anticollision. I think this is enough. However there is a risk of collision if the physical axes run independiently (not geared). There is not functionality right now to avoid a collision. We could think about a solution for this.

Removed usage of GVL.astAxes inside the functionblock, now uses
VAR_IN_OUT of the struct, where its passed by reference and must
be asigned.
@szilard-ess
Copy link
Copy Markdown
Collaborator Author

@rubenmess

2. I do not get what you are trying to suggest.

As we talked about on tuesday, you suggested that the homing through the virtual axis is not working. I tested it and you were correct, it was not doing proper execution. It had 2 reason, when we jumped into eCheckBladesHomed state, we immediatly left it as bBladesHomed were TRUE and the bBusy signals of both of the axes were FALSE. So to get a clean new home, I added an extre step, when bHomingRequested is set to TRUE, where we clear the calibration flag. But since this cannot be done through FB_Axis with a E_MotionFunctions or any other mean, I had to add an MC_Home function block inside FB_Slits to execute a MC_ResetCalibration.

In my mind, this should be done through FB_Axis with a E_MoitionFunction or something similar and not add MC_Home to each of the function blocks that needs to reset the calibration of axis.

3. I would not make any auto-configuration of any axes. I think it would be good to have a check and set a warning in case of something is not right.

Yeah, you are right, it would not be wise to do so. Ill look into a check implementation.

4. Right now the anticollision is not doing nothing. This is part of the initial configuration of the virtual gap axis, which a softlimit <0 means no anticollision. I think this is enough. However there is a risk of collision if the physical axes run independiently (not geared). There is not functionality right now to avoid a collision. We could think about a solution for this.

Yes, thats also true. What I really meant is bAnticollisonEnabled, which is used in the latter case as you mentioned. It should be working right now, thats why I am suggestion to set the initial value to TRUE.

On startup validate the required parameters for the virtual axes.
When all parameters are valid then check state finishes with
eAllParamValid. On encountering an invalid parameter check state
ends with eInvalidParam.
If bAutoHome was not enabled, you had to do manual homing of the
physical axes. This change adds the option to request and execute the
homing of all the axes inside the slit system without enabling
bAutoHome.
After further discussion, the automatic homing feature is usually
disabled.
When the slit was operational and bAutoHome was not enabled, if a new
homing request was issued, then after the decouple and calibration flag
reset the state machine waited for a second home command execution.
If stop/halt command is issued through one of the virtual master axis
during the homing of the blades, the command should stop/halt the blades
as well.
The anticollision now stops the blades, when they are in a marginal
distance from eachother. This is safer than calculate with the
deceleration curves or cycle times to stop them as close as possible.

actInterlock renamed to actAnticollision to better convey functionality
Previously when blades were operated without the virtual masters,
propogated their errors to virtual axes, without the virtual ones
being turned on.
Copy link
Copy Markdown
Collaborator

@rubenmess rubenmess left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have reviewed it and done testing in NMX slits systems. It works according the spec. It is ready to be merged
Documentation in confluence needs to be updated

@szilard-ess szilard-ess merged commit d12bfa6 into master Mar 25, 2026
2 checks passed
@szilard-ess szilard-ess deleted the MBP-369-slits-multimaster branch March 25, 2026 10:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants