[Feature Request]: Optimize McePosTable

[yeu-degroot]

This is about optimizing the source code of McePosTable.

In 0.1.0-beta, the program is quite large. There might be room for improvement:

• [x] Try combining state 11/12/13 into a dynamic state 11..19, where everything scales by a global constant NR_OF_INSTANCES
• [x] Remove redundant code like controlled stop
  This can be handled externally using the nPosTableMode and bWaitForStep
• [x] Make things dynamic where possible (e.g. by using FOR loops)
• [x] Remove code related to closure reference

Additional changes:

• [x] Add ACTIONID_WAIT_STEP
• [x] Add a nCustomActionID input so the user can mirror the current nActionID output number. So the bCustomeActionDone refers to the right nActionID
• [x] Transition to state 40 when resetting
• [x] Add nAbortingMode as SINT for the user to choose between a controlled or an uncontrolled stop when resetting PosTable
• [x] Rename nPostableMode to nMode
• [x] Rename nMoveStep to nInstanceNumber
• [x] Rename QAmax to QA_MAX
• [x] Test with 1 or 2 instances
• [x] Limit QA_MAX value
• [x] Increase the max number of instances to 20. Need to shift states > 20 by 10. Start motion states at 10 instead of 11
• [x] Add bUserframeDone and bToolDone temporary variable to enable motion FB
• [x] Use 1 FOR loop for tool, UF and motion FB calls
• [x] Use dynamic states in nPercentComplete mapping
• [x] Remove io.nCustomeActionID. Check CustomActionDone only if nActionID < 20
• [x] Replace the 2 in nPostableMode = 2 by a constant named PT_MODE_2

[yeu-rioual]

In the current state, PosTable can run with 2 instances up to 20. However, running the code with 1 instance needs some modifications. Do we really want to do this ?

[yeu-degroot]

Indeed it doesn't make sense to set just one instance. Let's limit it to 2 to 20.