Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Photo

Labview control of many steppers


  • Please log in to reply
10 replies to this topic

#1 kevinmh

kevinmh
  • Members
  • 6 posts

Posted 08 July 2013 - 01:02 PM

Hello!

I'm a master's student at Colorado State University and I'm beginning a project that will ultimately involve controlling at least 9 stepper motors independently and concurrently. I think we will only be able to afford to go the route where I buy the stepper motor drivers and motors myself and control them ultimately from Labview, which we already have a license for. (I have coded here and there in school, but haven't really put significant time into any language-hence the Labview control.) I'm looking into controlling them from a daq card. It seems that the cheapest route would be to buy multiple 4-axis drivers and control them through cards. So, I'll be controlling at least 3 of these drivers with this architecture.

I'm just wondering if anyone here has tried to control this many motors with labjacks. Was it necessary to use multiple cards? Were they run in parallel from multiple USB ports on the PC, or was some daisychaining needed (or possible)? Will labview be able to handle "parallel serial" control? On NI forums there seems to be an issue with not being able to achieve the needed timing through software, so they recommend using the timing on the card. What would that look like? Is there a better (but still cheap) control architecture, given my intents and limitations?

Thanks,

Kevin

#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 08 July 2013 - 03:59 PM

If you use stepper motor controllers, you typically just set a direction input high/low and then toggle a step input to move the motor 1 step. That would mean you need 18 digital outputs, which the U3-LV has. As for "independently and concurrently", you will have to provide more detail about what exact control you need and how fast you need it. From Section 3.1 of the U3 User's Guide, you can see that you can update the state of all digital outputs in as fast as <1ms.

#3 kevinmh

kevinmh
  • Members
  • 6 posts

Posted 15 July 2013 - 05:21 PM

Thanks for the reply!

 

So, the motion does not need to be fast.  Basically, you could think of the motion of the motors as controlling a filament winder with multiple payout eyes, if you are familiar with with this manufacturing process. And, this is a proof of concept design, that would need to be able to be sped up as much as possible if it went into production, but, ultimately, that's not what I'm doing.  The gist of it that I need the motion to be highly coordinated, so that I can tightly control the patterns that are created, and, I'm kind of guessing here, maybe max 1 rev/second. This seems approximately like what it seems like 3.1 is saying the U3 can do. So, that's with the USB2 hub? 

 

So, 'independently' because I need to be able to coordinate disparate motors by controlling each one and coordinating the motion in my code, and 'concurrently' meaning that it would be nice, perhaps even necessary, to move them all at once.  If they moved quickly enough it might be OK to move each one sequnetially, but, honestly, I'm just waiting on a reply from my advisor to be able to say for certain if 'sequential' motion was acceptable.

 

Thanks again,

 

Kevin



#4 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 16 July 2013 - 11:01 AM

The USB2 (or better) translates from full-speed (U3 USB) to high-speed and appears to make the USB host more efficient.  With the proper connection, you can update 1 or all digital outputs in about 600us, so you can see that in that realm of speed you can control lots of outputs at the same time.



#5 kevinmh

kevinmh
  • Members
  • 6 posts

Posted 16 July 2013 - 04:40 PM

Thanks, Admin.

 

Do you know any more about this counter/timing issue that I've seen?  It has something to do with poor software timing and the ability to use the counter to somehow send out a more tightly timed pulse train.  I'm mostly not clear on how to use the counter to clean up my software pulse train.  Or, is that only an issue with sychronous control? If I were sequentially microstepping various motors, as long as my high was high long enough and my low was low long enough to be able to step the drive to move each motor sequentially, would it not matter? Or, would those minimum values be part of the problem people try to overcome with a counter?



#6 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 17 July 2013 - 11:21 AM

I'm not sure what you are talking about.  Are you having some timer/counter problem with the U3?



#7 kevinmh

kevinmh
  • Members
  • 6 posts

Posted 18 July 2013 - 04:05 PM

Sorry if I'm being confusing, Admin.

 

I haven't bought anything yet.  I'm just trying to get an idea of what this issue is about and how to deal with it before I do purchase anything.  The first four posts of the following thread hopefully give an indication of what I'm talking about:

 

https://forums.ni.co...ight/true#M8809



#8 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 18 July 2013 - 04:24 PM

Those posts seem to relate to a problem someone might have with general motor control applications if software control is not sufficient.  As noted, the U3 can updated any/all digital outputs in about 600us, so if that sort of speed is sufficient then you are likely good.



#9 kevinmh

kevinmh
  • Members
  • 6 posts

Posted 20 July 2013 - 01:04 PM

Sure.  Updating the DOs quickly seems important.  But the issue as I see it is:

 

1) Software timing of a pulse train to a step/direction motor controller/driver can be deficient in that, even if the DOs are switched infinitely rapidly, not being able to control the timing of the pulses can be a problem. As an exaggerated example, you want a pulse every second, but your software outputs a pulse, then outputs a pulse two seconds later, then one 0.5 seconds later, then 1.2 seconds later, etc.

 

2) That deficiency is addressed by using 'hardware timing' generated by the use of a counter output in a DAQ card.

 

3) Apparently some models of NI DAQ cards can give you this counter output, thereby addressing the initial deficiency of poor timing in the pulse train. Apparently, you end up with a pulse much closer to every second, as I initally wanted in my example above.

 

So, I just wanted to confirm that I would be able to also do address this software timing deficiency with a LabJack, and, in order to feel more certain that this was possible, at a minimum, some very breif indication of how this was actually accomplished.

 

Or, do you think I've completely missed the point of the problem that forum referred to?

 

Thanks again.



#10 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 22 July 2013 - 11:04 AM

My point is that what what you describe can be a problem in general, but not with the example you give.  If you are toggling i/o ever 1 s, you should have no problem designing software that does that with acceptable jitter.  If however you are trying to toggle i/o every 1 ms, you can likely expect jitter of the same order.

 

The exact level of jitter in software control depends on lots of things, but I would say that with care you can keep it under 10ms, so perhaps that suggests that 10Hz control is about the limit.

 

The U3 has a couple timers to output pulses with hardware timing, but only 2 so not helpful for you with 9+ steppers.



#11 kevinmh

kevinmh
  • Members
  • 6 posts

Posted 24 July 2013 - 04:26 PM

OK.  I see what you mean. 

 

The pulse frequency I gave was meant to be arbitrary, but perhaps I should have given a more realistic example. Thanks for running with it anyway.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users