Digital I/O
Drive Stepper Using Digital output with Pulse sequence
Hello scuzzy,
Based on the information you provided I took a look at your example and made some minor changes that should get you what you're looking for. The example is written to operate 2 motors on channels 0 through 3 and 4 through 7, but you should be able to add more motors pretty easily by duplicating the outlined code. There are notes in the Block Diagram which describe the functionality of each step and I have posted an image of the Block Diagram for easier viewing. Let me know if you have any questions about the example.
Message Edited by Matt A on 04-07-2008 10:12 AM
Based on the information you provided I took a look at your example and made some minor changes that should get you what you're looking for. The example is written to operate 2 motors on channels 0 through 3 and 4 through 7, but you should be able to add more motors pretty easily by duplicating the outlined code. There are notes in the Block Diagram which describe the functionality of each step and I have posted an image of the Block Diagram for easier viewing. Let me know if you have any questions about the example.
Message Edited by Matt A on 04-07-2008 10:12 AM
Hello scuzzy,
I apologize if I was a little unclear in my first post, I probably should have posted the front panel as well. I have attached the image below so you can see the controls I am using. There you will see that the "Ports for Motors" control is actually an array of Physical Channels where each element in the array represents the lines required for one motor. In my example, I have selected port0/line0:3 for the first element in the array (motor 1) and port0/line4:7 for the second element in the array (motor 2). I selected the array option to allow for scalability and because the ability to index this array allows me to associate a particular grouping of lines with an array element, which I can later use to index my motors (allowing me to say motor 1, motor 2, etc).
I would point out some additional features in the VI I posted as well:
1. I would note that (as shown in the image in my first post) both of the DAQmx Write VIs are in the same loop, so the Rate (Hz) control will apply to both of them. That is to say, that both motors will be updated at the same time, so they will both be running at the same rate. However, they do have separate direction controls because the booleans can be independently configured to move clockwise or counter-clockwise. If you wanted to control the motors independently, you would need to put each of the sections of highlighted code into a separate while loop, similar to the image below.
2. The PCI-6509 provides software timed digital operations, which means that the ability to control the timing of the updates depends on how fast your operating system can run the LabVIEW code. In most Windows based environments, the best resolution you can attain is on the order of milliseconds up to tens of milliseconds. That means that if you tell LabVIEW to wait one millisecond between iterations of the while loop (1/1 msec=100 kHz update rate) that Windows could execute that code in intervals of anywhere between 1 millisecond and 10 milliseconds. Unfortunately, this is a limitation of the way that Windows handles different programs and distributes control. For example, opening an internet browser while your program was running would force Windows to allocate resources to that program, which would take resources away from LabVIEW and slow the execution. If you need to be able to control the update rate with better precision than this, you would like need to move to a Real-Time deployment environment or consider a device with hardware timed digital operations (like our M Series devices).
3. To address your question about "separating" lines, I would point out that you can simply create different digital tasks which contain the different lines you want to use. I have done this above in my example which uses line0:3 and line4:7 of port0 separately. One potential problem with this option is that you can have multiple tasks running at the same time which are attempting to access the same hardware. For example, when you use the DAQmx Start Task to run a task, that will block any other task from accessing that port either as an input or an output. However, since you are performing software timed updates and only access the hardware with a single set of a data at a time, you don't actually need to have the task running. As you can see in my example, I simply use the DAQmx Write to update the data. I never explicitly start and stop my task because the DAQmx Write will implicitly start and stop the task to write the data.
I hope this information helps to address your questions. Feel free to post back if you have anything else.
Message Edited by Matt A on 04-10-2008 04:41 PM
I apologize if I was a little unclear in my first post, I probably should have posted the front panel as well. I have attached the image below so you can see the controls I am using. There you will see that the "Ports for Motors" control is actually an array of Physical Channels where each element in the array represents the lines required for one motor. In my example, I have selected port0/line0:3 for the first element in the array (motor 1) and port0/line4:7 for the second element in the array (motor 2). I selected the array option to allow for scalability and because the ability to index this array allows me to associate a particular grouping of lines with an array element, which I can later use to index my motors (allowing me to say motor 1, motor 2, etc).
I would point out some additional features in the VI I posted as well:
1. I would note that (as shown in the image in my first post) both of the DAQmx Write VIs are in the same loop, so the Rate (Hz) control will apply to both of them. That is to say, that both motors will be updated at the same time, so they will both be running at the same rate. However, they do have separate direction controls because the booleans can be independently configured to move clockwise or counter-clockwise. If you wanted to control the motors independently, you would need to put each of the sections of highlighted code into a separate while loop, similar to the image below.
2. The PCI-6509 provides software timed digital operations, which means that the ability to control the timing of the updates depends on how fast your operating system can run the LabVIEW code. In most Windows based environments, the best resolution you can attain is on the order of milliseconds up to tens of milliseconds. That means that if you tell LabVIEW to wait one millisecond between iterations of the while loop (1/1 msec=100 kHz update rate) that Windows could execute that code in intervals of anywhere between 1 millisecond and 10 milliseconds. Unfortunately, this is a limitation of the way that Windows handles different programs and distributes control. For example, opening an internet browser while your program was running would force Windows to allocate resources to that program, which would take resources away from LabVIEW and slow the execution. If you need to be able to control the update rate with better precision than this, you would like need to move to a Real-Time deployment environment or consider a device with hardware timed digital operations (like our M Series devices).
3. To address your question about "separating" lines, I would point out that you can simply create different digital tasks which contain the different lines you want to use. I have done this above in my example which uses line0:3 and line4:7 of port0 separately. One potential problem with this option is that you can have multiple tasks running at the same time which are attempting to access the same hardware. For example, when you use the DAQmx Start Task to run a task, that will block any other task from accessing that port either as an input or an output. However, since you are performing software timed updates and only access the hardware with a single set of a data at a time, you don't actually need to have the task running. As you can see in my example, I simply use the DAQmx Write to update the data. I never explicitly start and stop my task because the DAQmx Write will implicitly start and stop the task to write the data.
I hope this information helps to address your questions. Feel free to post back if you have anything else.
Message Edited by Matt A on 04-10-2008 04:41 PM
