Advanced Search

In case of the delta servo drives , if you are using the A2 series , if I'm not mistaken they have a dedicated port for gantry control.

www.deltaww.com/en-us/FAQ/2076

I just spent *way* too much time debugging a multi-device CiA 402 problem, only to discover that I was doing distributed clock configs wrong in my XML file because I didn't really understand it.  Of course, we don't actually seem to have any documentation on correct values for dcConf anywhere, so I had to spend an hour or so researching the topic.

It looks like neither RTelligent nor Leadshine CiA 402 devices will work in CSP mode without distributed clocks enabled properly.   To review a bit, this is controlled by the per-slave <dcConf> tag in our XML file, which has 5 parameters:

• assignActivate
• sync0Cycle
• sync0Shift
• sync1Cycle
• sync1Shift

After digging into things, it looks like assignActivate should simply be set to whichever value is recommended in the device's ESI file.  Generally, this will be either 0x3xx or 0x7xx, and xx will be 00, 10, 20, or 30.

sync0Cycle seems like is should pretty much always default to "*1", which is our servo time period.  It's possible that really unusual hardware will want a different value here, but "*1" seems pretty sane as a default.

sync0Shift seems to vary widely in sample configs, but I suspect that 0 would be fine most of the time; this shifts the sync0 interrupt by some number of ns, which presumably reduces jitter slightly.

sync1Cycle and Shift are basically the same as sync0, but not all devices use sync1.  Ones that do sometimes set it to "*1" and sometimes to a small multiple like "*3", for every third servo cycle.

Given all of this complexity, is there any reason not to set dcConf by default in device-specific CiA 402 drivers?  For instance, I have a driver for RTelligent stepper and servo drivers.  Every single RTelligent device that I can find an ESI for says to use 0x300 for assignActivate.  So, if dcConf isn't explicitly set, I can add an implied <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0" sync1Cycle="*1" sync1Shift="0"/>.  It's possible that we don't want sync1 set, or want it set to a multiple of the clock time, but that's easy enough to handle on a device by device basis.  I'm not going to do this for unknown CiA 402 devices, but we can probably capture the bulk of known devices pretty quickly.

Anything that I'm missing here?  Is there anything subtle with shift times?

I'll go ahead and add all of this to the LCEC documentation soon.

On the pendant, as cornholio 'recommended', avoid usb/wireless and/or anything else that sounds fancy. Pendant *must* be hardwired to the motion control for integrity (and safety, ofc). Paramount importance, and the fundamental reason why professional industrial solutions remains wired and forever will.

wifi/usb pendants are okay for changing channels on the tele, namely a remote control. Volume up/down, etc. NOT for machine-tools.

My hope with a USB pendant was that I would avoid the 20+ hair like wires that come out of them. They are all I have used as they are compatible with anything. I do draw the line at the lack of an E-Stop button. I agree that having the pendant tied down is more reliable.

I was also hoping that new builds were moving to EtherCat, and that it was the recommended path. A little more costly maybe but working well without having to worry about which servo I picked. I would like to have feedback from the servos. I have purchased things in the past that were not compatible with Linux and have learned to watch out for compatibility. I have used the Servo To Go card the Motenc card the parallel port my own ISA cards Arduinos, blue and black pills for motion control. I have never used EtherCat, and would like to hear form someone that has. I would like to hear Yes, it is as great as it sounds, EtherCat is a standard, any EtherCat servo should be fine, it is working well, I would never go back, I would recommend it to my mother. OR something like I am a better person now, but it was painful.

My interest in the Raspberry PI is it's compactness. I do see that EtherCat is not working on the PI 5. I do see that the PI works with the Ethernet Mesa cards. I was wondering if there was a consensus that a proper PC is still the best option, or if the PI4 and now PI5 is evolved and supported enough that there is no reason to allocate the space in a cabinet to a PC. I have used PI2/3/4s, not the 5 yet. I would think the PI5 should be great.

I'm not trying to build anything fast, or that can hog material. My interest in the servos is just that they have become so cheap.

I have spent at least several hours reading the LinuxCNC site in the past couple of days. I have checked out LinuxCNC many times over the years, and I think I finally have a great opportunity to use it.

