|Power Supply||Does the Everest XCR offer a dual power supply input?|
Yes, Everest XCR could be powered using a single or dual supply input (logic & power).
Using a dual supply with low logic voltage allows reducing power consumption of the driver. More info here.
|Can I power on the servo drive below the minimum supply voltage?|
No, the minimum recommended power supply voltage for Everest Series is 12 VDC. When the drive supply voltage falls below 8 VDC, an under-voltage fault will stop the motor and the communications will be lost and drive reset.
|Can I power on the servo drive above the maximum supply voltage?||No, the maximum continuous power supply voltage for the Everest series is 80 VDC. It could handle short peaks of 85 VDC for 100 ms as well. Given the regenerative braking of many applications, it is suggested to operate at a lower voltage such as 72 VDC.|
Does the EVE-NET require us to use an external 5 V supply to power logic?
|Yes, Everest NET requires a power supply input of 5 VDC for logic and able to provide 200 mA.|
|Power Stage||Is the 30/60 A of the Everest the RMS value?|
No, the current specification is DC continuous current. Everest is able to drive current which corresponds to the crest of the sinusoidal current. Please read Disambiguation on current values and naming for Ingenia Drives. Note that the 30 A limit is basically a thermal limit on typical conditions but, with a good thermal design and dissipation it is possible to achieve 30 ARMS.
|What is the efficiency of the drive at rated conditions?||The efficiency of the Everest could be higher than 98 % including logic under the following conditions 80 V, 30 A @ 20 kHz PWM|
|What is the standard power consumption of the drive?||Everest Net standby losses are around 2.2 W. Everest XCR has a losses of 2.5 W. Details can be found on the product description.|
|What is the resolution of the current sensing of the Everest?||Configurable from 2.475 mA/count to 0.379 mA/count|
What is the maximum current that the Everest can ‘rectify’ from the 3 motor power phases back onto the DC bus when it is off?
|Everest can handle up to 20 A continuously when is off. Conduction through the "intrinsic diodes" is not very efficient. If you need higher current add external low capacitance, high current rectifying diodes.|
Does this rectification take place through the FET body diodes, or do the FETs turn on in this operating mode?
The GaN technology we use has no intrinsic diodes but a "diode like behaviour" when off. From functional point of view they will behave like diodes but with a big (> 2 V) forward voltage drop.
|Is there any current limiting available for this regenerative braking energy?|
No, currently does not have this feature, when the drive is disabled, the regeneration through "intrinsic diodes" is passive.
Do you recommend a common-mode choke between the Everest power stage and the motor being driven? If so do you have guidance on part selection?
If the choke is mounted on wire the part numbers on the manual of the Everest XCR can be used. Further info here.
If the current is not very high, PCB mounted 3 phase, common mode chokes are strongly encouraged. Choose a part number that offers 10ths of ohms of impedance between 20 MHz and 100 MHz. Laird technologies has part numbers that work pretty well
|We might prefer STO behavior to turn on braking rather than go zero-torque. Is this possible?|
Not by design. However, if you need this feature we would recommend implementing the following circuit in your interface board.
The "Forced Off input" should:
1) Disconnect a fully overcurrent protected load switch that disconnects the power supply to the drive.
2) Disconnect the STO lines so the power stage is off.
3) Activate a low-value shunt resistor & transistor that "short" the DC bus after disconnecting the DC bus. Add some hardware delay.
Is STO behaviour programmable (i.e. between full-braking or no-braking?)
|No. The STO behaviour is always disconnecting the power stage transistors. It is a hardware-only feature with absolutely no intervention or modification by software (for safety and reliability reasons). The status of the STO can be read by registers.|
|Can the servo drive cold start-up at -40ºC?||No.|
|What is the operative/storage temperature range of the Everest?||Operation -20 to +85 ºC. Storage -40ºC to +100 ºC|
|Communication||Does the Everest support USB or Serial Communications?||Everest Series only provides CANopen, EtherCAT and SPI (MCB) communication interface right now. However, a customized can be developed on demand.|
|Does the Everest support Ethernet TCP-IP?||Yes. Everest XCR & NET provides communication using standard Ethernet TCP (deprecated) / UDP.|
|Does the Everest support Ethernet/IP communications?||Not as a standard product. However, a customized (firmware only) solution can be provided.|
|What is the EtherCAT latency or delay?||Everest XCR latency is 2 cycles. When running the EtherCAT bus at 4 kHz this would involve a delay of 500 µs.|
|What happens if the EtherCAT cable is disconnected during operation?||The Everest XCR includes a protection that stops the motor after 1 ms if the EtherCAT cable is disconnected.|
|Is the Everest CiA-301 and CiA-402 compliant?||CiA-301, CiA-303, CiA-305, CiA-306 and CiA-402 (4.0) compliant|
|What CANopen transceivers are compatible with MotionLab3 and the Everest?|
Examples of proved, compatible transceivers:
|What is the maximum update rate that can be achieved with the SPI communication protocol? How does this update rate depend on the number of controllers on the bus? Also, what is the latency between sending a current setpoint and actually processing that setpoint?|
The maximum frame rate of the SPI communication depends on the Position/Velocity Update rate. By default, the drivers comes with 20 kHz update but you can configure it to 10 or 25 kHz as well. Please, notice that the final update rate strongly depends on the capacity of the master to handle the IRQ signal coming from the driver and also the time that it needs to process it and send a new frame. Any delay on this processing would directly affect the resulting update rate.
Connecting more than one driver to a single Master could be done by sharing the same SPI bus or using one SPI for each drive (Check the documentation https://doc.ingeniamc.com/display/SS/Protocol+description).
Regarding the delay between the reception of a new set-point and its processing, it could be up to one Position/Update loop (1/20 kHz by default).
|Motor||Can the Everest XCR handle voice coil and linear actuators?||Everest XCR is focused on rotary motors, Brushless and Brushed. Voice coils and linear actuators are currently not supported.|
|What types of motor temperature sensors does the drive support?|
Everest supports the following 2 wire motor temperature sensors: NTC, PTC, Linear Voltage Sensor, RTD, Silicon-based Sensor or Switch sensor.
|Feedbacks||How many feedback devices can I connect to the Everest?||The maximum number of feedback that can be read at the same time is fixed at 4. They can be used for commutation, reference, velocity, position or for auxiliary monitoring.|
|Can the Everest XCR handle BiSS-C bidirectional encoders?||Not yet but we are working on that improvement which should be available on Q1' 2020.|
|I see that there is a limitation for BiSS-C encoders that the Everest can handle. Can you develop on these limitations?|
Everest can read Single-Turn (ST) and Multi-Turn (MT) data from encoders using BiSS-C BP3 profile.
The maximum position data, which includes both ST and MT bits, is limited to 32 bits and the maximum frame size is limited to 64 bits. Everest is able to process Error bit, Warning bit & CRC fields (6 bits) of BiSS-C frame.
In the case of BiSS-C daisy-chained connection, the maximum total bit of both frames is also limited to 64 bits. Due to that limitation, the maximum position data for each sensor will be limited to 24 bits (32 bits for each BiSS-C - 1 bit Error - 1 bit Warning - 6 CRC)
We are working on increasing the maximum frame size to 128 bits.
|Can the Everest XCR read absolute encoder other than BiSS-C or SSI?|
Everest XCR hardware is ready for any absolute encoder based on RS485 physical interface, however only BiSS-C and SSI protocols are implemented right now.
In case your application requires other feedback support like Nikon-A, EnDAT, Panasonic or other please contact us.
|Can I use Absolute Encoder 2 input to read BiSS-C encoders?||Secondary input only accept SSI feedbacks, however, if you need to read more than one BiSS-C device you can daisy-chain and read them using Primary input.|
|Can I connect any BiSS-C encoder in daisy-chain?|
In order to use daisy-chain connection, the encoder must include a BiSS Data Input signal. Not all BiSS-C includes this signal.
For example, the iC-MHM sensor from iCHaus allows this configuration.
|Can you provide one or more approved SSI references that you know are compatible with your drives?|
We would suggest some manufacturers of SSI encoders with proven compatibility with our drives:
|What is the maximum frequency that the incremental encoder stage of the drive can read?||50 MHz. 10 MHz recommended.|
|Assuming that I choose the same position data bits, should I go with a BiSS-C or an SSI encoder?|
In general, BiSS-C is a more robust, faster and standard protocol however the final decision will strongly depend on your needs.
BiSS-C is a standardized protocol which defines the frame format, include some bits to signal warning / error situation and includes also a CRC to validate the data. The maximum clock frequency could reach up to 10 MHz or more and even include a signal delay compensation to work properly with long cables. Being standard allows you to swap from one manufacturer to another without big effort.
On the other hand, SSI is not standardized and each manufacturer provide its own frame implementation which sometimes include specific bits and / or CRC but sometimes only provide the position data. Each feature will need to be checked and implemented specifically for that provider. The maximum clock frequency stays in the 1-2 MHz order and does not include delay compensation. None of this limitation implies that the SSI is a bad option if you don't need them.
|Control||Does the Everest support FOC commutation?||Yes|
|Does the Everest have a triple-loop (position > velocity > current) scheme?||Yes|
|What is the update rates of the motion loops of the Everest?||50/25/25 kHz for current/velocity/position loops|
|What is the maximum frequency that the encoder stage of the drive can read?||50 MHz. 10 MHz recommended.|
|Can we define the frequency of loops separately or if define current loop freq to 60 kHz, the servo loop become 20 kHz automatically?|
Consider we are running motor in velocity mode at 1 rpm. Ideally, we need velocity error 0%, which practically not possible but to get min. velocity error %, what should be SSI encoder resolution & what is formula to calculate it?
For SSI encoder, what is best clock cycle freq we need to select.
Basically, we need to run the system (drive + SSI Encoder) at same clock cycle to get better performance or response. Or advice what should be servo loop we need to set and what should be clock freq. of encoder we need to set.
|Does the Everest have dual-loop (motor and gearbox) support?||Yes|
|When Everest is powered down completely, and the connected permanent magnet motor is spun – what is Everest behavior? Are the phases open-circuit? Is there any protection from overvoltage if motor RPM climbs high enough? Or are phases short-circuited?||The Everest behaves as a full bridge 3 phase rectifier. The DC bus voltage will rise according to the peak value of the motor back-EMF. If this value does not exceed the maximum absolute ratings of the drive or interface board electronics (80 V) it will be "fine". The feeling will not be of a braking motor, but rather a free-wheeling once the bus has been charged.|
|Input / Outputs||How many GPI/Os does the Everest have?||Everest Core, Net & XCR includes 4 digital inputs and 4 digital outputs. The voltage level differs between the different Everest version.|
|On the Everest Net, the digital inputs are 3.3 V logic level and are not listed as 5 V tolerant, but the STO inputs are. Are they not 5 V tolerant?||Correct. The digital inputs are not 5 V tolerant, however, STO inputs could handle it.|
|Can I use the analog input for torque sensor purposes? What are their purposes?||Right now, the analog input only reads the voltage and propagates the information thought the communication interface. In the future, we are going to use this information to close a torque loop inside the driver.|
|Does shunt only become active when motor is 'braking' or is it always active?||The shunt output (that can be configured by registers) can be mapped to a GPO and depends ONLY on the value of the DC bus voltage. Has no intelligence, just a voltage comparator. As you know the Everest NET has no shunt transistor embedded.|
|Can the braking resistor be de-activiated over the CAN interface, if desired?||Yes. Take a look at here to understand how to configure it.|
|What is the accuracy (or tolerance) of the braking shunt activation circuits in Everest?||Better than 2%|
|Command Source||Can the Everest drive work in standalone mode?||This capability is not yet available for the std product. Please, contact us if required this feature.|
|Can I do any programming into the Everest drive?||This capability is not yet available for the std product. Please, contact us if required this feature.|
|Can I use the analog input as command source with the Everest?||Everest XCR includes an Analog input but it is thought to be used as Torquemeter input.|
|Software||Does the Everest come with a configuration software for initial commissioning?||Yes. Everest product line is compatible with MotionLab3 which provides a set of tools to configure and validate the commissioning of the system.|
|Does the software have auto-tuning capabilities?||Yes. MotionLab3 includes a Current, Velocity & Position Auto-tuning system.|
|What Operating system requirements do I need to fulfill in order to use MotionLab3 properly?||MotionLab3 is only compatible with Windows 10 64 bits. We are working on Linux integration.|
|Installation||What is the purpose of the case of the Everest? Is it only for heat dissipation purposes?||Heat dissipation and protection of the interior PCBs|
How hard is it to remove and install the heatsink? A better mounting option for us is to use the screws going from the top of the PCB, through the Everest heatsink, into the enclosure. We don’t need threaded holes for that, so we are thinking of drilling out the threaded holes in the Everest heatsink to 2.7 mm ID.
Everest XCR housing cannot be disassembled nor modified as standard option.
Details on the recommended front installation could be found here. Ingenia could provide the Flat heatsink option upon request.
|Standards / Certifications||Is STO of the Everest certified?|
Not yet, we are working on the certification.
|What Temperature standards does the Everest meet?|
IEC 60068-2-1: 2007-03 - Cold (Operational) test
IEC 60068-2-2: 2007-07 - Dry heat (Operational) test
IEC 60068-2-78: 2012-10 - Damp heat, steady state (operational) test
IEC 60068-2-38: 2009-01 - Composite temperature / humidity cyclic (operational) test
|What certifications does the drive have?||RoHS, CE|
|Customizations||Can I change the power connectors of the Everest for a pluggable terminal block?|
If you require this kind of modification, the best way to proceed is by developing a specific interface board.
You can do it on your own using EVE-NET and the application guide or if you prefer we can do it.
|Can I modify the shape of the housing of my Everest? Can I remove any material without damaging the circuitry inside?||No, the housing of the Everest cannot be removed nor disassembled. Please contact us if you require customization.|
Is there a minimum time that I have to wait between a WRITE request(Initiate Upload) and READ request(read upload)?
When I Initiate a Download(write to SDO) do I need a READ request to follow so that the Read mailbox is cleared for the next write request?
|What derating does the drive have?|
0 kHz ~ 100 kHz PWM frequency
|When Everest is powered down completely, and the connected permanent magnet motor is spun – what is Everest behavior? Are the phases open-circuit? Is there any protection from overvoltage if motor RPM climbs high enough? Or are phases short-circuited?|
|Does shunt only become active when motor is 'braking' or is it always active?|
|Can the braking resistor be de-activiated over the CAN interface, if desired?|
|What is the accuracy (or tolerance) of the braking shunt activation circuits in Everest?|
I have a few questions related to the online brake resistor documentation at Dimensioning a shunt resistor for regenerative braking:
I have some questions regarding response times when sending commands via the CAN interface:
|The analog input of the Everest Net is +/- 3.3V for torque sensors. We have 0-5V sensors that we need to integrate to and will be grounded to the same reference that the motor controllers are. Is it possible to change that to a single ended 5V ADC like are used for the motor temperature input? With or without NRE.|
|How can I access the MCB registers through CANopen?|
|Which is the the maximum pressure that Everest can withstand?|
|Is it possible to use the dedicated motor temperature input as a sensor input that is not included as motor control feedback or over temperature safety.|
|Will I be able to drive a BLDC motor with hall sensors at low speeds with the Everest?|
|I see the Everest drive can handle low inductance motors, have you got a reference value for the minimum inductance it can handle?|
|Up to what electrical frequency can the Everest servo drive handle?|
|Does the Everest have gain scheduling as a feature?|
|· Can the status of the analog inputs be read from the CAN bus?|
|Do you have some ideas how to make deasy chaining for power? We do have 6 axis robot. Can you recommend some special connectors, you’ve already used?|
The power conception for sensors is: 5 V 200 mA total max. Pins 1, 9, 14 are internally connected.
We do have 1x Aksim absolut with 150mV and, Roll In incremental with 170mV. Total 320mV.
If we use digital halls in addition, it will take even more power! Right? How to solve this? Do you have some ideas?