Controlling 2 independent Stepper motors with variable speed and direction using U3 and Labview

To really be independent you might need 2 U3s, but generally based on your description I think trying it with 1 U3 is worth a shot.

To create your output waveforms you will use 2 timers where each is in 1 or 3 modes:  PWM 16, PWM 8, or Frequency Output.  The key limitation with 1 U3 is that all timers use the same clock source so you are limited in the difference in frequency you can get from 2 different timers.  Knowing that TimerClockDivisor and TimerClockBase will be the same for both timers, and only TimerValue can be different, look at the frequency formulas for those 3 modes and you will see the limited options.

As for tracking the number of steps, you can use the 2 counters on the U3 to count the pulses from each timer (jumper each timer output to a counter input), but the counters will not track direction ... they will simply increment by 1 for each timer pulse.

"from what i saw in other posts, its not easy to change PWM frequency without stopping the timer and starting again. is that right?"

That is correct. The U3 has one clock that is used to drive both timers. That means that the frequencies of the the two are linked. In the case of PWM one can be on 16-bit and the other on 8-bit, in which case the 16-bit timer will run at 1/256th of the 8-bit timer's frequency. The other option is the frequency output mode. Frequency output mode still depends on the main clock, but has more variability. Here's a like to some more details: https://labjack.com/support/datasheets/u3/hardware-description/timers-co...

The timer stop featureis a timer mode, so it will use one of the two timers available on the U3. When enabled, timer-stop will turn off the other timer after a specified number of pulses. This can be very useful when you want to send a specific number of pulses to a stepper controller.

Have you seen our labview example archive: https://labjack.com/support/software/examples/ud/labview

Can I use two Frequency outputs independently or will it be the same issue as two PWMs?

From Sections 2.9.1.1, 2.9.1.2, and 2.9.1.7, here are the formulas for frequency:

Hz (PWM16) = (TimerClockBase/TimerClockDivisor) / (2*16)
Hz (PWM8) = (TimerClockBase/TimerClockDivisor) / (2*8)
Hz (Frequency Output) = (TimerClockBase/TimerClockDivisor) / (2*Timer#Value)

1.  As they all are based on the same TimerClockBase and TimerClockDivisor, they are are linked to some extent.

2. Changing TimerClockBase or TimerClockDivisor requires re-configuring the whole timer system and thus is not necessarily super smooth.  Changing Timer#Value can be done much more smoothly ... for example with eTCValues.

So probably about the best you can do with 1 U3 is to use 2 timers in Frequency Output mode, set TimerClockBase and TimerClockDivisor to provide the range of frequency you want and never change them, and then just use Timer#Value to set each timer to one of 256 frequency options at any time.

Finally, if you could suggest:  If i forgo the HW timed option and go for the I/O output (i know this is software timed), what do you think the fastest rate of pulses I can send out of two I/O?

Figure it takes about 1 ms per packet you send to the U3.  That packet could set the state of multiple I/O, it could set them to one state and then change them to another (make a pulse), and it could even contain a whole bunch of updates with WAITs in between.  See "Software Timing ..." and "WAIT Technique ..." here:

https://labjack.com/support/app-notes/waveform-generation

A typical example would be to send a packet such as:

FIO0=0
WAIT=5000
FIO0=1
WAIT=5000
FIO0=0
WAIT=5000
FIO0=1

This would take roughly 500us to get the packet from your software to the U3.  Then in the U3 it would set FIO0 to output-low, wait 5ms, set FIO0 to output-high, wait 5ms, set FIO0 to output-low, wait 5ms, and finally set FIO0 to output-high.  Then it would take about 500us for the response (e.g. no error) to go from the U3 back to your software.

I'm not sure this feature will help you but something to consider if you are looking at software control.

1.  No, the U3 can only process 1 command-response at a time.  It must send out the response before it will handle another command.

2.  You want to use the add-go-get technique described in Section 4.1 of the U3 User's Guide.  See "U3 Multiple IO Example.vi" or "U3 Single Pulse Bit Ouput (no-timer).vi".

Hello. I'm trying to figure out the maximum rate that I could successfully send digital 3.3V pulses to a stepper motor, and I've already looked at the waveform generation page and several others. Having looked at section 5.2.5 of the U3 User's guide (U3/U6) regarding feedback packets, I am still unsure how many bytes would be used by the packet suggested above by LabJack support:

"FIO0=0
WAIT=5000
FIO0=1
WAIT=5000
FIO0=0
WAIT=5000
FIO0=1"

Can someone please help me understand how many bytes each of these commands requires based on 5.2.5 and how many bytes would be required for the response? My hope is that understanding this will help me understand how many commands I can fit into a single packet, which will tell me how many pulses I can send per unit time based on how long it takes to send, execute, and return each packet.

Any help would be appreciated.

For efficiency and when setting one digital I/O line, use the UD IOType LJ_ioPUT_DIGITAL_BIT to set FIO0 and LJ_ioPUT_WAIT to set the WAIT delay. If you need to set more than 2 digital lines at the same time use LJ_ioPUT_DIGITAL_PORT as it will use less bytes then 2+ LJ_ioPUT_DIGITAL_BITs in most cases.


These UD IOTypes will build a low-level Feedback command with a max. size of 64-bytes. Feedback is documented here (5.2.5):

https://labjack.com/support/datasheets/u3/low-level-function-reference/f...

The base Feedback command is 7 bytes. The following is how the UD IOTypes map to low-level IOTypes and their command data bytes:

LJ_ioPUT_DIGITAL_BIT = 4-bytes:
    BitDirWrite = 2-bytes
    BitStateWrite = 2-bytes

LJ_ioPUT_WAIT = 2- or 4-bytes:
    WaitLong = 2-bytes
    WaitShort = 2-bytes
    Notes: WaitLong is used when: microseconds / 16384 > 0
           WaitShort is used when: (microseconds % 16384) / 128 > 0
           Integer division is used.

LJ_ioPUT_DIGITAL_PORT = 7- or 14-bytes
    PortDirWrite = 7-bytes
    PortStateRead = 7-bytes
    Note: PortDirWrite is conditionally used when the UD driver detects a change in direction (input to output).

For example:

AddRequest: LJ_ioPUT_DIGITAL_BIT=0 (4-bytes)
AddRequest: LJ_ioPUT_WAIT=5000 (2-bytes)
AddRequest: LJ_ioPUT_DIGITAL_BIT=1 (4-bytes)
AddRequest: LJ_ioPUT_WAIT=5000 (2-bytes)
AddRequest: LJ_ioPUT_DIGITAL_BIT=0 (4-bytes)
AddRequest: LJ_ioPUT_WAIT=5000 (2-bytes)
AddRequest: LJ_ioPUT_DIGITAL_BIT=1 (4-bytes)
Go

Would be a 29-byte command Feedback command (7 + 22), and the driver would add an extra dummy byte to the end to make it size 30-bytes since commands need to be an even number in size.

Support,

I see now that hardware timing is the way that I want to go. This leaves me with the following question: I am using LabVIEW 2015, and the Frequency Output mode and Stop Timer mode on Timer0 and Timer1, respectively to execute a pre-defined number of steps. How then, can I use a limit switch or prox sensor to interrupt the process before the specified number of steps has occurred (without an irreversible shut down of power)?  

What I mean is this: Ideally, the switch would be wired to some input so that it could sometimes stop all motion with minimal software delays, and in other cases simply be a way that the program can check that the motor is in fact in the right position (i.e. is at the limit switch position) before beginning motion. Is there any way to do this? I'm imagining use of a Stop Timer mode that waits for a single pulse from the limit switch, and then in other scenarios is reconfigured to be a simple digital input. The problem I see with this is that I am already using both my Timer0 (in Freq. output) and Timer1 (in Stop Timer mode to count pulses sent out by the timer), and can't use Timer1 for more than one thing at the same time. Does this make sense?

I appreciate your help,

Johnathan

All I can think of is to have software poll the state of the switch so you can make your desired decision.  That means perhaps 1 ms to poll the switch and then at the limit another 1 ms to tell the U3 to stop pulsing.

On the T7 you could have this in a script that should be able to do this simple feedback much faster than the 2 ms loop above.

Thank you LabJack Support. Yes, I was hoping to avoid slowing down the process with polling every iteration, but I think the additional 2 ms is tolerable. I have a couple more questions for this stepper motor application:

1. If I am running two stepper motors at different (and varying) rates, AND I want to count the # of steps with Stop Timer mode, am I correct in thinking I would need two U3s to do this? i.e. Is there no other way to accurately control # of steps that doesn't consume both timers for one motor?
2. Is it possible to output pulses with Timer0, use Stop Timer mode with Timer1, AND still use the Stream Mode to read other digital or analog input signals at the same time with one U3? I just noticed that eTCConfig() seems to be used in both scenarios.
3. Maybe this is silly, but it doesn't seem obvious to me from what I've found online so far: eTCConfig(), when configured in PWM16 or Frequency Output modes for example, actually initiates pulses from the U3, right? Or are they initiated from eTCValues()?

Thank you again,

Johnathan

Never mind Question 3; it is clear to me now that eTCConfig() does, in fact, initiate the pulses, whereas eTCValues() only reads them. My first two questions remain, however.

1.  Yes, 2 devices is about the only way to get different pulse rates, and for sure the only way to use 2 stop timers.

2.  Yes, that sounds fine.  I can't think of a problem with what you describe.

3.  Correct.  eTCConfig does initiate the pulses assuming you pass values that would cause pulses to occur.