It seems the WHB04B-6 pendant has no estop button. I see the VistaCNC pendant does. I would feel better about having an E-Stop. I hesitate to use the word recommended, but is there a "recommended" USB pendant?

Thanks for your help.
I have searched.
I would like to know from people who have gone before, recently. Would they recommend what they have done? Would they do it differently? I have gone through the EtherCat discussion. Would anyone who has experience with that recommend that? I did see that Dela servos were recommended. How critical is that? I did see that they recommended a standard. It has been hard to make verify that a product meets any specific standard. Would it be way simpler to get a pulse driver board. The hardware documentation section is from 2008 as far as I can see. There is plenty of discussion about technical detail, but no "This is the best practice in 2024". Go this way grasshopper.

I see you haven't tried the search function.
forum.linuxcnc.org/forum/search?query=re...before&childforums=1

Hi Everyone,

I have looked for recommended hardware and have not found much. If I have missed a big section, please let me know

I need to build a 3 axis mill as some parts I want to build won't fit on what I have. I have a fair bit of experience with this sort of thing, just not LinuxCNC. I could go to a friend, but I would like this capability.
I would like to know what the recommended control hardware is for low risk/headaches. 
I would like to use EtherCat. I have never used EtherCat. Is this a bad idea? What should I watch out for in a Chinese EtherCat servo, any recommendations? I see the RaspberryPI 5 is not ready for EtherCat. Is the RaspberryPI4 OK? Should I just use a PC? What should I watch out for on an Intel PC motherboard?
If not EtherCat, what? I do not want to depend on the PC for the real-time pulse generation. I do want home switches, and a few relays.
The USB pendant I see the most documentation on is the WHB04B-6 CNC wireless handwheel. I want something USB, as I would like to avoid all the wiring from a traditional pendant. Is this pendant well supported? The most supported USB pendant? Is there a cabled version? 

Any recommendations appreciated.

Look you are going to need to post the hal & ini files.

Check the address of your Mesa card, the documentation of your card contains this info, this documentation can be downloaded form the Mesa sight.
Make sure the mesa card and computer do not have the same address.
Check you cables.
Only have a cable between the mesa card and the pc no hub\switch\router or any other exotic hardware.
An USB to Ethernet device is not recommended to connect the computer & mesa card.

But the hal & ini files are important.

Here is the report file.
I store the python and macros folder as Aciera told.

Error report created by /usr/lib/tcltk/linuxcnc/show_errors.tcl:

Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.8.4-1-gb7824717b
Machine configuration directory is '/home/der/linuxcnc/configs/katinaki_12_probe'
Machine configuration file is 'katinaki_12_probe.ini'
INIFILE=/home/der/linuxcnc/configs/katinaki_12_probe/katinaki_12_probe.ini
VERSION=1.1
PARAMETER_FILE=linuxcnc.var
TASK=milltask
HALUI=halui
DISPLAY=gmoccapy
COORDINATES=XYYZ
KINEMATICS=trivkins coordinates=XYYZ kinstype=BOTH
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Starting HAL User Interface program: halui
Found file(REL): ./katinaki_12_probe.hal
Found file(REL): ./custom.hal
Starting TASK program: milltask
Starting DISPLAY program: gmoccapy
(0, ' = ', '/usr/bin/gmoccapy')
(1, ' = ', '-ini')
(2, ' = ', '/home/der/linuxcnc/configs/katinaki_12_probe/katinaki_12_probe.ini')
Entry = trivkins
Entry = coordinates=XYYZ
found the following coordinates xyyz
Entry = kinstype=BOTH

**** GMOCCAPY GETINIINFO **** 
Number of joints = 4
4 COORDINATES found = xyyz
('Fount double letter ', )
joint 0 = axis x
joint 1 = axis y0
joint 2 = axis y1
joint 3 = axis z
{0: 'x', 1: 'y0', 2: 'y1', 3: 'z'}

**** GMOCCAPY GETINIINFO **** 

