Conversation
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.
|
Hi
|
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.
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.
Yeah, you are right, it would not be wise to do so. Ill look into a check implementation.
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.
rubenmess
left a comment
There was a problem hiding this comment.
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
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: