epics-modules / ecmc Goto Github PK

When operating in velocity mode, the softlimits are disobeyed.
At passing the respective softlimit, an error is raised, e.g. ERROR_MON_SOFT_LIMIT_FWD_INTERLOCK, but the axis is not stopped.
However, after manual intervention, the axis is block in the direction of the violation. So in general the limits are operation, have no effect during a move.

commands like this will create an 'unknown command' error.

ecmcConfigOrDie "Cfg.EcAddSdo(${ECMC_EC_SLAVE_NUM}, 0x8018, 0x1, 1, 1)"

Is it possible to remove the whitespaces in the parser?

Currently the product ID is provided by ecmccfg via the variable ECMC_EC_PRODUCT_ID .
Only a single ID can be specified per script. However, some slaves are virtually identical, I.e. EL1008 and EP1008-0002 or EP1008-0005. For those slaves it would be beneficial to provide a list of products in the instantiation script. The ECMC sanity check at configTime would have to check whether any of the reported IDs matches the Array provided.
The scripts would become generic, e.g. EX1008.cmd to cover all of the above mentioned terminals.
This would also reduce the number of substitution files. As of now, each slaves need it's own.

Since ECMC is able to operate w/o the motorRecord, a means to limit the maximum velocity should be available.

So far, it's possible to catch high velocity violations only via monitoring, which is nice, but always throws the axis into an error state.
The new feature should reject velocity setpoints above the specified upper limit.

If SPMG is set to Stop or Pause when a new setpoint is issued, DMOV drops to 0, but returns to 1 even though the commanded position isn't reached.

Expected behaviour:
With a new setpoint being issued, the DMOV has to transition to 0 and stay there. Only after the setpoint is reached, or the setpoint is set to a value within the "at target" interval, the DMOV should return to 1.

Reasoning:
A valid setpoint is accepted but the target isn't reached. Thus, the move isn't done. Hence, DMOV must stay 0.

Affected version:
v7.0.6

tested on Debian 10 with ECMC v7.0.0

@javicereijo noticed a bug in ecmc brake handling. Two similar scenarios:

• If, for some reason, the drive, is not enabling when receiving an enable command the brake will open anyway since it is triggered on the enable command edge (low to high).
• Maybe same case actually.. The motor is enabled, then loses enabled , then the brake will not engage since enable cmd is high.

Decision after discussions involving @javicereijo, @kivel, @anderssandstrom was:

• Let brake command be triggered by enabled status instead of command. Start delay counter at rise of enabled status instead of command.
• If enabled status is lost the brake need to engage (without wait for standstill).

@anderssandstrom

This proposal is to share a testbed hardware configuration (BOM, and others). It may boost several projects that want to see how the entire system works together.

I am sure ESS has the plenty of examples for motion application (maybe only one axis) and sampling environment. At this part, I can resume my previous work for the EtherCAT master and real-time Linux configuration as well.

The current handling of under/overflow is not in sync with TwinCAT.
This causes critical issues when switching between controllers.
Also the operational range of devices will be impaired as the full range of the encoder cannot be used. Or at least not in a intuitive way.

Two examples:

1. A device needs the approx. 4000 of the available 4096 multiturns of an AM81xx motor for full stroke. Before gearing in, the device is moved to the neutral position (0) and the motor is positioned at 2048 revolutions. With TwinCAT, this system will always recover from power loss with a valid position.
2. X-ray mirrors are often equipped with very high resolution encoders that need the full information depth. I.e a 50 mm stroke with a 1 nm, 26-bit encoder. With ECMC, such a system will report wrong positions after a restart of the EtherCAT hardware if the system was in the upper range of the encoder. This is not intuitive as engineers are used to under/overflow handling at the lowest and highest value of the encoder, not mid range.

I strongly recommend to change the under/overflow handling in ECMC to make it identical to TwinCAT.

[Not sure if this is the right place to report this, but for some reason https://github.com/EuropeanSpallationSource/motor repo has issue reporting disabled.]

When I try to use HVEL field of the motor record from https://github.com/EuropeanSpallationSource/motor it does not seem to have an effect on the speed of movement when homing (write 1 to HOMR) is initiated. The motion towards the home position is always slow.

Add support for multiple encoders to the axis object. At least 2 should be supported.

Why?
Twincat allows multiple encoders.. :)

This is with NTM==1

• Case 1: Motor moves 0-->100, user enters '0' again
  result, Motor stops but does not go to Zero.

• Case 2: Motor moves 0-->100, user enters '50' (motor is at 25 at this moment)
  result, Motor stops at 51 (slight overshoot) but does not move to 50.

To me it seems as of the MR is calling the 'stop' but not issuing a new move command.

Current situation

The atTarget-flag of the axis is set to true even when the axis was stopped by a limit switch. Thus, not reaching the desired target.
Also, the setpoint is synced to the readback after ramping to standstill, which is not desired.

requested changes

• set atTarget only when the actual target is reached
• prevent setpoint from synching to actualPosition when stopped by limit switch.

So far virtual and physical axes are named identically ax<id>. This makes it hard to tell them apart in PLCs.
By separating each type into its own namespace and easier management of axes is achieved, i.e. for axes added later in the development process.
Ideally it would be possible to name the axis with arbitrary names instead of ax<id>.

The application will time out when attempting to enter OP-mode with DC slaves at low cycle rates <200 Hz.

Currently, the time jitter on the master PC might interfere with locking the DC clocks.
optimizing the rt-performance, in order to minimize jitter did not yield any improvement.

So far, parameters like powerAutoOnOff=2 can only be used with the motorRecord.
In case ECMC is used w/o the motorRecotrd, these features are not available.

IOCs forward linking from ${IOC}:MCU-updated freeze once the value reaches 2.147.483.647.
After manually resetting the forward linked PV, the IOC recovers, but the value of the cycle counter (MCU-updated) is negative. Thus pointing towards an overflow.
Can the cycle counter be migrated to a 64-bit integer?