[KINS] KINESTYPE is trivkins
Found kinstype=BOTH but using trivkins
It is not recommended to do so!
Will use mode to switch between Joints and World mode
hopefully supported by the used <<trivkins>> module

**** GMOCCAPY GETINIINFO **** 
No MAX_RAPID_OVERRIDE entry found in [DISPLAY] of INI file 
 Default settings 100 % applied!
**** GMOCCAPY GETINIINFO **** 
Preference file path: /home/der/linuxcnc/configs/katinaki_12_probe/katinaki_12_probe.pref
**** GMOCCAPY GETINIINFO **** 
 No DEFAULT_SPINDLE_SPEED entry found in [DISPLAY] of INI file
**** GMOCCAPY INFO ****
**** found valid probe config in INI File ****
**** will use auto tool measurement ****
**** GMOCCAPY INFO ****
**** Entering make_DRO
axis_list =
**** GMOCCAPY INFO ****
**** Entering make ref axis button
('Filepath = ', '/usr/share/gmoccapy/images/ref_all.png')
('Filepath = ', '/usr/share/gmoccapy/images/ref_0.png')
('Filepath = ', '/usr/share/gmoccapy/images/ref_1.png')
('Filepath = ', '/usr/share/gmoccapy/images/ref_2.png')
('Filepath = ', '/usr/share/gmoccapy/images/ref_3.png')
('Filepath = ', '/usr/share/gmoccapy/images/unhome.png')
**** GMOCCAPY INFO ****
**** Entering make touch button
**** GMOCCAPY INFO ****
**** Entering make jog increments
**** GMOCCAPY INFO ****
**** Entering make jog button
**** GMOCCAPY INFO ****
**** Entering make joints button
**** GMOCCAPY INFO ****
**** arrange JOINTS button
Found 8 Joints Button
**** GMOCCAPY INFO ****
**** Entering make macro button
found 0 Macros
**** GMOCCAPY INFO ****
**** arrange DRO
3
**** GMOCCAPY INFO ****
**** Place in table
**** GMOCCAPY INFO ****
**** get DRO order
**** GMOCCAPY INFO ****
**** arrange JOG button
less than 6 axis
**** GMOCCAPY INFO ****
**** Invalid embedded tab configuration ****
**** No tabs will be added! ****
**** GMOCCAPY INFO ****
**** no audio available! ****
**** PYGST libray not installed? ****
**** is python-gstX.XX installed? ****
**** GMOCCAPY INFO ****
**** Entering init gremlin ****
Kinematics type changed
('_set_enable_tooltips = ', True)
**** GMOCCAPY INFO ****
**** No virtual keyboard installed, we checked for <onboard> and <matchbox-keyboard>.
**** GMOCCAPY INFO: Gcode.lang found ****
**** GMOCCAPY GETINIINFO **** 
Wrong entry [DISPLAY] CYCLE_TIME in INI File!
Will use gmoccapy default 150
**** GMOCCAPY INFO : inifile = /home/der/linuxcnc/configs/katinaki_12_probe/katinaki_12_probe.ini ****:
**** GMOCCAPY INFO : postgui halfile = postgui_call_list.hal ****:
Shutting down and cleaning up LinuxCNC...
Running HAL shutdown script
task: 227 cycles, min=0.000076, max=0.016383, avg=0.009195, 0 latency excursions (> 10x expected cycle time of 0.010000s)
hm2: loading Mesa HostMot2 driver version 0.15
hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
hm2_eth: 10.10.10.10: INFO: Hardware address (MAC): 00:60:1b:16:83:5c
hm2_eth: discovered 7I96S
hm2/hm2_7i96s.0: Low Level init 0.15
hm2/hm2_7i96s.0: Smart Serial Firmware Version 43
hm2/hm2_7i96s.0: 51 I/O Pins used:
hm2/hm2_7i96s.0:     IO Pin 000 (TB3-01): InM Input Module #0, pin in0 (Input)
hm2/hm2_7i96s.0:     IO Pin 001 (TB3-02): InM Input Module #0, pin in1 (Input)
hm2/hm2_7i96s.0:     IO Pin 002 (TB3-03): InM Input Module #0, pin in2 (Input)
hm2/hm2_7i96s.0:     IO Pin 003 (TB3-04): InM Input Module #0, pin in3 (Input)
hm2/hm2_7i96s.0:     IO Pin 004 (TB3-05): InM Input Module #0, pin in4 (Input)
hm2/hm2_7i96s.0:     IO Pin 005 (TB3-06): InM Input Module #0, pin in5 (Input)
hm2/hm2_7i96s.0:     IO Pin 006 (TB3-07): InM Input Module #0, pin in6 (Input)
hm2/hm2_7i96s.0:     IO Pin 007 (TB3-08): InM Input Module #0, pin in7 (Input)
hm2/hm2_7i96s.0:     IO Pin 008 (TB3-09): InM Input Module #0, pin in8 (Input)
hm2/hm2_7i96s.0:     IO Pin 009 (TB3-10): InM Input Module #0, pin in9 (Input)
hm2/hm2_7i96s.0:     IO Pin 010 (TB3-11): InM Input Module #0, pin in10 (Input)
hm2/hm2_7i96s.0:     IO Pin 011 (TB3-13/TB3-14): SSR #0, pin Out-00 (Output)
hm2/hm2_7i96s.0:     IO Pin 012 (TB3-15/TB3-16): SSR #0, pin Out-01 (Output)
hm2/hm2_7i96s.0:     IO Pin 013 (TB3-17/TB3-18): SSR #0, pin Out-02 (Output)
hm2/hm2_7i96s.0:     IO Pin 014 (TB3-19/TB3-20): SSR #0, pin Out-03 (Output)
hm2/hm2_7i96s.0:     IO Pin 015 (TB3-21/TB3-22): OutM Output Module #0, pin Out-04 (Output)
hm2/hm2_7i96s.0:     IO Pin 016 (TB3-23/TB3-24): OutM Output Module #0, pin Out-05 (Output)
hm2/hm2_7i96s.0:     IO Pin 017 (TB1-02/TB1-03): StepGen #0, pin Step (Output)
hm2/hm2_7i96s.0:     IO Pin 018 (TB1-04/TB1-05): StepGen #0, pin Direction (Output)
hm2/hm2_7i96s.0:     IO Pin 019 (TB1-08/TB1-09): StepGen #1, pin Step (Output)
hm2/hm2_7i96s.0:     IO Pin 020 (TB1-10/TB1-11): StepGen #1, pin Direction (Output)
hm2/hm2_7i96s.0:     IO Pin 021 (TB1-14/TB1-15): StepGen #2, pin Step (Output)
hm2/hm2_7i96s.0:     IO Pin 022 (TB1-16/TB1-17): StepGen #2, pin Direction (Output)
hm2/hm2_7i96s.0:     IO Pin 023 (TB1-20/TB1-21): StepGen #3, pin Step (Output)
hm2/hm2_7i96s.0:     IO Pin 024 (TB1-22-TB1-23): StepGen #3, pin Direction (Output)
hm2/hm2_7i96s.0:     IO Pin 025 (TB2-02/TB2-03): StepGen #4, pin Step (Output)
hm2/hm2_7i96s.0:     IO Pin 026 (TB2-04/TB2-05): StepGen #4, pin Direction (Output)
hm2/hm2_7i96s.0:     IO Pin 027 (TB2-07/TB2-08): Encoder #0, pin A (Input)
hm2/hm2_7i96s.0:     IO Pin 028 (TB2-10/TB2-11): Encoder #0, pin B (Input)
hm2/hm2_7i96s.0:     IO Pin 029 (TB2-13/TB2-14): Encoder #0, pin Index (Input)
hm2/hm2_7i96s.0:     IO Pin 030 (TB2-16/TB2-17): IOPort
hm2/hm2_7i96s.0:     IO Pin 031 (TB2-18/TB2-19): IOPort
hm2/hm2_7i96s.0:     IO Pin 032 (internal): IOPort
hm2/hm2_7i96s.0:     IO Pin 033 (internal): SSR #0, pin AC Ref (internal) (Output)
hm2/hm2_7i96s.0:     IO Pin 034 (P1-01): IOPort
hm2/hm2_7i96s.0:     IO Pin 035 (P1-02): IOPort
hm2/hm2_7i96s.0:     IO Pin 036 (P1-03): IOPort
hm2/hm2_7i96s.0:     IO Pin 037 (P1-04): IOPort
hm2/hm2_7i96s.0:     IO Pin 038 (P1-05): IOPort
hm2/hm2_7i96s.0:     IO Pin 039 (P1-06): IOPort
hm2/hm2_7i96s.0:     IO Pin 040 (P1-07): IOPort
hm2/hm2_7i96s.0:     IO Pin 041 (P1-08): IOPort
hm2/hm2_7i96s.0:     IO Pin 042 (P1-09): IOPort
hm2/hm2_7i96s.0:     IO Pin 043 (P1-11): IOPort
hm2/hm2_7i96s.0:     IO Pin 044 (P1-13): IOPort
hm2/hm2_7i96s.0:     IO Pin 045 (P1-15): IOPort
hm2/hm2_7i96s.0:     IO Pin 046 (P1-17): IOPort
hm2/hm2_7i96s.0:     IO Pin 047 (P1-19): IOPort
hm2/hm2_7i96s.0:     IO Pin 048 (P1-21): IOPort
hm2/hm2_7i96s.0:     IO Pin 049 (P1-23): IOPort
hm2/hm2_7i96s.0:     IO Pin 050 (P1-25): IOPort
hm2/hm2_7i96s.0: registered
hm2_eth: in hm2_eth_reset
hm2_eth: HostMot2 ethernet driver unloaded
hm2: unloading
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
/usr/bin/gmoccapy:312: GtkWarning: Invalid icon size 48

  self.widgets.window1.show()

(gmoccapy:4812): GtkSourceView-CRITICAL **: 16:28:35.685: gtk_source_language_manager_set_search_path: assertion 'lm->priv->ids == NULL' failed
postgui_call_list.hal:10: Pin 'iocontrol.0.tool-prepare' was already linked to signal 'tool-prepare-loopback'
4766
4808
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

---

Info report created by linuxcnc_info:
The file:    /tmp/linuxcnc_info.txt

Hi,

Lately I am having some issues with my parallel port configuration and decided to switch to a Mesa 7i96s.  Since I do not have a lot of experience with hardware of this kind, I have some questions/doubts before proceeding:

- By switching from Parallel to 7i96s I will also eliminate the breakout board that came with the machine, as well as the wiring from BB to stepper motor drivers.  I do not know which cables are recommended for connecting the 7i96s to the stepper drivers.  Would a twisted pair cat 6E cable be OK for that?
- Currently the wiring from my machine to the stepper motor drivers has all the step+ and dir+ of all axis wired together (breakout board only has step and dir, no step+ step- and dir+ dir-).  I guess with the 7i96s I should connect all step+, step- and dir+ dir- to the equally named pins on the stepper motor drivers separately?  (not joining all the + ones)
- The BB on this machine only has one Yaxis output that connnects to both Y axis drivers (this is a gantry machine).  Should I do the same with my mesa card or use a separate Y1 and Y2 output to each of the drivers?

Thanks in advance

Geert

7 - IO QUANTITY & TYPE

Once the command signal type is determined, the next step is to make a list of all inputs & outputs (IO) required or desired.  Include all sensors, switches, buttons, relays, etc.; all hardware which needs to signal or be triggered by LCNC should be on the list.
      
    • Inputs to LCNC
        ◦ Voltage supplied (or required) by component
        ◦ Current/amps consumed/supplied by component
        ◦ Analog inputs?  i.e. potentiometer, pressure transducer, etc.
    • Outputs from LCNC
        ◦ Does the component sink or source voltage? Or either?
        ◦ What voltage?
        ◦ Current/amps consumed/supplied by component

Are there lots of IO or just a few?  Are most of the IO for an operator control panel, or lots of relays to drive auxiliary functions (coolant pumps, lube pumps, lights, air cylinder valves, etc.)?  Do your drives require an enable signal?

Note that many newer, but not all, Mesa cards can be configured for both sinking and sourcing inputs & outputs.

Answering the questions above will help you form an idea of how many and what type of IO you need.

ADDITIONAL CONSIDERATIONS
Beyond axis drive command signals and general IO, you should consider the following questions:
    • Spindle - how do you plan to control the spindle(s)?
        ◦ On/off relays with manual speed control?
        ◦ 0-10v speed control?
        ◦ PWM?
        ◦ Analog or Step-dir servo?
    • Encoders - do you plan to add linear encoders for closed-loop feedback to LCNC?
        ◦ Do you have 'dumb' analog servo drives and LCNC will close the loop?
        ◦ Do you need/want a spindle encoder?
    • Operator console - do you plan to add/build a feature-rich (i.e. complicated) operator station with physical controls?  These can eat up IO quickly with lots of buttons, switches, and lights
    • Plasma - not specifically detailed in this guide, but the THCAD series of frequency to voltage cards are widely used for plasma arc sensing.  Additional research on which FPGA cards are most recommended for use with the THCAD would be prudent.
    • Expansion - do you think you might want any/all of the above in the future? Some Mesa FPGA cards are more expandable than others, depending on what it is you want to add in the future.

 

As promised, confirmed as working with 6 Axes on ESP32 at full 200khz.
24 hour torture and stability testing has been done.

Please read the readme carefully.

Be warned - the ESP32 GPIO is only technically 3.3v compliant so you may need level shifters depending on your application or use-case.

Although, that said, external Stepper motor or closed loop stepper servo drivers usually sink so little current across their EN,Step and DIR pins it isn't a major cause for concern - at least based on my testing here but your milage may vary. You have been warned at least.

Designing a low cost custom PCB with a $5 ESP32 WROOM or WROVER stamp and a LAN8720 Phy would be straightforward - there are plenty of reference designs out there. See Olimex github for a good example.

Just be sure to wire up your GPIOs and any level shifters or isolators accordingly.

Using a WT32-ETH01 module and a custom carrier board would work fine - just be aware of the IO limitations and map out your step and dir pins properly to ensure the RMT peripheral works (test it before designing your board).
Extending the firmware to use a I2S or I2C GPIO mux for other inputs and outputs would be recommended. There are plenty of ESP32 Arduino libs for this.
The software foundation is in place at least.

Adding hardware based high speed Servo Encoder pulse feedback via the Pulse Counter Peripheral hardware is also possible and can use existing Arduino ESP32 libraries for this. The stepper generator does not use the Pulse Counter Peripheral for this reason and future potential.

The firmware has been purposefully based on Arduino libraries and not native esp-idf to make it easier for everyone to extend/adapt to their own use-case. It's been designed and optimised heavily to be as extensible as possible by leaving a CPU core spare to do other tasks.

Project is based on the original HAL2UDP concept by Juhász Zoltán. Thanks goes to him and anyone else who helped contribute to the original project.

github.com/wezhunter/ESP32_LinuxCNC_MotionController_RealTime

Have fun
 

My personal experience thus far is that it is an awful process. I tune them to the same parameters since the JL/JM inertia estimation is almost identical.

Process (roughly):
-Movement only through linuxcnc as two joints on one axis (Gantry mode)
-Using a notebook with asda tuning software, connect to one drive via usb
(A) -Move the axis using linuxcnc and check following error
-determine adjustment and edit servo 1, then switch over to servo 2 and perform identical adjustment
Repeat from (A)

Two notebooks are advisable, as you well spent a lot of time fiddling with the serial cables and reconnecting.

Glad the Delta drives are working well for you, that's a good data point as their manuals and software seem good (like Beckhoff).

Has anyone tried a gantry where a pair of servos are needed to move one axis, I have read manuals for three mfg. so far and they all suggest an 'automatic' method where the drive software moves the motor to figure out the inertia and resonance...

For a dual motor gantry I think they would need some sort of coordinated scheme where (somehow) both motors move in sync. In no manual have I found anything like that at all. Yes there are the two axis and three axis controllers but I've not seen dual motor on one axis mentioned. Maybe there is some trick for tuning one motor at a time.